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 true agile environment, or
a matured scrum practice, the team is almost on an auto-pilot! The only two
needs for the team are to get the 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 as a whole 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 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 show stopper (DONE criteria not going to be met), then, it is
possible to move this story to subsequent release. Using MS Project, still commitment
planning can be forecasted better. Using project reports and earned value techniques, one can do similar analysis as velocity tracking and burn rate!
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.
Thoughts?
