In today’s blog post we will elaborate on the problems of having too many people working on the activities in our organisation, and find their root causes. And we will do that with help of our Prefilled Problem Picture Analysis Map, which we now continue to fill in. Here is the link to the presentation of it in an earlier blog post for newcomers or as a refreshment, The beauty of negating our principles to become root causes – The Prefilled Problem Picture Analysis Map.
Here is its empty structure:
At the top we have our problem description “Our product development is too slow, too expensive and delivers the wrong products” and at the bottom we have the dark truth; “A non-adaptive organization will die”, which means that the more principles we fail to fulfil, the harder we will have to be adaptive. And if our organisation has many remaining root causes, i.e. does not fulfil most of the principles, our organisation cannot survive. The red boxes we will from now on, in this, and coming blog posts, fill in with our negated principles, that then become our root causes. The white boxes will be filled with the many symptoms that are commonly found within any organisation.
Now we are going to start to ask multiple why. To our why questions, there are often multiple answers (symptoms), but today we only concentrate on the chain of symptoms that passes the too many people symptom, and finally ends up in root cause(s). We have already started with the chain of symptoms for the queue symptom which regards Flow Efficiency in this former blog post, and now we do the same for too many people, which regards Resource Efficiency. But, remember that they are tightly connected, which can be found in this former blog post.
Our start problem description is this.
Asking why, will give us the following symptom to add to our chain of symptoms:
Asking why again, will give us also the following symptom in our chain of symptoms:
Project Administration Waste is the waste we get just to go to project meetings, discussions, etc., and has been elaborated on in this blog post. Asking why again, will give us also the following symptom in our chain of symptoms:
And now we have found the too many people symptom, we were looking for (the empty box is not important now, and will be explained in a later blog post). Our too many people symptom has two variables to play with, and that is people and activities, same as for the queue symptom. And as you remember from earlier blog posts, for example, Our total organisation definition for a flourishing organisation, we have our start organisation definition “People that interact to solve activities with interdependencies”, so now we are close to the root cause(s), our negated principles. And since these variables represent the left part and the right part of our start organisation definition, we must at least ask why two times, since it most probably are at least two root causes. This will finally give us also the root causes for this chain of symptoms:
As you can see, in this case, this chain ended up in two root causes, two of our negated principles for a flourishing organisation. So, if we have the too many people symptom in our organisation, we need to look into both these root causes and do our best to dissolve them. And no one of the root causes requires some magic to happen, only hard work and determination that they need to be fixed. But, if we instead try to fix the too many people symptom directly, then the hocus-pocus will never stop, that we can be sure of. Because, then we can never ever get control of what we are doing, because we are sub-optimising our own organisation, by trying to optimise its parts.
If we look at these two root causes and Agile development’s handling of them, this is really Agile development’s strong part, since the whole idea with autonomous teams are T-shaping and full-time resources.
If we instead look at traditional waterfall of working in a silo organisation, this is instead its biggest nightmare since the last decades, when the market requires speed. And it does not seem to get better. Silo organisations have I-competence in too strong focus and thinks that specialisation will solve all their problems, giving (just one exemple of what can happen):
- more specialisation and even more people to solve one task, the bigger the organisation gets when the market requires speed
- which leades to even more part-time resources
- which leads to more Project Administration waste
- which leads to even more people at the meetings, decisions, discussions* (giving also big problems to come to a conclusion with the rate of interactions increasing exponentially)
- which leads to less time for actual work on the product/service
- which of course effects the outcome and are products are expensive, slow to market and are too expensive to develop
- which leads to a lot of overtime
- which leads to stressed people
- which leads to worse quality
- which leads to more overtime in order to fix the quality issues
- etc.
And with our two root causes above, that do not need any knowledge of rocket science to be solved, give us all we need to solve the specialisation syndrome* once for all. We only need to accept that there is no other solution. And if we not accept, we will continue to sub-optimise our organisation. What constraints the silo organisation puts on the solution to these two root causes, will be discussed in a later blog post.
How Lean Production and Lean Product Development take care of these root causes, will be brought up in this series of blog posts regarding Organisational Clogging, for Lean Production here, and for Lean Product Development here.
Now we are well prepared for a series of blog posts regarding Organisational Clogging, to elaborate some more on too many people and activities in queues in our organisations. Then we can also fill in the empty box in that is missing text in some of our pictures. Many living Complex Adaptive Systems have built-in anti-clogging-systems, where especially ants behaviour have been analysed by scientists, and this will also be part of the coming series. C u soon.
Next “chapter” according to the reading proposal tree is the series of blog posts about filling in chains of symptoms in our Prefilled Problem Picture Analysis Map. For deepening examples about organisational clogging and what kind of problems that can clog a organisation, see this blog post series.
*actually, the first symptom is that it is too many meetings (for decisions, discussions, problem solving, etc.). If we ask why on that, we will get the symptom, that it is hard to come to a conclusion. Why again will give two symptoms, a) people missing at the meeting b) too long meetings. Another why on them gives the same symptom, our symptom “Too many people at the meetings”.