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