Wednesday, July 26

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

Recently some of my friends and colleagues asked me the question that:

Though there are various types of Agile methodologies XP, SCRUM, and RUP available right now, but when you start a project which one do you choose and what criteria do you apply to assess whether the methodology is the best match for a specific project. A short answer will be pick the one you feel most comfortable with, but if you really want to compare them and pick the best one for your project then having a solid understanding of the difference between theses processes is a must-have. I am writing this post in the hope of shedding some light to this tough question. Perform a quick search you can find introductory articles such as this one from Agile Alliance, but it does not sound too practical or useful for a real life project.

As an independent consultant, I have been working with different companies with different sizes who endorse different development processes ranged from Waterfall to XP, iteration length ranged from 18 months to simply a week. Recently and fortunately I finally had a real-life hands-on experience on setting up a SCRUM team and working with it to deliver some rather complicated product under tight deadline which you can think of it as a performance and stress test for the SCRUM process, hence so far I have worked with all three of the most popular Agile methodologies therefore I want to share the tips and pearls I discovered and the lessons I learned, and paid dearly for it.

Before I can start, some people might ask how come RUP is also categorized as an Agile methodology here? Isn't it a heavy weight process that is CMMI compatible and only used for over weight project and teams? The answer to that is "Yes you are right but only partially right". RUP - Rational Unified Process; If you strip down all the fluff that's created around this methodology for obvious marketing reasons from IBM, and if you look deep enough under the hood RUP is nothing but a set of guide lines and principles - so called The Spirit of the RUP:

  • Attack major risks early and continuously ... or they will attack you.

  • Ensure that you deliver value to your customer

  • Stay focused on executable software

  • Accommodate change early in the project

  • Baseline an executable architecture early on

  • Build your system with components

  • Work together as one team

  • Make quality a way of life, not an afterthought

As long as you are following these essential principles, you can consider your project is following RUP process. So RUP process can have an iteration as long as a year or no iteration at all (it is possible to structure a RUP process with waterfall model although it is usually not a good idea) or as short as a couple of days. A RUP team can contain as many as 200 engineers or just one person (yourself working on your personal website in your basement). Based on that you can see actually RUP is considered more higher level methodology comparing to XP or SCRUM since it does not have strict rules or practices that you need to follow, all the artifacts and disciplines are optional so you can pick and choose as long as you know what you are doing, hence you can really consider RUP as a super set of XP or SCRUM. As matter of fact, you can effectively follow XP and RUP at the same time, there is no conflict between them at all.

But to avoid confusion, in this post I will follow the widely spread belief and treat RUP as a separated methodology with its own flavor.

Its 10 o'clock now, time to go to bed since I have a 7:30 SCRUM meeting every morning .... Don't be shocked, this meeting has actually nothing to do with SCRUM process and in fact it is a very valuable lesson I learned, and I will explain the details in another post :)

No comments: