Wednesday, August 16, 2006

How to select a right Agile methodology for your project - Part 3

In my last two posts we have talked about XP as well as a little bit about RUP, and today I will explore the SCRUM methodology. Relatively speaking SCRUM is still the new kid on the block comparing to the other two, and that is also why you can easily observe the similarities among them since SCRUM does borrow ideas from both XP and RUP. Some even went one step further and announce SCRUM “as a management wrapper for Extreme Programming” (see Control Chaos website for more details on this theory) and similar claim for RUP as well (follow this link for the full article). Although I don't totally agree with this management wrapper theory, I do agree that SCRUM did learn from both XP and RUP through their success and failures, and try to come up with a better process.

Since most of people agree that SCRUM is more comparable to XP than RUP, plus at its core RUP is just a set of guidelines as I mentioned in part one, hence here I am going to focus on comparing SCRUM with XP and show what are the implications and hidden differences between them that you need to look out when implementing SCRUM in your project. As a methodology, SCRUM is more about management than development, comparing to XP SCRUM does not give out or enforce any coding guidelines or practices, such as the test first, pair programming, and refractory that XP requires, however in process management aspect SCRUM is way more rigid than XP, it has hard fixed requirement on team size, meeting frequency, meeting length, iteration length, and so on. But before we jump into details, I want to point out the first and foremost difference between SCRUM and XP which is also the reason why I don't agree with ADM's “using SCRUM as a management wrapper for XP” theory. If you remember what we talked about in part two, that the one and the only one reason why XP is considered so extreme is it allows customer changing their requirement at any time they want even in a middle of iteration. In order to make the whole process more manageable, since manageability is the most scaring part of XP at least for the traditional managers, SCRUM took this cornerstone of XP out of its process. Now people can argue that they can use SCRUM as a management wrapper for XP, since SCRUM does not have its own development principles so XP development style fits it pretty well, but can you still call it XP. I don't think so. It is like for people who find white-water rafting as a sport is too extreme and unmanageable, so to make it more manageable they take out a 'white-water' part and then claim calm-water rafting is a management wrapper for the white-water rafting although you can still apply all the precautions and best practices that 'white-water' rafting requires, but can you still call it an extreme sport?

Alright thats enough about the management wrapper theory, now lets take a look at some core SCRUM rules as well as the reasons and implications behind them:

  • Fixed Backlog Items (Requirement) for each Sprint (Iteration)

    • Reasons

Although SCRUM does acknowledge the changing nature of the requirement during the process, as we mentioned before in order to increase the manageability as well as lack of development principles and guidelines SCRUM is neither designed nor capable to handle frequent change of requirement in the middle of a sprint.

    • Implications

As soon as the sprint kicks off, all sprint backlog items become frozen. New backlog items only get added to the product backlog item pool, and picked only as early as when the next sprint starts. Because the relative inflexibility of the requirement, when implementing SCRUM the development team should always start picking the high priority items first since they are most likely to be the most stable requirement. Also due to this stableness, when using SCRUM on a simple project excessive testing and high level unit-test coverage might not be necessary (high test coverage, above 80%, is still recommended if the project is complex or it has a long predicted field life in other words refractory is required for the evolving architecture)

  • Fixed Sprint (Iteration) Length – 30 days

    • Reasons

First of all it is a widely accepted optimal iteration length for a 7 person team in RUP community (See The Rational Unified Process Made Easy for more information on recommended iteration length). Secondly in SCRUM for each Sprint there are relatively formal planning and review process (usually it takes a day or two), a very short Sprint will just simply create too much overhead because of this form of ceremony. Last but not least, because SCRUM does not enforce high test coverage, hence change of implementation and architecture is relatively expensive therefore the process was designed to shield any changes from the outside world for fixed period of time allowing the team to focus on what they are doing and get into their flow to maximize the productivity when minimizing the overhead.

    • Implications

If you are working on a project that needs very short iteration probably because a large degree of uncertainty and unpredictability within the requirement or just simply because of a super aggressive deadline, and before you try to customize your iteration length you should really consider XP or AUP which are tailored for short iteration or even downsize your team to fit a shorter sprint (usually I don't recommend shorten your sprint to less than 2 weeks with SCRUM), but if you insist to change the length of iteration remember the following consequence as well as some recommended solutions:

Consequence

Recommended Solution

Overhead from formal planning/review ceremony

Batch the planning and review activities for multiple sprints in one session

Overhead from more dynamic requirement and implementation

Increase test coverage as well as the SCRUM Master needs to do a better job to shield the team from the outside 'noise'

  • Max Team Size - 7 people

    • Reasons

Firstly because SCRUM does not require pair programming (here is an excellent article I read a couple of years ago thats explains why paring is a good idea), knowledge does not get spread as naturally as it is in XP and to overcome this problem SCRUM uses close-up open working space concept as well as mandatory daily meeting to help speedup the knowledge transfer. When you increase the team size over 7, this approach become insufficient to serve its purpose. Secondly like XP due to the decentralize the team structure that SCRUM adopted, once you have a large size team too many communication paths get created, and research shows that once team size exceeds 12 the communication overhead starts growing exponentially.

    • Implications

SCRUM does not have any problem handling team thats smaller than 7, but you need to be very careful when considering to increase your team size over that. Here are some possible consequences when you do that and recommended resolution from me:

Consequence

Recommended Solution

Inefficiency caused by large number of communication paths

Assign a team lead who is not the SCRUM master since the SM has to deal with the blocking issues plus shield the team from the rest of world. The team lead needs to be equally involved as well as focused on development to reduce the communication paths effectively.

Knowledge become isolated to its implementer

Promote pair design, pair programming, and conduct code review if necessary, in addition to that high test coverage as well as simple design will help preventing accidental breakage of the existing implementation because the modifier lacks of the appropriate knowledge.

In summary SCRUM is much more manageable at least in traditional sense comparing to XP plus the fact that in SCRUM all the traditional managerial type of position and pay check can be easily kept as the chickens (Observer/Contributor) to avoid the pain of converting people from architect to developer, thats why it remains so far the most favorite choice for any project that wishing to transit from more traditional waterfall model to a relatively more agile approach.


Huh... this turned out to be another lengthy post, and I am hoping you will find the reading is not too bumpy and the information is useful.

No comments: