This is the last blog post and the wrap-up in the series of way of working history.
The attentive reader, has of course already figured out, that another option to work faster is in some cases to create a modular platform* (not only valid for hardware, but also for big systems with software), and that was not stated as an option in a former blog post. Companies with enough product volumes can calculate and see if that is a way to increase the speed. The car industry learnt this a long time ago on a market that requires new models frequently and that has the volumes. Toyota was one of the first, and learnt from Scania in the middle 1990s, a joint venture where Toyota on the other hand taught Scania about Lean production. Toyota now has its Lean Product Development with modularity and Scania has its own Scania Production System. The waterfall method on the other hand is good at decreasing transdisciplinary complicatedness, which means good at doing incremental development, but is missing the experimental step, which is needed when reducing transdisciplinary complexity. Any attempt to reduce transdisciplinary complexity without experiments, means attempting to “specify out” the transdisciplinary complexity by writing more detailed specifications, which is impossible, since we do not know what knowledge we from start are missing.
In software development there are seldom any disciplinary complexity, which is mainly in hardware development, with the need of finding new science and more advanced technology. Reducing transdisciplinary complexity/ complicatedness with iterations by doing experiments to gain a lot of knowledge, or prototypes in order to gain some more knowledge, do not differ between hardware and software, since it is not possible, as stated above, to “specify out the complexity”. But lately, with the introduction of agile at scale, the “specify out the complexity”-concept has come back, since the wholeness is divided into parts, without even thinking about how the parts would fit together, i.e., not even a hypothesis for the systems design of the wholeness. This not only means that it is difficult to make big software systems since the systems design is missing, it also means that is impossible to make modular platforms, since the requirements are divided into parts (and often before all requirements have been stated), making platforms with modules impossible to implement.
I omitted modular platforms by purpose, since it makes another clear and needed shift into complexity, in the same way as for software development, but from another point of view. So, a consequence of that the market requires speed, is that some industries need to clearly enter the world of complexity from another point of view and make modular platforms with interfaces, which in some cases need to be valid up to 10-15 years, i.e., future proof.
A short summary about the different problems that was encountered for the hardware vs software product development are:
– For hardware projects (Technology Push): You know what to do, but not if you can do it. Pre-development is a continuously on-going activity, and is only put in the projects when the technology is mature enough. The (thinking is that) hardware project only starts when the pre-development is ready, and the prototypes made are work in the Complicated domain. Experts will guide us with the needed changes after every prototype, along with increased functionality.
– For software projects (Consumer Pull): You know that you can do it, but not what to do. Of course, also new technology and advanced technical system solutions can increase the complexity, sometimes making the time needed to solve the project longer than the patience of the customers/companies, leading to a failure and a cancelled project.
We have this picture as summary:
Both is about complexity and neither hardware projects, nor software projects can be saved by better specifications made by the System department in the beginning of a project with the waterfall of working. Neither of them can in a smooth way solve this without costly, time-consuming, quality deficient rework, because this is complex. We are in the Complex domain of the Cynefin™ framework [1] even though it has been entered by different reasons. In the Complex domain the waterfall way of working is insufficient when it comes to cross-functional work all over an organisation, and with long phases as well, neither appropriate for gaining the necessary new knowledge.
So, the market of today demands the companies to frequently start in the Complex domain in the Cynefin™ framework. Most probable not every time, but the companies must know how to take care of complexity, in much more extent than ever before. And the companies need to be fast. But then we really must do something about the waterfall way of working, otherwise it will look like this. Note that we with fully parallel work need to avoid the use of the word phase.
And the picture shows how cumbersome it really is, since so many companies are stuck here, even today, even though many decades have passed since the problems first were arisen. Quoting Einstein again:
Without changing our patterns of thought, we will not be able to solve the problems we created with our current patterns of thought.
Albert Einstein
The waterfall way of working follows a certain pattern with its phases, and the silo organisation controls the projects. So, when things get tough, the answer from the silo organisation is of course better specifications and more control, the fail-safe approach. And to let employees work outside their respective manager’s area of responsibility to solve the interrelationships, that is to lose control for the managers. So that won’t happen either, when the projects start to blow their mile stones. My own experience is that, the only time employees can really work to reduce transdisciplinary complexity, with multiple free interaction in a silo organisation, is when a task force is started. This means that the customer is waiting for a critical bug to be fixed, which can result in the need of updating the systems design.
Now, I think we know our history well regarding silo organisations with water fall way of working and enough for our purpose, and as you understand the Body Of Knowledge, built up during the past half century are impressive. This is an important observation, because it means that we need to understand what of this Body Of Knowledge we cannot use anymore, but also what of it we still need. We cannot risk that a new way of working only discard the old stuff as bad, and that the new stuff will solve it all, where the truth really is somewhere in between. System Collaboration will guide us to the way of working appropriate for our organisation to flourish.
Now it is time to go back and look at our organisation and the definition “People that interact to solve activities with interdependencies” again. And also understand why I said that we needed the start definition to be short, and then I made the definition long. Because it can be made shorter for a complex adaptive system, right.
C u in the next blog post.
Next “chapter” according to the reading proposal tree is the blog post about digging into our set of principles.
References:
[1] Snowden, Dave. The Cynefin™ framework. Link copied 2018-10-04:
https://www.youtube.com/watch?v=N7oz366X0-8