This is the second part in a blog series talking about the IP Iteration that happens as part of the Scaled Agile Framework® (SAFe®). Missed the first part? Read it here.
What's the typical structure of an IP Iteration and why is it like this?
SAFe marks the boundaries of its PIs (Program Increments) through the IP Iteration. This is normally a two-week period during which the following activities are scheduled:
1. Completion of work
There is some contingency allowed in case that teams are very close to finishing their work in the current PI and can finish. The official guidance is up to one week, in practice less is desirable or this becomes a "buffer" teams will depend on.
There is also an allowance here for release activities - these will depend on whether major releases are aligned with PIs or not (a business decision, not required by SAFe) and the nature of the major release process: whether it is complicated and time-consuming or a simple "button-push".
2. Programme alignment activities
In SAFe, these mirror the Scrum activities exactly, except for the larger programme (team-of-teams).
We have a period of Joint Refinement (Preparation for PI Planning): this is time for teams to examine the programme backlog items and priorities expressed through the desired sequence of Features for the forthcoming PI. The teams need to make sure they understand what the Features are, why they have been prioritised and how they might implement them.
This refinement time is also the place to ask obvious questions, pinpoint important spikes (research/proof of concept/prototypes) and make sure that PI Planning will be as productive as possible.
We have a Joint Review of the last PI (PI Demo) as part of a larger Inspect & Adapt (I&A) session. The review enables everyone to see what has been created over the last PI and also for wider stakeholders that are not a part of the programme day-to-day to see progress and become involved.
The I&A session goes on to become a Joint Retrospective where the team-of-teams reflects upon the systemic issues that need to be tackled to enable all teams to go faster. Often these are organisational impediments in wider functions and processes that are not as "agile" as they need to be. This is a great opportunity to focus on resolving these issues with the pressure that comes from such a large group being impacted and being in the same space together.
This leads up to PI Planning itself, which is an alignment and planning activity to create a plan for the PI ahead and commit to clear business goals that the teams believe can be delivered. This is essential for the organisation to be able to make larger and wider commitments to its customers and stakeholders. It is also a golden opportunity to drive out dependencies and risks, and ensure that the teams can proceed as independently as possible supported by a well-coordinated wider organisation.
PI Planning example, courtesy of one of Radtac's clients
The result is an aligned plan that does not prescribe the details of the solution within each sprint but does deliver discrete Features and business goals. This plan can also act as a yardstick against which to track progress during the PI.
PI Planning can be highly controversial with 2 days time all spent together. In practice (even in the official SAFe guidance) it is less than 2 full days and can be optimised once ways of working are matured to take less time - albeit often spread across two elapsed days to allow overnight reflection.
Following PI Planning, some time is allowed to align supporting tools (e.g. electronic systems) and departments with the planning outputs - the Programme Board, PI Objectives etc.
3. Medium-term innovation work
Most organisations struggle to make time for bottom-up innovation activities from teams. They often adopt the language of innovation without providing the means.
SAFe reserves time during the IP Iteration to focus on this, for example by running multi-team "hackathons" and other activities. It is common to set a real business goal (e.g. a new solution to problem X) and then minimise constraints on the teams to maximise their creativity.
Sometimes this might seem like a luxury that an organisation cannot afford. If that's the case, the decision to axe this time should not be taken lightly. Innovation in working practices, tools, technologies, solutions is one of the biggest routes to significant leaps in improvement - so effectively the organisation is saying "we cannot afford the time to make big improvements because we are so busy just keeping up as it is". That might be a passable short-term strategy but it is not going to deliver significant benefits in the long-term.
Remember, this innovation time can be as much about team and programme tools as it is about new solutions - it can be an ideal time to upgrade environments, roll-out new automation tools without the disruption of doing this inside a regular Sprint. Also, it is a great time for Communities of Practice to drive forward disruptive improvements in how they work.
Need help with your SAFe transformation? Talk to us to get advice from our coaches, consultants and trainers who will help you succeed.
4. Long-term technical debt work
One of the most misunderstood aspects of the IP Iteration is the opportunity to work on long-term technical debt. Agile-heads often read this and think "but hang on, technical debt should be tackled inside Sprints!" and it conjures up past demons in their minds such as hardening Sprints and other hole-digging ways of working that have since been abandoned.
Teams should absolutely tackle and deal with technical debt as they go along and avoid creating new debt unless there is a compelling business tradeoff in its favour.
However, many organisations are not in a purely greenfield development landscape and there's a significant legacy of technology, systems and debt that cannot easily be "nibbled" away Sprint by Sprint.
The IP Iteration is explicit time put aside that can be used to tackle this harder long-term debt at a time when teams are not simultaneously under pressure to deliver against their short-term Sprint goals. Sometimes making explicit time for this is the only way to ever move forward - so don't dispense with this activity without careful thought.
5. Educational and performance management sessions
It is the nature of many programmes (team-of-teams) in practice that some educational activities will be team-based and some will be role-based (cross-team). Very few organisations have completely cross-functional team members that are genuinely interchangeable and have no job titles. Most have discrete roles and careers and are exploring greater collaboration between roles in teams.
The aligned cadence of SAFe enables planned training (and workshops, coaching, simulations and other similar activities) to work both functionally and cross-functionally involving multiple teams. Ideally, this is when these activities are booked and kept outside Sprints. The predictable nature of SAFe's calendar means these dates can be booked long in advance.
Another commonly adopted practice is to schedule performance management reviews with line managers during the IP Iteration. Then they can be given the time and consideration they deserve.
In Part 3 of this article series, we’ll revisit our original objections and see what conclusions we can draw.