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 domain. And finally, we will go through a short conclusion regarding this series.
Common sense: Planning is done top-down – no matter number of teams involved
This means that even if we transform our organisation to agile at scale, it still means that we need to start top-down, exactly the same as a single Scrum team does. Here we need to be vigilant to agile scaling frameworks, that actually scales bottom-up, losing the unified whole.
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 (especially new) product development regardless size of the organisation, smaller activities will many times effect both our efficiency and effectiveness negatively.
Common sense: We always need to test the whole product to be sure that is is working as intended
Correct. This means that even if we are trying to make smaller and smaller activities in (especially new) product development, we still need to test the whole product after we have integrated the last part of the product, no matter if we have a Continuous Integration strategy or not. See this blog post about aggregation vs integration vs false integration for more information.
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 are listening to people they think know better
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. It is an extremely high risk that we do not listen to our people when they are flagging for problems and their unsolved root causes, or issues that the new method or framework cannot solve. This is especially valid on the whole, which can be difficult to see, if also the system test becomes insufficient. 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 still having many unanswered questions (generated by unsolved root causes). This makes raised issues on the whole to be neglected and swept under the carpet, due to lack of time, or worse, due to that the framework really does not have the solution.
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 ;-).
Common sense: There are many different contexts in an organisation, so it is not reasonable that they can have the same way of working, even if the way of working looks easy, structured, neat and tidy
As stated before, agile scaling frameworks, that scale Scrum teams bottom-up, we need to be very vigilant towards, since that implies the same way of working as in production, which is not the same as product development, where agile teams belong.
Common sense: It is good to involve our people in the wholeness, especially in a big organisation where it is easy to lose the Big Picture, but not everybody need end to end or universal knowledge
As stated before, agile scaling frameworks, that scale Scrum teams bottom-up, stating that only the agile teams actually do all the work, we need to be vigilant to and not lose our common sense. Because, this means that only the agile teams create value to the customer. In the end this means that everybody in the agile teams need to know everything, which is neither efficient nor effective, and very far from utopia.
Conclusion of the series:
- Trust your common sense
- And as you already have understood:
– the reason that someone, proclaiming a method or a framework, needs to affect our common sense, is only to be able to sell you a “one size fits all” solution, a simplistic solution that will not work in a complex context, but which really is the sale argument.
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, since nothing can be preset, due to different contexts:
For horizontal scaling:
And like this for vertical scaling:
The reason is that it is the common sense or the Lean/Agile thinking, the 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. But, in this case we only scale sidewards and upwards, to be able to show that the organisational principles are scalable up to a certain size, which can be seen in this picture.
As we can see, the organisational principles are valid for quite big organisations, but we always need to keep in mind that we always need to do the planning including the systems design top-down depending on context, as it is one of our common senses. We can therefore only spread the knowledge about Lean/Agile thinking, values and principes from agile teams outwards and upwards in the organisation, but when building up a new Lean/Agile way of working or when making our products, we must always have a top-down approach. If we think of a house, it becomes straightforward. We do not make a house by starting with the rooms, first of all we need to have an architecture of the house, which is only possible to realize by a top-down approach from the requirements on the house (the functional and especially the non-functional requirements).
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. And when we get different common senses suppressed, our organisation are in even deeper trouble, since Respect for People is then impossible to achieve. This is due to the increase of problems, the increased number of unintended consequences, since the suppressed common senses lead to that severe problems that our people flag for, are surpressed and therefore never solved.
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.