Sunday, February 17, 2008

Right way to do Agile

If you are practicing Agile methods, I am sure at some point of time, you would have asked yourself or somebody else,

Am I  practicing Agile, the right way ?.

I would like to call this as an "eternal question on Agile".

If you visit any of the Agile related Yahoo or Google groups, people would be asking the same/similar eternal questions.   I conduct many Agile training programs and coach teams, and I keep getting similar questions.

There are many such questions. Some of them include  :

  • What is the ideal length of iteration ?
  • Do I need to practice Scrum meeting everyday ?
  • I am working on maintenance project, do I need to practice Scrum meeting every day ?
  • Can we have multiple Scrum Masters in a Scrum team

When I hear these questions, I feel that there is something missing in their understanding of meaning of Agile/Agile methods.

As we know, Agile is all about values and principles. These values and principles are manifested into practices with the help of Agile methods like XP, Scrum, DFDM, etc. But, the practices not limited to the one recommended by above methods. Beauty with Agile methods is, one can invent any practice/set of practices one wants provided the practices don't violate the values and principles.

You would say that's fine, I understood but where are the answers to above questions ?  My answer would be,

  • Invent any practice you want provided you satisfy the customer and team
  • Modify any practice you want provided it does not violate the Agile values and principles. It should be done after taking the team into consideration and a thorough research.

Practices should not be modified to satisfy an individual's taste. Many of the practices proposed by XP, Scrum are recommended after a thorough research and they have their own benefits. Some of them when practiced, are intended to identify risks and issues in the project. When a team practicing Scrum hits a painful point, they would tend to tweak the practice to reduce the pain. But instead I would recommend the team to retrospect and see the hidden issue behind the pain


No comments: