When to use agile approaches?

Some projects have considerable uncertainty around project requirements and it is a big challenge for our teams to fulfill those requirements using current knowledge and technology. These uncertainties for sure will contribute to high rates of change and project complexity. 

As scrum master I can tell that as project uncertainty increases, so too does the risk of rework and the need to use a different approach, so in order to mitigate the impact of these risks, our teams should select life cycles that allow them to tackle projects with high amounts of uncertainty through small increments of work. 

Any team can verify their work when they use small increments and can change what they do afterwards. When teams deliver small increments, they are better able to understand the true customer requirements faster and more accurately than with static written specification and yes, this sounds like scrum.

‍

A development team can plan and manage projects with clear and stable requirements and clear technical challenges with low or none risks and little difficulty. However, as the uncertainty increases, the likelihood changes, wasted work, and rework also increases which is costly and time consuming and there's where an agile approach could make sense.

Some teams have evolved project life cycles to use iterative and incremental approaches. Many teams discover that when they explore the requirements iteratively and deliver more often incrementally, the teams tend to adapt to changes more easily. These iterative and incremental approaches reduce waste and rework because the teams gain feedback.

These approaches use:

• Very short feedback loops
• Frequent adaptation process
• Reprioritization
• Regularly updated plans
• Frequent delivery
  

The Stacey complexity model will help us to identify the nature of the project in order to select an approach that suits better for the team aiming to deliver value:

‍

What do simple, complicated, and complex projects mean?

 In order to understand the Stacy complexity model, we could see it as following:

• If the technical degree uncertainty and requirements uncertainty are low, then we could say that the complexity of the project is low or is a simple project where the team could select a linear approach.
• If the technical degree and requirements uncertainty are high, then it is a chaotic project where the team including the stakeholders should start to set limits in order to gain certainty on the requirements by iterative and incremental deliverables. 
  

The iterative, incremental and agile approaches work well for projects that involve new tools, techniques, hardware, technology, or application domains. They also work well for projects that:

• Require research and development 
• Have high rates of change
• Have unclear or unknown requirement, uncertainty or risk
• Have a final goal that is hard to describe
  

‍

By building a small increment and then testing and reviewing it, the team can explore uncertainty at a low cost in a short time, reduce risk and maximize business value delivery. This uncertainty may be centered on suitability and requirements (is the right product being built?); technical and feasibility and performance (can this product be built this way?); or process and people (is this an effective way for the team to work?). 

All three of these characteristics:

• Product specification
• Product capability
• Process suitability
  

Typically have elements of high uncertainty.

As a conclusion; iterative and incremental approaches have their limits of applicability. When both technology uncertainty and requirements uncertainty are very high the project moves beyond complex to chaotic and in order for the project to become reliably possible, it needs one of the uncertainty variables to be contained.