Inertia is the residue of past innovation efforts. Left unmanaged, it consumes the resources required to fund next-generation innovation.

—Geoffrey Moore

100% utilization drives unpredictability.

—Don Reinertsen

Innovation and Planning Iteration

The Innovation and Planning (IP) Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

SAFe has an intense focus on continuous customer value delivery, and people are busy working on the Features they committed to during PI planning. Every Iteration counts and the teams are mostly heads down, delivering near-term value. One iteration after another, the Solution marches closer to market. The attention on solution delivery is intense and unrelenting.

Of course, a focus on one thing—delivery—can lead to a lack of focus on another—innovation. Given the constant urgency for delivery, there’s a risk that the ‘tyranny of the urgent [iteration]’ will override any opportunity to innovate. To address this, SAFe provides dedicated innovation and planning iterations.

Details

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 pattern. These may include:

  • Time for innovation and exploration, beyond the iterations dedicated to delivery
  • Work on technical infrastructure, tooling, and other impediments to delivery
  • Education to support continuous learning and improvement
  • A dedicated time for the PI System Demo, I&A workshop, PI planning events, and backlog refinement, including final prioritization of Features using Weighted Shortest Job First (WSJF)
  • Final integration of the solution, including verification and validation, if releasing on the PI boundary
  • Final user acceptance testing and documentation, and any other readiness activities that are not feasible or economical to perform at every iteration

IP iterations fulfill another critical role by providing an estimating buffer for meeting PI objectives and enhancing the predictability of PI performance.

Agile Release Trains (ARTs) typically report that their overall efficiency, velocity, and job satisfaction are  enhanced by regular opportunities to ‘recharge their batteries and sharpen their tools.’

Allow Time for Innovation

One of the pillars of the SAFe Lean-Agile Mindset is innovation, but finding time for ideation and change in the midst of delivery deadlines can be difficult. To this end, many enterprises use IP iterations for research and design activities and hackathons. There are two simple rules for hackathons:

  • People can work on whatever they want, with whomever they want, so long as the work reflects the mission of the company
  • The teams demo their work to others at the end of the hackathon

The learnings from hackathons routinely make their way into Program Backlogs and often help drive innovation. They’re fun, too!

Dedicate Time to PI Events

Performing the I&A and PI planning during the IP iteration avoids a reduction in velocity of the regular iterations. More importantly, these events can be held on a cadence so that their occurrence is better guaranteed.

Also, it’s likely that some just-in-time, last-responsible-moment Program and Solution Backlog refinement and Feature and Capability elaboration during this period can significantly increase the productivity of the upcoming planning session.

Integrate the Complete Solution

When a solution includes hardware (and other components), it’s harder to integrate end-to-end continuously. Full integration at the Program Level, as well as the Large Solution Level, may be feasible only during the IP iteration. In these cases, it’s just common sense to plan for that.

However, the IP iteration should not be the only attempt to integrate the assets into the system. Full or partial integration happens over the course of the PI, with a total solution integration occurring at least once per PI. This approach validates the assumptions early enough to be able to respond to significant problems and risks within the PI.

The final PI system demo occurs at the end of each PI. It is the integrated presentation of the work of all teams on the train, done in a staging environment, and emulating production as much as possible. In large Solution Trains, the system demo feeds into the aggregate Solution Demo.

The IP iteration is also a placeholder for the final integration and Solution Demo. It’s a more structured and formal affair, as it demonstrates the accumulation of all the features developed over the course of the entire PI for a Solution Train.

Typically, the solution demo, which is part of the Solution Train’s I&A event, which feeds into the retrospective and the collection of various PI progress Metrics.

Advance Development Infrastructure

Lean delivery puts increased pressure on the development infrastructure: new continuous integration environments require provisioning; new test automation frameworks must be implemented and maintained, Agile project management tooling adopted, upgrading or enhancing cross-team and train communications systems, and the list goes on.

It’s often more efficient to improve infrastructure or perform a migration at a time when there isn’t a critical iteration demo just a few days away. (Many times, the improvement stories are from the team’s Iteration Retrospective or Enablers.)

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, so time must be spent continuously improving them.

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 frequent. Also, the initial move to Lean-Agile requires many new techniques and skills, including:

Making time for continuing education gives teams and leaders a welcome opportunity to learn and master these new techniques. It can also be used to launch 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 percent utilization drives unpredictable results [1].” Simply put, planning everyone to full capacity, does not allow people to flex when problems inevitably occur. The result is unpredictability and delays in value delivery. As a countermeasure, the IP iteration offers a ‘guard band’ (or small buffer) to prevent unfinished work from the current PI from carrying over to the next PI.

During PI planning, the ART does not plan features or stories for the IP iteration, providing a buffer (extra time) to the teams for responding to unforeseen events, delays resulting from dependencies, and other issues, increasing their ability to meet Team and Program PI Objectives. This buffer substantially increases the predictability of the program’s outcomes, which 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 merely become a crutch.

A Sample IP Iteration Calendar

IP iterations take on a somewhat standard schedule and format. Figure 1 provides an example IP iteration calendar. The items in orange represent Solution Train events, while the blue ones are for a single ART.

Figure 1. Example calendar for an IP iteration

 


Learn More

[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 1 November 2017