TOC based Architecture of Enterprises - Some Ideas
Theory of Constraints
Architecture of Enterprises: Some Ideas
February 20, 2022
This is not an "it must be like this" article - it's more a collection of thoughts that have come up over the last few months. For a while now, I have been getting more and more calls from companies that started with SAFe and value-stream-oriented teams in the last 1-2 years and now have more and more problems with throughput, costs, dissatisfied customers or developers. But now to my thought ...
... is it possible that we just made a mistake in our thinking, and that value-stream-oriented teams are nothing other than the "good" old silos?
I came to this idea because we get requests like this: We have now implemented these value stream teams or SAFe ...
- ... but there is always one value stream that blocks all the others!
- ... but we are not able to get strategic or innovative projects out anymore!
- ... our customers do not get what they need fast enough - so they start to build workarounds!
- ... but the Product Increment plannings are getting longer and longer - and the teams are still waiting for each other to deliver!
We see a speed-up in the work of each team, at least in the beginning. And we see extremely high cohesion within the team - that is cool and powerful. But whenever there are dependencies across the teams and streams, problems occur.
The evangelists now say "you have to decouple the value streams better" - fine, that is a no-brainer and everyone knows it.
But strategic projects always go across value streams to get synergies - that is their aim. And if you are honest, breakthrough innovations have the same character. A breakthrough innovation makes value streams obsolete or connects/integrates value streams into a new one. Both strategic and innovation initiatives cut across value streams.
That sounds like the old days when we blamed the silos for not being able to innovate!
Now, look at the picture at the top of the article - if you turn your head by 90 degrees, then the value streams look like silos - right?
So let's think differently ...
... if value-stream-oriented teams are not the solution - then what?
What about this - don't look at the structure of an organization at all. Really look at the value generation. Then you'll find two kinds of value generation: (1) changing the system and (2) producing the core value. The first is project-oriented, the second is production (see Agile). If you look from a systemic perspective at the work that flows through an organization - then you see three layers, and on each one the system changes its structure.
On the top layer, you have a lot of initiatives and the order can be changed easily - that is production. So the idea is to stagger all these initiatives based on the constraint - see Theory of Constraints - Drum-Buffer-Rope or Simplified Drum-Buffer-Rope.
The middle layer is the "pain" (aka projects) layer. In this layer, the individual projects are in scope. But they have dramatically different characteristics. They have to deal with dependencies (internal and external), and what makes it worse, there is a critical chain of dependencies to be fulfilled, with feeding chains - and worst of all, every day you lose on the critical chain, the due date will move. This is the domain of real project management - here the toolset of Critical Chain Project Management in our DolphinUniverse Community with its buffer management is king!
On the value generation layer (aka teams), you again have many small tasks/stories/subtasks or whatever, which can be re-sorted every time one is finished. On this layer, only flow counts - no due dates - no dependencies - just flow. So here the ideas of Tame the Flow from @Steve Tendon (and a little bit of me) are perfect.
The idea to put all this together is not new - since 2013, Steve and I have applied it in quite a few organizations. In the end, it's simple - if you start from the top and do not overload the constraint, then it will be easy to keep track of all the dependencies in the projects. Everyone has resources to work on the critical tasks, and everyone has the same priority - flow at project level - cool. And at team level - just pull whatever is urgent and make sure that the touch time is as high as possible.
This model is completely agnostic to any structure you choose - all the control mechanisms are independent and just focused on the element to be produced. Pure FLOW. And after a while, the structure develops exactly as it must in order to generate optimal FLOW - it is somehow a fluid organization.
One More Idea for End2End Value Streams
The idea of having fast, flexible End2End-responsible teams close to the customer is a very powerful one - so we should not skip it. But maybe there is another idea that is mandatory to make this happen - it's the idea of dividing the stable from the fluid stuff - a classic platform concept.
Above the API, you can have as many independent teams as you want - they are the frontend - like any app development team. They can do what they want - but be aware that they will show the same 3-layer structure as shown above - just with more focus on the team layer. Maybe they don't need projects at all - because they have only ONE.
Below the API, you see platforms on top of platforms - very functional stuff. Stable, and focused on generic functions that change very slowly. Here I assume you'll find more projects, because if you want to change something, you have to take care of the dependencies between the platforms and domains.
Conclusion
There is no black and white - but if all you have is a hammer, everything looks like a nail. OK, you can also drive the screw into the wall - but you need more force, and maybe it's not so effective.
So you had better know when to use what!
If you want to learn more about all this stuff - in our DolphinUniverse Community you'll find everything for free.