Innovation and Planning Iteration

The Innovation and Planning (IP from now) is a special iteration planned at the end of a Program Increment and is a critical phase to improve the process before the next Program Increment (PI).

It is a concept originated from SAFe but is generally valid and can be applied to most Agile scaled frameworks.
It serves two main purposes:

  • Innovation: reserve dedicated time and opportunity for innovation spikes, hackathons or infrastructure improvements 
  • Planning: reserve a buffer for meeting the PI Objectives and providing an estimating guard band for cadence- based delivery and enhancing the predictability of PI performance. 

Innovation and planning iterations provide a regular, cadence-based opportunity – every Program Increment (PI) – for teams to work on activities (plans, demo, improving together) that are difficult to fit into a continuous, incremental value delivery pattern, always under the tyranny of urgency.

Without the IP Iteration there is a risk of little innovation and the technical debt growing uncontrollably but also of having people burning out.

Let’s say the iterations are two weeks long, then an IP iteration (also two-weeks long) could look like this:

  • the first week can be dedicated to:
    • a buffer for leftover work (if you need more time than you did something wrong in the PI Planning), 
    • the final verification, validation and integration, 
    • innovation (spikes, hackatons, studies, …), 
    • prepare the next PI planning (PI readiness)
  • the second week can be more structured with
    • the Inspect & Adapt workshop and
    • the PI planning

Let’s see the main parts.

A buffer for leftover work

Very important to remember is that the the first part is a buffer to handle what was unexpected during the PI, don’t rely on it. It’s very easy to consider having always one or two extra weeks when planning the PI and cram more features in it or – even worse – to leave testing and bug fixing to this time.
It’s not extra time that can be planned! It’s a buffer for the unexpected.
And the unexpected it will happen, you just don’t know what will be.

Integrate the complete solution

An Iteration System Demo occurs at the end of each iteration: an integrated presentation of the work of all teams on the release train, done in a staging environment which emulates production as closely as possible. 

But sometimes the solution is very large or complex and may be hard to integrate end-to-end continuously the works from all the team. Imagine if there is hardware involved and those related teams have longer iterations.

In these cases, it makes sense to plan for an aggregated solution demo, which takes place during the IP Iteration, so at the end of each PI.

The solution demo presents the combined development efforts of multiple Agile Release Trains (ARTs)—along with the contributions from suppliers and other solution participants— and makes them visible to customers and other stakeholders for evaluation and feedback. 
Therefore the PI System demo is the beefed-up version of the iteration system demos, the chance to integrate together parts that are normally complex to do earlier.

The IP Iteration is the time to prepare it.

An anti-pattern is leaving integration of the whole system to the IP Iteration. The IP iteration should not be the only attempt to integrate the assets into the system: always plan for (at least partial) integrations happening over the course of the PI, with a total solution integration occurring at least once per PI.

Iterations and demos

Inspect & adapt 

The Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI), where the current state of the solution is demonstrated and evaluated by the release train teams and stakeholders. 

Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.
The Agile Manifesto emphasises the importance of continuous improvement through the principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” 

All stakeholders participate along with the Agile Teams in the I&A event. The result is a set of improvement backlog items that go into the Program Backlog for the next PI Planning event. 

In this way, every Agile Release Train (ART) improves continuously, at every PI.

You can see the I&A as the program-level retrospective: an event to improve the PI results.
The event is time-boxed to around half a day: 3 – 4 hours per Pl.
Attendees are the Teams and stakeholders.  

There are usually three parts in an Inspect and Adapt event:

  • PI system demo
  • Collect and analyse quantitative measurements
  • Problem-solving workshop 

Pl System Demo 

The result of the complete integration is a PI system (or solution) demo. At the end of the Pl, the teams demonstrate the current state of the solution to the appropriate stakeholders. 

It is often led by Product Management, POs and the System Team, with the Scrum Masters facilitating the Team preparation and is attended by Business Owners, ART stakeholders, RTE and of course the teams.
It should not be a slides presentation by the POs but as much as possible concrete with real products and direct involvement of the teams.

This approach validates the assumptions early enough to be able to respond to significant problems and risks found within the PI. 

This demo is therefore a critical event. It’s also a moment to celebrate the accomplishments of the last PI.
Each PI demo represents a significant learning point in the history of the solution, converting some product development uncertainty to knowledge. 

The results of this demo determine the future course of action.

Review the quantitative measurements

In the second part of the I&A event, the teams collectively review any quantitative and qualitative metrics they have agreed to collect, then discuss the data and trends.
In preparation for this, the RTE and the Solution Train Engineer are often responsible for gathering the information, analysing it to identify potential issues and facilitating the presentation of the findings to the ART. 

One primary metric is the program predictability measure. 

As part of the Pl System Demo, each team compare the planned vs the actual business value. 
Remember that the planned business values have been set during the PI planning.

Now teams meet with their Business Owners to self-assess the business value they achieved for each objective and then sum up all objectives into a team’s achievement percentage.

The values can be different as it can happen that a feature is done but partly compliant; its value is not exactly what was planned because of some limitations.

Each team’s planned vs actual business value is then rolled up to the program predictability measure. 

The Pl predictability measure shows whether achievements fall into an acceptable process control band . 
Reliable trains should operate in the 80–100 percent range; this allows the business and its external stakeholders to plan effectively and handles common variations.

Note: Uncommitted objectives don’t count toward the commitment but do count toward the actual business value achievement, as can also be seen in the table:

Team predictability measure
The program predictability measure shows whether achievements fall into the acceptable control band (in green)

Retrospective

The teams finally run a brief (30 minutes or less) retrospective, the goal of which is to identify a few significant issues they would like to address during the problem-solving workshop. 

There is no one way to do this; any Agile retrospective format can be used. 

Based on the retrospective – and the nature of the problems identified – the facilitator helps the group decide which issues they want to tackle. 

Each team may work on a problem, or new groups can be formed across different teams to work on the same issue providing cross-functional and differing views of the problem. Self forming groups bring together those who are best motivated to address the issue. 

Key ART stakeholders—including Business Owners, customers, and management—join the teams in the retrospective and problem-solving workshop. Often it is the Business Owners alone who can unblock the impediments that exist outside the team’s control. 

The problem-solving workshop 

Teams conduct a short retrospective, then systematically address the larger impediments that are prioritised. 

  1. Agree on the problem to solve
  2. Identify the biggest root-cause using a 5-Whys analysis or similar 
  3. Brainstorm solutions 
  4. Identify some improvements that can be added immediately into the backlog

The Scrum Masters/RTE facilitate one of the teams in the workshop and make sure improvement items are included during the Pl planning.
It’s important that actionable improvement Features are created: those improvement items enter the Pl Planning process and – if doable – the improvement items are demoed in the next Pl System Demo. 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s