Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

The IP Iteration: It may be SAFe but is it Agile? (Part 1)

"But this just isn't Agile!  Why can't we just keep Sprinting?".
"We don't have time for this, we've got too much work to do!".
"Planning together is worthless because everything changes soon afterwards."
"It is boring and a waste of my time, I'm here to write code".


These are just some of the things we regularly hear from clients who are learning the Scaled Agile Framework® (SAFe®). The part of SAFe they seem to struggle with most is the IP Iteration (sometimes called the 'bridge') that handles the switch between two adjacent PIs (Program Increments). This is probably the most misunderstood part of SAFe and the one that is abused the most in practice.


Let's start by unpicking why SAFe works like this - because there are good reasons that cannot be trivially dismissed.


The Plan Do Check Adjust/Act (PDCA) Cycle


Plan Do Check ActFirst of all, most Agile methods are based on the PDCA cycle. (Note that there are alternatives to PDCA such as John Seddon's Check-Plan-Do.  However they are all ultimately variations on the same activities, just with different emphasis.)


PDCA is a basic improvement cycle that can be applied individually, to a team, to a programme or a wider organisation.


Planning - planning work/activity to do.
Doing - doing the work/activity.
Check - evaluating how we did.
Adjust(/Act) - improvement actions to get a better result next time.


Sports work like this. Before the game, we plan tactics and strategy. Then we play the game (do).  After the game, we review our performance: what went well and badly and why (check).  Finally, we take learnings from this review and work to improve for future games (adjust/act).


Scrum's Daily Scrum also encapsulates a very short-term version of PDCA, albeit out of the normal order:

  1. What did we do yesterday towards the Sprint Goal? (check)

  2. What will we do today? (plan)

  3. Any blockers or impediments? (adjust/act)

  4. Then we get on with a day's worth of work (do)

 

Scrum is PDCA applied to a single team


The Scrum method is also a direct implementation of the PDCA cycle on short cycles of 1-4 weeks, we have:

 


Scrum Framework v2 essentialsSprint Planning - Planning a sprint of work together as a team.

Sprinting - Doing the work, including our Daily Scrums.

Sprint Review - Reviewing the work to evaluate how we did.

Sprint Retrospective - Reflecting and learning to define improvement actions.


Scrum also includes Refinement, since there's a need to prepare work for it to be ready for Sprints - in professional sports, usually someone else takes care of arranging the tournaments and games we will play.

 

 

To make Scrum work, we force some tradeoffs onto the whole Scrum team:


  1. We will all work together with an aligned cadence of Sprints, so the whole team uses the same Sprint length - even if this is sub-optimal for some types of work (e.g. UI work could run on a faster cycle than API).

  2. We will all come together as a team to refine, plan, review, retrospect during each Sprint and daily throughout the Sprint to stay aligned as a team. This is another conscious tradeoff - it may be sub-optimal for some individuals to have to attend all of these sessions since they may have less to contribute.


We can see then that Scrum itself embraces PDCA at two levels: daily and per-Sprint.  Most Agile practitioners never question points 1 and 2 above, they take them for granted.  That's what it means to do Scrum properly.



Why do we need to run through the PDCA cycle on a medium term with the larger group?


Scrum says nothing about multiple teams, nor does it give any programme guidance: it is a single-team method. That means we have to supply something beyond Scrum itself in order to handle a team-of-teams that needs to work and coordinate together.


There are today a variety of scaling methods: Scrum of Scrums, LeSS, DA, SAFe, Nexus, Scrum@Scale. Most of these provide ways to coordinate teams on a larger scale by bringing together some or all of the team members in joint programme sessions.


SAFe takes the view that a programme is a "team of teams" all working together to achieve a larger goal, typically by all working on a common large system/solution.

Team of teams


To have an effective "team of teams" we need periodic coordination activities that bring everyone together, build relationships and create a wider team ethic. SAFe's approach is "all-hands" similar to LeSS, which contrasts with some of the alternatives (Scrum of Scrums, Scrum @ Scale) that use a sub-set of the team to coordinate across the programme.


SAFe includes everyone in the larger team (up to 125 people per Agile Release Train / programme) because it believes the tradeoff of face-to-face interactions across the wider group has coordination benefits that outweigh the costs.


This is like the tradeoff in Scrum of having only part of the team present for a refinement session.  A partial team can refine work but then there's a need to brief/include the rest of the team after refinement, which adds an extra step/overhead. Having the whole team present can risk wasting some people's time (little to contribute) but it is often the better tradeoff.


SAFe also achieves the time and space for these alignment activities by forcing an aligned iteration cadence on the teams in each ART. This is a conscious tradeoff and is the same tradeoff that Scrum makes at the team level: some teams would prefer a shorter or longer iteration length but the benefits of an aligned cadence for the programme as a whole outweigh these individual team preferences.


What's the right length for a medium term PDCA cycle?  SAFe applies PDCA on a roughly quarterly cadence through the use of Programme Increments (PIs) of 8-12 weeks, giving 4-6 PIs per calendar year.  With annual holidays, it is common to treat SAFe as supplying 4 "quarters" of work which can then align with annual financial planning.


In the upcoming Part 2, we’ll explore the IP Iteration and the reasons for its structure.

Author

Tom Sedge

Tom Sedge

Tom is an Organisational Therapist specialising in end-to-end Product & Service delivery via Agile, Lean, Systems Thinking. His vision is a world where work is fun, meaningful and transforms lives inside and outside each organisation. His mission is to turn slaves of the system into masters of their destiny. He works in both the private and public sector, using his 20 years of experience to navigate the challenge and pain of transforming mindsets, cultures and long-standing operational practices. He understands that sometimes the hardest part of change is persuading people to drop their defences, see things differently, take action and try something new. Read more