28 September 2019

In the last 2 weeks, I had the privilege of meeting Jeff Sutherland and Klaus Leopold, in London, along with a bunch of brilliant people.

The theme is pretty similar in these two meetings and all the participants have similar questions. Everyone hit the limits of Scrum and other agile practices. The overarching question was:

How to achieve business / organisational agility?

Many in the audience questioned, “is it in fact a good idea to make few teams go faster in the larger context of an organisation”. If not, what they suggest?

Both Jeff & Klaus echoed similar sentiments, though the degree of convergence isn’t 100%. 

Here is my take-away from these two meetings

1. Scrum at team level isn’t making organisations go faster. This is the unanimous view of all the participants in these two meetings. Jeff & Klaus agreed with this. 
   1. As a consequence of this, development-team’s productivity or any measurement of it doesn’t really matter
   2. Few faster teams create choke points, which is detrimental to organisational agility – so Scrum implementation in few areas alone is a recipe for disaster
2. There is no way to create “fully independent cross-functional teams”- whatever way you group the teams (product teams, value teams, journey teams, chapters, squads, tribes etc.)
3. Any number of practices / ceremonies won’t help you achieve agility; there are more fundamental issues to solve – many are organisation specific.
   1. In fact, Jeff said, his decades of research showed him that implementing more than 5 practices actually kills both productivity and projects (SAFe – watch out)
   2. Ivar Jacobson counted about 100 such practices / ceremonies so far in various agile methods and frameworks

What are their solutions to these?

• Jeff suggests “Scrum @ Scale” and
• Klaus suggests “Flight Levels“

I’d like to add few cents of my own on the above.

If you dissect both, there isn’t much difference nor there is much disagreement. In fact, Klaus is careful enough to encourage many of the agile practices that Jeff and others advocate. But, PMP or Prince2 didn’t say anything different either. Then, where is the catch – how do you achieve organisational agility?

For this, we need to understand agile & lean thinking in organisational context – Agile thinking when applied to organisational context, it is no longer about how we develop software but how do we structure and manage the organisation in the new context. Most importantly, we need to identify inefficiencies along the value stream to structure the new context.

As Klaus said, “agility of an organisation is not having many agile teams but having agile interactions between teams”. The fundamental reason for this, identified decades ago by Russell Ackoff, is “the performance of the system is not the sum of its parts, it’s the product of its interactions”.

The usual reaction in many organisations to address these interactions issue is to hire people to manage interactions among teams. These species are usually called project manager or programme managers or delivery leads or implementation managers or release train engineers. The result is increased communication overhead (increased number of reports from teams to these managers, then summarised versions of these to other team managers and completely different interpretation of these by other teams – Chinese whispers…)

Jim Highsmith, one of the “agile manifesto” signatories, said: to achieve business / organisational agility we need to answer two questions

1. In what ways our business need to be more responsive and
2. If we have the capability to develop and deploy, how can we take advantage of that.

Once we answer above two questions, we need to establish these four to achieve organisational agility:

1. Establish “purpose” based on the needs of one or more constituents (such as customers,partners) for which the business / organisation exists
2. Bring decision making to the place where work happens.  Decision making in agile context is treated as a team sport. If the only people who are empowered to make decisions are at the top, agility is impossible. You need to ensure that the people closest to the problem to be solved are given the power to solve the problem
   1. Having visual boards at Flight Levels 2 & 3 is critical for this
3. As a consequence of #2 (decision making at shop-floor), establish frequent feedback-loops. As decision making happens deep in the organisation, they may not have view at higher levels. Frequent feedback loops limit the impact of blast radius.  This also reduces the lead time in “idea to impact” cycle.
4. For #3 to work, you need clear & measurable KPIs. Establish them. The question we need to ask here is: “If we’re right, how will we know?” Ensure that these KPIs directly map back to “purpose” you established and the teams have real-time visibility of these, not just to C-suite. A note of caution – don’t measure everything just because your tool-chain allows it. Only “measure what matters”- the fewer the better

• 

•