Applying agile: where to start

In the last year or so, Scrum has become very popular and people are trying to apply it left and right. I don't know if it is Scrum but the number of projects that are trying to use agile methodology have exploded in the last one or two years. And there is a problem with this. Many projects that "start being agile" are not agile at all.

For example: imagine you're working on a project where you used to develop for 4 months and then test for 2 months and then prepare a release for one month. Your boss have heard that agile increases productivity and you start having 3 week iterations; 2 weeks of development, one week of test and prepare a release for one week. Instantly you see productivity drop 50%. And the reason is that you have just chopped up your regular work in smaller chunks and the productivity feels like it drops because you now do 3 weeks of work in 5 weeks.

The problem with agile is that you need to understand it fully before you can implement it correctly. And this applies to the large picture (Scrum, XP) and the small picture (TDD, Daily stand-ups) - if you do not understand the purpose, you will probably do it wrong. Agile methods like Scrum will act as an catalyst helping you understand what all the building blocks are but you will still need to understand the purpose in order to be successful.

Then we have another problem; Agile methods, especially when applied as a bundled concept like Scrum may not fit every organization. For example I heard that one company I've previously helped start using Scrum (and I think I was successful since more and more of their development teams are using Scrum even without my help) are now trying to apply Scrum to the marketing team. I'm sure their marketing team will have benefit from some of the parts suggested in Scrum but if they try to force all their work into a Scrum-like cycle I think they will need a really, really good coach to get it right.

Yet another problem with applying agile is that it will probably be a big change in how you work and I know many developers who don't like change. These developers will try to resist and see all the problems with the new methodology and you will be working upstream in order to get them aboard. And I think there is an easier way to do it.

So where do I start?

There are several books you can read in order to prepare your self and try to not fall into the same pits as everyone else before you. Think that will be a future post... I have come to the conclusion that applying agile in small steps are probably the easiest way to do it. If you're going to apply agile in tiny steps I think this is the way to do it:

• 1. Start having daily stand up meetings!
  I think this is the most important thing you should do, especially when you consider the cost against the positive effects of daily stand-up meetings. Communication is the key to success regardless of if you're developing games or building cars.
• 2. Respect the retrospects!
  The retrospect is the time after each iteration where the team sits down and talks about what went well and what went less well in the last iteration. Things that can be improved are discussed and a plan to improve is put into place. If you have many problems (as many teams think they have in the beginning of their agile journey) you should concentrate on the top two or three problems the team perceives. Also remember to respect the outcome of these meetings! If the team perceives something as a top problem - management must let the team try to remove that problem.

Thats it... If you do those two things correctly you will successfully implement agile into your team. If you think my list is to short you can always look at this Scrum checklist. But what about iterations? I mentioned that you should have retrospects after each iteration but that is not on the list... Well iterations are not needed to have retrospects. Just have your retrospects at a regular interval and I suggest no more than four weeks apart in the beginning. The longer the period between the retrospects the more problems will the team see and the slower change will be because after each retrospect the process used by the team will improve. If you want really quick changes in the process you should have a retrospect each week. Also iterations gives you the power of closure which should not be forgotten but if I have to choose between iterations and daily stand-ups or retrospects - iterations come in last. Also there is no point in making the list any longer because the last item, respect retrospects will over time have you implement all other good things than are considered agile.

Finally I think there is one more thing you should do in order to quickly become successful with applying agile. Get a coach! Maybe that should be the only item on my list because everything else will come over time with help of a good coach. I did not put it on my two item list because I know many teams will not have the opportunity to hire a coach. But if your retrospective shows the team wants a coach - you should get one. If your organization does not allow you to hire an agile coach there are two other things you can do; Ask around on agile forums or get someone from outside the team come and listen to your daily stand-ups and retrospects. This person will look at the process from the outside and may in many cases come up with a few new ideas on how to improve that you have not yet thought about. This person from the outside may also say things that the team is afraid to say. This will also bring problems to the surface.

Preemptive comment: How does Microsoft do Agile? Well Microsoft Research have one report you can read. And I will also come back to this subject in later posts on this blog.

Comments

• Anonymous
  April 13, 2008
  The comment has been removed

• Anonymous
  May 15, 2008
  Previously I've written about where to start when applying agile to your project. But not all people

• Anonymous
  August 19, 2008
  Sometimes I come across a team saying; " We can't use Scrum because there is no project. We just do what

• Anonymous
  April 04, 2009
  Yesterday Henrik Kniberg published this draft on Kanban vs Scrum . I think it is a great article describing