Many organisations are trying to become more agile. Some succeed, but in many cases they struggle. Even though they might use a process like Scrum, have things called Backlogs and people called Product Owners, when they compare what they are doing with the past, they aren’t often actually delivering different outcomes.
The post Sliding Doors – A Tale of Two Agile Teams describes one project and shows how teams (in this case, the Blue team) can appear to be agile, but not actually be agile – they could have delivered their prototype using traditional development approaches. But this doesn’t just happen in small teams; it is also evident at an organisational level, particularly when organisations try to make Programmes more agile.
Craig Larman is a respected agile thought leader, and the author of various books on scaling lean and agile approaches, including developing the LeSS (Large Scale Scrum) approach. He has a theory on why adopting a cultural change like agile is difficult – He calls it Larman’s Laws of Organisational Behaviour.
Larman’s Laws state that “Organisations are implicitly optimized to avoid changing the status quo middle and first level manager and “specialist” positions and power structures“.
Furthermore, he goes on to state that change initiatives will end up being manipulated (probably by those managers and specialists) into “redefining and overloading the new terminalology to mean basically the same as the status quo“. His main message being: culture follows structure, which is similar to the quote (often attributed to Peter Ducker) of Culture Eats Strategy for Breakfast.
If the cultural change desired by the organisation is to become more ‘Agile’, this battle between the status quo (structure) and the change initiative (strategy) can manifest itself in various ways. Some of the more obvious are where particular projects or areas are deemed ‘not suitable’ for Agile because they are in flight, too strategic, too important, not important enough, etc. Almost any project or team can find some reason why they are different or special enough to be exempted from the change initiative.
However, more subtle subterfuge can be seen in teams that seem outwardly to be embracing the new initiatives. Consider where traditional delivery areas have decided (or been told) to start being agile. They will commonly begin with Scrum. According to the Scrum Guide (which surprisingly few Scrum teams have actually read), Scrum has three roles: Product Owner, Scrum Master and the Development Team.
Despite Scrum never describing Scrum Master or Product Owner as jobs, it is common to see Scrum teams with a full-time Scrum Master and a full-time Product Owner. These people are often intelligent, honourable people, who want to do all they can to help the project succeed. They will fill their days with work to benefit the team. In a truly agile team, some of this will be as part of the development team, perhaps elaborating the detail of a story being developed, running tests or configuring the environment.
But, that’s a problem if they don’t have the right skills. And, in traditional organisations used to full time jobs like Project Manager, Test Manager, Business Analyst or UX Designer, the people in those old jobs don’t necessarily have the right skills to be useful as part of the development team. But that’s OK – perhaps the Project Manager can be Scrum Master, the BA Product Owner and everyone else in the Development Team.
The problem with this is that (if you believe Larman), the organisational culture will lead the Scrum Master to start behaving a lot like a Project Manager; and the Product Owner to behave a lot like a Business Analyst. This can manifest itself in many ways. Some that I have seen include:
- Scrum (stand-up) agendas expand to cover more information and take longer;
- Sprints start to be planned further in advance, so that the customer knows what they can expect later;
- The Product Backlog items get more and more detailed, meaning that the customer becomes reluctant to change things because the team looks so busy and well planned;
- Sprint goals (if they exist) start to describe building blocks of capability that have dependancies with later Sprints;
- The ‘working software’ delivered each sprint frequently can’t actually be used by the customer without additional work;
- Teams start to fragment by function, with the UX specialists doing their work in one Sprint, the developers coding it in the next, and the testers testing it the Sprint after.
When you take a step back, the team might be following agile processes, but they are behaving as a traditional team; and the customer outcomes are the same as they always were.
However, this can be avoided by recognising that cultural change is massively enabled when combined with organisational and behavioural change. Agile approaches don’t require the status quo specialist and management jobs to be carried out in the same way as before; so people from those jobs need to consciously decide how that will affect them.
For analysts, this can be a bit daunting, but it is also an opportunity to broaden their skill set, and apply their existing skills in new ways. For example, working with developers elaborating stories within a Sprint; working at a higher customer level on backlog refinement and high level business goals; helping the team set proper Sprint goals that genuinely deliver customer value; or leading on detailed modelling to support the developers.
Being agile is hard; it’s even harder when you are used to more traditional approaches, but remembering Larman’s Laws can help you recognise when the status quo organisation is dominating, and prompt you to do something about it.