This is the last post of this series and also the last blog post about common senses that are dependent of scaling. Today we will once again cover the scary part when our free will is strongly affected by external forces wanting us to ignore our own common sense in our own context. And finally, we will go through a short conclusion regarding this series.
Common sense: Smaller and smaller activities cannot always be better
Correct, which we already elaborated on earlier in this series in this blog post, instead it always depends on context, and for product development regardless size of the organisation, smaller activities will many times effect both our efficiency and effectiveness negatively.
Common sense: Respect is always needed, not only within the team themselves
This is a very important common sense, since respect is always important, no matter of size of the organisation, no matter on what level or position an employee with an idea sits. This refer to one of W. Edwards Deming’s famous quotes:
Everyone is already doing their best; the problems are with the system … only management can change the system.
But, it has unfortunately too many times been misinterpreted. What it states is that only management can change the system, and that is because they are the owners to the processes of the system. But it does not state that management themselves necessarily understands what changes to do on the system to make it better, which is the misinterpretation of the quote. If we misinterpret this, it will give us a reason for not listening to our people raising way of working issues on the whole, leaving them to only improve within the team. The misinterpretation can be of two main reasons;
1) Management really think they know better or
2) The implementation of a new method or framework is not understood by management and can therefore only be executed exact as it is prescribed.
The former of them is probably not so common in organisations, especially not for product development, but the latter is scary, since then the organisation is out of control of the transformation to a new method or framework. This also means that the transformation of the organisation’s way of working most probably is controlled by external consultants sometimes most of the times without any knowledge of neither the organisation’s domain, nor context. And as we understand, now it starts to get really scary, with extremely high risk that we do not listen to our people when they are flagging for problems, or issues that the new method or framework cannot solve, especially on the whole. The risk for disrespect of people within the organisation is very very high and even more if we have a transformation that is behind schedule, making raised issues on the whole to be neglected and swept under the carpet, due to lack of time.
Common sense: Integration points are always necessary for the integrating to a wholeness, but not to use false cadence
When several teams making something bigger, the integration points are really important milestones, synchronising the teams at integration and verification of the whole. At the same time, it does not mean that the integration points need to be every x week, instead the part of work needing longest lead time, sets when the next integration point should be. And the same goes for the teams between the integration points, an exact interval is not a must, since it most probably will generate an unnecessary need of scarce (centralised) resources at the same time, see this blog post for a thorough explanation about false cadence problems.
Common sense: Interdependencies and dependencies will not disappear just because we use cross-functional teams, they will at most only be different
Teams that work together will always have interdependencies and dependencies to each other and to common experts. Of course, we always need to try to reduce them as much as possible, but the most important is that we can keep track of them when we have them. To connect teams that have been autonomous from start can be tricky, since their respective way of working may not consider interdependencies and dependencies to other teams and experts, since their old wholeness were only one team itself.
The solution with having a big time-margin when teams are dependent to each other, is not a very good solution, since it effects the flow efficiency negatively. No, the solution is to bring up all interdependencies and dependencies so the teams clearly can see them and plan thereafter.
Common sense: Queues on the teams’ Kanban boards must really not be compared to car queues
As stated in an earlier blog post, cars have nothing in common, aside from that they are cars and driving at the same time. They have neither a common goal, and nor interdependencies or dependencies to each other. They are only egoistic heading for their destination. Making the comparison of a team’s queue of activities with car queues is bad, but comparing a bigger organisation with many teams and their Kanban boards with car queues is very bad, since now the interdependencies and dependencies increase dramatically. This means that the organisation really needs to take care of them, in order to reduce the queues on the teams’ Kanban boards, and once again the organisation’s own future is in the hands of the organisation itself, and not in any blurry comparison with car queues.
Of course, problems will always arise due to for exemple variability, meaning that we need margins in the time plans and overcapacity at bottle necks, even though thorough planning has been made. But, without planning, we will get a chaos (which we can not blame on the variability) and then the comparison with the car queues is fully reasonable, but only then. So, if we get queues because we have a bad or non-existing planning, we cannot blame variability, but our own stupidity ;-).
Conclusion of the series:
- Trust your common sense
- And as you already have understood:
– the reason for someone, a method or a framework trying to affect our common sense, is only to be able to sell you a “one size fits all” solution.
But, as we already know, a “one size fits all” solution does not exist, since any solution is always depending on the domain and the different contexts within the domain, and of course also the size of the organisation.
The different domains, contexts and size matches also the three different possible scaling that we addressed in the first blog post of this series; scaling out to the other parts with other contexts within the organisation, scaling up to other contexts of the higher levels within the organisation and secure that any part of the organisation that is big, can manage also that needed scaling for their team of teams.
This means that the original pictures of the horizontal and vertical scaling instead must look like this:
For horizontal scaling:
And like this for vertical scaling:
The reason is that it is the common sense or the Lean/Agile thinking, values and principles we are scaling outwards and upwards, not a certain “one-size fits all” method or framework that maybe did not even meet our common senses without scaling in the first place.
As last words in this series, it is important to state that the number one common sense to start to follow is of course Respect for People and if we lack that, our organisation is in deep danger. And as we also stated, listening to our people when they bring up problems and also taking care of the problems, is very important, since problem-solving in our products as well in our organisation is another very important common sense. So if we not respect our people, it has high risk to lead to that we cannot solve our organisational problems, meaning we are once again in deep danger. As we see, these two common senses are closely related to each other and disrespect of people, too many times makes the organisation become stalled, unable to solve its organisational problems, which Deming pointed out time after time.
That was all for this series of blog posts. C u soon again.
Next “chapter” according to the reading proposal tree is the series of blog posts about Lean thinking.