How Agile are you? Part 1: Conducting an Agile Maturity Assessment

In part 1 of this series, Richard Wisbey shares how TattsGroup performed an Agile Maturity Assessment to determine how Agile their teams were

Part 1: Conducting an Agile Maturity Assessment

During an Agile transformation, there comes a point when the basic framework has been implemented and Agile is part of the day to day working life. At this point, it is reasonable to ask the questions; are we finished? Can we improve our Agility? Where do we go from here?

An Agile Maturity Assessment (AMA) is a way to answer these questions. By taking each Agile practice (or sub-practice) and assessing it against maturity criteria and assigning it a level gives a team a baseline to improve from. Striving to “level-up” can be the incentive a team needs to improve and optimise their Agile game.

What is an AMA?

An AMA or Agility Maturity Assessment is essentially a checklist of agile practices sorted into areas of most relevance. These practices are rated against maturity criteria to assess how Agile a team or organisation is and highlight where they can improve. An AMA can be run as a facilitated workshop whenever the team feels that it has made progress in its way of working or there has been some changes made to the day to day running of the team. Generally, every three months is a good standard.

At this point, it should be noted that the following information is drawn from personal experience with the maturity assessments conducted at TattsGroup in Queensland. This method of running an AMA is by no means the only way or the right way. It is given here as an example template to start a team off with Agile Maturity Assessment. Likewise, the structure of the assessment is also an example. Teams should adapt and modify the information here to fit into their own organisation and team culture. This is Agile, please adapt and overcome.

AMA Levels

The AMA is comprised of Practices organised into Areas. These practices are rated via levels. The levels for the AMA are;

1 – Shoshin – The Beginners Mind

Unaware, Ad-hoc, Reactive.

Most teams start here. There are no defined standards in Shoshin and any Agile processes are ad-hoc and differ between members.

2. Zanshin – (Remaining Mind) – The Alert Mind

Aware, Defined, Repeatable.

Teams here are running in a general Agile fashion. Practices are used and the team is aware of what needs to be done but does not always use Agility to its fullest extent.

3. Shu – (Obey) – The Follower

Managed, Standardised.

Teams in the Shu space employ Agile principles regularly in a standardised manner. Their team practices are disciplined and are regularly reviewed and updated. These teams can link their practices to the strategic value of what they deliver.

4. Ha – (Detach/Depart) – The Explorer

Responsive, Value Focused, Proactive.

Ha teams have all the standard Agile practices running smoothly. They are starting to adapt and evolve individual practices to fit their way of working more efficiently. Ha teams continually review and incorporate feedback from other areas into their practices. There teams actively review and align their practices to the strategic goals of their parent company.

5. Ri – (Leave) – Transcendence

Innovative, Adaptive.

Teams that have reached Ri are recognised as forerunners of Agile change. They are truly innovative and often transcend the need for strict adherence to formal methods whilst still maintaining strict discipline in their practices. The parent company of these teams recognises their value and is influenced by them when defining strategic goals.

Areas and Practices

Remember every team is different so Areas and Practices should be modified to fit the specific needs of the team and its environment. Ideally the Agile community in a team’s organisation should get together and create their own AMA criteria. Examples are provided for a couple of practices in each Area below (* denotes a quality that must carry forward to other levels);

Team – Adaptive Planning.

	Team does not plan.
	Irregular planning occurs. Plans are not clearly visible to people outside the team.
	Team can commit and deliver the plan.* Release plan is updated at end of every iteration. * The plan is made visible to people outside the team. * Data is used to support planning decisions.*
	Team is sometimes in a flow state. Planning occurs outside regular ceremonies in response to changing conditions.* Plans are pro-actively communicated to relevant stakeholders.* Planning includes customer representation.*
	Team plans constantly. Plans are focused on value delivery. Team is constantly in a flow state.

Other examples of practices for assessment in the Team Area are;

• Stand-ups.
• Visual Planning.
• Show Cases.
• Retrospectives.
• Risk Management.
• Iteration Management.
• Definition of Done.
• Social Contracts.
• Quality.
• Team Size.
• Sustainable Pace.
• Self-Organisation.
• Progress Tracking.

Product Management – Backlog Management.

	No backlog exists.
	A backlog exists. The backlog is reviewed on an ad-hoc basis. No prioritisation criteria is defined or applied. Not all backlog items are estimated.
	Multiple backlogs exist but are specifically aligned to a product or service area. Backlogs are reviewed regularly. * Clear prioritisation criteria are defined and applied to all backlog items. * All backlog items are prioritised and estimated Select team members add new items to the backlog. * Select team members are involved in backlog review activities.
	A single prioritised backlog exists which can be sliced by product. All team members (including SMEs) are aware of the backlog contents and current state.* Subject Matter Experts are involved in backlog review activities.* SMEs and select team members add new items to the backlog.
	Backlog is visible to the whole organisation. Anyone can add new items to the backlog. A single prioritised backlog exists which can be sliced by product and strategic goals.

Other examples of practices for assessment in the Product Management Area are;

• Prioritisation.
• Visual Planning.
• Product Ownership.

Technical Practices – Continuous Integration

	Not Implemented.
	Set up, but manually run. Failures not fixed right away.
	Run every hour. Failures fixed fairly quickly.
	Run every 10 minutes. “Stop the Line” on failures until fixed
	Run on every check-in.

Other examples of practices for assessment in the Technical Practices Area are;

• Elaboration.
• Test Driven Development.
• Behavioral Driven Development.
• Automation.
• Acceptance.
• Elicitation.

Conclusion

An Agile Maturity Assessment (AMA) answers the question; How Agile are you? An AMA takes established Agile practices and assesses them against a set of maturity criteria defined by the team or organisation. A team is then assigned an overall level and can clearly see what is needed to be done to reach the next level, both overall and for each Agile practice. In the second part of this blog (Part 2: Day to Day Agile Maturity), the integration of Micro AMAs into a team’s daily Agile practices will be covered.

Acknowledgements

A Special thank you to The Agile Improvement Team at TattsGroup. Thank you for all your support. They are real brains behind this flavour of AMA. They are;

• Sharon Robson.
• Mike Burns.
• Daniel Ginn.
• Will McNelis.
• Jacinta Streat.

References and Reading

There are many different flavours of Agile Maturity Assessments out there. Some of the approaches and techniques that were consulted whilst writing this article are included in a full reference list in Part 2: Day to Day Agile Maturity.