Thursday, January 25, 2007

Scrum vs. RUP - The winner is...

...the Team!!!!

Back in August, I talked about how agile was working with my offshore team. Over the past few months we've had our ups and downs, but the good thing is that we've learned from our mistakes and continued to modify the process to fit our project's needs. All those iteration assessments (or lessons learned or retrospectives) that we conduct really pay off if you take the time to adjust based on what you learn.

Overall, we've ended up modifying our strictly RUP process to accomodate for some of the Scrum methodologies that we are comfortable with as an organization. Here is an update:

Potentially Releasable Software
  • The team was having difficulty with this concept
  • The team was killing themselves trying to get the defect counts within the acceptance criteria
  • We came up with a compromise that is working well.
    (1) Iterations are now about 3 months long versus 5 weeks
    (2) We deliver an "in progress" build to the customer at the end of each month to get early feedback; this build always includes UCs that have been completed during that month and other in progress UCs.
    (3) We commit to meeting the quality criteria by the end of the iteration
Product Backlog
  • We've altered the Product Backlog to be a combined Release Roadmap and Release Planning document
  • It serves the same purpose, however it has made planning easier since we have added more columns to track builds, effort per build, contingencies, rework, etc.
Planning
  • This was the biggest problem area and the area where we've seen the most improvement. It's amazing how good planning improves morale!
  • We now have one master Iteration Backlog for the team as a whole.
  • Each of the teams manages their own Project Plan and these roll up into a Master Project Plan.
  • From the Master Project Plan I can get the progress of the build and the progress of the iteration.
  • We are using both burndown and burnup charts. This makes is very easy to see the progress and gives the customer visibility into the project.
  • On the burndown charts, I track the remaining effort against the target.
  • On the burnup charts, I track the percent complete against the target.
  • The actual data that generates these charts changes to red if something is behind.
Sample Iteration and Build Burndowns




























Sample Iteration and Build Burnups



3 comments:

James Peckham said...

"The team was killing themselves trying to get the defect counts within the acceptance criteria "

sounds like there was a clear indication that your backlog items were too big or the team was underestimating. What did the team think? Were there a lot of surprise acceptance tests in the middle of sprints that the team hadn't accounted for? Maybe those should have been new story cards or new backlog items.

Anonymous said...

In SCRUM, even a 5 week iteration is on the long side. To go to a 3 month iteration sounds an awfully lot like Water Fall and definitely not Agile. Part of the intent of Agile/Scrum development as I get it is to work off small, logical chunks of work and get them to the end user as soon as possible. You continuously build code and as each area of functionality is complete, the product owner decides if there is value to release, or if there is a mis-direction. If you go in 3 month chunks, you can really miss the mark and be way out in left field long before you realize you left the base line.

Andy said...

Excellent call out. One thing to note, though, is that the iterations are 3 months, not the sprints. The sprints still remained 1 month long. There would be a formal review of the release every three months. Thanks for the comments!