One of the biggest wars in today’s software development
community is the choice to use Microsoft Project Plan. In a traditional plan
driven approach, the value of Microsoft project plan to know the higher-level
milestones, traceability of hammock, resource leveling, earned value, project and
resource calendar, unit of work, impact of delay, critical chain versus
critical path, network analysis, early/late start/finish, lead/lag discussions,
and multi-project/program dependency are all very well understood.
But, when you turn the attention to agile, the story shifts!
Agile focuses fundamentally on self-organized teams that manage their own tasks
who are empowered to try different approaches. This is one of the reasons why
the Scrum methodology doesn’t even mention a project manager role but only the
scrum master role and product owner roles. But, in a truly agile environment, or
a matured scrum practice, the team is almost on an autopilot! The only two
needs for the team are to get clear direction and business need on what
features to develop (product owner) and the support to keep deviations minimum
to work on the delivery (scrum master).
But how often are the teams so self-reliant that they think
of the feature outside of their business unit on the delivery? When
the team is depending on the other leaders to drive this priority, interface
with the product development to provide the clear direction (business need and
business impact) among other things, the project manager role emerges again. If this need exists, then, what’s the
question behind the MS Project in agile methodology?
Let us think from agility. The goal of Agility is to focus on
burn rate and velocity. These are good key performance indicators (KPI) in agile world in a product
development setting. For instance, if we have 500 story point worth of user
stories with each sprint taking up ~50 stories over 2 weeks, then, at the end
of 10 iterations (discounting the hardening iteration), we expect all features
to be completed. Now, say at the end of third sprint (6 weeks have gone), you
are at 120 story points. We use the velocity to look for patterns in what types
of commitment can be delivered by this agile team or the burn rate to project
when the project can be delivered. The project managers that understand the earned value management (EVM) principles can utilize planned value, earned value, and actual cost to analyze patterns. Properly utilized, these values can come directly out of the Microsoft Project Plan even in the absence of a Project Management Information System (PMIS).
If the individual iterations are a major milestone with
additional hammock activities focusing on specific user stories, then, the
Microsoft Project can still be a value-added tool for the project manager to
use in an agile setting. In such cases, if required, the Project Manager can
still limit the focus only to the user story level tracking and should the user
story become a showstopper (DONE criteria not going to be met), then, it is
possible to move this story to subsequent release. Using MS Project, commitment
planning can be forecasted better. Using project reports and earned value techniques, one can do similar analysis as velocity tracking and burn rate!
At the same time, think about the transparency of work required not at the team level but at the organizational level. If every team starts using their own tool, then, how do we tell the full story to the program and portfolio management, business units, and to the senior executives? This is where the use of a good integrated application lifecycle management tool comes, such as SpiraTeam, very handy (Rajagopalan, 2012). As the Vice President of Program Management Office with many different projects and programs, even though Microsoft Project, Jira, and OnTime were used originally, we found more value in replacing it with SpiraTeam (Inflectra, n.d) that supported almost all the needs of single source of truth (SST) while reducing the total cost of ownership (TCO) further. The incremental updates we have seen in SpiraTeam based on some of our recommendations and the support we have received seem to emphasize our right choice of investing in the ALM tool rather than work with a myriad of tools and spend time in using data in the backend to discover patterns.
The tool is only a means to accomplishing the work. If simple Excel or white board can be used for Agile tracking, then, to discard such a power-loaded tool as a non-agile tool is a premature exclusion of the tool without considering its benefits. The winds are changing on how the tools have emerged and so it is also time to change the sails. Otherwise, the winds will alter the course of our voyage.
Thoughts?
References
Inflectra (n.d.). SpiraTeam. Retrieved from https://www.inflectra.com/Products/SpiraTeam/
Rajagopalan, S. (2012). Leading Change: Remote Teams can collocate on the right ALM tools. Retrieved from https://agilesriram.blogspot.com/2012/04/leading-change-remote-teams-can.html
