- Principle #1: Take an economic view
- Principle #2: Apply systems thinking
- Principle #3: Assume variability; preserve options
- Principle #4: Build incrementally with fast, integrated learning cycles
- Principle #5: Base milestones on objective evaluation of working systems
- Principle #6: Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Principle #7: Apply cadence, synchronize with cross-domain planning
- Principle #8: Unlock the intrinsic motivation of knowledge workers
- Principle #9: Decentralize decision-making
Principle #4: Build incrementally with fast, integrated learning cycles
The epiphany of integration points is that they control product development and are the leverage points to improve the system. When timing of integration points slips, the project is in trouble.
—Dantar P. Oosterwal
In traditional, phase-gated development, investment costs begin immediately and accumulate until a Solution is delivered. Often, little to no actual value is provided before all of the committed Features are available or the program runs out of time or money. During development, it’s difficult to get any meaningful feedback, because the process just isn’t designed for it. What’s more, the development process itself isn’t set up or implemented to allow incremental Capabilities to be evaluated by the customer. As a result, the risk remains in the program until the deadline, and even into deployment and after initial use.
No wonder the typical procedure is error-prone and problematic, often resulting in loss of trust with the customer. Attempting to adjust for this possibility, both parties try even harder to define the requirements and select the best design up-front. They also typically implement even more rigorous phase gates. Each of these remedies, unfortunately, actually compounds the underlying problem. This is a systems-level problem in the development process: It must be addressed from a systemic perspective.
Integration Points Create Knowledge from Uncertainty
Lean principles and practices approach the problem differently. Rather than pick a single requirements- and-design choice early on—assuming that this choice is feasible and will provide fitness for purpose—a range of requirements and design options (Principle #3) are considered while building the solution incrementally in a series of short timeboxes. Each timeboxed activity results in an increment of a working system that can be evaluated. Subsequent timeboxes build on the previous increments, and the solution evolves until it is finally released. The knowledge gained from integration points is not solely to establish technical viability. That is, integration points can also serve as minimum viable solutions or prototypes for testing the market, validating usability, and gaining objective customer feedback. Where necessary, these fast feedback points allow teams to pivot to an alternative course of action, one that should better serve the needs of the intended customers.
Integration Points Occur by Intent
The development process and the solution architecture are designed, in part, to focus on cadence-based integration points. Each point creates a ‘pull event’ that pulls the various solution elements into an integrated whole, even though it addresses only a portion of the system intent. Integration points pull the stakeholders together as well, creating a routine synchronization that helps assure that the evolving solution addresses the real and current business needs, as opposed to the assumptions established at the beginning of the process. Each integration point delivers its value by converting uncertainty into knowledge:
Knowledge of the technical feasibility of the current design choice
Knowledge of the potential sustainability of the solution, based on objective measures (Principle #5)
Faster Learning through Faster Cycles
Integration points are an example of Shewhart’s plan–do–check–adjust cycle (Figure 1) and are the mechanism for controlling the variability of solution development [3].
Figure 1. Plan–do–check–adjust cycle
The more frequent the points, the faster the learning. In complex systems development, local integration points are used to assure that each system element or capability is meeting its responsibilities to contribute to the overall Solution Intent. These local points must then be integrated at the next higher system level. The larger the system, the more such integration levels exist. Solution designers recognize that the top-level, least-frequent integration point provides the only true measure of system progress, and they work to create these points as frequently as possible. All stakeholders understand that when the timing of integration points slips, the project is in trouble. But even then, this knowledge helps spark the necessary adjustments to scope, technical approach, cost, or the delivery timing needed to redirect the project to meet revised expectations.