This is the final blog post and the wrap-up of the Product value flow in the Cynefin™ framework, by Dave Snowden.
And here is the picture of the total Product value flow in the Cynefin™ Framework again.
There also at least three important things to be considered when we are talking about the Product value flow, and how we must not do. They are always important, but especially when our organisation is making adaptations to the current way of working or completely transforming to another one.
1. The Product value flow can never be static, since market need will frequently change, which require new products or services of different size, that need to come fast to the market. This means that flexibility in the organisation’s actual way of working is needed in order to meet this. Remember also that at the introduction of projects in the 1950s, the reason was that we needed structure, coordination and someone responisible. But, that we also got a great flexibility in starting different projects in any size and at any time, due to that projects are loosely coupled to the Line organization, which is very powerful.
At ING the Line organisation is loosely coupled to the tribes and squads doing the actual work [1], and at Spotify they state that there squads are loosely coupled, but tightly aligned [2], where the latter means not only that they need to have the same goal, but also that the journey to the goal with all its interdependencies between the teams and experts, are common. If the Line organisation is glued together with the product development, tremendous problems can arise when the product development’s projects/products needs to change in size or quantity due to new products or services, i.e. new market need. To avoid problems, the teams must be possible to put together to different programs in any combination, and the size of the teams must be possible to change as well. Small, middle and big programs in different numbers. Also, at Spotify they look over this every three month to always have the best set-up of the squads and tribes.
Note! There is a big danger if the environment is too well angled before an adaptation or transformation to another way of working starts. The reason is that with a distorted reality, it looks ok to implement a static product value flow because everybody already knows what to do. And having static organisations, is actually a decrease of flexibility compared to the flexibility that was introduced with projects as stated above. This is especially common when introducing frameworks using Agile development to some extent, where the software architecture and the systemisation, first are done and it is only to start coding in the new framework. And then, it is not only the new way of working that has a walk in the park, the old way of working did finish on a walk in the dark in order to decrease the number of problems before the introduction of the new framework, making any rational comparison totally impossible.
2. Avoid having multiple Product value flows; one for new products, one for variants, one for maintenance issues, etc. Try instead to think of the Product value flow as it is shown in the Cynefin™ Framework, since it is rather different contexts then different flows that are of importance. Remember also that the more different flows in the process descriptions, the more process documentation to take care of.
3. Many times, especially at banks, there is from beginning an Operational value flow that covers the business, and with the introduction of IT and software development, the latter becomes a separate Product value flow. This is also a very difficult setup, since there is a very high risk that it becomes a water – Agile framework – fall, distancing the product development from the customer, making high risk for making the wrong product in the increasing digitalised world that almost always is a Consumer Pull. And during our digging into the history, we already know that Consumer Pull in combination with software development doing waterfall way of working, was extremely painful (details here). So, we need to stick to only one consistent end to end product value flow, no matter where in the Cynefin™ Framework the starting point is.
When understanding the Cynefin™ Framework, we can see that the last two bullets are both necessary and possible to do. A static Product value flow must really be avoided as stated in the first bullet; it is a very rigid solution, just compare with traditional projects that can be any size or quantity in a silo organisation with projects (see this blog post for details).
When it comes to development of new products, I think like this when the Product value flow are shown in the Cynefin™ Framework:
The seamless development of new easy-producible complicated products and services that delight the customers, always starts with complexity.
And when starting directly in the Complicated domain where experts can help, of course also requires a seamless flow to the Obvious domain, but if we get Product value flow right, there is no matter what domain we start in, since we only have one flow.
In the coming series of blog posts, we will continue to look into our start organisation definition “People that interact to solve activities with interdependencies to achieve the purpose*”, and first it is time to concentrate on the last part of it, the blog post series with the “activities with interdependencies” part, and see what principles it will generate.
C u soon.
*With organizational purpose means; manufacture a product, service, develop a new product, etc., with a certain price and quality. We are not talking about the nowadays popular Purpose statement, that is only a continuation of the easy-gamed value and mission statements. In this kind of statements, behaviour, properties and core values of our employees are stated, which is more of wishful thinking, since they will only emerge from multiple interactions within the organization. Since the interactions in turn, also emerge from our way of working, one can believe that if the purpose of the organization is not fulfilled, neither will the emergent behaviour and properties of our organization be what one could wish for.
References:
[1] Rigby, Sutherland and Noble, “Agile at Scale”. Harvard Business Review, June 2018 issue.
Link copied 2018-09-05: https://hbr.org/2018/05/agile-at-scale
[2] Spotify’s video about their Culture. Link copied 2018-09-22.
https://vimeo.com/85490944