The purpose of Quantitative Project Management is to manage projects by a set of defined number driven parameters to achieve the stated project objectives. Apart from having familiarity of various quantitative methods, such activity also demands planning, reporting, and analysis. Unfortunately, Agile methods don't support activities like planning and reporting in a formal way. It doesn't have any role for Project Manager. That leaves the entire space of quantitative management open for interpretation.
So, how should an Agilist address the need of Quantitative Management? The earlier proponents openly discarded the existence of such need, but no longer. As Agile methods are becoming mainstream, such questions are real, demand for demonstrating project performance through numbers are phenomenal. The only quantitative reporting available with Agile methods are burn charts. The chart shows the effort burned over a period of time, and how the budget gets consumed. The chart does not reflect anything with respect to the work product quality. The chart does not reflect anything with respect to the meeting project objectives. The chart does not reflect anything pertaining to the analysis and resolution. As a result, the seasoned Agilist is bound to look into the classical quantitative management techniques, devise his/her own plan and execute it.
This brings back to the same situation similar to my previous post: wearing a project manager's hat while still within the team. Somebody like the product owner should prepare the metrication plan, collect data during scrums/otherwise, report data through a frequency driven reporting, and perform necessary analysis. If the data collection becomes part of the scrum, then the scrum format needs to be tailored. Instead of sticking to the 3 question format, a fourth question may get introduced by asking 'Tell me your numbers'. Or, a standard form can be used to collect data in writing.
The good news is, many large projects today use some process support IT platform, even if the project follows Agile methods. Tools like Team Foundation Server, etc. becomes quite useful in storing and updating the sprint backlogs. The same tool can also provide quite a few meaningful metrics based on how much of the backlog tracking is being done through it. At a minimum, the three basic project performance criteria can be derived quite easily: schedule, cost, quality. There is a minor twist though. The definitions of these parameters within the scope of Agile Programming are different to that of what the classical project management techniques taught us. My next posts will start exploring those areas.
