This is part six of this series of blog posts regarding organisational problem-solving. Today’s blog post will handle problems with queues of activities, which has been a focus area for especially Agile development for more than one decade. With that said, it is now the time to start to change our patterns of thought somewhat and I hope you are ready for that.
Very common today, especially in Agile development, is the presentation of queues of activities as one of the biggest problems, if not the biggest, for low flow efficiency. There are a tremendous number of articles, books, tools, methods and measurements on how to try to control queues. For a small company or one team, the queues of activities probably can be handled even though they are affecting the efficiency, but the more teams that are achieving something together, the more and longer queues, if they are not handled properly.
Of course, if we are having queues of planned activities (I differ it from non-planned activities, which are more of a priority problem), where ever they are in the organisation, we will have a mess, with low efficiency, both low flow and resource efficiency as a consequence. But, the queues themselves are only symptoms, so the real problem is that we are not asking why we have the queues, so we can find the root cause(s) to the queues. As we already know since the beginning of this series, the only appropriate handling of any (organisational) problem is to start to ask why we have the problem in order to find the root cause(s), since we otherwise guaranteed will have a sub-optimisation*, including a lot of unintended consequences, with unknowable what, when and where. We only know why we have them ;-).
If we look into what queues of planned activities depend on, we have the following possible alternatives if we do a dependency analysis for queues of activities to be handled by people. The queues depend on:
- No people to take care of the activities
- People have the wrong competence and cannot handle the activities; normally due to too low T-shape, but of course missing I-shape (specialist) competence is of course sometimes also an issue
- The activities have interdependencies** to other teams
- The activities have interdependencies** to common experts/expert teams
- If, and only if takt time is used: the activities have interdependencies** to common stakeholders, common system experts/system expert teams, (big) rooms, tools, etc.
Or here as a picture:
Traditionally in projects with the waterfall methodology, queues arrived at well-known bottle necks like system integration and verification, configuration management or release handling, expert areas that normally are centralised and system oriented (wholeness). We get the following dependency analysis:
Normally this is solved by having some slack (buffer) in the time plan and/or underutilization (over capacity) at the bottle neck, where over capacity at the bottle neck is the cheapest solution for the total organisation. From the department owning the resources point of view, it is of course much more expensive for themselves respectively, but is only sub-optimisation thinking. Unfortunately, the buffer in a time plan is more invisible than a head count in a department, so the buffer has been the normal solution, even though projects waiting are very costly.
In Agile development we still have bottle necks at experts, but other queues have arrived on the scene, the queues within the team itself, more specifically the queues on the Kanban boards. If we examine this thoroughly, we can see that we suddenly have all the first four bullets above, giving this dependency analysis:
If we also use takt time, which is common in many scaling frameworks for agile, we have the last bullet as well, which gives us this scenario, where we suddenly also have symptoms regarding the needed involvement of important people having the wholeness, the Big Picture and also leaving the necessity of too many (big) rooms unsolved, etc:
And all these root causes above are in the Agile case tried to be taken care of by solving the impossible, the “queues of planned activities” symptom, which has resulted in all these books, articles, tools, methods and measurements, boiling down to these characteristics; Flow Efficiency calculations, queueing theory, WIP Limits, but also; economics of queues, WIP Control, WIP Constraints, traffic flow theory, Little’s Formula, Little’s Law, M/M/1/infinity queues diagrams, Cumulative Flow Diagrams, many different measurements, etc.
But where is the why question when we have queues in Agile development, since we understand from the dependency analysis that Agile really has introduced new dependencies? The why question is forgotten. Painfully forgotten, since symptoms cannot be solved, and when we try to solve them, we get unintended consequences, chains of symptoms that we cannot foresee or handle and that never ends. Forget asking why, is the SCQA (Situation – Complication – Question – Answer) and MECE techniques in the box, and that is also literally since it is constraining the solution to be inside the box (frame), sliced in any dimension; the silo /value stream /department /unit /group /team /economy /effectiveness /deliveries, etc., which is called framing. But, the solution to the root causes cannot be framed, they will be anywhere in the organisation, especially the solutions that affect higher levels or the whole organisation.
But we have more problems with the above thinking, that queues can be solved and that is about variability. Normally car queues and airport security queues are showed as examples of queues, which is too simplistic, generating more mess. The reason is that the presented queues are totally isolated with extremely high variability (non-planned), combined with an over-utilisation at for example rush hours, or aeroplanes landing with hundreds of people at the same time. Product development can and must be planned, which reduces the variability dramatically. But, do not forget to solve your organisation’s problems first, otherwise the variability may increase tremendously and you are out of control to understand why.
Without looking for the root causes to our organisational problems, especially regarding interdependencies and complex activities, it is not possible to state that if we reduce the batch size, we will have higher predictability, and therefore reduce our queues. Reduce batch size, as the panacea method for getting rid of queues, is really nasty, since it is only valid for very easy contexts, or the Clear domain in the Cynefin™ Framework by Dave Snowden, where product development not belongs. And since it is trying to cure symptoms for product development, there is of course no solution either. This also means that gaming and sub-optimising measurements comes handy, since making the epics/features/user stories smaller is stated as a good and successful approach. This indirectly means that proving that the new method or framework is working better and better is treacherously easy when counting smaller and smaller work packages, even though the real flow end to end has decreased.
And do not forget that higher predictability seldom means an increased flow, rather the opposite in product development, so we always need to go for the root causes. See also this summary blog post for the negative impact of increased hand-over waste, when having small activities.
And car queues are even too simplistic for production, not only for product development, which can be seen in Toyota’s brilliant solutions in their production, where all queues are regarded as bad. Toyota uses under-utilization (cycle time is 90% of the takt time) together with WIP (Work-In-Process) Inventories as time buffers, to achieve Just-In-Time, which makes the queues almost non-existing in Toyota’s production system, here is a blog post explaining that thoroughly.
So, except from all these bullets above, we need to add the following chain of symptoms to get it straight about the reason for queues. If we have queues, we ask Another why and also get the following scenario; “It is variability in the arrival time of the activity”. We ask why again and get the following; “It is variability in the processing time for the activity in the former process.” We ask why again and the answer are either that of course variability can happen anytime, or that we have not planned at all or at least not good enough. We get the following picture of all different reasons to queues, here is the .pdf file, symptom example – queues of planned activities with consequences:
If we go over to the car queues with the same bullets as above and convert them to be useful for car queues, the bullets will instead look like this with the needed solution added (remember that for car queues we do not care about the reason for the cars arrival time, meaning we are not interested in the processing time of the former process):
- No lane to take care of the car
=> All lanes are full; has the solution that the car arrivals need to be better planned, so they do not arrive at the same time - Lanes have wrong competence and cannot handle the car
=> Lanes can handle any kind of vehicle (total T-competence), within the regulations of course - Cars have interdependencies** to other cars
=> No; cars are independent from each other. We can see the cars as fully independent activities.
So, traffic authorities have made all lanes possible for any vehicle, and with making more lanes and by introducing tolls they are trying their best also to plan the cars in order to not exceed reasonable car queues.
As you already have understood a dependency analysis is very close to the result after a traditional analysis to find the root cause(s), and we already have the root causes of queues together with further elaborations on WIP Limits problems in this detailed blog post, where it looked like this:
But, with the dependency analysis we went a little deeper and more specific in order to find the introduced dependencies in Agile development, which had been very difficult to understand by looking only at the two root causes. This is of course valid for any way of working, and the dependency analysis can then reveal new dependencies that have been introduced compared to the ones we have been used to. And these introduced dependencies in Agile development are making the (same) root causes affecting the product development even more with symptoms that can never be fully explained per se. The necessity of increasing the T-shape for the team members, most Agilists are aware of, but all the dependencies regarding the planning part, have been constantly ignored, or maybe more correct, not understood.
And the reason for differentiating the dependency analysis and a traditional analysis to find the root cause(s), will be further explained at the conclusion of this series of blog posts, at the twist when all pieces are put together.
This was all for today’s blog post.
C u tomorrow.
*in this series of blog posts, an excessive amount of methods and ways of working have been thoroughly examined, and without asking why first on the problems of the organisation, we can see that many of them only try to solve symptoms, which means that they can only do harm to the organisation.
**also includes dependencies