This is that last blog post about common senses that are independent of scaling. Today we will 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.
Common sense: Micro management is always bad – but its presence depends on the organisational setup
Micro management is always bad, and is one type of disrespect towards our people. But today when many organisations have introduced projects, especially for companies developing products, this is many times not a big problem. Still though, organisations that only have a line organisation or where the people’s level in the line hierarchy are very important, can suffer from micro management when operating in a complex context like new product development. This means that as always, context is important also when talking about micro management. So, if your context is new product development and you are using projects, watch out for methods having too many principles that take care of micro management problems. These problems are only symptoms, impossible to solve, meaning a high risk that the method gives you more new problems, and not solving your old ones.
Common sense: Architecture is important to consider – but depends on context
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 may only have a rudimentary architecture. But, if the product will live for a decade or more, 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. 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.
Common sense: Everything is not complex
We need to embrace complexity. But we cannot embrace everything as complex. If something is not complex, rather complicated, there are another way of working to take care of a problem, and experimentation is then never the appropriate way forward. This is especially true when we mess things up ourselves by bad planning, or non-planning, making a somewhat chaotic situation, but our answer to it is to say that the situation is complex so we must experiment to get new knowledge. As we already understood by this time, we must always ask why when we have a problem within our organisation, until we find the root cause(s) to the original problem. Two of the corner stones of Lean values and principles are Jidoka and Continuous Improvement*, where the former means to find problems and solve them and the latter means to improve an already stable, standardised and well-working process, see this series of blog posts for a thorough explanation about the pillars of Lean thinking.
Common sense: Our estimates becomes better over time with our learning curve – but with continuously unsolved problems, they won’t
The more we work with activities that are similar, the more accurate we can make estimates on how long time the activity will take. But, if we continuously have problems like interdependencies and dependencies to other teams and experts, we will neither be able to make an accurate estimate nor willingly to make an estimate without a very big margin. According to Lean values and principles, one of the corner stones is Jidoka, which means that we always need to look for problems and solve them. The issue is that some Agile methods and scaling frameworks have mixed this cornerstone up with another of the Lean values and principles cornerstones, namely Continuous Improvement, which means to make something better that is already stable, standardised and well-working. This has tragically led to that the cornerstone Jidoka has been removed, meaning that the 5 whys? technique has been removed or used only for some small problems, but definitely not for organisational problems. Instead Continuous Improvement is erroneously used, for organisational problems between the teams, which only lead to sub-optimisation and no solution more than random walk in the fitness landscape. Once again, we need to ask why and solve the root cause(s), because unsolved organisational root causes will have a very heavy negative impact on our ability to learn all over the organisation.
Worth noting about estimates regarding product development is that over the years, the estimates for I-shaped teams in hardware product development have become more and more accurate. Software on the other hand, with T-shaped teams have now started their journey, a journey that is very different since the team together estimates the size of User Stories/Features instead of activities per discipline. This require a new approach of estimating, for example Planning Poker, since no analyzer, coder, tester etc. has the full knowledge about the estimate for the total User Story/Feature. Planning Poker is made individually (local knowledge), without knowing the estimate from the others in the team. This has great value if the the individual answers are aggregated to the teams average answer some way, since the total procedure is then called Wisdom of Crowds , or Distributed Cognition , as Dave Snowden thinks is a more appropriate name. But, if the individuals discuss the different answers to agree to some concensus, or for changing individual answers, the validity of the team’s estimate is radically reduced. Unfortunately, this is normally the case.
Common sense: Everybody does not need to know everything
Redundancy is important as we discussed before. But that does not mean that everybody needs to know everything. And except for that we do not have the time that everybody learns everything, or that we then will get a cognitive overload, it is not necessary either and most probably also a bad idea due to people’s different preferences of what to learn. Some people need to be specialised, some experts over an area, some generalists with broad competence, etc. No, instead we need to look for the criticality of the different activities being done, in order to find out the redundancy needed.
Common sense: Car queues is a bad example when having queues of planned activities on a team’s Kanban board
Cars in queues 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 egoistically heading for their destination. But, for planned activities even within a small team, the team members have a common goal and they know that the planned activities have interdependencies and dependencies to each other that the team members need to solve with their interactions. This means that the team have the future in their own hands, and by planning they can reduce their queues considerably. For a further detailed exploration of problems with queues of planned activities and how to solve them, see this blog post.
This was all common senses that do not depend on scaling or not and in tomorrow’s blog post we will continue with the common senses that depends on scaling in bigger organisations. And we will start with the one that are our free will.
C u tomorrow.
*Remember that on the whole only continually improvements can be done, due to the synchronisation needed between the processes when the respective process’s improvements are executed at the same time. An example is takt time change in manufacturing, where the processes can (and must) themselves be continuously improved, as long as they do not affect another part, in order to be able to improve the takt time on the whole manufacturing plant, as well as to be flexible enough due to ups and downs in the number of manufactured units.
 Snowden, Dave. Blog post. Link copied 2019-10-31.
 Snowden, Dave. Blog post. Link copied 2019-10-31.