We start to summarize the need of the market and what that means.
The market is volatile and needs speed, flexibility and deliverables that becomes more and more complex for an organisation to find the solution to. The solution involves more and more the total organisation, as well as the customers and end users.
Now when we know the market need, we can negate its need as well and put at the top of the Prefilled Problem Picture Analysis Map for organisations. That will give us a problem description when we cannot meet the market need. The symptoms in the map will cover any organisation and its deliverables.
When we ask why we have this problem, we can find multiple symptoms and after many why, also their connections to the root causes, our negated principles.
As already mentioned, faster can also for hardware (and software) development be solved with platforms, that as a consequence put you into the Complex domain in the Cynefin™ Framework by Dave Snowden [1] for the whole organisation. But, for software development, faster can also mean that as soon as you know what to do, you can develop the deliverable incrementally in the ordered domains, when closing the gap. Minimum Viable Product, MVP, is incrementally done, and is commonly used as an abbreviation for a deliverable that has value for the early adopters and that provides feedback as well, so we know that we are on the right track towards customer satisfaction.
But, with a hardware platform you can have the same thinking, and change existing (and already working) modules incrementally. This is fully used in the car industry, which for every new car model program also have changed some modules in the platform, to cut cost, make the functions better like noise, comfort, air pollution, etc. So, when you have the total platform ready and make an existing module better, you are in the ordered domains for the platform, but of course the module itself can require a team to start to investigate in the Complex domain. But, since there is already an existing working module, there is low risk. If the new module is not ready to the release date of the new car model, you just take the old module, you are only risking a worse function then expected or too high cost. This is also the essence of working with multiple concepts, which is a way to lower the risk.
So, for any organisation to work smoothly with low risk, the key is really to understand the Cynefin™ Framework [1] and what domain you are in and when there is a context shift to another domain, deliberate or accidental. We need also to be able to work in the Obvious, Complicated and Complex domains. And the more uncertain we are, especially the more complexity we have, the faster we need feedback, i.e. it must be very short cycles in the Complex domain. The more certain we are, the longer the cycles can be in product development. We also need to make continual Integration Events to get feedback of the total deliverable. Both short cycles and continual Integration Events are very important to achieve fast feedback in case we are on the wrong track regarding what the customer really need or to track faults, quality problems, EMC problems for hardware products, etc. as soon as possible. And with the market need of flexibility*, fast feedback is a must, when we have any kind of uncertainty, since the market will inevitably change and our competitors can find smarter, faster and cheaper solutions than ourselves.
To sum-up the need of timely Integration Events, it looks like this:
We are doing activities in order to get timely feedback at Integration Events that depends on if:
– we need completely new knowledge (complex) – and of course we have no experience of this knowledge, since we do not know it
– we have knowledge and experience about parts (complicated) – but, we have the experience how to get the knowledge (by prototyping)
– we have the (currently best) knowledge (obvious) (currently best, meaning that we can always become better) – we have the total competence (knowledge+experience). Because we have all the knowledge and experience we need, the feedback is only a follow-up of the current status, if we are on track. This means that the activities can be very long.
In a production context the processes are highly repetitive, and the parts are not integrated, instead they parts are aggregated together to the complete product, i.e Aggregation Points. In Lean production for example, quality issues, muscle, finger and back strain, etc. have all been weighed together, and at for example Toyota, the processes have a cycle time of as low as 2-4 minutes. Every process step can be seen as one activity in the total set of activities aggregating up to a car, meaning we are talking about feedback as follow-up to make our repetitions even better. So, in production we are not talking about feedback to get new knowledge so we can continue with the next process, since the process and all its activities is already planned. Actually the whole product (a car for example) is already planned and will be done according to the currently best competence (knowledge and experience). Instead the future cars can be done even better (quality, flow etc.) when we continuously get more and more feedback, meaning we can update our respective processes. Note that no matter of the length of the production processes, we will get the same activities done and therefore get the same feedback, meaning that the takt time in the production unit depends on other parameters.
Regarding flexibility, our organisation need to be prepared for not only making smaller changes of the outcome from our existing team of teams to adapt to customer need, but also be flexible enough to make changes in how we organise our teams and team of teams to achieve the outcome. That means that our working teams cannot be stuck in an inflexible Line hierarchy either, see this blog post for more information.
These are our first principles, derived from the market need.
Principle: We need to be able to work in parallel (if needed).
Principle: We need to be able to work incrementally (if possible).
Principle: We need to have timely* Integration Events** end to end – (to get just-in-time* feedback).
In a picture the principles we have found so far will look like this.
In this blog post series, these principles will be visualised in the Cynefin™ Framework. This will depict the Product value flow that our organisation need to be able to handle in order to bring our product from the first thinking and all the way to release, to meet the market.
And if we negate our principles to get root causes and put the latter in the Prefilled Problem Picture Analysis Map, it will look like this.
In the next blog post there will be some more explanation of the negating of principles and also the Prefilled Problem Picture Analysis Map itself.
Next “chapter” according to the reading proposal tree is the series of blog posts regarding the principles from the “activities with interdependencies” side of our start organisation definition of our organisation. See also this blog post for a deep dive into the product value flow in the Cynefin™ Framework.
*according to context and the needed flexibility, which means that we need to understand, nourish and be able to do work in every domain of the Cynefin™ Framework, and also recognize and promptly respond to context switches, deliberate or accidental.
**in manufacturing we have Aggregation Points, which is a special case of Integration Events taking zero time.
References:
[1] Snowden, Dave. The Cynefin™ Framework. Link copied 2018-10-04:
https://www.youtube.com/watch?v=N7oz366X0-8