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: We humans reduce the complexity by talk, text, pictures, diagrams, structures, drawings – not only by talk
We humans have reduced complexity since ancient times by iteratively and alternate talking, writing things down, making pictures, drawings, structures, etc. Organizational problem-solving is for example one area where the complexity is high from start, due to the enormous number of problems. Of course, we humans always talk to each other, which is our best and fastest channel for communication in any context, but when the complexity increases, only talk without chalk simply won’t do the job. But, in the cases when someone want to hide the truth under the carpet, we will be standing in front of a massive wall of words, an endless speech, continuously changing the subject.
This is nowadays especially true for organizational problem-solving, since claimers of a recipe do not want to hear about problems with their recipe. The reason is that this recipe is the only one they sell, and many times the only thing they know anything about. If they fail to convince that the recipe is the silver bullet, the next step is to use master suppression techniques. For example, convincing management that they only need to do orally answers, claiming it takes too long time to answer emails, or review feedback stating problems with the method or framework, claiming that the other people are against changes and therefore is legitimate to remove them from meetings, etc.
Common sense: We people cannot learn everything we want to – we have limits within our DNA
This is also an ancient common sense, and is the reason why we have different educations in the school system. And it is not only difficult to learn too many different things, it is easy to forget them, if you do not use them, or you are never good enough if you use it to seldom, which goes for both remembering things and the memory of doing things including the muscle memory. This goes for all contexts, from production to product development. We take two examples of virtual delivery teams to exemplify this.
The first example is from a production context, from Scania, truck company in Sweden. Until the beginning of the 1990s, they had several different cab teams, each of the teams responsible for the total assembly of one cab at a time. Due to the many small operations needed to assemble the cab, the team members could not learn all operations, and not any operation good enough, even when they did some specialization within the cab team. All these tremendous number of operations led to slow assembling, with a lot of quality issues, the team members were actually not good at anything good enough (and probably issues as well, depending on many persons working in the small space within the cab).
The other example is from Buurtzorg, a Dutch healthcare organization from beginning for home care, that started 2006. Buurtzorg is using small independent multidisciplinary teams* of registered nurses and assistant nurses, with freedom, trust and autonomy to govern and plan their respective work, which has been a very successful concept. Similarities between Buurtzorg teams and Scania cab teams are that they are virtual (sometimes also called integrated, or multi-disciplinary) teams, taking care for the whole delivery, with guilds as a foundation and that the respective team can bring customer value. It is though very important to add that there still are centralized and supporting functions to the teams; supporting doctors, or a wheel chair repairment, supporting procurement functions and logistic for Scania cab teams (and probably also Buurtzorg teams in order to lower the material cost and logistics), salaries and other administration (for both), etc. The biggest difference between them, is that the Buurtzorg teams can take care of all the different team operations needed to be deliver the value, meaning that they will be good at their respective profession. But, for the Scania cab teams, there were too many operations to be learnt good enough, in order to have efficiency and quality. That led to that Scania needed to adapt the thinking of the Toyota Production System, with teams as processes, where no process is similar to another process in the plant.
These two examples both show a clear context, with two very different solutions, due to the fact that they are two different sub-contexts within the clear context. For Buurtzorg the solution is independent delivery teams, but for Scania the solution is instead the Scania Production System, where there are hundreds of dependent teams producing one cab every takt time with a centralized material flow. This means that we always need to consider a top-down approach, before we can understand the solution, and not just try to copy someone else’s solution.
Interesting to see is that the Buurtzorg teams are the totally contrary to the Karolinska hospital solution, which is dividing the patient into more than 100 different value streams. The Buurtzorg team solution goes the other way and tries to take responsibility for the whole patient.
So, it is time to be very vigilant when we hear things like; “Do you not believe in the team?” as a comment, when the team need to absorb all the knowledge the company have, both regarding specialist and generalist competences and all their existing experience. And the need for the absorbing? Because, symptoms are trying to be solved due to an erroneous way of working, which is, as we all know hereby, impossible.
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. This is valid not only when operating in a complex context like new product development, but also in more clear contexts, like production. This means that as always, context is important also when talking about micro management, which is bad in any context, but where it in a product development context also can lead to making the product wrong.
So, if our context is new product development and we already are using projects, watch out for methods to transform to, having too many principles that take care of micro management problems. Micro management problems are as all problems are, impossible to solve, since they originating from something deeper rooted, meaning a high risk that the method gives us more new problems, and not solving our old ones. We need to be very vigilant if we are operating in the domain of product development for big software systems, since many new methods and frameworks only are trying to solve symptoms to a too great extent.
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 become 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 requires a new approach of estimating, for example Planning Poker, since no analyser, 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 individual answers are aggregated to the team’s average answer some way, since the total procedure is then called Wisdom of Crowds [1], or Distributed Cognition [2], as Dave Snowden thinks is a more appropriate name. But, if the individuals discuss the different answers to agree to some consensus, 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.
*Recently Buurtzorg has started making +teams, which means that they also are adding physio- and occupational therapists to the team to become a +team, instead of them only being a part of the formal network, as for the prior Buurtzorg teams.
**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.
References:
[1] Snowden, Dave. Blog post. Link copied 2019-10-31.
https://cognitive-edge.com/blog/wisdom-of-crowds/
[2] Snowden, Dave. Blog post. Link copied 2019-10-31.
https://cognitive-edge.com/blog/drachten-horses-cognition/