The last part of our start organisation definition is “activities with interdependencies”, and we can call this Queues. In the blog post “Time to dig into our principles”, the reason why can be found.
There are many levels where we can find queues of activities to individuals, teams or team of teams. A company has a queue of customer requests, which for example can be broken down to:
– projects/programs (with many teams), which in turn will break them down to activities for respective team on a detailed level,
– or sometimes also further broken down to activities for a person.
For simplicity only activities of the two lowest levels are shown, but they can be any at level, and the higher up in the organisation, the more cross-functionality we will have.
The activities discussed further on will be planned activities, planned within a time box, because it is only then we have promised to achieve a result within the time box. These planned activities are only valid for the Complicated and the Obvious domain in the Cynefin™ framework, because here we have the knowledge so we can do planning. In the Complex domain we have great lack of knowledge about our solution. This means that we need very fast iterations (to get fast feedback) of, many times unknown length, and always unknown result, i.e. here we need to gain knowledge before we can plan our activities.
For our purpose the queues of planned activities will be categorized in two different types:
- A queue with planned activities of different kind handled by teams/persons within a project/program
– this queue is in control of the project/program, i.e., they have the competence
– this queue we can call a Lean queue* - A queue with planned activities of the same kind from many different projects/programs to a specialized person/team, which can be outside the projects/programs or working part time in many different projects/programs
– this queues is out of control for the projects/programs
– this queue is the reason for bottle necks in an organisation
– a queue to a security control at an airport is an example
– at this queue we need over capacity
– this queue we can call a Mean queue (nasty queue)
Since we have our planned activities in the queues we can of course never remove all our queues. But, we always need to try to convert Mean queues to Lean queues if possible, since if we do not do that, we will have Activities in Queues waste, since it will effect the Flow Efficiency negatively. When it is not possible to convert to Lean Queues, we need to have over capacity at the Mean queues. For product development this can be queues to any expert, like system integration & verification (I&V), configuration management, etc., since all resources normally cannot be in the projects/programs.
It is very important to understand that there is no difference at all to have a specialist that all projects/programs need to use, or to have the same specialist working part time for each project/program. Absolutely no difference, even if the latter looks better. Specialisation of our resources is really the wrong way to go, we need T-shaping of most of our Resources instead to remove both the number of queues and the length of queues. This will be elaborated thoroughly on in this blog post about the root causes to queues.
Worth noting is that if a project/program does not plan well or if we have scarce resources in the projects, the Lean queues will of course also become bottle necks, but only within the project or team of teams, which means a local flow efficiency problem.
Important to understand is that variability is always present. But, does that implicate that we always can blame variability when we have queues? No. No. No. Every time we have a queue we need to ask ourselves why we have the queue. The Prefilled Problem Picture Analysis Map for organisations (here is the series of blog posts), clearly shows that we cannot blame variability (and we must be sane), since queues in organisations are always only a symptom of something deeper. Nothing else. Which means, that if we try to fix the queue with for example WIP constraints or reduce batch size as the panaceas, this will of course not solve the real root cause. Instead it will only give us new chains of symptoms anywhere in our organisation, at any time. We are trying to fight our own system that we built ourselves. But, the only way to change our system to the better is to solve the root cause to organisational problems, because then we know we will fulfil another principle in our set of principles. When we instead are trying to solve symptoms, we are only sub-optimising our system and we will lose. Every time. This will be elaborated on thoroughly in later blog posts.
Now it is finally time to deepen the understanding of the first part of our start organisation definition, namely the “People that interact” blog post series.
C u soon again.
*Since Toyota’s untold mission is to broaden the competence of their people in production (multi-I-shape, see this blog post), in product development (T-shape, see this blog post) and also elsewhere in their organisation, I found that Lean queues is really a telling name.