Many, many years ago Frederick Brooks wrote a seminal book called “The Mythical Man-Month”. (yes, I know the title is politically incorrect when seen with today’s eyes)
While the best-known result of the book, also summarised in the title, is what is sometimes described as “we’ve never seen nine women join forces and have a baby in one month”, the book is actually a collection of essays on software engineering and, as such, delivering value in many different directions.
One interesting observation he makes in the essay “No Silver Bullet – Essence and Accident in Software Engineering” is that every software has a certain complexity. And he proposes to distinguish between Essential and Accidental complexity:
- Essential Complexity is the complexity intrinsic in the problem we want to solve. It’s there, and we cannot change it. A simple example is “1+1=2”: it’s easy, it’s complexity is minimal.
- Accidental Complexity is the complexity we add because of the way we work. Continuing the previous example, if I know “1”, my colleague working knows the other “1”, another colleague working from another site in another continent knows “+”, and some other colleague somewhere in yet another continent knows the “=“ and the necessity of bringing all the information together and having some very complex compliance processes on top and working with different languages, cultures, …, then 1+1=2 could become an incredibly hard problem.
The complexity of 1+1 per se remains the same, but we have added a lot of accidental complexity, making the problem much harder than it could be.
In organisations
While Brooks talks about software, he hints the problem is much bigger:
“Not only technical problems but management problems as well come from the complexity. This complexity makes overview hard, thus impeding conceptual integrity. It makes it hard to find and control all the loose ends. It creates the tremendous learning and understanding burden […]”
So the concept can then be applied also to organisations. I often see companies organised is what seems to be a totally irrational way. The following is an example of a hypothetical company having different clients asking for different functionalities. As it often happens, companies try to create synergies and reuse what is developed in its various parts, and this is fine, but then the actual product delivered to the clients are composed by several contributions.
We call this “Composite Value Stream”, i.e. not a simple or linear path from requirement to product, but a highly interconnected network of parts that needs to come together into a product.
As companies tend to optimise locally, one common pattern is to have teams specialised in a certain type of work, so the “production” in this Composite Value Stream is organised in components:
And, because “we want to be agile” there are some Product Owners being “owners” of a part of the process:
And, usually, there are also departments with some line managers because “matrix organisations are good and modern” [or management fads, as I call them…], resulting in a nightmare like this:
Wait, there’s more…
And… on top of this there are some other issues to consider:
- Physical locations
- Different languages and cultures used – “Let’s use English as the common language” is easy to say, often very hard to do
- The technical architecture of the product
- The level of technical excellence of the organisation (and when in a large organisation there are different levels of “excellence” in different sites, it can be a lot of “fun” – and I am sarcastic here, of course!
- The number of technologies involved
- Of course, internal politics
- Complex internal processes
- …
So… how do you expect to make this work?
This is accidental complexity in action!
I have seen organisations playing in the same space having wildly different cycle times for what they do. In one case, I measured a 27x difference in resolution time for the same type of showstopper bugs, and the difference was not in the quality of the people but in how they were made to work!
Obviously, these organisations were not designed in this way. On the contrary, they are the results of years and years of changes applied without a real design and sometimes with the intent of locally optimising for one parameter without understanding the systemic implications.
Complexity reduction is the way to large-scale agility
Of course, we need effective teams! Of course, agile methods can be a great help, but in a situation like the one depicted before, having a team or even all the teams “doing agile” might increase the perception of efficiency, but maybe not the organisation’s effectiveness.
But if you’re in a leadership team of an organisation that wants to really become more effective, it is important that you – as a team – approach this complexity and work to reduce it. The only practical way is to do it in iterations, always experimenting with an open mind, trying to remove or reduce it, one step at a time. Yes, it’s a darn long-term commitment and very hard work, but we know it works and can be effective, thanks to the work of Toyota and the lean movement.
Together with some colleagues(*) we’re developing a set of principles to help you on this path: more information is coming soon!
My final recommendation is that please don’t consider agility as a “process” to implement with the teams. While that is a part of “the work”, the real challenge is reducing the organisation’s accidental complexity. On a positive note, agile teams implemented properly, i.e. capable of being product teams and technically excellent, can help you a lot on this path. But they are helpless if the organisation is blocking their path to success!
(*) Credits to Colin Bird, Simon Roberts, Matt Roadnight and Ian B. Olsen, who co-developed these ideas!