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 to 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 [1] will override any opportunity to innovate. To address this, SAFe provides dedicated innovation and planning iterations which are a key aspect of the Lean Enterprise’s broader innovation culture.

Details

Understand the IP Iteration Activities

Innovation and planning iterations provide a regular, cadence-based opportunity, every Program Increment (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
  • Cross training to develop skills in new domains, development languages, and systems
  • Dedicated time for the Inspect & Adapt (I&A) event, backlog refinement, including final prioritization of Features using Weighted Shortest Job First (WSJF), and PI planning

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 such as 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, since these events are held on a regular cadence and can be scheduled well in advance, 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

The 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 which emulates production as closely as possible. For ARTs that are part of a Solution Train, the PI system demo feeds into the aggregate Solution Demo, which also takes place for during the IP Iteration. It’s a more structured and formal affair, as it demonstrates the accumulation of all the features and capabilities developed over the course of the entire PI for a Solution Train.

When a solution includes hardware (and other components), it’s harder to integrate end-to-end continuously and full integration 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.

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. 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. It’s often more efficient to improve infrastructure or perform a migration at a time when the teams aren’t in the midst of critical work.

Enable Continuous Learning

Employees at every level 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:

Practitioners are also challenged to keep their technical skills current. New technologies are being introduced more frequently than ever before. Investing in people who can work across multiple systems, domains, and languages creates a ‘T-shaped’ (deep skill in one area, working knowledge in multiple other areas) and even ‘E-shaped’ (deep skill in more than one area) workforce. This provides the organization with maximum agility and flexibility to deliver the most important backlog items. However, it is difficult to find time for this type of growth alongside the drive to constantly deliver new features. IP iterations are a perfect time for this investment.

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 [2].” Simply put, planning everyone to full capacity, does not allow people the ability 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 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 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 this estimating guard band 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] Hummell, Charles E. Tyranny of the Urgent. IPV Booklets, 2013.

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

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

Last update: 10 February 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.