Agile Maturity Model (Scrum)

Being ‘Scrum’ is surprisingly subjective as implementation is deliberately open to interpretation, this can lead to misrepresentation.  This post attempts to take out some of the subjectively by creating a Scrum Maturity standard teams can objectively start to measure themselves against.

There is a problem with Scrum, which makes it both powerful and at the same time ineffective.  It is a framework and a mindset.  This allows teams to flex to their surrounding environment by not setting a prescriptive set of rules. This lack of prescription is where I see a number of teams and organisations struggle.

Teams and companies can quite often think they are ‘doing Scrum’, when in fact they are somewhere along what I would term a Scrum Maturity level.

By starting to put together an objective model, we can  allow teams to recognize where they are within a Scrum Maturity level.  This also help solves a number of issues, such as:

  • The subjectively of the statement ‘They are think they are doing Scrum, but aren’t..’
  • ‘We are doing the ceremonies, therefore we are doing Scrum’
  • Allowing a more objective measure to external and internal stakeholders where a team is with their Scrum Maturity
  • “We are doing Scrum, but it isn’t working for us”

The Scrum Maturity Model I’ve started to put together is based broadly on the CMMI model principles:

Screenshot 2016-05-08 09.08.22
CMMI Model

General Overall Team Behavior associated with Agile Maturity:  

  • Level 1Performed, mini-waterfall.  Struggling to hit release dates. ‘Test is a blocker’ often quoted.
  • Level 2Reactive.  Internal processes still being matured. Release dates often involve drama.
  • Level 3Defined.  Delivery predictable, Process introspection still in flight.  Internal team and process is becoming predictable and reliable
  • Level 4Quantifiable.  Delivery is mature. Actively seeking to remove  any internal process risk factors .  R&R’s within team are well understood.
  • Level 5Improving.  Delivery is mature.  Teams actively seeking external areas of process risk to improve.

I’ve attempted to distill the above broad levels further into the table below.  Grouping of behaviours and attributes are indicative and not definitive of Level achieved.

As I started sketching out the attributes I noticed they could be grouped broadly into team and process behavior.  As Scrum maturity grows stronger, collective team behaviour becomes more noticeable.  This leads me to believe that it is difficult to achieve an advanced level of Scrum maturity without creating a strong team in the process.

Note:   This is very much Work In Progress – I’ll keep refining.

Scrum Maturity Model (levels and attributes)
Stage:  1 – Initial, Performed

General Behavior:  Chaotic, Delivery unpredictable – Mini waterfall

Process Attributes:

  • Unpredictable delivery estimates
  • Large Number of outstanding defects
  • Separate teams (test/dev/PO)
  • Burndown Charts not making sense
  • Sprint Planning session is actually a ‘Sprint Giving’ session
  • Sprint Planning > 6 hours
  • Large amount of metrics/ reporting required outside of main toolset set of choice (e.g. Jira)
  • No CI tools in place
  • Retrospectives held, many items identified – very little worked on and resolved

Soft Attributes:

  • Time spend resolving conflicts due to semantics and not actual work – e.g. Defects are not defects, but improvements or issues
  • Teams hours are unpredictable, weekend/out of hours working is frequently requested
  • ‘Testing is a blocker’ is often cited
  • Excessively large team at standups 
  Stage: 2 Managed

General Behavior: Process is Reactive

Process Attributes:

  • CI Tools in place
  • Merging/Branching strategy
  • Disciplines relating to Teams still sitting separately
  • Testing starting to be merged into development activity – Done includes ‘Developed and Tested’
  • Estimates more predictable, but still erratic
  • Metrics/ Reporting / Status updated required outside of JIRA
  • Work starting to become less ‘lumpy’ for test and dev disciplines

Soft Attributes:

  • Team not a Team, just a group of individuals sitting together
Stage: 3 Defined

General Behavior: Process is defined, beginning to be proactive

Process Attributes:

  • Burndown charts burning down
  • Teams are multi-discipline and at a reasonable size
  • Sprint Planning is taking < 2 hours
  • Defects backlog start to be managed and resolved – less discussions around semantics for changes
  • Retrospectives result in inhibitors being identified and resolved

Soft Attributes:

  • Sprint Planning: Team is estimating as a team, not being dominated by a few individuals
  • Development activty assisting test team do their job more easily
  • More inter team dialog, less emphasis on tooling as a method of communication
  Stage4:  Qualititively Managed

General Behavior:  Process is well defined, predictable, measured and controlled

Process Attributes:

  • Teams estimating Sprint capacity correctly and consistently over a prolonged period
  • Burndown charts for last X months are consistent
  • A team is thought of as a cohesive unit consisting of dev, test and PO
  • Delivery capability is understood, trusted and predictable
  • Small number of associated defects with team, actively working on moving them to ‘zero’
  • Team hours are predictable
  • Unit/BDD are being pushed

Soft Attributes:

  • Team has dialog, not quiet – humour and friendly jibes across all team members
  • Standup’s are relaxed and friendly in atmosphere
  • Team Activities, team members doing stuff together e.g. lunches
  • Positive team attitude
  • Positive and confident team pushback in Sprint Planning/Grooming
  • Small number of metric’s required to indicate progress – Burndowns are trusted
  • Feedback from end users welcomed
  • Regression testing is automated (Can be a little clunky)
Stage: 5 – Improving

General Behavior: Focus on Continuous Improvement

Process Attributes:

  • Proactive in ‘looking forward’ for new incoming activities.
  • Backlog Grooming sessions < 1 hour
  • Looking ‘outside’ of ones team to proactively increase the quality of incoming work and outgoing work e.g. BDD
  • Team becomes much less dependent on SM, SM is more freely available
  • Defects actively zeroed in by team and put to bed. Near Zero outstanding defects in backlog or associated with team
  • Delivery Pipeline i.e. How to get from Done to Production is being proactively improved.
  • Regression testing is automated and fast (Unit/Integration/GUI)

Soft Attributes: 

  • Team is proactive is actively seeking areas of external risk to help improve
  • Primary focus on ‘end user’ and end user feedback (less on internal metrics)
  • Team needs little direction from SM
  • Strong Confidence within team members of their own and each others capability. Little thought to proving themselves externally as individuals

Scrum is powerful because it isn’t prescriptive in the implementation of process.  There are however  process attributes that are common across a broad domain of teams across industry.  Which I’ve attempted to capture above.

This lack of prescription in process implementation makes Scrum less brittle (than other approaches) and allows different teams to flex to their strengths and weaknesses.

By starting to acknowledge or put some sort of objective reasoning around levels of Scrum Maturity this may aid teams that are struggling to move forward, and provide a useful method for assessment.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s