Monday, March 30, 2015
Value of Microsoft Project Schedule in Agile Environment
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.