Use the System to Change the System

Executives now realise that in the new world of fast paced market disruption, old ways of developing software are no longer effective. We need product thinking, outside-in design with agile self-organising teams. However, we've spent more than 40 years not trusting corporate employees to build the right things. We’ve created elaborate processes, governance and management hierarchies in an attempt to address any poor outcomes. We’ve purposefully constrained employees not to think beyond perfectly documenting, coding then testing whatever is described by the business, their managers and the architects. 

On the flip side, all too often, the answer appears to be an agile transformation that involves “setting the people free” by removing the constraints.

Having invested so much in institutionalising employees it shouldn’t be surprising that it typically ends badly if we suddenly remove all of the constraints.

Parallel with Another System

This approach has parallels to the system of releasing captive animals into the wild. So let’s take a look at how that works out.

The animals can be split into three main groups:-

• Those that have been in captivity so long that they have no awareness of the dangers of the wild and are quickly killed by predators
• Those that are too afraid to explore their environment and die more slowly through starvation or disease
• A small number that survive

Enterprises I’ve been involved in where executives have attempted agile at scale and their strategy has been to immediately remove all of the constraints on the development teams have driven three outcomes:- 

• Projects that fail due to high unpredictability and poor quality
• Projects that fail due to confusion about how to operate
• A small number of projects that succeed

The similarities are striking.

A 2008 study showed that only 33% of captive animals survived in the wild, even after the considerable work that’s been done in recent years in improving reintroduction schemes. I see project statistics that look little better. Just like these released animals, a large number of developers, and therefore their teams either don’t understand the broader risks or are paralysed while they work out where the constraints are and fail. 

When Executives Fight Their System

An example of this for real was when I worked in one product team of 600 people that were told to go agile. Everyone was sent on certified Scrum training. They were put into Scrum teams and sent off to build and ship the next release of an existing product. The list of features wasn’t put in any order and managers were given no guidance on what their role now was, other than some of Scrum trainers telling them that they needed to fire themselves and become developers.

The leadership kept insisting that the teams were very smart so they’d work out the order in which things should be built. Just like the domesticated wild animals described earlier, these teams had been used to a highly controlled environment. They had been very hierarchically managed. The Leads all giving directive guidance to each person on the team about what and how they should build things. The delivery of components and their integration was coordinated at the end of the build phases by a war room style release management leadership team.

The teams didn’t “work it out”. In the end, middle management decided to step in and recreate the war room in order to save the release. They blamed the agile delivery approach and this tainted that organisation's appetite to try again. Last I heard they’d gone back to their old model and now a few years later are looking at agile again - what a waste.

So what have I seen work when moving large scale, command and control organisations to a more agile delivery model.

Cultural Jujitsu

Having studied martial arts when I was younger, one of the lessons I learnt was to use your opponents strength against them. This has stood me in good stead in the engineering transformations I’ve lead. If the system of delivery is a long-standing hierarchical command and control approach then you should use that same system approach to slowly change the culture.

Start at the team manager level by commanding that managers:-
1. Set the intent and constraints over giving detailed work instructions
2. Challenge the team to meet the intent within those constraints

Notice the managers are “commanded” to set constraints and set intent. This is what I mean by using the system to change the system. Using commands to remove the need for commands, over time, by replacing them with constraints and setting intent. 

I’ve seen this work well in one of my previous organisations. It  took more than 9 months for managers to both have the skill to set good constraints and intentions. It took the same amount of time for the team to build up trust with their managers by shipping better software.

The cross-team decisions remained as command and control to give some familiar structure for teams to operate within. This way  they still had a clear way of building the larger product.

The teams were told the relative value the organisation gave each feature. This was to encourage self-organisation across teams based on delivering higher valued features sooner.Some teams were better at this than others. The best teams created their own regular cadence of events with other teams they shared dependencies with. They started to optimise the delivery of their parts of the product. This left their managers more time to remove impediments and manage risks - their role in large scale agile delivery.

The role of the Performance Review

I’ve a dim view of the annual Performance Review process. However, it can be another useful tool in using the system to change the system.

The performance review tool typically rewards selfish behaviours  through a focus on what specific actions the individual has done to ship a new feature or close a deal. It drives local optimisation. Some performance review systems have a “how I did this” dimension which supposed to balance the “what I did”. In most corporates, I’ve been involved the “how” carries little weight when compared to the “what”.

Depending on how far you can change the performance review process, you have a number of options:-

1. You can remove the process entirely. Do it as soon as possible.
2. You can change the questions. Replace the questions with those that better support the behaviours the organisation needs. For example, What did you do to help your team succeed? What did you to help the organisation succeed?
3. You can’t change the questions. In the early days, command line managers to re-train their teams to answer the existing questions using responses that demonstrate the behaviours the organisation is looking for. Command the managers to interpret the responses focusing on the change you want. For example, if the existing question asks what features the team member delivered this year into the product, the answer would describe concrete examples of the contribution made to team in order to ship this years features.

It’s critical to reward the behaviours more than the outcomes. If there’s a problem with outcomes there’s normally other issues than the person at fault. 

Walk the Talk

Edgar Schein describes how organisational culture is observable through artefacts, espoused values and assumptions. In order to move from a command and control system to a system that can adapt at pace, culture is key. Those in command in these organisations need to refresh the espoused values to aligned with the new more agile behaviours. Challenge old assumptions. Use the systems reliance on being commanded.

In Turn the Ship Around, David Marquet describes some great examples of how this can be done. 

An example not in the book is where those in control tell stories of those who succeeded during a critical incident by using the new behaviours. Even more importantly, those in control demonstrate in their own actions the changes they expect in others. Those behaviours that begin to move from command and control to setting constraints and managing by intent. They make sure they’re seen to be doing this and during the inevitable errors they will make they share their mistakes and learning with the people who work for them.

It’s the System Stupid

Working with Kate Gray, she reminded me of Bill Clinton’s campaign strategy to keep focusing on ‘It’s the economy, stupid’ message. 

This is a great reminder that when a heritage organisation is looking to become more agile it’s not one thing that needs to change. We can’t blame the culture, the tools, the processes or the people. It’s the system stupid. So use it.