Thursday, August 6, 2015

Agile vs Traditional Project Management

This post is meant for practicing project managers who are transitioning from traditional “earned-value-analysis” based project tracking, to an Agile Scrum based project tracking. It could also be vice-versa. I personally had to undergo this transition in the reverse order, as I moved from Nokia, where Agile Methodologies were well in practice, to Accenture, which was more traditional waterfall-model based. Note that I dont have very strong opinions on which is better – although most of the software industry is (or has) moved on to Agile, traditional “Earned Value” based tracking also has it’s benefits. The focus of this post is to try to put the two methods together, and make sense out of it. There could be cases where a team is following scrum, but the project manager needs to report to management in a more traditional format.

Let’s take a hypothetical project, where a team of 10 people have to implement the following feature list.
For simplicity, billing rate is kept at $10 per month, per resource.

Feature List
Dollar Value
 (Person Months)
Feature-1 100 10
Feature-2 50 5
Feature-3 100 10
Feature-4 25 2.5
Feature-5 25 2.5
Totals 300 30

Let’s assume the following
  • The project starts in January, with a team of 10. The plan is to complete Feature-1 and Feature-3 in Jan & Feb.
  • From March onwards, 5 people take on Feature-2, while the rest of the 5 jointly take on Feature-4 and Feature-5
  • In April, all features are implemented, and the project is completed.
  • However, Feature-5 takes longer than expected, and 5 people have to continue working in April, and finally complete it in May.
This could be tracked using Earned Value Analysis using the following graph.

At any reporting date, the difference between the graphs for “Earned Value”, “Planned Value” and “Actual Cost”, “Planned Cost” give the overall status of the project. The idea here is that value is earned only when a feature is completed. The status report each month (or week, or day) shows
  • How much value has the project earned so far?
  • How much value was planned to be earned so far?
  • What was the resource cost spent on this project so far?
  • What was the planned resource cost so far?

Now, let’s assume the same project is run in a Scrum mode. Scrum breaks down timelines to 2 week, or 4 week “Sprints”.
The scrum team calls the feature list a “Product Backlog”, and breaks it down into tasks that it can take on in the next sprint (Sprint Backlog). The team meets daily, and updates how much effort is remaining in completing the tasks. The overall project status is reported using a Sprint Burndown chart, which would look something like this.

It shows that the progress slowed in Sprint-3, but was back on track in Sprint-5. The project delay happened, and additional 2 Sprints (1 month) were needed (to complete Feature-5, as above). Usually, Burndown charts show the effort (person months/weeks/days), but I have used the dollar value (effort x billing rate).
The status report here, at any point during the project, shows
  • What is the remaining effort to complete all the product backlog.
  • Is the team ahead of plan, or behind plan.
  • The same, for cost, if Burndown chart is plotted with billing rates.
So, in a nutshell, both traditional and Agile methodologies present the same data in status reports, but in different formats.
It should be fairly simple for a project manager to take data from one format, and report in another format. However, in order to do this, one needs to ensure that there is a one-to-one mapping between the project feature list, and the Scrum product backlog. This is usually not a problem in organizations where proper requirements management tools are being used. Features are usually documented & sized in such tools, and can be the reference for the product backlog in scrum.

No comments: