Team Atlas: When the ART Cadence and the Team's Habits Collide
Team Atlas is one of six teams on the Payments Agile Release Train. It has eight members: one Product Owner and seven engineers, three of whom also sit on the production on-call rota and lose roughly a third of each iteration to support tickets. Nobody holds the Scrum Master title; the tech lead takes the role on a rotating basis each iteration and mainly runs the stand-up. Atlas runs three-week iterations, while the other five teams, the System Demo and the PI boundaries all run on two weeks. The team stopped attending the ART Sync last quarter 'because we're always behind.' Velocity over the last four iterations was 42, 18, 39, 21. The retrospective has been cancelled three iterations running to make time for demo preparation. The PM, who is not the Product Owner, regularly emails individual engineers with work requests and expects them completed within the iteration.
1. Sort these symptoms into (a) ART-level constraint violations, (b) team-level hygiene problems and (c) role confusion. You cannot fix everything in iteration one - what do you do first, and why?
Read the worked answer
Nearly every symptom here is structural rather than attitudinal.
(a) ART-level. The three-week iteration is the big one. Cadence and synchronization are properties of the whole ART: the System Demo, the PI boundaries, the program board and every cross-team dependency quietly assume that all teams share iteration dates. A team running three-week iterations cannot integrate with anyone on time and cannot converge during PI Planning, because its draft plan does not line up with the other five. Non-attendance at ART Sync is the same class of problem - it hides dependencies and impediments from the one forum built to resolve them.
(b) Team-level hygiene. The 42/18/39/21 velocity swing, no visible WIP discipline, an unmanaged ~35% interruption rate, and a cancelled retrospective. The retro matters most because it is the team's own improvement mechanism; cancelling it for demo prep is trading the cure for the symptom.
(c) Role confusion. A rotating part-time tech lead is not a Scrum Master, and the PM emailing engineers directly bypasses the PO's single prioritized backlog.
What first. Restart the retrospective - it is fully within your control, costs nothing, and creates the mechanism that makes the other fixes stick. Simultaneously take the cadence question to the RTE, because iteration length inside an ART is an ART decision, not a team preference. The PM conversation comes third, and it comes with the PO in the room.
2. The team argues for keeping three-week iterations: 'Two weeks is too short, we can't finish anything.' How do you reason about it, and what is your move?
Read the worked answer
Separate the principle from the symptom.
In Scrum proper, iteration length is a team's own decision. In SAFe it is bounded by the ART: every team on the train shares cadence so that integration, the System Demo, dependency resolution and PI boundaries line up. A team that unilaterally changes length has effectively opted out of the train without saying so.
But 'we can't finish anything in two weeks' is real information and should not be dismissed with a rule. In practice it almost never means the box is too small. It usually means: stories are too large (features decomposed only to the component level, not to vertical slices), work in progress is unconstrained so nothing gets finished, or interruptions eat the container. Atlas has all three - 35% on-call load and a 2:1 velocity swing.
The move: bring data to the RTE and the other teams rather than either complying sullenly or defecting. Show the interruption rate, show what fraction of carried-over stories were never sliced small enough, and propose the fix (smaller slices, WIP limits, an explicit support rotation so on-call is planned capacity, not a surprise). Offer a two-iteration trial with those fixes in place. If the data genuinely shows two weeks is unworkable for this team, that is an ART-level decision to make openly - not a local habit.
3. The PM's direct emails to engineers. What is the Scrum Master's intervention, and what are you careful not to do?
Read the worked answer
The PO owns and orders the team backlog. A second, invisible queue fed directly by email destroys the team's ability to plan, makes velocity meaningless, and undermines the PO's authority - so the SM does have to act. But the intervention is about making the work visible, not about policing the PM.
Do:
- Capture the requests. Every PM email becomes a candidate backlog item that goes to the PO for prioritization, with the requester and the date attached. Nothing is silently absorbed and nothing is silently refused.
- Show the cost with data: how many of last iteration's carried-over points came from mid-iteration injections, and what they displaced.
- Coach the PM on the consequence in their own language - context switching, unpredictable delivery, and the fact that a request honoured this week is a commitment broken next week.
- Route genuine production emergencies through the on-call path, which is already a sanctioned interruption.
- Loop in the RTE if the PM is a manager or business owner, because this is a train-level anti-pattern, not a private misunderstanding.
Be careful not to: position yourself as the team's bodyguard against the PM, or promise the team you will 'stop' the requests. That trades a short-term relief for a long-term loss of the relationship you need. Also do not let the requests simply vanish - invisible refusal is worse than invisible work.
Record it in the impediment backlog either way; a recurring pattern deserves to be visible at Inspect & Adapt.