There is more than one good explanation to why many organizations that have undergone an agile transformation and implemented an established agile framework at scale still struggle with time-to-market and customer satisfaction issues.
But there is one explanation that all my transformation clients would sign in blood without thinking. It’s a complicated explanation to label, so I will allow myself to clumsily reduce it to Stakeholder Management. Every product, every Agile Release Train, every SAFe portfolio has some stakeholders attached to it, and the mere fact that these should need to be “managed” suggests a certain degree of methodological omission on behalf of the mentioned agile frameworks.
Often viewed as the VIPs of the ART, the stakeholders (primarily business owners and executives) have over the years of agile scaling developed quite a terrible reputation of hopeless class skippers, who only rarely bless the system demo with their absent-minded presence and who consistently endorse the Scrum teams with a frugal “looks great,” only to drop their real opinion bomb on the last demo of the PI once they’ve finally managed to tear themselves away from their phones and actually tried the product out.
Of course, not all ART stakeholders are like that, and I am certainly not suggesting that simply having this rather ambiguous label applied to oneself automatically injects a personality-altering serum into your bloodstream, turning you into a terribly irresponsible and arrogant person. The problem is, as is often claimed by convicted criminals, in the system.
While stressing the importance of business owners and other stakeholders for the success of the ART, apart from the once-per-quarter business value assignation, neither SAFe nor other scaled agile frameworks prescribe how exactly the individual work of business owners should effectively plug into the workflow of the ART. But without this alignment, ARTs face delays, wasted effort, and a growing disconnect between business priorities and actual development. Time-to-market stretches longer than expected, and teams are left scrambling to adjust to last-minute demands rather than executing on a well-integrated plan.
While Scrum teams operate in structured sprints, many stakeholders treat their contributions to PI objectives as secondary to their personal workload rather than fully integrating them into their own structured planning. In fact, as will be outlined in one of our next agile blogposts Agile Beyond Teams (stay tuned…), even roles embedded in the agile teams (Scrum Masters and Product Owners) have a bit of the same problem, as their work isn’t really planned within the scope of the teams and they too can become bottlenecks without a proper method to it.
Adopting agile methods for individual planning like Scrum for One or Kandike helps bring alignment between agile teams and other passengers of the Agile Release Train. But how exactly should this alignment be achieved for temporary passengers (ART stakeholders) who only intended to go one stop?
Regardless of whether you apply an agile method to your individual planning or not, if you have been assigned to an ART in the capacity of any kind of stakeholder – be it a business owner, an RTE or a Product Manager, there are three important things you should do to make yourself dramatically more useful to the ART’s accomplishment of its PI objectives and prevent yourself from becoming a bottleneck.
1. Make PI and Sprint Goals Personal
If you’re a stakeholder in an ART, your personal planning should explicitly integrate the ART’s PI objectives to which you are capable of contributing. Otherwise, your daily tasks risk becoming disconnected from ART priorities, and your ability to support the teams effectively will be compromised.
Here’s what you should do:
- Identify the PI objectives that are relevant to you and include them among your individual mid-term goals. (For example, if you’re using Kandike for personal planning, such PI objectives should be on quest cards in your Mission Deck.)
- Align your short-term goals with the sprint goals of any team working toward a PI objective you can influence. (In Kandike, that would mean making at least one of your game objectives contribute to the relevant team’s sprint goal.)
- Plan your contributions ahead of time. If you intend to help, create tasks for it during or ahead of the relevant sprint – meaning that your contributions to the sprint goal should be planned, not spontaneous.
2. Synchronize Cadence
Agile thrives on predictability and iteration, yet many stakeholders operate outside the established sprint and PI cadence. When teams work in fixed two-week sprints, but supporting stakeholders follow inconsistent or reactive planning cycles, misalignment is inevitable.
Here’s what you should do:
- Plan your individual work in sync with the sprint cycle of the teams you support. Your individual sprint (if using Scrum for One) or game (if using Kandike) should start and end at the same time as the sprints of the teams on the ART.
- Schedule your planning and priority-setting sessions in coordination with ART events, ensuring that your focus aligns with what the teams need from you at the right time. If you are working on an agile team, you should place your individual sprint planning (or dealing session, if using Kandike) right after the team’s.
3. Allocate Capacity
Many stakeholders acknowledge the importance of PI objectives but fail to align their personal capacity planning with them.
Here’s what you should do:
- Stop treating your involvement in the ART as extra work. Structure your personal workload around ART needs to the same extent to which your capacity is formally allocated to that ART. If you are using agile methods for individual planning – set a guardrail for how many story points (if Scrum for One or Kanban) or card value (if Kandike) you can allocate in each sprint/game.
- Block capacity for product demos and other ART interactions (backlog refinement, Inspect & Adapt etc) in your plan (use event cards in Kandike) to ensure you’re available when the teams need you.
- Proactively allocate a percentage of your work capacity to ART-driven initiatives rather than assuming you’ll “make time when needed.”
Not easy?
To some it won’t be. If you’re the kind of stakeholder who is also a product owner in another ART, where the team cadence is different, then you may have trouble with one of these three pieces of advice. But I can bet my dog’s commitment to dull nutritious dogfood and feed it cake for a week if most of the people reading this haven’t checked more than one of the three points above (this may not sound like a hard bet, but I assure you that cake is really bad for dogs and I love my dog).
For an ART to be successful, alignment cannot stop at the team level. Stakeholders who integrate structured, agile-compatible personal planning methods into their workflow move beyond passive oversight and become active contributors to ART success.
Because here’s the truth: if you’re a stakeholder, your involvement is either accelerating progress or slowing it down. The difference comes down to whether you treat your role as a passive advisor or as an integrated part of the agile system. Teams thrive when those around them actively engage – not just when it’s convenient, but when it’s needed most.
By aligning your individual planning with PI objectives and portfolio goals – ideally using agile personal planning methods like Scrum for One, Kandike or Personal Kanban – you ensure that your contributions aren’t last-minute reactions but deliberate, value-driving actions. True agility happens when everyone – not just delivery teams – works in sync with the ART. And that includes you.
Oh, and if you feel that either you or your organisation need to sharpen your saw when it comes any of the agile methods above, feel free to check out the trainings in SAFe, Scrum and Kandike on P3 Academy.
