This is the last part in the 'SAFe® IP Iteration' series. Read part one here and part two here if you missed them. In part three, Tom goes back to address the original objections to whether the IP Iteration is Agile.

Coming back to the original objections

Let's go back to our original objections and deal with them now that we understand why SAFe is constructed the way that it is.

"But this just isn't Agile! Why can't we just keep Sprinting?".

Some people really dislike the "break" from the cycle of Sprints and view the IP Iteration as an ineffective tradeoff that isn't needed because all of the above activities can be worked into each Sprint for each team. This is essentially the single-team Scrum view that life should be an endless series of Sprints.

The normal response to this is to point out that there's a bigger programme picture, that the team is part of a team-of-teams and time needs to be spent on those activities, and that all of this rests on the same PDCA principles that underpin Scrum.

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".

"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

First 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 plantactics 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).

As a SAFe® Program Consultant Trainer, I have launched many Agile Release Trains (ARTs) over the last two years in a variety of industries and countries. Every time, I look to try something new (an experiment) to see whether there is a better way of doing things.

So, through a series of blogs I am going to share some of those experiments that I have found really useful. Perhaps try them out for yourself and let me know how you get on.

Have you ever wondered what a Leading SAFe Training Course would be like? In this blog post that’s exactly what you’ll be able to read.

First of all, what is SAFe®?

The Scaled Agile Framework® (SAFe) helps businesses address the significant challenges of developing and delivering enterprise-class software and systems in the shortest sustainable lead time. It is an online, freely revealed knowledge base of proven success patterns for implementing Lean-Agile software and systems at enterprise scale.

Darren Wilmshurst and Radtac had the great chance to run a Q&A session with Dean Leffingwell, creator of the Scaled Agile Framework. Dean’s answers on SAFe updates, implementation advice, challenges, and more are captured in a series of blog posts and short videos.

In the first video of the series, Deans answers questions on the future of the Scaled Agile Framework, and in the second episode Dean talks about the major impediments to implementing SAFe and the Leadership Challenge. In the third episode Darren and Dean talk about projects, project managers, Scrum and Kanban in SAFe environments.

This is the fourth and final part of the series - view the first part here, the second part here, and the third part here.

***

In this fourth and final episode of our ‘10 Questions with Dean Leffingwell’ series, I’m talking to Dean about the appropriateness of using Agile and SAFe for legacy developments, compared to green field developments.

Darren Wilmshurst and Radtac had the great chance to run a Q&A session with Dean Leffingwell, creator of the Scaled Agile Framework. Dean’s answers on SAFe updates, implementation advice, challenges, and more are captured in a series of blog posts and short videos.

In the first video of the series, Deans answers questions on the future of the Scaled Agile Framework, and in the second episode Dean talks about the major impediments to implementing SAFe and the Leadership Challenge.

This is the third part of the series - view the first part here and the second part here.

**

In this third episode of our ‘10 Questions with Dean Leffingwell’ series, I’m talking to Dean about the role of Projects and Project Managers within the Scaled Agile Framework® (SAFe®).

Darren Wilmshurst and Radtac had the great chance to run a Q&A session with Dean Leffingwell, creator of the Scaled Agile Framework®. Dean’s answers on SAFe® updates, implementation advice, challenges, and more are captured in a series of blog posts and short videos. This is the second part of the series - view the first part here.

***

In this second episode of our ‘10 Questions with Dean Leffingwell’ series, I’m talking to Dean about what he sees as the major challenges for implementing SAFe in an organisation.

Dean Leffingwell, Entrepreneur, Author, CEO of Scaled Agile Inc. and creator of the Scaled Agile Framework® makes a rare visit to the UK. I’ve had the great chance to spend a day with Dean and Radtac, where we engaged in a series of events.

Dean Leffingwell Executive Briefing by Radtac

If you are in any way familiar with SAFe®, then the name 'Dean Leffingwell' will surely resonate with you. Creator of the Scaled Agile Framework®, Dean is a fantastic author and speaker - and we had the honour to spend an exciting day with him in London on June 12th. More below on how the day unfolded, what Dean taught us, and why you won't want to miss Darren's SPC class in August.