The first trembling steps towards Our Methods – part 1/5 – Introduction

Welcome to this series about our first trembling steps on the way to Our Methods. Our Methods will of course build on Our set of principles and the implications of the principles. The focus is mainly on product development, hardware, software or a mix between them, since product development covers all the domains in the Cynefin™ Framework. From that total, we will also make a method for production.

The series will start with a categorisation of the principles to make it easier to understand in what category of principles we get the biggest problems in our organisations of today, to get a view from many different angels when we are making Our Method for product development.

Especially the categories reduction and integration are the most interesting of the categories, since the former is still valid today, but where the latter has become cumbersome with the introduction of speed to the market, but also the more complexity when making both the products and platforms with modules for our products. As you will see it happens to be the reduction category that will be exclusively from the activity side of our system start definition “People that interact to solve activities with interdependencies” and the integration category that will be exclusively from the people side of our set of principles. We will also bring up the problems with the popular engineering metaphor; regarding the pair of reduction and aggregation, within different contexts.  See also Dave Snowden’s blog post for details about the engineering metaphor and its poor utility regarding complexity.

By looking at the principles from this categorisation perspective, we can at the same time see what has happened during the history of organisations and the change of the market and see what differs between the problems they could solve in the 1950s and the problems we cannot solve today. This will give us further understanding to that Our Method not only is following Our set of principles, but also that we are solving the problems in the current organisations of today, not adding other problems and definitely not trying to solve symptoms. We will mostly focus on silo organisations and organisations doing agile (where the agile teams is a virtual structure, and not an Agile organisation), since they are the most common ones, since any method trying to solve organisational problems in organisations but never asking why on the original problems, can only be sub-optimising per se, see this problem-solving series for the details, or here for a deep dive into the theory.

After that we will start looking at Our method from the view of a small company and from that discuss what problems that arise automatically when a company gets bigger. We do this both from the perspective of no changes in the market and the market of today, to really be able to differentiate the organisational problems that depends on growth from the ones that depends on a changed market. This is vital.

The engineering metaphor requires some extra explanation. It fits the work in silo organisations with KPIs on the silos, that do product development but not using project, like a glove, by first reducing the problem into many small activities that fit each managers area of responsibility and then put the result together. But, there is actually no difference to organisations doing agile, where the activities also are small. Putting the parts together is a mix of integration and aggregation, where the integrations mostly is done within the silos and teams of teams for agile, and the aggregation is mostly done between the silos or team of teams, since there is actually no one responsible for the total product. The latter is a hand-over comparable to hand-overs between processes in Lean Production, see this blog post for more details about Concurrent Overlapping Disciplines, meaning that proper system tests are missing.

Since the complexity for hardware product development (Technology Push) normally (development of a new platform can have complexity within the project) has been handled in the research and pre-development phases before the setup of a project, the engineering metaphor is appropriately applicable in a project for hardware product development, but with the consequence that all the small activities especially for a big company makes the development very, very slow. This is a tremendous loss of Flow Efficiency mostly depending on the phenomena of “too much of everything” waste in form of meetings, interaction chains, activities, emails, etc, which is a consequence of specialisation, but also a loss of the Big Picture. With low Flow Efficiency also the effectiveness will indirectly suffer with the right product too late, or the wrong product at the right time ;-).

With software product development instead, that is almost always Consumer Pull, the complexity, a mix of not knowing what to do and that the customers did not know what they could get or wanted, are put inside in the project instead of in research and/or pre-development as for hardware Product development. This means that for software product development in a traditional organisation, the engineering metaphor was never ever appropriate. This non-handled complexity within the projects is a big reason to the tremendous much higher failure rate for the software projects compared to hardware projects in a traditional silo organisation with waterfall way of working.

In tomorrow’s blog post we will go into the categorisation of our set of principles.

C u then.

Leave a Reply