The Scaled Agile Framework (SAFe) gives you a fairly detailed recipe for launching an Agile Release Train (ART), yet the launch stories I hear from other organizations vary significantly. That still surprises me, so I want to tell ours. We stayed close to the textbook, and four years later it’s worth looking at what that got us, and what it didn’t.
Honestly, I didn’t launch that first ART. I was a participant, and it was a refreshing feeling: I got to weigh in without being the designated facilitator responsible for the Planning Interval (PI) event going well. That didn’t last. By the second PI, I was the Release Train Engineer (RTE), a servant leader and coach for the ART, and I’ve facilitated every PI event since. The ART also outgrew itself fast, so before long we were launching more ARTs.
What are SAFe, Agile Release Trains, and PI Planning?
SAFe is a set of practices for coordinating agile work across many teams. An ART is a group of 50-125 people comprised of smaller teams that plan and deliver together on a shared schedule. That schedule runs in PIs, roughly 8–12 weeks each (SAFe originally called them Program Increments and now calls them Planning Intervals). Every PI starts with PI Planning: a two-day event where all the teams and the business owners agree on what they’ll deliver and how their work connects.
Four years later
It’s been four years since our launch. While writing this, I went back to what we actually briefed at the time, and it didn’t always match what I remembered. Memory keeps the dramatic parts and smooths over the rest, so one of the rewarding parts of writing this was correcting my own version of the story. This isn’t intended to be a how-to. It’s a look back at the decisions we made at launch, how they still shape what we do today, and why, despite maybe changing a few things, I would do it all over again.
PI 1: Small, trained, and by the book
We started with two teams, about 40 people, and trained everyone in SAFe before the first event. A SAFe Practice Consultant (SPC) who had launched ARTs inside their own company ran it. Since there was no previous PI, there was nothing to inspect, so we skipped Inspect & Adapt, the end-of-PI retrospective.
We stayed close to the framework on purpose. The closer we stuck to the book, the more the standard training would apply without anyone translating “what the course said” into “what we do here.” It also gave us a baseline. Run it as designed, and if the results aren’t there, change one thing, see whether it helped, then move to the next problem area.
What we got wrong
One customer can’t speak for everyone. I remembered having no customer in the room at all. The briefings say otherwise: we had one representative. The catch was that they came from just one of several organizations we served, and each of those organizations worked differently. They spoke, reasonably, from their own perspective. That was probably the best we could have gotten at the time, but real buy-in from the whole organization would have been better. Even better would have been stronger strategic direction from leadership on the goals we were trying to achieve as an entire organization. Because we started small without it, we later had to go back and “fix” the process for everyone. We are still “fixing” things now.
Twenty-eight objectives. Two teams walked out of that first PI Planning with 28 PI objectives. PI objectives are meant to be a short list of the outcomes a team commits to for the increment. Ours appeared to map one-to-one with features: a renamed backlog, not a statement of what we were trying to achieve.
PI 2: Ripping off the bandaid
For PI 2, we brought every team on board and invited the business owners. I remember it being rough. I had just gotten over my first bout of COVID a week earlier, so I wasn’t in peak condition to host a 200+ person event. I’m sure you are remembering I said an ART should be only 125 people and 200 is greater than 125. Having a new ART comes with necessary overhead and logistical considerations that organizations like ours can be reluctant to add. We really should have been 2 ARTs at this point, but we had concerns about having insufficient staff to split across with appropriate subject matter expertise. Another learning point that we would have ideally done differently, but sometimes you make do with what you have.
We had trained the teams but not the business owners, so we explained their role to them in the middle of PI Planning, in a format nothing like how they normally worked. We botched business value: instead of having the business owners agree on a score for each objective, we collected everyone’s scores and averaged them, which flattened every real disagreement into a meaningless midpoint. And one team’s entire plan changed in the room. Bringing the right people in hadn’t solved the vision problem. It had exposed it.
Tracing the threads
The most useful part of looking back was seeing how much of today traces to those first decisions. The 28 objectives weren’t a one-time quirk. Distilling our work down to a few overarching goals and outcomes is still a challenge for us.
Sticking to our ART upper bound number is still a struggle. We have generally waited to feel the real pain of being too big before we split things or right-sized them.
Vision is still the hardest thing to get right. What has helped most is tying our communication back to our operational value streams: the end-to-end flow of how an organization delivers value to the people it serves. When every conversation about work points back to that flow, people can see which part of the workflow a feature is improving. It doesn’t solve vision, but it gives everyone a shared map to argue over.
Why starting anyway was the right decision
It’s easy to read everything above as a case against how we launched. I read it the other way. Every one of those problems surfaced because we were actually executing, and we either corrected each of them over time or continue to correct them. If we had waited for full buy-in, a clear vision, trained business owners, and all the necessary ART Product Management and Engineering overhead we might still be waiting.
Starting by the book is part of what made those corrections possible. With a baseline, we could change one thing at a time and see whether it worked, instead of guessing which of a dozen changes made the difference. How we’ve corrected course, and where we’re still working on it, is a story for Part 2.
What I’d leave you with
- Objectives aren’t features. If your objective count matches your feature count, you’ve written a to-do list, not a set of outcomes.
- See the bigger picture, but don’t let perfect be the enemy of good. An ART that’s running and imperfect will teach you more than a perfect one that’s still on the drawing board.
- Reflect regularly. Looking back shows you which early decisions are still shaping today’s problems, and that’s how you make better ones next time.
Our first ART wasn’t the launch I’d design today. But it, and now multiple ARTs, have delivered real value for four years, and it never would have if we’d waited until we could do it perfectly.