How Agile Are You?

During an Agile transformation, there comes a point when the basic framework has been implemented, the ceremonies are being observed, 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 work to and, improve from. Striving to “level-up” can be the incentive a team needs to improve and optimise their Agile game. Whilst a full AMA is needed to establish a baseline it can be as cumbersome as it is thorough. The pain of a full AMA can be alleviated by integrating it into Agile ceremonies and day to day Agile life. One way of doing this is with an AMA board and deck of AMA “Top Trumps” cards. Using these tools in a team’s Standups and Retrospectives keeps the AMA fresh and manageable on a day to day basis.ion to Agile Maturity

 

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. However, in the spirit of Agile, this assessment interval can be accelerated by including small AMA’s in every iteration with minimal impact to the team.

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;

Shoshin 

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.

Zanshin

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.

Shu

3. Shu – (Obey) – The Follower

Managed, Standardised.

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

Ha

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

Responsive, Value Focussed, 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. Their teams actively review and align their practices to the strategic goals of their parent company.

Ri

5. Ri – (Leave) – Transendence

Innovative, Adaptive.

Teams that have reached Ri are recognised as forerunners of Agile change. They are truly innovative often transcending 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 it’s 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;

Team

  • Adaptive Planning.

Shoshin

Zanshin

Shu

Ha

Ri

  • The team does not plan.
  • Planning occurs but is irregular
  • Plans are not clearly visible to people outside the team
  • Team can commit to the plan*
  • Team delivers 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

  • Stand-ups. 

Shoshin

Zanshin

Shu

Ha

Ri

  • Stand-up’s are not occurring.
  • Stand-up’s happen but are irregular
  • Team “just goes through the motions”  Stand-up’s go overtime
  • Not all team members participate
  • Team iteration DoD is not visible at stand-up
  • Only a selection of the work is spoken to

 

  • Stand-up’s occur daily.
  • Stand-up’s are completed within 15 minutes
  • All team members participate in stand-up’s
  • Stand-up’s occur in front of the teams work wall
  • Team unit of work DoD is visible at stand-up*

 

  • The definition of done is used as a tool to check that a task can move between states (exit criteria defined)
  • All notable obstacles are presented, including those that the team members can resolve themselves
  • Team members pro-actively identify any risk to iteration completion and take steps to address these*
  • The iteration goals are stated and conversation is focused around achieving those goals

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

  • 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.

Shoshin

Zanshin

Shu

Ha

Ri

  • 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.

 

  • Stand-up’s occur daily.
  • Stand-up’s are completed within 15 minutes.
  • All team members participate in stand-up’s.
  • Stand-up’s occur in front of the teams work wall.
  • Team unit of work DoD is visible at stand-up.

 

  • Multiple backlogs exists 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 estimatedSelect team members add new items to the backlog.
  • Select team members are involved in backlog review activities.
  • 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 .
  • Prioritisation.
  • Visual Planning.
  • Product Ownership.

Technical Practices

  • Continuous Integration

Shoshin

Zanshin

Shu

Ha

Ri

  • Not Implemented.
  • Set up, but manually run.
  • Failures not fixed right away.
  • Run every hour.
  • Failures fixed fairly quickly.
  • Run every 10 minutes.
  • Drop everything 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.
  • Behavioural Driven Development.
  • Automation.
  • Acceptance.
  • Elicitation.

Running an AMA Workshop.

The first time an AMA workshop is run can take a long time. Establishing a baseline for the Team is essential however. The prerequisites that are needed for an AMA are;

  1. All Areas and Practices must be defined.
  2. Levels must be be outlined for each practice with assesment criterea (as per the examples).
  3. All team members should read and assess the practices before hand then this saves time in he actual workshop.

The first time around a member of the team that defined the criterea for the practices should facilitate the workshop. This is often an Agile Coach but does not have to be if one is not availble. The facilitator then works through each area and each practice calling for a vote on what the team believes the score to be. Thus;

  1. The highest and lowest scores should be explored (justified) and the teams decision adjusted accordingly.
  2. The team may decide unanimously on a score or the facilitator can take the average.
  3. There are no part scores.
  4. The facilitator keeps track of the scores.

During the scoring process the creiterea for each practice can be reviewed and updated with feedback from the team.  The facilitator or assistant should take notes and update the criterea later. Once the scoring is finished the scores are averaged to show the overall score and a level is assigned. Artifacts generated from the teams first AMA should be;

  1. A spreadsheet with all the practices and thier criterea. With all practices scored by the team.
  2. A summary poster can be created to display next to the teams working wall (Kanban board etc…) showing all the practice headings and thier scores.
  3. Removable tags or sticky notes can be used on the poster so it is easy to change.

After the AMA

Now that a baseline has been established for the team by the first AMA the team needs to constantly review and update thier AMA. If this is done every 3 months the team will need to run a full AMA every time and this can become cumbersome and is often put off indefinitely. To combat this AMA fatigue the team can run Micro AMA’s in thier retrospectives and address them in the daily stand ups. This keeps the AMA in the forefront of the teams Agile thinking without becoming a burden. To integrate this process into the team’s daily processes and ceremonies the following steps can be taken;

  1. In the first AMA, look at one or two of the lowest scoring items and the criterea needed to “upgrade” them.
  2. Depending on iteration/sprint duration only pick a small number of items e.g. a two week iteration should have no more than two items, a monthly only four.
  3. The AMA items are not meant to be work that detracts from the team’s core work. They are meant to keep continous Improvement alive in the team.
  4. Create small user stories for these practices and assign them to volunteers as a low priority. (Volunteers should be roatated every iteration).
  5. The team members responsible for the AMA items then work on whatever is needed to increase the score by the end of the iteration.
  6. At the end of the Teams Retrospective spend 5 mins assessing and voting on the AMA actions that have been worked on.
  7. If the levels have increased then update the summary tracking poster.
  8. Choose and assign two more AMA Actions to another two volunteers (not the same volunteers as the last ones).
  9. Rinse and Repeat.

Conclusion

Acknowledgements

References and Reading

  1. https://www.benlinders.com/tools/agile-self-assessments/ – A good starting point with lists to articles and other teams practices.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s