When to apply agile methodology?
‘When to apply agile methodology?’ is one of the frequently asked questions about agile. Before getting into that discussion, let us revisit the term’Agile‘. Really what is it?. Is it a method?. Is it a methodology? or is it an attitude?. Actually the term agile is used to represent a various frameworks like Scrum, XP, TDD, UDD etc which supports the underlying spirit of the agile manifesto and principles. All these frameworks are iterative and incremental. They advances through a series of iterations. Every iteration produces ‘little more’ of the final product.
Now let us get into the main topic ‘When to apply agile methodology?’.
One must consider these three aspects. The first one is the scope volatility, followed by frequency of releases required and the technical flexibility.
What is the maturity of the scope defined?. Is it likely to change very often?. If you feel that the scope will change very often, then that justifies agile adoption in your project. Here are some of the typical project types which calls for agile adoption;
New product development projects
Product enhancement projects
Defect fixing projects as there are ambiguities of scope
Planning and engineering phases of all projects
Frequency of releases
Does your project calls for frequent releases?. In other words, by making frequent releases, can the project benefit by addressing the following better;
Managing stakeholder expectations. Frequent releases improves stakeholder engagement.
Technology risks. Agile methods will help to identify technology risks very early. This will reduce rework considerably
In general, frequent release milestones will help to manage risks better in a risky project. At the same time, if the customers are not willing for frequent releases, then it is a different story.
When I say technical flexibility, there are two types of technical flexibility. Domain specific flexibility and engineered flexibility. Within a construction project, within the construction phase the technical flexibility is very low to accommodate changes. Where as information technology related projects are more flexible to change. These are examples of generic domain specific technical flexibility.
Within information technology projects, if the technical architecture is not highly modular like the service oriented architecture popularly known as SOA, then it will not be able to accommodate changes that easily. I call it as engineered flexibility.
The following three questions will help you to decide the suitability of agile methodology for your projects;
What is the likely hood of scope change?
How will frequent releases help to address major risks?
Does the technical domain allow for changes, even late in the project?
If the answers to these three questions are ‘Yes’, then your project will benefit by adopting agile.