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 must be done top-down – no matter number of teams involved or organizational size, and planning is context independent as well.
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 by scaling bottom-up, ignore middle- and long-term planning, as well as losing the systems design, and by that also the possibility of integrating to a unified and well-functioning 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, due to losing the Big Picture of all small activities with interdependencies, as well as not reducing the transdisciplinary complexity and complicatedness.
Common sense: Architecture is important to consider – but the importance is highly contextual
The level of structure needed for the architecture of products and services is strongly context dependent. If we are going to make an application within 6 months that will live only up to a few years with no security needed, may only have a rudimentary architecture, since we can refactor also the architecture if we get structural deficiencies. But, if the product will live for a decade or more, or need high security, requirement traceability is important, etc. or combined, the architecture is extremely important from start, in a top-down approach as stated earlier, to avoid too many patches in the code further on. The latter case means that building the software architecture and the code at the same time, or constantly add new architecture before coding is very risky, with the risk of having a dead software product within a couple of years, or a product that does not work. The same goes for hardware products, giving a product that is too expensive to produce due to patches, requires considerably expensive updates at the customer or in worst case leading to a need of changing to another product at the customer.
So, we need to be vigilant to methods and frameworks claiming emergent design/architecture is the thing even for big systems, since the risk taking for the organization will be enormously high of making the wrong or non-working product wrong.
Common sense: We always need to test the whole product to be sure that it 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 refers 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 events are always necessary for the integrating to a wholeness, but not to use false cadence
Cadence is in product development what takt is in production, which means doing things in parallel, but never the same kind of activity at the same time. But it is a big difference between them, since there are more of our organizational principles that need to be fulfilled in a complex context like product development. One of the phases for product development is therefore the systems design phase, reducing the transdisciplinary complexity and complicatedness, and which is does not exist in production. Trying to give this competence to the teams at lower levels, also means that the systems design is done too late, and where everyone’s responsibility also means no one’s responsibility. Or the other not suitable way is that the teams need to wait for the systems design, due to no long-term planning.
To have work that is sequenced is used to avoid that some resources and competences become a scarce resource, which is interestingly also context independent. The failure of false cadence has the main reason that we humans cannot learn or remember an infinite number of things, which means that if we try, we will be bad at many things, regardless if it is our memory that is overloaded or muscle memory that is used too infrequently. Of course, all humans do not like to do all different things, which also is a problem., since just because you like house carpentry, does not mean you like (or have the competence) to do the architecture of the house. For product development we also add the need of system design in the first phase, as mentioned above. This phase is necessary so that the different disciplines in the design phase can work in parallel towards a common Integration Event.
This means that when a time box for many teams ends, we will integrate, verify and validate the parts in product development and aggregate parts in production, see this blog post for more details about integration and this blog post about the necessity of sequencing, by looking to the similarities between production and waterfall. When several teams making something bigger, the integration events are really important milestones, synchronising the teams at integration, verification and validation of the whole. At the same time, it does not mean that the integration events need to be every x week, instead the part of work for some of the teams, that need the longest lead time, sets when the next integration event should be. And the same goes for other teams between their integration events, an exact interval is not a must, since it most only will generate an unnecessary need of scarce (centralised) resources at the same time. When using the term Integration Event, it is clear that the teams working with their part to make a delivery to a common Integration Event, where the deliveries are integrated, verified and validated to a bigger delivery. It is important to state that these Integration Events, in most cases regarding big scale product development, not necessarily is a complete customer delivery. See this blog post for a thorough explanation about false cadence problems.
Since product development is a complex context, and by that not domain dependent within its context, it means that we will have the same symptoms no matter the domain, when we are not fulfilling our organizational principles. Introducing false cadence (sub-optimization) will therefore always lead to that, positions on the wholeness, centralized ones or the ones that are reducing transdisciplinary complexity or complicatedness, are needed too late and in a greater amount than their numerical. This has happened in hardware and/or software in governments, bank and finance and the autonomous vehicles industry the last years, when introducing methods and frameworks for agile at scale.
It is worth mentioning again about the risk when transferring a method from a non-complex context to a complicated or complex context. Of course, it is good if we can have autonomous teams and decentralized decisions like in production, when possible. But, to remove planning, add false cadence (everything at the same time) and false integration (no systems design, just aggregation), but calling that cadence and continuous integration, only means sub-optimization of the whole organization. This means that built-in root causes remain in the way of working forever, leaving the organization in frustration over the inefficiency and ineffectiveness. Remember also that mindset and culture are effects (very late symptoms) of a malfunctioning way of working, meaning that we can never wish for them, i.e., they are only an effect (a bi-product) of our way of working.
Common sense: Interdependencies and dependencies will not disappear just because we use cross-functional teams, they will at most only be different (and in worst case, due to non-existing long-term planning, also be very late discovered)
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.
This means that in this case, it is actually a very bad idea to bring in coaches, that try to make the team more collaborative or improve the team dynamics, since that is not the root cause to the seen problems. To focus on the symptoms are always a bad idea, but in this case, which will be like trying to force a screw with a hammer, it can really destroy the team spirit, and maybe the team trust as well.
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 example 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 cannot 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 needs to affect our common sense is because they sell something that actually is not working as proclaimed. It can be a method or a framework, often backed-up with heavy commercial, trying to convince us that the solution is a “one size fits all” solution. Often the method shows a simplistic solution, that actually will not work in a complex context like product or systems development, but where the sales argument is that it is universal. And since the method or framework looks simple and structured, like all work in non-complex context is, the appearance is treacherous. There has been a desire of finding new methods for the last half century, but with meagre result, which Dr. Russell Ackoff brought up already 30 years ago, see this blog post for a dissection of his mentioned anti-systemic methods. This journey has continued and nowadays, especially when having big organizations doing big software systems, where it is desirable to find a method that is well-functioning for also the new-development part of the whole software life-cycle. For hardware products, both product development and production, there are already well-functioning methods for the whole life-cycle. See this blog post series for a deep-dive into Dissolve the problems in organizations, clearly showing the need for finding and solving the root causes (fulfilling science) to our organizational problems, no matter way of working, in any context or domain.
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 set in advance, 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 principles 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 is in even deeper trouble, since Respect for People is then impossible to achieve. This is due to the increase of the number of problems, the increased number of unintended consequences, since the suppressed common senses lead to that the severe problems that our people flag for, are suppressed, or the symptom are solved, 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.