Today’s blog post is about the contextual aspects and need to be considered separately, since it is a very important aspect, but easy to get wrong.
The product’s context
Our product’s context is vital because it reveals how we shall work, and that is why the Product value flow in the Cynefin™ framework is so important to understand, see earlier blog posts with the same name. The Product value flow* shows the journey of our system product or service from start, which can be anywhere along the value flow, to goal, hopefully without loop backs.
Complexity- on different organisational levels
Everything we do about our product or service is not complex, but if we have complexity, we are in the Complex domain in the Cynefin™ framework. Depending on what level the complexity is on within the product, sub-parts or the total, it can be taken care of by a team, a team of teams, etc. and all the way up to the portfolio level team, or any needed mix to solve the complexity. A mixed team is many times necessary in order to reduce interaction chains and have the real customer close, for achieving fast feedback.
Integration Events need to be timely
When we are making the alignment, what we need to do and when, our goal is to get just-in-time (timely) feedback at our Integration Events. With that is indirectly meant that we need to set the right time box length depending on the context of the activities, between consecutive Integration Events. Which also means that we cannot always set a static time box length, or have takt time.
Time boxes
But, to be able to set the time box length right, depends on what domain in the Cynefin™ framework the teams are working in; complex, complicated or obvious, and of course also other things like lead times, that is common in hardware product development. The team with the longest lead time decides where the next Integration Event will be in time, and indirectly sets the length of the time box. The time box length then becomes a part of the total critical line. Within the time box we of course we have Daily Builds, Continuous Everything, follow-ups and other check points.
Regarding the length of a time box a rule of thumb is; complex means that we can have really short time boxes of hours and days, especially when experimenting in software development in order to understand what the customers want. The ordered means that a longer time box is possible, which also yields for software development when we know the customer requirements, since we nowadays have Daily Build and Continuous Everything already in the software development process.
The Integration Events need as already stated to be timely, so we have just-in-time feedback. This means that it is important to have the right length of the time box also to avoid start up and close down waste, what is called Project Administration waste, when using too short time boxes, where the details can be found in this blog post.
If appropriate, a time box to the next Integration Event, can for some teams be divided into sub-time boxes, sprints, and after every sprint we can have a very short check point if the team is on track, problems that have arisen, document reviews, code reviews etc. The check point should really be short, since it is at the Integration Event the value is integrated to a sub-product, MVP, full release, or just to get feedback of the team of teams’ total work in a sub-integration. As stated before; with Daily Build and Continuous Everything for software development, the need of bigger check points between the Integration Events have decreased.
The teams working in parallel do not necessarily need to have the same feedback check points in time, since it depends on which context each team has between the Integration Events, how synchronised their work is, etc.
But, if a mix between complex and ordered tasks are worked on until the next Integration Event, there must for every team in the complex domain, exist a team with a concept in the ordered domains, to be able to set a length of the time box. Time box length will also be elaborated further on in a later blog post.
Problem-solving and continually doing improvements
To continually do improvements are important, but most important are to solve problems within the organisation. And if we do not understand the differences, we are in deep trouble. See this series of blog posts about a deep dive into Toyota thinking and the differences between problem-solving (Jidoka) and improvements (Continuous Improvements**)
Now we have considered some important aspects regarding the implications of our set of principles. A good example of an early way of working that was not only successful, but that can be seen follows our set of principles to a very high degree is the way of working from the famous HBR article “The New New Product Development Game” [1], which in this series of blog posts are broken down principle by principle.
Tomorrow’s blog post will handle the continuation of our total organisation definition, since we can now make it completely full. C u then.
Next “chapter” according to the reading proposal tree is the series about Our first trembling steps to our methods. There are also some different deep dives to dig into; Sequential or parallel which is the best series, the Flow Efficiency series, Aggregation vs Integration vs False Integration, WIP limits in agile development are suboptimising our organisation and finally The New New Product Development Game in our set of principles series.
*when we are building our Product value flow in order to meet the market, flexibility is a necessity, which was also brought up in the first part of this series about the organisational aspects, but also in the former series of blog posts about the Product value flow in the Cynefin™ framework, i.e. a morphological organisation is needed.
**remember that on the whole only continually improvements can be done, due to the synchronisation needed between the parts when the respective part’s improvements are executed at the same time, for example takt time change. The parts can (and must) themselves be continuously improved, as long as they do not affect another part.
References:
[1] Takeuchi, Hirotaka and Nonaka, Ikujiro, ”The New New Product Development Game”. Harvard Business Review, Jan 1986 issue.
Link copied 2018-09-05.
https://hbr.org/1986/01/the-new-new-product-development-game