In Introduction to Agile Project Management Part 1 and Part 2, we explored the concept of a Project Plan, how to produce it and the role of the Agile Project Manager (APM). In our final installment, we put it all together and delve into managing the Project Plan.
Managing the Project Plan
One of the best things about Scrum is that we get actual information about actual development every Sprint. This information is what allows us to manage the Project Plan; this information allows us to do actual Project Management. We Manage (Maintain/Update/Re-Baseline) the Project Plan based on what is actually happening; we do not manage the People in order to make the Plan come true. This is what we’re supposed to do… this is one of the fundamental maxims of Project Management… Project Management is supposed to be an inherently agile process — just ask any PMP.
So, what do we do?
It’s actually relatively simple. At the end of each Sprint the APM follows a few simple (straightforward, but not necessarily easy) steps.
1. Collect Information
At the end of each Sprint, the Team does a Product Review with Stakeholders. After they conduct this Product Review, the Team’s Product Owner should meet with the Agile Project Manager, and give him or her the following information:
- The number of Hours that were spent by the Team in this Sprint, on Stories that were part of this Project. This should include all hours actually expended by the Team, whether or not the Team Members were paid for them, whether or not the Client was charged for them, whether or not they were ‘on the clock’, whatever…
- The number of Points that were earned by the Team in this Sprint, on Stories that were part of this Project. This includes all the Points for all the Stories (that were ‘chargeable’ to the Project) that got to Done in the Sprint; that is, all the completed Stories that helped develop, support, or deliver the Scope of the Project.
- Any change in the Size (in Points) of the expected Scope for the Project. While the first two bits of information are objectively determined, this one could be subjective.
I note that the Team must not give the APM inaccurate information. It is the APM’s responsibility to figure out what to do with the information; and it is the Team’s responsibility to be Value-Driven and give the APM the best (and most accurate) information it can.
2. Conduct Variability Analysis
The APM now does Variability Analysis based on this information; it needs to be determined if any of the Planning Assumptions need to be re-baselined. While any or all them could be affected, the APM must pay particular attention to determine if the new information forces a re-baselining of ProdRate, since this is the one Planning Assumption the APM has little (or no) control over.
There are many techniques for Variability Analysis, from ‘seat of the pants’ estimations to Earned Value Metrics to sophisticated statistical methods. In my opinion, it really doesn’t matter, since the APM is accountable to explain why (or why not) the Planning Assumptions are being re-baselined. He or she must use a method that is acceptable to his or her Stakeholders, so I treat this as a self-organization issue.
What you want is for the data to indicate that your plan is going well. Sometimes the data is kind and indicates that things are ok, and sometimes are even better than you planned! Often, however, the data is unkind, and tells you that either the ProdRate or BurnRate (or both) is too low, or there is excessive required Scope, or something.
No Matter what the data tells you, the re-baselining is important, as the new Planning Assumption baselines should be used as input for future Project Plans. In particular, if the data is telling the APM bad things, the APM must not lie to himself, he or she must re-baseline!
If the new, re-baselined, Planning Assumptions show that the Plan is in trouble, the Agile Project Manager has some decisions to make…
3. Make a Decision About What to Do…
If the Planning Assumptions change, the APM needs to decide whether or not to change the Project Plan (Cost, Scope, and Schedule). This is not automatic, and here are some of the options to APM might try if the new baselines show that the Plan is in trouble. To be specific, these are options to use if the Team’s ProdRate is not as high as it ‘should’ be:
- The APM may require the Team to work extra uncompensated hours to increase the BurnRate, which gives the impression (to people outside the Team) that the ProdRate has been increased. This may work in the short run, but will invariably lead the team to working at an unSustainable Pace in the long run. In any case, the APM may not lie to him- or herself about the fact that the ProdRate has not actually increased; in fact, because of the unSustainable Pace, it has probably actually decreased.
- The APM may try to improve the ProdRate by giving the Team some training, or improving the development environment, or something. This is laudable, but must be done early because the time spent on the training or improvements is time not spent on the actual Project goals. In effect, the Scope of the Project has been increased by adding Items for training, learning new tools, and so on…
- The APM may try to decrease the size of the Scope, either by actually decreasing Scope or by taking advantage of a new Framework or off-the-shelf solution. This is a reasonable thing to try, but keep in mind that the Stakeholders may not be pleased by the results.
- The APM may try to increase the ProdRate by simplifying the Definition of Done (DoD). In essence, the APM is trading an increase in Technical Debt for an increase in speed. This may work in the short run, but the UnDone work that piles up will eventually need to be Done. In Essence, the APM is pushing the Scope to clean up the UnDone work into future Projects or Releases.
Now, all of these options, and lots of others I haven’t mentioned, could be reasonable from the APM’s perspective. The only good thing about them, from the Team’s perspective, is that the APM is accountable for the results and for explaining why he/she thinks they might work.
Or, of course, the Agile Project Manager could just change the Project Plan to be in sync with the new, re-baselined ProdRate…
4. Modify the Project Plan, if necessary
If the option is to change the Project Plan, the APM must modify the Project’s Cost, Scope, and Schedule in order to match the new ProdRate. This is actually pretty straightforward, and is based on the following two equations:
1) Scope (in Points) = ProdRate (in Points/Hour) x Cost (in Hours), and
2) Cost (in Hours) = Schedule (number of Sprints) x BurnRate (in Hours/Sprint)
Since ProdRate is fixed, the first thing to do is use equation 1) to balance Scope and Cost. Now, since changing Scope will force a change in the Backlog to match the new, changed Scope, it will be easier to change Cost. This does not mean that Scope shouldn’t be changed, just that it will be easier to change Cost.
Once the APM has balanced Scope and Cost, he uses equation 2) to balance Schedule versus BurnRate. It is probably risky to try to increase BurnRate very much from what the data shows its baseline should be, since that could put the Team at an unSustainable Pace, or have an effect on other work the Team is trying to do. Again, not to say that you shouldn’t change BurnRate; but it is easier to change Schedule.
The APM will probably need some help with this work, especially if there is a change in Scope — thus requiring an update of the Backlog. That is why I recommend that the APM be a member of a Management Scrum Team that has the right people with the right skills needed to do this work (but that’s another story)…
And, finally, the Agile Project Manager must make sure that all the appropriate Stakeholders know about the new Project Plan and re-baselined Planning Assumptions…
Summary
Anyway, that’s all there is to it (grin)…
What I have just described is how to do Agile Project Management with Scrum (APMwS) for relatively long Projects — probably three months or longer. It puts the onus of Project Management where it belongs — on an APM who is outside the Scrum Team actually doing the work. It is both agile (updating the Project Plan every Sprint) and supported by standard Project Management theory. In my opinion, this is what is required in order to do ‘proper’ Project Management in a Scrum environment — at least for relatively long Projects.
I hope this helps…