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 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.
I omitted it 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 then the customers/companies patience, 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  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.
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 transdisciplinary with multiple free interaction in a silo organisation, is when a task force is started, i.e. the customer is waiting for a critical bug to be fixed.
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 passed 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.
 Snowden, Dave. The Cynefin™ framework. Link copied 2018-10-04: