Agile Scorecard? No! A better idea…

scorecarddOh no, yet another management team has asked for an agile adoption score card so they can “know how agile the teams are.” Wrong question! Here is why…

What gets measured gets manipulated

What happens next is that all teams are measured. To increase our score, my team need to do something called retrospectives. Fine let’s put another useless meeting in for the whole team. We need somebody called a scrum master? Fine, Dave can do that in addition to his already crazy workload. He can also spend the time writing post-its and putting it on a board (Yaahaay! A board = more points on our scorecard). Destroys value. Frustrates everybody. Yet another thing management put in the way of actually doing the work. Sigh.

Why do management care about how agile the teams are? Surely management really cares about things like return on investment, customer satisfaction, speed of response to the market. Measure these things if you like – although these are lagging indicators so aren’t very practical for decision making but this is a topic for another day.

Two better questions management might ask

Surely, if a team has a good understanding of agile practices, they can be trusted to adopt the practices that add value. Instead of a score card, here’s the first question management should ask each team:

Q1: Does the team have access to agile experience?

Experience means “having done it before successfully” – be they developers, product owners, scrum masters, agile coaches, etc. Agile practices are context specific so it’s best if the team have access to somebody or somebodies who have done it multiple times before. Somebody who has already had the “aha moment” that what worked in one team, does really work in the second team – it needs adapting.

Not everything is under the team’s control. So the second question management needs to form a view on:

 Q2: What barriers to experimenting with agile adoption is the team experiencing that are outside the team’s control?

Don’t just have somebody send a survey out. Don’t delegate it to a “transformation” team. Management must Go See to get close to the work and have a personal experience of what is really happening.

Set up the Systemic Improvement Service

When management have an initial list of systemic barriers to adoption, prioritise them and get to work removing them –  keep going forever. This will need quality time from management – the issues thrown up are likely to be tricky to resolve. LESS calls this an Improvement Service which anchors it firmly as a service management provide to the teams  Here’s some classics you might find near the top of your improvement backlog:

  • No widespread alignment about why we need to be agile/how urgent it is for the organisation/what it means to us
  • Senior management believe they can define in advance where value is and when it should be delivered by
  • Loads of handoffs to people external to the team
  • Teams unwilling to experiment due to delivery pressure, fear of failure, …
  • Technical debt rarely paid back
  • Product owner not empowered to prioritise
  • Temporary project teams
  • Teams too big
  • Slow and painful interaction with enterprise architects
  • Infrastructure and deployment processes sub-optimal

Think bottlenecks

If you think your bottleneck is that most of the teams don’t have access to agile experience, then get going with recruiting more scrum masters, coaches, etc. More likely is that the bottleneck is the capacity of the organisation to remove systemic impediments (i.e. chew through the list above). Work on expanding this capacity! The teams will become more agile when their environment lets them. The job of management is to shape this environment. Increasing your capacity to do this shaping might just be your best investment.

2 Responses to Agile Scorecard? No! A better idea…

  1. Sean Moir says:

    Great post Chris. You’ve summarised very nicely some issues we have seen in our work.
    I have recently come to the view (partly through training so not claiming it my own) that 3 things need to change in order for any meaningful change to take place; leadership; structure and culture. Incremental changes in each of these enable further incremental changes in the others. It is unrealistic to expect that any single action or practice adoption will be effective without supporting changes in the other elements of the trinity. Rather a change in one area can be viewed as an enabler for changes in others.
    Your summary point about increasing the ability to remove systemic impediments, and investing in leadership ability to create the right environment to enable this is absolutely spot on.

  2. Good article, Chris. I like in particular your opinions on measures.
    Good luck! Klaus

Leave a Reply