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 discussions in the two blog post series the implications of the principles and transforming your organisation with common sense. The focus is mainly on product development, in any domain; hardware, software or a mix between them (hybrid). With product development in focus, that means that our context is the Complex context in the Cynefin™ Framework by Dave Snowden. We will also be able to make a method for production, even though this is not the main focus, as well as that Lean production already is state of art. For both product development and production, we will end up with schematic pictures in the last blog post in this series, pictures that follow our set of principles for their respective context, Complex vs Clear, when referencing the Cynefin™ Framework. This means that respective picture is domain independent, which means that the differences between hardware and software product development, after the research part for hardware is finalized, actually is not that big. But, through the series we will also discuss how different solutions have been implemented for software respective hardware, i.e., the details that are domain dependent, and therefore will not be part of the pictures.
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 the way of workings in our organisations of today. This in order to get a view from many different angels when we are making taking the first trembling steps towards our methods for product development (and production), so we do not only understand WHY our methods need to look like this, but also WHY they cannot be implemented differently.
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 for a common purpose.” 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.
Reducing the complexity for hardware product development (Technology Push) normally (development of a new platform can have complexity within the project) is normally handled in the research and pre-development phases before the setup of a project. This means that if we use prototypes within the project, in order to reduce the last complexity (rather complicatedness) in our product, this means that the engineering metaphor is to some degree applicable here, where our experts can guide us from the result of testing the prototypes. But, beware when big organizations are doing small projects, since the consequence is that all the small activities make 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, when having Consumer Pull, the complexity, a mix of not knowing what to do, and uncertainty, the customers did not know what they could get or even 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 with Consumer Pull, the engineering metaphor was never ever appropriate. This non-handled complexity and uncertainty within software 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.