Whenever I sit on a project review and ask the question on quantitative management, this is the first quantitative parameter that I hear: Schedule Variance. Across the projects, IT and non-IT included, this is a metric of concern. Or, may be this is the easiest metric to measure, only to discover that the results are dismal at large.
Riding on the old English anecdote that Time is Money, the importance of schedule variance is indeed paramount. However, when it comes to following the Agile method, it becomes a bit different. May be a bit interesting too. Let me explain why: Agile methods by definition, cannot have any schedule variance. All deliveries are contained within one sprint or other. Sprints do have a fixed end date. As a result, the schedule variance of all sprints are zero.
While the sprints end on time, the deliverables don't. The unfortunate fact is covered up by simply pulling the deliverable off the sprint, and pushing it to the next sprint. So, if the measurement is done sprint-by-sprint, the schedule variance is zero. If the measurement is done output-by-output (or by deliverable), the result is unlikely to be zero. Sad but so real!
At the risk of antagonizing the proponents of Agile methods, the metrication on this area needs a pragmatic approach. Sprints are fine, but their end dates are curved on stone. But the buyer get most benefit when the work products are delivered on time. The product owner may take the responsibility of listing down the macro level deliverables to define such packages. The product owner may also need to do a thorough homework in determining the realistic and beneficial date for each of these packages to become usable. For the consultants working for their clients, it would be useful to have an open meeting with the client to agree on these dates. Once the dates are agreed, measure the schedule variance of each of these deliverables, and aggregate those to the project level.
Many a times, while speaking to the buyer or sponsor about Agile methods, it was found to be drawing a good degree of enthusiasm simply because there was a promise of showing the work products early enough while in the making. The same enthusiasm get converted to frustration when the buyer gets to see a lot things frequently, but none of those make any sense to him/her. A delivery centric view covering only the deliverables that matter most would be good to sustain the enthusiasm, as well as would save some time for both developers and buyer. The same feeling can get echoed through the measurement technique described above for schedule variance. We cannot simply ignore this metric for sake of the definitions within Agile Programming method.
