Inertia is the residue of past innovation efforts. Left unmanaged, it consumes the resources required to fund next-generation innovation.
100% utilization drives unpredictability.
Innovation and Planning Iteration Abstract
Lean, Agile, and SAFe all provide a dedicated focus on continuous delivery of Customer value. Every Program Increment (PI) ends with a System Demo and an Inspect and Adapt workshop that create a focus and integration point for the entire Agile Release Train (ART) and Value Stream. It’s a critical point in development, one that shows the progress of the Solution to all stakeholders and supports the need for continuous value delivery. To that end, during the PI, teams are busy working on the Features that they took on in PI Planning. Every Iteration counts, and the teams are mostly “heads down,” focused on near-term delivery. PI after PI, the solution marches to market. The focus on delivery is unrelenting.
Of course, a focus on one thing, delivery, can lead to a lack of focus on another, in this case innovation. Given this constant urgency, there is a risk that if time is not put aside for innovation, the “tyranny of the urgent iteration” will trump the need to constantly innovate. To address this, SAFe provides for Innovation and Planning Iterations. These serve a variety of purposes, including a dedicated time for planning, retrospecting, and exploration and innovation. They serve a number of other purposes as well; all are described in the details below.
Understand the IP Iteration Activities
Innovation and Planning Iterations provide a regular, cadence-based opportunity every PI for teams to work on activities that are difficult to fit into a continuous, incremental value delivery paradigm. These can include:
- Time for innovation and exploration
- A dedicated time for the PI System Demo, Inspect and Adapt workshop, PI Planning events, and backlog refinement
- Final integration of the Solution
- Work on technical infrastructure, tooling, and other systemic impediments
- Enablement of continuing education
In addition, IP Iterations fulfill another critical role by providing an estimating buffer for meeting PI Objectives and enhancing release predictability.
Agile Release Trains typically report that their overall efficiency, velocity, sustainability of pace, and job satisfaction are all enhanced by regular opportunities to “recharge their batteries and sharpen their tools.”
Allow Time for Innovation
One of the pillars of SAFe’s Lean-Agile Mindset is innovation, but finding time for free association and innovation in the midst of delivery deadlines can be difficult. To this end, many enterprises use IP iterations for research and design activities and hackathons. The rules for a hackathon can be simple:
1. Team members can work on whatever they want with whomever they want, so long as the work reflects the mission of the company
2. They demo their work to others at the end of the hackathon
Hackathon learnings routinely make their way into Program Backlogs and thereby help drive innovation. They’re fun, too!
Dedicate Time to PI Events
The PI system demo, inspect and adapt workshop, and PI planning are critical events that take time to execute. Placing them in a dedicated IP iteration means that all other Iterations can have normal lengths and velocities and are not truncated by the time dedicated to these critical functions. Even more important, the events can be locked systematically into the program schedule, so that their occurrence is thereby better guaranteed.
In addition, it’s likely that some just-in-time, last-responsible-moment Program and Value Stream Backlog refinement and Feature and Capability elaboration during this period can significantly increase the productivity of the upcoming planning session.
Integrate the Complete Solution
The IP iteration contains the system demo and provides time for final testing of the Solution, including final performance and other Nonfunctional Requirements (NFR) testing, standards and security validations, user acceptance testing, final documentation, and any other readiness activities that are not feasible or economical to perform at every iteration.
When a complex solution includes hardware and other tangible components that are more difficult to continuously integrate end to end, full integration at the Program Level as well as the Value Stream Level may be feasible only during the IP iteration. In these cases, it’s just common sense to plan for that.
That being said, this should not be the only attempt to integrate the assets into the system. SAFe organizations rely on frequent integration, which—even when not fully end to end—addresses specific aspects of the solution and validates the assumptions early enough to be able to respond to significant problems and risks within the PI. These integrations are demoed at the system demo at the end of every iteration. The IP iteration is a placeholder for full, final solution integration that must happen at least once per PI. The System Team(s) typically assists the Agile Teams with this integration effort.
Advance Development Infrastructure
Lean delivery puts additional pressure on the development infrastructure. New continuous integration environments must be erected, new test automation frameworks must be installed and maintained, project management tooling is adopted, intra- and inter-team communications systems may need to be upgraded or enhanced, and the list goes on. While many of these items can and should be addressed in the course of each iteration (they are often improvement stories from the team’s Iteration Retrospective or Enablers), it can be more efficient to perform an upgrade or migration at a time when there isn’t a critical demo just a few days away. We all understand that we have to sharpen our tools from time to time. Agile Teams are no different; indeed, they have an even higher dependency on their working environments than do regular teams, and so they need to spend time building this environment.
Enable Continuous Learning
Lean engineers and leaders are lifelong learners. Changes in technology, as well as changes to method and practice, are routine; opportunities for continuing education, however, are far less common. In addition, the initial move to Lean-Agile requires many new techniques, including feature/Story writing, building in quality, automated testing, collective ownership, Lean-Agile architecture, Continuous Integration, pair work, Product Owner and Scrum Master skill mastery, and team building. Providing time for continuing education gives teams and leaders the time they need to learn and master these new techniques. This time can also be used to foster and support Communities of Practice devoted to these and other topics. The net results benefit both the individual and the Enterprise: employee mastery and job satisfaction increase, velocity goes up, and time to market goes down.
Leverage the Built-in Estimation Buffer
Lean flow teaches us that operating at 100% utilization drives unpredictable results. Put simply, if everyone is planned to full capacity, there is no one available to flex when problems inevitably occur. The result is unpredictability and delays in value delivery. To address this, the IP iteration is treated as a “guard band” or estimating buffer. During PI planning, no features or stories are planned for development in this iteration. This buffer gives the teams extra time to respond to unforeseen events, delays in dependencies, and other issues, thereby increasing their ability to meet Team and Program PI Objectives. This substantially increases the predictability of the program’s outcomes, an attribute that is extremely important to the business. However, routinely using that time for completing the work is a failure pattern. Doing so defeats the primary purpose of the IP iteration, and innovation will likely suffer. Teams must take care that the estimating guard does not simply become a crutch.
A Sample IP Iteration Calendar
Taking all the above into account, many teams’ IP iterations take on a somewhat standard schedule and format. An example is illustrated in Figure 1.
 Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 17.
Last update: 21 April 2016