Why So Many Agile Frameworks?

Agile approaches are a response to the high failure rate of the traditional project methodologies used to deliver software solutions.  A diverse group of thought leaders and organizations devised alternative ways to deliver software.  In this post, we introduce some of the many Agile frameworks available and discuss their scope and limitations.  The next post looks at why Agile frameworks better deal with uncertainty.

Traditional ‘Waterfall’ Methodologies

Traditional project methodologies treat software projects like engineering projects.  Here, the solution is specified in detail upfront with an assumed high degree of certainty.  They are known as ‘waterfall’ approaches as the sequential stages cascade like a waterfall.  Typically, the stages are something like:

  • Requirements gathering & analysis
  • Design
  • Solution build
  • Testing
  • Deployment into operational use

Train Wrecks

However, stakeholder’s view of a solution can be very fuzzy at the start of a process.  Often, people are not sure exactly what they want until they see something.  Waterfall methodologies do not easily support people changing their minds as their understanding and preferences grow.  Defined methodologies are typically successful with the following characteristics:

  • Well-defined and stable requirements
  • The solution technology is familiar, tried and tested
  • There are few surprises and all goes as expected and planned

Of course, projects be successful using this kind of approach.  The problem is when there is uncertainty around the required solution.

  • A common waterfall problem is when the stakeholders test the solution and it does not meet business expectations.  Now, there is re-work that was not in the original plan
  • During the testing phase, the technical team find the solution components do not work together as planned
  • The project will now revisit previous phases – analysis, design, build, test – to rework the solution
  • The deadline is still fixed
  • The supposedly sequential project stages start to crash into each other like carriages in a train wreck
  • Typically, a project will reduce the test phase, to accommodate re-work, and the quality of the solution suffers

Project Success Rates

Even now the success rate for projects is not great.  This is seen in the 2015 Chaos Report from the Standish Group.

  • Success – on time, on budget with a satisfactory result
  • Challenged – considered late, over budget or did not meet the target
  • Failed – canceled or not adopted by the users

Chaos Report

Flavours of Agile

There are a growing number of Agile frameworks from which to choose – some are listed below.  For information, the Agile Manifesto signatories are green in the list below.

Remember, the various brands of Agile can have a different scope of focus.  On the left, frameworks, such as basic Scrum, focus on one team involved in complex product development.

When teams work at scale a multi-team approach like those on the righthandside are more appropriate.  For example, DSDM or SAFe are fuller approaches that can scale for large projects or programmes.  We can apply Kanban to both simple or complex configurations.


Simple Team Approaches Fuller Scaled Approaches
Scrum Dynamic Systems Development Method (DSDM)
Extreme Programming Scaled Agile Framework (SAFe)
Kanban Kanban
The Lean Start-Up Large Scale Scrum (LeSS)


The Right Approach

The purpose of the frameworks can differ and there are no out-of-the-box Agile approaches.  Moreover, frameworks deliberately have gaps that teams fill when they think about how to use it in their environment.

  • Extreme Programming, as the name suggests, concentrates on how teams work together to deliver software solutions
  • SAFe also has a focus on technical delivery but at scale in large enterprises
  • Small teams – technical or non-technical – can use Scrum to deliver complex products ranging from AI to weddings
  • Teams can use DSDM at scale or more simply for technical or non-technical solution delivery

A Blended Approach

Furthermore, like Russian dolls, teams can use different frameworks within other frameworks.  In other words, we can combine elements of frameworks and techniques to suit our purpose:

  • For example, Scrum teams may use aspects of Extreme Programming if they are developing a software product
  • Or, we can wrap Scrum in DSDM for a full project lifecycle
  • Within SAFe, the delivery teams can use a hybrid of XP and Scrum or Kanban

In addition, we can use Agile techniques and practices across frameworks, such as:

  • Timeboxing (sprints) of work
  • Daily stand-up meetings (Daily Scrum)
  • Iterative development of solutions
  • User stories
  • Story points estimating
  • MoSCoW prioritisation
  • Kanban boards – AKA ‘walls of work’ or team-boards
  • Burn-up or burn-down charts

To conclude, we’ve seen that Agile approaches are a response to the high failure rate of the traditional project methodologies where there is high uncertainty.  Agile is not a single thing, but a collection of frameworks that can have a different purpose and scope of focus.  Lastly, we saw how teams can combine frameworks and techniques to create an approach that works for them.  The next post looks at why Agile frameworks better deal with uncertainty.