A Senior Director of HR reached out with a phrase I’ve heard more than once: “We have about ten agile teams. I think.”
The qualifier was the tell. Teams existed, yes. People were trying to work in an agile way. But when we sat down and mapped what was actually happening across a large enterprise organization, we found ten teams with ten different definitions of agile. Some had Jira boards. Some didn’t. People moved between teams based on whichever project needed help that week. Sprint lengths varied. Stories were sized differently from one team to the next. Standups happened when they happened.
These weren’t broken teams. They were trying. But trying to work in an agile way is not the same as actually being agile.
The Foundation Has to Come Before the Framework
The instinct in this situation is to fix the tooling. Get everyone onto the same Jira board. Build a shared template. Run a retrospective. None of that sticks if you don’t have stable teams underneath it.
You cannot measure a team’s performance if its roster changes every two weeks. You cannot build cadence if every team starts their sprint on a different day. Consistency in ceremony and process requires stability in people and structure first.
Before we touched a single Jira board, we did the work that nobody wanted to do. We identified every actual team. We defined team boundaries and norms. We established fixed rosters so people stopped floating between projects based on who was loudest that week. Then we set up a consistent Jira scrum board for each team, structured identically, so every team was working from the same context.
It sounds simple. It is not easy. Defining team membership means having uncomfortable conversations about priorities and assignments. But you cannot build an Agile Release Train on teams that don’t fully exist yet.
Train the Whole System, Not Just the Teams
With stable teams and a shared tooling foundation, we moved into training. Not a half-day overview. Real, role-specific SAFe certification.
Leaders went through Leading SAFe so they understood how to enable an ART, not just fund one. Scrum Masters went through SAFe for Scrum Masters. Product Owners and Product Managers went through SAFe for Product Managers and Product Owners. The teams themselves went through SAFe for Teams so everyone shared the same mental model of how work flows, how stories get sized, and what a sprint is actually supposed to accomplish.
This matters more than it looks on paper. When a leader doesn’t understand how an ART works, they make decisions that undermine it, pulling people mid-sprint for urgent projects or approving scope changes that blow up commitments. When a Scrum Master doesn’t know what SAFe expects of their role, they fill gaps with old habits. The training isn’t a box to check. It’s the thing that allows everything else to work.
Launching the Agile Release Train
Scaled Agile defines an Agile Release Train as “a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions in a value stream.” The key phrase is long-lived. You cannot build one from shifting, loosely connected groups. You build it from the stable, trained, well-defined teams we’d spent weeks creating.
We launched an ART of eight solid agile teams. All on the same cadence. All starting their sprints at the same time. Sizing stories the same way. Running backlog refinement consistently so the work was always ready when the sprint started.
The results came in stages. After two weeks, we could measure basic performance. Were teams delivering what they committed to? Were stories sized right? After a month, we could see trajectory. Were teams improving or declining? After a quarter, we could measure the ART itself. Not just individual teams, but the whole body of HR Engineering and supporting operations teams moving together toward a shared goal.
That kind of visibility is what a team health assessment can help sustain over time, giving leaders a consistent signal on how teams are doing, not just how the project is going.
The Real Question Isn’t About HR
Here’s what some of the leaders in this engagement found surprising: the fact that these were HR teams changed nothing about how we built the ART.
HR Engineering teams are engineering teams. They build systems. They manage products. They deliver services. Treating them as a special case, or assuming agile somehow works differently for HR, is exactly what kept them stuck. Once we stopped making that distinction and treated them as a product delivery organization, the path was clear.
The problem was never that HR couldn’t do agile. Nobody had ever actually set them up to do it.
By the end of the quarter, the Senior Director could see the entire picture. Not a collection of individual status updates. One ART, moving as one body, with measurable performance and a clear direction.
Can you do that with your teams? If not, let’s talk.
If this sounds like where your organization is stuck, this is exactly the kind of work we do at Stephens Insight Group. Talk to us about your transformation
Sources
- Agile Release Train — Scaled Agile Framework