Tuesday, July 29, 2008

Transitioning from Waterfall to Agile - Some tips

The day comes when suddenly somebody in the organization starts talking about Agile, and decides to implement Agile . This senior person who made this decision, would have heard somebody saying

Agile improves productivity !! and saves money Or the customer would have said, if you don't practice Agile I will not give the project to you(in an outsourced scenario)

Whatever the reason be, now the development team has to start practicing Agile. Note that moving from waterfall to Agile is not only needs the change in software development process but also the entire thought process surrounding the software development. Changing the thought process is not easy, as people practicing Waterfall would have reached some kind of comfort zone and immune to the pain and suffering from the consequences of practicing waterfall. So, it would take a lot more effort for them to unlearn the old way and learn the new way of doing software development.

In order to make the transition smooth here are some tips which could act as pain killers

1. First and foremost thing is to identify a good Agile coach.

2. Get all the team members to undergo training on Agile (XP, Scrum, etc)

3. Don't force all the Agile practices at once. Take one or two practices at a time and give sufficient time for the team to learn and practice.

- For ex: One can start with shorter iterations and scrum/daily stand up meetings.

4. Don't wait for the right day to start Agile. Start today. Go run to a shop and get hold of a Good Agile book(s).

Some good books for starters include,

  • Agile and Iterative development a manager's guide by Craig Larman,
  • Ken Schwaber's book on "Agile project management with Scrum",
  • or any Extreme Programming book.

5. Start with 4-6 weeks iteration rather than 1 week iteration. Many new comers to Agile feel suffocated with 1 week iterations. Earlier the waterfall teams would have delivered softwares once in 6 months, and suddenly asking them to deliver in a short period makes them resist to Agile.

6. Take a simple and low risk project to try Agile. Also, with the help of Agile coach ensure that this project succeeds

7. Try to make use of visible tools like Flip Charts, Burn Down charts, Post-It notes, spreadsheet and encourage more interactions among developers. Make the developers to come out of their cubicles and start designing things on boards.

8. Ensure that management provides complete support to the Agile coach.

9. Even though having indepth understanding of Agile values and principles are key to succeed in an Agile environment, the team may not be able to grasp all of them at once. As and when each practice is introduced to the team, show them the relationship to the values and principles.

10. Don't bother if you would like to start with Scrum or XP. Instead, put all the Scrum and XP practices in a big basket, take the simplest one at a time and start practicing it. Over a period of time you would understand what is best for your team.

11. Scrum and XP advocates specific team structure like having Product Owner, Team, cross functional teams, no hierarchy, a team coach, scrum master, etc. This is a very sensitive issue. Suddenly informing the team that all of you are same, might heart the ego of senior people. I have heard stories where the seniors have quit teams as they were equated to the junior members by calling all of them as team and by dismantling the hierarchies . So, don't worry about dismantling the current team structure. Let the team learn slowly the importance of the values and decide what is best for them.

12. Let the project manager's slowly transition from their current responsibilities to become scrum masters.

1 comment:

Girish Hegde said...


The tips are good. However I have some reservations with the last point which says, don't hesitate to dismantle the team!

Dismantling team overnight is not an easy job, neither it is beneficial to the project. It should be a gradual process and there has to be a slow transition. It is quite sensitive. There can not be one hard rule and I think such things should be addressed on case to case basis!