Why Use An Agile Framework?

The growth of Agile frameworks has been a response to the historic failures of traditional project management.  The first thing to note is that Agile is not one thing but an umbrella term.  There are a number of Agile frameworks available, some have been used since the 1990s while others have been developed more recently.  Although there are similarities across Agile frameworks they can have varying focuses of scope and be used differently in different environments.

In this post, we introduce some of the frameworks used and discuss their scope and limitations.  The next post looks at why Agile frameworks can be better when a project deal with uncertainty.

Traditional ‘Waterfall’ Methodologies

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

‘Waterfall’ methodologies try to fix requirements early and plan the delivery in detail upfront – sometimes years in advance.  Typically, the sequential stages are something like this:

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

However, knowledge workers’ ideas of a solution can be very fuzzy due to the conceptual nature of software and service delivery.  To start with, they are not sure exactly what they want.  Waterfall methodologies do not easily support people changing their minds.  Of course, projects can be successful using this kind of approach –  typically with the following characteristics:

  • Well-defined and stable requirements
  • Familiar tried and tested technologies
  • There are few surprises and all goes as expected and planned

Project Success Rates

However, projects with these characteristics are rare.  There are many examples of failed projects – especially IT related projects. For example, in the United Kingdom, a National Health Service project cost over £12Bn and did not deliver a single thing of use.  In general, the overall success rate for projects is not great.  This is detailed 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

Many issues can arise that undermine project success:

  • Stakeholders test the complete solution and it does not meet business expectations
  • Now, there is re-work that was not in the original plan or budget
  • 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

On a positive note, projects are more likely to be successful when an Agile approach is adopted.  Agile is not a silver bullet and the team needs to be experienced and use an appropriate framework.  The required solution emerges, as the team starts working together, their understanding grows, and preferences solidify – often from being able to see something.

Flavours of Agile

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

It is important to note 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 right-hand side, is 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 a the basic team level or to manage a strategic portfolio.


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.