An analogy between continuous product development and continuous improvement
While developing products, there are two common modes. One is creating development projects when needed; and the other is doing continuous product development. While improving organizations or changing things for the better, there are two similar modes. One is creating change projects when needed; and the other is doing continuous improvement.
In this article, we would like to contrast development projects vs. continuous product development with change projects vs. continuous improvement.
Development Projects vs. Continuous Product Development
Development Projects…
Development projects have a clear beginning and end, and they are considered independent from each other. Development projects are created when needed, thus, they often happen at intervals. When we organize development work into projects, usually they are large projects for big releases. In the beginning, we plan the project in detail, then execute the plan and release it in the end. The internal checkpoints in traditional development projects are usually phase based. Development projects assume high certainty, thus the general mental model is “plan & execute”.
Continuous Product Development…
Continuous product development is open-ended; we can’t know when it will end. Therefore, we continue in short iterations and usually small releases until it is not worth furthering it any more. Each iteration leads to small product increments, which are delivered for both feedback and value. Continuous product development acknowledges high uncertainty, thus the general mental model is “inspect & adapt”.
LeSS suggests moving from development projects to continuous product development. The below are a few related LeSS experiments.
Avoid…Projects in product development / Try…Continuous product development
Try…Continuous product development rather than projects
Let’s look at the below aspects to understand why it is suggested so, as well as what factors drive and restrain them.
- Independent vs. Continuous
Projects are independent from each other, and each project has its own goal with its own constraint of scope, time and cost. In product development, projects are usually associated with releases. Are those releases independent? Not really, each new release is based on an old release. I once heard from a CTO who said “one challenge for them is to end a project”. After learning to distinguish between products and projects, he realized that they were doing product development, and applying projects in their product development just did not fit.
As different project managers and project teams work on different projects, they try to optimize for project goals at any cost. If they were independent, that would be fine. When they are connected, short-term local optimization causes long-term global problems. On the contrary, the same product owner and development teams would work on the product, release after release, in continuous product development. This makes it more likely to balance short-term needs and long-term goals.
- Plan & Execute vs. Inspect & Adapt
Strictly speaking, “plan & execute” is not tied to projects. However, in practice, the bounded nature of projects encourages us to plan in detail upfront and wish that only execution is needed during the course of projects.
In order to make “plan & execute” work, a necessary condition is high certainty. For example, the requirements can be fixed in the beginning and there will be little change afterwards; the requirements necessary for certain outcomes can be predicted with high certainty; the technologies used to implement those requirements are mature, and there will be little surprise during the development; accordingly, we can make more or less perfect estimates. However, these conditions often do not hold true in product development; there is full of uncertainty instead. Therefore, we must inspect & adapt in short iterations to discover and deliver value.
- Big batches vs. Small batches
Why put big batches of requirements rather than small batches into development projects?
In some cases, it is claimed that all requirements are necessary to deliver value. It is actually one requirement being split into many interdependent sub-requirements. But is it possible to split differently into many independent requirements? Most likely yes, with the proper skill. Then we don’t have to put all of them into the same project, and they can fit well into short iterations.
In other cases, large projects are motivated by the high transaction cost involved in planning and releasing. Planning cost comes from the work necessary to start developing certain requirements; releasing cost comes from the work necessary to release requirements to customers and users. When they are high, we tend to run large projects to develop in big batches. Moreover, this is self-reinforcing. The high cost is caused by our inability to plan and release effectively, but when we plan and release only rarely, we don’t have much chance to develop our ability, so that the cost remains high, which further justifies large projects. The alternative is to plan and release in small batches with short iterations, then we get better at planning and releasing, as we do in continuous product development.
Change Projects vs. Continuous Improvement
Change Projects…
Change projects are projects, thus, have a clear beginning and end too. They are created for improvement, every now and then. Other names for change projects are transformation projects, framework adoptions, etc. Changes in change projects are usually large, leaving daily and incremental improvements out. Traditional change projects are planned, executed and completed with internal checkpoints. Like development projects, change projects assume high certainty, thus the general mental model is“plan & execute” too.
Continuous Improvement…
Continuous improvement continues forever, as we will never reach perfection. Retrospective is the most common mechanism for continuous improvement. This can be at various levels such as team, department or organization, as well as at various intervals such as once every sprint, quarter or year. In continuous improvement, we do both Kaizen (making small and incremental changes) and Kaikaku (making big and radical changes). Like continuous product development, continuous improvement acknowledges high uncertainty, thus the general mental model is “inspect & adapt” too.
LeSS suggests moving from change projects to continuous improvement. The below are a few related LeSS experiments.
Avoid…Agile/lean transformations or change projects
Try…Agile/lean adoption forever
As you may have noticed, LeSS uses “adoption forever”, rather than “continuous improvement forever”, even though it is the same message. In my experience, “adoption” is more often associated with change projects. Moreover, “adoption forever” sounds awkward. Anyway, let’s still look at the below aspects to understand why it is suggested so, as well as what factors drive and restrain them.
- Independent vs. Continuous
Change projects imply getting change done. We stop after it is done, at least for a while. This conflicts with the never-stopping nature of continuous improvement. In fact, the difficulty in answering the question of “are we done with the transformation” has hinted at the conflict.
Lack of continuity is a common problem for improvement. When each change project is treated independently, we move to one direction with project A, then move to another direction with project B. After several transformations, we don’t make much real progress. What is the object to be changed? The whole organization as a system. Like our product, it evolves by carrying the legacy. When we have different project managers and project teams focus on getting specific changes done, it makes short-term local optimization more likely, causing long-term global problems. In the mode of continuous improvement, however, it is the same group of people - managers, coaches and teams - who try to introduce change after change and improve the whole organization forever.
- Plan & Execute vs. Inspect & Adapt
Change projects are often managed by a similar “plan & execute” approach. The same necessary condition is high certainty. This requires the same necessary conditions for high certainty. For example, changes are solutions for problems, and they need to be proven - best practices that would work under any circumstance; the change process is mechanical - we just need to impose changes onto people, then we get desired outcomes. However, those are far from the reality; the organization is a complex system with high uncertainty. Therefore, we must inspect & adapt to make real improvements.
- Big batches vs. Small batches
Why put big batches of changes rather than small batches into change projects?
In some cases, we need to change a few things together, in order to achieve the desired outcome. For example, as indicated in the Star model, if we only introduce a change in processes, there will be inconsistency with other elements, thus, one change is not sufficient.
On the other hand, it is also common that unrelated changes are bundled in a large project. Similar to large development projects, this can be motivated by the high transaction cost involved in planning and releasing. Here, planning cost comes from the work necessary to initiate certain changes; releasing cost comes from the work necessary to adapt to those changes. When they are high, we tend to run large projects to change in big batches. Again, this is self-reinforcing. The high cost is caused by our inability to change, but when we change only rarely, we don’t have much chance to develop our ability, so that the cost remains high, which further justifies large projects. The alternative is to change in small batches, then we get better at changing, as we do in continuous improvement.
Conclusion
Overall, there are many similarities behind continuous product development and continuous improvement. Through this analogy, we can understand better why we move towards them as well as what factors drive and restrain them, so that we focus on those critical factors during the transition.
