Value Stream Mapping and Theory of Constraints
Theory of Constraints has its roots in industrial process optimization, where individual process steps are usually pretty well understood and repeatable. In Cynefin terms, this sounds very much like the Complicated Domain. Cynefin’s recommended actions for this domain are sense–analyze–respond. Applied to Value Stream Mapping and Theory of Constraints this would be:
- Sense: map the value stream and gather data
- Analyze: identify the bottleneck
- Respond: intervene with good operating practices to dissolve the bottleneck
As a first order approximation, this view makes sense for software development. There, we also have pretty clearly identifiable steps that could be mapped by a value stream. And indeed, this is basically how you get started with Kanban in software development.
Complex Adaptive Systems and the Cynefin Framework
However, software development lacks a critical feature of industrial processes, it is not a repeating process. Developers continuously build new features, they invent new solutions, their work is creative in nature. This strongly questions the applicability of Theory of Constraints for software development and suggests that it is not a Complicated Domain process.
If we look closer at the process of software development, we see a few interesting properties:
- There are certain process constraints like choice of programming language or a time budget for specific features, but developers are generally free to implement solutions freely within these constraints. In Cynefin terms, these would be enabling constraints.
- Similarly to the first point, the implementation of a new feature is often times unclear until work starts. It emerges from the interaction of the developer with the existing code base.
- This interaction also has qualities of coevolution. Developers, their techniques, and the code often change in interdependence.
- The path from pre-feature code base to post-feature code base is often only clear in hindsight. We observe retrospective coherence.
The properties described above are the cornerstones of a Complex Domain process in Cynefin. Suggested actions are
- Probe with parallel, safe-to-fail experiments
- Sense the system’s reaction to the probe
- Respond by reinforcing positive reactions and dampening negative ones
However, that is not the whole picture either. Sometimes features are well understood and it is pretty clear what to do. The code base is in good shape and there are no surprises. There actually are features that can be implemented with a Complicated Domain approach.
Now, what does this tell us? Actually, there is not a single process of software development, but there are features of varying degrees of complexity that require different approaches for successful implementation. If we understand which of our features are deeply in the Complex Domain, which ones are pretty clear and “just” complicated, we can manage our features and the team’s workload appropriately. We can manage feature velocity by not overwhelming the team with uncertain, Complex Domain features but can balance these explicitly with well understood, Complicated Domain features and even some Obvious Domain quick wins.
With the introduction of the Cynefin Framework, we opened our eyes to different levels of complexity in software development. Features in different domains of the Cynefin Framework require different approaches.
When implementing Complex Domain features, the future is uncertain and our processes should reflect that. It just doesn’t make sense to optimize efficiency in these cases.
When we are implementing features from the Complicated Domain, however, life is very different. There we know pretty well what is going on and we can indeed optimize throughput. Value Stream Mapping and Theory of Constraints are viable approaches there.
If I could spark your interest in the Cynefin framework and you want to learn more, in particular how to apply it to software development, I suggest you go over to Liz Keogh’s blog and take a look at Cynefin for developers.