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:
General Overall Team Behavior associated with Agile Maturity:
- Level 1 – Performed, mini-waterfall. Struggling to hit release dates. ‘Test is a blocker’ often quoted.
- Level 2 – Reactive. Internal processes still being matured. Release dates often involve drama.
- Level 3 – Defined. Delivery predictable, Process introspection still in flight. Internal team and process is becoming predictable and reliable
- Level 4 – Quantifiable. Delivery is mature. Actively seeking to remove any internal process risk factors . R&R’s within team are well understood.
- Level 5 – Improving. 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:
Soft Attributes:
|
|
| Stage: 2 Managed
General Behavior: Process is Reactive Process Attributes:
Soft Attributes:
|
|
| Stage: 3 Defined
General Behavior: Process is defined, beginning to be proactive Process Attributes:
Soft Attributes:
|
|
| Stage4: Qualititively Managed
General Behavior: Process is well defined, predictable, measured and controlled Process Attributes:
Soft Attributes:
|
|
| Stage: 5 – Improving
General Behavior: Focus on Continuous Improvement Process Attributes:
Soft Attributes:
|
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.
Agile QA 