By way of context, Participatory Budgeting (PB) in Core SAFe is a twice-a-year portfolio event where a cross-section of business, technology, and operational leaders work through how the portfolio's money should be spent. Groups of five to eight are each given the whole portfolio budget and asked to fund the solutions already running (baseline solution investments, or BSIs) and the epics competing for new money (proposed solution initiatives, or PSIs). The pattern across the groups shows leadership where there is agreement and where there is not.

The bit people seem to miss is that giving people a voice does not mean giving up decision rights. As I always tell my classes, the decision makers are the decision makers. Participatory Budgeting doesn’t have to change that. In fact, I have always found PB to be a low-cost, generally successful experiment. The executive gains a room full of stakeholders telling them which things everyone agrees to fund, which things nobody will defend, and which handful are genuinely contested. At a minimum, the list of items competing for funds will be shorter at the end of a PB session than it was at the start. 

The real risk is that the executive does not listen and the whole exercise gets ignored. I fear that would be soul-destroying.

Introducing Strategic Investment Planning

In April 2026, Scaled Agile revised the guidance article on Participatory Budgeting and renamed the event Strategic Investment Planning (SIP). My sense is this was a wise decision. Participatory Budgeting never resonated with senior executives. Strategic Investment Planning sounds like something an executive would want to participate in (see what I did there?!). It also speaks to what the event actually is: a structured conversation about where to put the portfolio's money.

The forums are an input, not a decision

While I have always taught that the output from Participatory Budgeting was a recommendation to the executive, the framework was less definitive. The PB article stated the purpose of PB was to get feedback from key stakeholders "and determine how to allocate the budget best." It also said the results "do not directly determine the budget allocations for the value streams." 

The SIP article now makes it explicit: portfolio leaders may or may not make all funding decisions during the event. They may instead use the forum feedback in a soon-to-be-held Strategic Portfolio Review. The forums surface what the organisation values and where the tensions are, and can be an explicit input to a Strategic Portfolio Review where portfolio leadership acts on what they have heard. (This approach does make it harder for the exercise to be quietly ignored.)

The updated agenda carries the same instinct in a smaller way by noting that sending epic and solution briefings to attendees ahead of the event can help generate more thoughtful discussions during the timebox. (Surely people were already doing this? Maybe some weren't?)

From LPM to Portfolio Leadership

The definition of Participatory Budgeting was not the only point of confusion for  SAFe Lean Portfolio Managers. I think the most popular LPM question I have been asked over the years is: “Who is LPM?"

It's a fair question. SAFe is full of sentences where Lean Portfolio Management does something: LPM provides, LPM aligns, LPM allocates. It's not always obvious who that actually refers to. When it comes up in class, I explain that it depends on the organisational context: in a smaller portfolio, it is typically the executive team; in a larger one, a group of senior leaders across business, technology, and finance who are empowered to make portfolio decisions. It was a good answer (if I do say so myself!), just not one I could easily point to in the framework.

This changed in October 2024, when Scaled Agile introduced the Portfolio Leadership role and icon on the big picture as part of the Reimagining SAFe initiative. Portfolio Leadership names real people, with real authority, who are accountable for the outcome. 

In the change from PB to SIP, references to LPM, such as "LPM allocates the portfolio budget," and "the LPM team makes final determinations," have been replaced with "Portfolio Leadership allocates the portfolio budget" and "Portfolio Leadership makes final determinations."

This change was not a simple find-and-replace. If you read the guidance, you will find that LPM still does the costing and the analysis: it allocates the baseline solution investments for the budgeting period, treats previous investments as sunk costs, and analyses the results of the forums. But Portfolio Leadership turns up wherever funding decisions get made. 

Scaled Agile says as much in a note at the top of the SIP article, stating that the update preserves the collaborative forums of PB "while establishing stronger financial accountability for Portfolio Leadership and executive fiduciaries."

The Value Management Office (VMO) is also named as having a specific role in the event, further disambiguating the generic LPM guidance. It helps Portfolio Leadership calculate the baseline solution investments, and may present the forum results.

What does not change

The mechanics are unchanged. Four steps: prepare content, assemble participants, conduct forums, analyse results. Groups of five to eight. The BSI and PSI structure: what you spend to keep the lights on versus what you spend on new epics. The budget allocation method. If you have run a PB event, you already know how to run a SIP event. And if your leaders have been making the call in the room, nothing says they have to stop. May or may not is the point, and that choice sits with them too.

The courseware will catch up eventually. It always does. In the meantime, if you are implementing LPM, you have clearer language for the accountability conversation with your leaders. And when someone asks me who LPM is, I can finally point at the framework rather than answering from experience.

The day delivered real value in shared understanding and dependency visibility. It also taught us something awkward: most teams told us their plans had not materially changed as a result of the day. The planning had already happened, continuously, outside the room. So we chose to stick with rolling wave, and my conclusion at the time was that without stakeholders in a room making trade-off decisions, the PI construct wasn't adding value for us.

I remember Dean’s reaction to the blog very clearly. He acknowledged that our approach worked for a stand-alone ART but would struggle when there were dozens or even hundreds of ARTs trying to coordinate at enterprise scale. It was a fair point. Over the years, I have revisited the idea of rolling wave planning. Oddly, every RTE I have suggested it to did not want to give up the forcing function of the two-day PI Planning event, which ensured Product Management had a ready backlog. I never forced the issue, as I always worried that if or when the organisation added ARTs, the lack of cadence-based PI Planning would become a challenge. I had also become a huge advocate of the magic of the tried-and-true two-day PI Planning format. 

When Andrew Sales announced in session four of the AI-Native SAFe series that the two-day PI Planning event is replaced by a one-day PI Outcome Planning event in AI-Native SAFe, I had mixed feelings and a strange sense of déjà vu.

Not a Shorter PI Planning. A Different One.

Let's start with what PI Outcome Planning actually is, because it is not PI Planning compressed. The article states the change plainly: the two-day event "that provided the time and space for the entire ART to create a set of plans" becomes a one-day event "that focuses on in-flight re-alignment". Having read the guidance, my view is that this is a different planning philosophy, not a rename.

Consider what arrives at the event. In Core SAFe, PI Planning consumes an ART backlog that Product Management has prioritised using WSJF. In AI-Native SAFe, Business Owners and ART leadership draft a set of PI outcomes beforehand, informed by the roadmap, the vision, progress on ART outcomes and learnings from Sense and Respond events. The prioritisation call has always been made before the room, in both models. The difference is that Core SAFe names the method for making it, and so far, AI-Native SAFe doesn't.

The draft PI outcomes go to the teams a week before the event, and teams draft their own team outcomes in the days leading up. It looks like an IP iteration in shape, though the article never calls it one. This is the part I keep turning over. We have spent years teaching teams to limit their pre-planning, precisely because teams that arrive with a finished plan won't change it in the room. I've watched that dynamic from the other side: at our one-day event, plans didn't change on the day because rolling wave meant the planning had already happened. Now the guidance asks teams to arrive with drafts. Are we recreating the anti-pattern we spent a decade coaching out? Or does it not matter this time?

Maybe it doesn't. The old anti-patterns were anti-patterns of output planning. Pre-committing hurt the process because teams would anchor to their plan and resist re-planning as it felt like waste. Two days were necessary because negotiating every feature and dependency across an ART takes two days. PI Outcome Planning doesn't plan all the teams' outputs. The day alternates between outcome breakouts, where the teams contributing to a PI outcome converge on how they'll achieve it together, and team breakouts, where each team consolidates its own plan. The teams on the ART are explicitly told not to identify all their outputs. Instead, they identify only what they need to commit to outcomes and milestones, then let the specifics of the work emerge over the PI. In some ways, this seems similar to the Discovery pattern we use to define features ahead of PI Planning. 

On the other hand, it is possible that the anchoring behaviour we saw in teams that pre-planned was never about outputs. Maybe it's about humans defending decisions they made before they walked in, and outcomes will anchor just as hard as features did. The drafting happens team by team, from the same set of draft PI outcomes, so what happens when two teams arrive at an outcome breakout with roughly the same team outcome? Someone will be giving up a position their team formed before the event. That might be exactly the trade-off conversation the breakout exists to host, or it might be the anchoring problem with a new name. I genuinely don't know, and I will be interested to see how this plays out in the gemba. 

What is clear is that, like PI Planning, PI Outcome Planning creates the space to make the trade-off decisions and align teams. The article's worked example shows exactly that: a team surfaces a capacity clash, it goes to Management Review and Problem-Solving as a "decision needed", a pilot gets deferred in the room, and the PI outcome's key results are adjusted to match. The day ends with a confidence vote on the result.

In the meantime, I suspect the nuance of one-day PI Outcome Planning vs the anti-pattern of one-day PI Planning will be lost on many, and the detail that explains the difference lives behind the SAFe Studio paywall. I feel for the many RTEs that are about to be inundated with the message "Scaled Agile says PI Planning can be one day now". When responding to this, I recommend sticking to the facts and posing the question: AI-Native SAFe has a different event called PI Outcome Planning. Are you proposing we move our ART to an AI-Native operating model?

Turning Up the Good with Sense and Respond

The other new event in AI-Native SAFe is Sense and Respond: two hours, every iteration, for the whole ART. It replaces the half-day end-of-PI Inspect and Adapt event and the System Demo each iteration. The first hour senses: progress against PI and team outcomes with updated key results, product demos, workflow improvements and challenges, and customer feedback and metrics. The second hour responds: identifying what needs a response, exploring options, and agreeing decisions and actions with owners.

One part of this is similar to the pattern I have been using since 2013, the end-of-iteration "Bubble Up", where teams surface challenges outside their control in their retros, and delegates bring them to a cross-team session, where sometimes another team has already solved the problem. We have long had a theory that a fortnightly Bubble Up reduces the need for the I&A problem-solving workshop, because problems are raised and addressed as they emerge instead of being stockpiled for the end of the PI. The article seems to agree: it notes that AI-Native ARTs may choose to run the problem-solving portion of Inspect and Adapt periodically.

The more time I spend thinking about Sense and Respond, the more I find myself thinking about Core SAFe. Teams and stakeholders regularly complain about the duplication between the fortnightly System Demo and the PI System Demo, and I've never had a good answer for them. A version of Sense and Respond might be it: one fortnightly event consolidating the demos, the measures and the improvement conversation, doubling down on the two-week cadence, which is where we have always believed learning and improvement live.

Adrienne and I made the case for progressive objective evaluation at the 2022 SAFe Summit: Business Owners at every System Demo, scoring objectives as they complete instead of all at once at Inspect and Adapt. It works when the Business Owners are in the room. Core SAFe has always expected Business Owners at the fortnightly System Demo, but in my experience, that attendance is patchy at best. The end-of-PI System Demo catches what the fortnight misses. AI-Native SAFe removes this safety net.

The way we measure has changed too: Business Value and Actual Value are not mentioned in the new event guidance articles, and ART predictability appears to be gone with them, in favour of key results reviewed at every Sense and Respond. The in-flight measures and trade-offs now live in one fortnightly event, and the ask has grown from an hour to two. Will Business Owners give us two hours a fortnight? I'm not sure they will.

Sense and Respond feels like the rolling wave approach we used at EDW, with one difference: AI-Native SAFe keeps the PI cadence alongside it, and uses it to close the gap Dean called out. Teams sensing and responding independently drift apart, and the divergence compounds; the article says as much. Sense and Respond is the fortnightly correction, and PI Outcome Planning is the periodic re-anchor. On paper, that's rolling wave planning in SAFe with Dean's objection answered.

Meanwhile, in Core SAFe

One more thing from session four, and it might be the most immediately useful. Andrew Sales announced an update to the Customer article, and when I went looking at the change I noticed something he didn't mention: the update was made to the Core SAFe Customer article, with AI-Native SAFe linking through to it. As far as I can tell, that's the first time the two models have been updated in unison. I've written before about how much of the AI-Native SAFe guidance would serve Core SAFe practitioners just as well. This is Scaled Agile doing exactly that, and I'd love to see more of it. You don't need to adopt any of the AI-Native SAFe patterns to benefit from this one.

The new content is more practical but not equivalent. The section with the four-part customer typology is gone, and it is replaced by a customer feedback loop and useful guidance on customer demos, including a simple two-by-two grid to help teams frame the right approach for the right purpose: is the purpose to learn or to persuade, and is the reach small or large? The combination maps to the stage of your product and creates optionality I suspect many teams have never considered. Most default to the same demo format every time.

What's Next

Session five, Building AI-Empowered Products, runs in two weeks. Session six, Adopting AI-Native SAFe, is on 25 August, the same day the AI-Native upgrades go live: free, on-demand, with an expert upgrade for SPCs, ASPCs and SPCTs and a certified member upgrade for anyone holding any SAFe certification, any version. I'm hoping session six also answers the question I keep circling in this series: who is AI-Native SAFe actually for? See you then.

Rebecca opened with the big question: Do we still need ARTs in this era? Her answer was, of course, yes. Her rationale was that in the AI era, we still have system-level problems that no single team can solve alone, and so there's still a need for cross-team collaboration. This makes a lot of sense to me. I still remember the early versions of SAFe, where an ART made sense anywhere a large group of (software) people needed to work together to solve a problem. I think that still holds true today, with or without software. (This is the same logic we applied when introducing the Agile Release Tram.) 

Pump Up the Volume (Any 1990 Christian Slater fans out there?!)

Six characteristics define an AI-Native ART: 

1. Organised around products, 
2. Outcome-driven, 
3. Powered by human expertise and judgment, 
4. Balancing rapid innovation with cadence-based learning, 
5. Optimising shared AI workflows and platforms, and
6. Ensuring AI governance and ethics.

For the most part, these characteristics are not foreign to SAFe. What has changed is the amplification, and that's a positive move.

Cadence is the clearest example. "AI makes ART cadence more important than ever," Rebecca said, because teams working faster accumulate local decisions and dependencies faster, and new learning pulls the product in different directions. The importance of cadence definitely isn't new. Scaled Agile just pumped up the volume. ;-)

Organising around products is the one that caught my attention first. I've spent almost a decade teaching "organise around value". So I had a look at the AI-Native ART article for context. It contrasts organising around products against organising an ART around a system, a function, or a project. Which is exactly what organise around value has always argued: don't build a train around a platform, a department, or a piece of work with an end date. Same same but different.

New to the ART

Number six is the new one. Though AI governance and ethics aren't new to SAFe. What is new is that this is now an explicit expectation of an AI-Native ART.

This responsibility cannot be delegated to the teams. (I think Deming would approve!) It manifests as a centralised responsibility for setting standards and policies that teams work within. The ART gets two responsibilities: ensuring education and adherence to the portfolio's AI governance, ethical guidelines and guardrails, and defining any extra its own products need.

Four practices sit underneath ensuring AI governance and ethics:

1. Defining policies around acceptable risk
2. Integrating AI governance into shared platforms
3. Establishing standards for consistency
4. Operationalising human accountability

These practices make a lot of sense for anyone deploying AI agents, regardless of what operating model they're running: Core SAFe, AI-Native SAFe, or something else completely different. As Rebecca said, "Agents require management. People require leadership."

The Bottleneck Moved

Two weeks ago, Andrew told us the barrier to building solutions had evaporated, crediting Mik Kersten. (Kersten's Output to Outcome is out now. It's downloaded on my Kindle, but that's as far as I've got!) Rebecca picked up the same thread and took it somewhere new. Teams now produce significantly more output than before, she said, “in some organisations, pull requests alone have increased up to 100x.” Her conclusion: “that moves the bottleneck from creation to validation.”

In some ways, I'm not sure creation was ever the bottleneck, at least in the world of software development. I feel like every value stream map I've facilitated illustrates that the bigger delays are upstream and downstream of coding. But what does hold true, whether or not creation was ever the constraint, is that validation is certainly one now. We are producing more output than ever before, at a faster rate than ever before, but humans still need to review all of it.

Is the future more Kanban than Scrum?

The AI-Native Teams article describes four capabilities rather than roles: product, builder, domain expert, and AI. They use a flow-based approach built on three activities: align, sense and respond. Some events are scheduled, others are pulled when they're needed - the team decides what works for them. 

What's gone is the iteration boundary. Nothing happens because it's the end of the sprint. When I wrote Is it SAFe to Kanban? I quoted David Anderson: “Kanban dispenses with the time-boxed iteration and instead decouples the activities of prioritisation, development, and delivery. The cadence of each is allowed to adjust to its own natural level.” 

It sounds like a SAFe Kanban team to me but I guess that is up to the team to decide. ;-)

In my view, the concept of a team having capabilities rather than roles is a real strength. I like how it “demands collective ownership” of the outcomes. I’ve always said Agile is a team sport. This guidance should help organisations get better at the game. 

No Playbook and No Training Wheels

I keep coming back to this section of the AI-Native team article:

Importantly, the AI-Native Team does not have a set blueprint for the events it implements to execute these activities. The team must determine its own interaction patterns based on the context in which it operates.

I feel like it is asking a lot of a team that is already working in a very new and highly dynamic context. (Remember that validation bottleneck?)

Helping the team design and improve the way the work works has historically been the domain of the Scrum Masters (or Team Coach if you prefer). 

As I wrote in Is it SAFe to Kanban?, Scrum comes with a playbook, the Scrum Guide, which I see as providing training wheels for new agile teams. Kanban has no equivalent. Teams have to be disciplined about WIP limits, build a system with clear policies, and then work to reduce the WIP limits over time. That was my conclusion then and I'd still argue it: Kanban isn't a good choice for teams that lack discipline.

There's no Scrum Master in an AI-Native team. The word doesn't appear in the ART article or the Teams article. It appears in the AI Value Architect article as a candidate pool, in which Scrum Masters and Team Coaches are natural candidates for the new AI Value Architect role.  

While the AI Value Architect is described as coaching multiple teams and solutions, this coaching focuses on AI Adoption rather than team-level agility or flow. For me, this raises the question of who will help teams determine their “own interaction patterns”?

Part of me says a high-performing Agile team will work this out for itself as it moves to becoming an AI-native team; however, every organisation that has ever invited me to help them uplift their Agile practice has one thing in common: no Scrum Masters. Perhaps this will be addressed later in the series.

An AI Value Architect by any other name (Thanks, Juliet)

I hadn't seen a role called AI Value Architect before it appeared in AI-Native SAFe, but I have seen organisations create new roles or hats with similar aspirations, around coaching AI adoption and unlocking value from AI workflows and tools. With the creation of the AI Value Architect role and accompanying responsibilities, Scaled Agile has provided a solution to a gap that many organisations have been trying to fill.

Overproduce on Purpose AND Own Every Word

These two expectations of the AI-Native Team will cause some tension. They quite possibly already are. We know that output is now unconstrained, and this creates the opportunity to overproduce in the name of exploration and innovation. However, we also know that Generative AI can be unpredictable (that’s the generative part!). So its work needs to be validated, and keeping a human in the loop is critical here. 

Sustainable pace is going to become an imperative for team and ART success in AI-Native SAFe. I am feeling this acutely myself at the moment. For the last few weeks, I've been enjoying the access to Claude Fable included in my Claude subscription, and I have generated more content than I can consume. Nobody made me do it. I just wanted to maximise my output! Ironic, I know. I have been kicking off chats in quick succession so they run in parallel, and desperately trying to keep up with the response rate. (It's more like whack-a-mole than a sensible use of AI!) Fifteen years of teaching WIP limits destroyed by one limited-access frontier AI model!

I suspect I’m not unique in this regard, so I find myself wondering how a team with no blueprint and no Scrum Master will apply responsible AI practices and maintain a sustainable pace in this new world. (And if they work it out, maybe they can shoot me some tips - thanks in advance.) 

The focus of session four will be SAFe events in the age of AI. Perhaps the answers will be there.

What’s next

Session four went to SAFe events in the age of AI: What Happened to PI Planning in AI-Native SAFe? Session five follows two weeks after that: Building AI-Empowered Products with continuous innovation and governance. Session six, Adopting AI-Native SAFe, is on 25 August, aligning with the release of the AI-Native upgrade path for active SAFe certification holders and the launch of the new AI-Native Value Architect course (an evolution of the current AI-Native Change Agent offering). See you in a couple of weeks.

This is not a new problem. It is a more visible one.

Those of you who have worked with us will know our feature discovery pattern. This is our approach to ART backlog refinement, designed to ensure ready, prioritised features for PI Planning. Every team on the ART reserves a percentage of their capacity every iteration to work on feature definition (discovery) for features targeted for the next PI. Teams use this reserved capacity to work with Product Management, the System Architect, and subject matter experts to align on the benefit, acceptance criteria and high-level solution for candidate features. This works best when Product Management has a vision and roadmap that is supported by a clearly articulated architectural runway developed by the System Architect.

Organisations that have this pattern nailed will find the new guidance less of a wake-up call and more an expanded vocabulary for something they were already building toward: a curated data stack. For everyone else, the urgency just arrived before the foundation did.

Delivery isn't the (biggest) problem anymore

Recently, I have been invited behind the curtains at a number of organisations, some past customers, some entirely new, and what I am seeing is a new pressure that did not exist two years ago. For the ARTs that haven't yet built a strong feature discovery practice, the squeeze is real: the pace of AI-assisted delivery has outrun the ability of Product Management to feed the ART with a well-defined, strategically coherent backlog.

Without a product vision, an outcome-driven roadmap, and an architectural runway that looks out further than the next PI, the ART runs out of material. Or worse, the ART's attention is diverted to random work disconnected from the product's strategic direction, in the name of "resource efficiency", the efficiency paradox Lean has been warning us about for years.

Feed the agent, or it feeds itself

An agent doesn't know what it doesn't have. It can only work with what is there. The product vision, the ART outcomes, the architectural constraints, the customer and market environment: if these things do not exist, or exist somewhere but have not been maintained, the agent reaches for them and finds nothing useful. So it does what any self-respecting autonomous agent would do. It finds the open door, sprints straight down the hallucination hallway, and keeps going. No one told it to stop.

That is not a technical failure. That is the predictable output of an underfed system. And the fix is not better prompting; it is the curated data that should already be there.

ARTs that were already struggling to get a coherent vision and roadmap in place before AI came along have not suddenly solved that problem. They have supercharged the gap, not closed it. The gap that was manageable when humans were compensating becomes something else entirely when agents are amplifying.

The guidance arrived at the right moment. Use it.

Honestly, I am seeing more pain than success out there. The new articles give Product Management and the System Architect something concrete to work with, not just a diagnosis of what is missing, but a framework for building it. We consider feature discovery a "turn up the good" pattern for ART backlog refinement. It is time to turn up the good again.

The agents are already here. Are you ready to feed them?

The Barrier to Build Has Evaporated

Andrew's premise is that when AI makes it cheap to produce endless output, chasing more output becomes exactly the wrong strategy. The value comes from what you learn and validate, not from volume. He credited this to Mik Kersten, author of Project to Product, whose new book Output to Outcome is out on 14 July, and illustrated it with Cognition, the company behind the AI software engineer Devin. Their process: build multiple new agents and features every week, review them with senior leadership on a weekly cadence, keep pursuing whatever looks promising, and drop everything else. Most of what they build never sees the light of day.

I think he's right, and I don't need Cognition's example to believe it. I'm about as far from a software engineer as you can get, and I can now sit down with an LLM and produce working code myself. The barrier to building, or at least to prototyping, has all but evaporated. This still blows my mind.

Where I'd add a caveat is that this isn't true for every organisation today, which is exactly why Core SAFe and AI-Native SAFe exist side by side rather than one replacing the other. Not everyone is operating at the same level as Cognition.

The Outcome-Driven Product Development Cycle

Andrew then walked through the five-stage cycle sitting at the heart of the whole model: outcomes, priorities, outputs, measurements, value. It applies at every level, portfolio, ART and team. Outcomes set the destination and are expressed as OKRs. Priorities decide where funding and capacity go. At the portfolio level, that means investment strategy; at the team and ART level, it means committed capacity. Outputs are the features, prototypes and experiments teams produce. Measurements tell you whether those outputs are moving you toward the outcome and give you the basis to decide whether to continue, stop, or pivot to something else. And value is the tangible result, deliberately made concrete rather than abstract: customer outcomes and business results, measured through ROI. Every step feeds back into the one before it.

The five-stage cycle feels somewhat familiar. It echoes the SAFe Lean Startup Cycle and the Continuous Delivery Pipeline from Core SAFe and, in my mind, represents the intent of these practices. Of course, there is often a stark difference between how Core SAFe is intended and how it is implemented. It will be interesting to see how the AI-Native reimagining of the Product Development Cycle to be Outcome-Driven changes the reality of SAFe in the field. If AI-Native can crack this nut, I see a huge opportunity to make a similar change to Core SAFe.

There are, however, two clear differences I noticed from Core SAFe. The treatment of OKRs and the treatment of ROI.

Andrew described outcomes being expressed as OKRs “down to the individual contribution that a team is making in a particular PI.” This was interesting to me, as the Core SAFe OKR guidance explicitly cautions against using OKRs to define PI Objectives, warning that they take too long to write and that key results are often lagging indicators, poorly suited to a PI timebox. So after the call, I looked at the AI-Native SAFe guidance to validate the shift, and there it was: AI-Native SAFe uses PI and team-level OKRs to maintain strategic alignment and intent. This is new.

AI-Native SAFe shifts the value conversation toward ROI in an effort to make it more tangible. Core SAFe promotes Innovation Accounting instead, deliberately deferring heavy financial modelling until organisations are more confident they're building the right thing. When Andrew mentioned using ROI to measure value, I got curious and went to the AI-Native SAFe guidance to learn more.

It's more nuanced than a straight swap. The guidance agrees that ROI is a lagging indicator and builds its own leading indicators to compensate for it: feature adoption, cycle time, and customer retention. But it also recommends modelling ROI upfront and continuously, with forecasted ROI shaping which initiatives get funded from day one, treating token and inference costs as variable operating expenses that must be built into the calculation from the earliest planning stages, not bolted on after launch. That's the part Innovation Accounting explicitly said to defer. 

Four Pressures on the Portfolio

Andrew named four pressures AI is putting on portfolio-level investment.

Technology velocity: annual budget cycles can take six to nine months to formulate, and by the time the budget is approved, the technology it was built around may already be behind. His fix is shorter, more frequent funding cycles rather than one annual lock-in.

I think organisations are underestimating the impact of this one. I look at organisations kicking off multi-year ERP replacements right now and wonder whether the solution will be fit for purpose by the time it is completed (or abandoned mid-flight!)

ROI predictability: nobody has a reliable five-year return model for AI yet, and it’s causing decision paralysis for some organisations. His fix borrows from venture capital: place a number of small bets, let the failures die quickly, and put more weight behind whatever's working.

ROI has always been hard. The money now pouring into AI is just sharpening the question.

Competitive dynamics: whoever gets to market first is building an advantage that's proving very hard for anyone else to close, so speed to a working version now matters more than a polished launch later.

First-mover advantage has always mattered. AI turns the dial up. I find myself wondering whether falling behind in this age will be harder to claw back from than it ever was before.

Resource allocation: locking your full budget into legacy IT roadmaps leaves nothing to redirect when something better comes along. His fix is a strategic AI reserve, budget deliberately held back so you can move when it's worth funding.

Strip away the AI framing, and resource allocation is just agility: the ability to respond to change. It's the one pressure I'd bet most transformations already claim to have solved and few actually have. Watch how fast a strategic reserve gets raided the moment a project runs over budget.

A New Scale of Budget Risk

Andrew also flagged a shift in how ART budgets work. Costs used to be predictable: salaries, licences, some infrastructure. Token consumption is now pulling a growing share of that into variable spend, bringing three new risks.

• A popular product can quietly get expensive. Cost now follows usage in real time, which Andrew called "a good problem to have" until the bill arrives.

• A simple-looking prompt can hide real complexity. Retrieval, conversation history, and system instructions can all fire behind the scenes, again and again, turning one request into tens of thousands of tokens.

• Vendors keep rewriting the rules. Models get deprecated at a pace we haven’t experienced before, pricing structures change, and it can catch you out mid-cycle.

In my experience, the use of SaaS products had already begun pushing ARTs to think beyond labour, licences and infrastructure, but token consumption is an entirely new scale-of-usage challenge. There are plenty of stories doing the rounds about enterprises blowing through token budgets. Andrew's point about vendor pricing risk is real, but it reminded me there's a second risk he didn't mention: we're also watching model access get switched off overnight by politicians. The age of AI is clearly going to be an unpredictable place to be managing a budget in.

ART Outcomes, Vision and Roadmap Get an Upgrade

Andrew introduced the AI-Native SAFe Outcome Tree as the replacement for the old planning chain, epics cascading into features, features cascading into stories. Features still exist; they're still one of the outputs teams produce, but the fixed hierarchy that used to link and trace them upward is gone. His reasoning: increasingly, we can't specify in advance what's going to get built or exactly how, so a rigid cascade of outputs handed down from the top doesn't hold up anymore. Instead, strategic outcomes set at the portfolio level cascade down to teams, who define their own outcomes at a much shorter horizon, sometimes just days. I like the outcome tree, though I'm genuinely curious about how the mechanics will work at the scale of an ERP replacement. 

He also drew a clear distinction between ART outcomes and the PI objectives we already know. ART outcomes come before planning. They're not a commitment; they're the direction an ART is aiming for and the thing PI Planning has to work out how to pursue. Their job is to help the portfolio monitor and steer, give each ART a boundary for what it's there to achieve, and give teams a reason for the work rather than just a list of it. 

Andrew was equally specific about product vision, built on three pillars:

• Informed by data, using AI to run sentiment analysis and track competitors and industry movement at a scale no product manager could do manually.

• Aligned with what the portfolio is funding and the financial limits it's operating inside.

• Anchored to the technology and architecture an organisation can actually deliver on, not just what's technically possible somewhere else.

Roadmaps change shape too, moving away from a straight list of features toward outcome-based swim lanes, with milestones and releases still marked, but read as a tool for checking direction rather than a delivery schedule. A swim lane for outcomes doesn't close when a feature ships. Several outcomes only reveal themselves over time, so that lane keeps being watched and validated well after release.

Organisations have always struggled with vision and roadmaps. Whatever an organisation does badly today, I expect the age of AI will amplify.

Context Is King: Curated Data Is the Enabler

Andrew closed out the session by talking about how AI gets briefed to do its job: context. I love this! Context came out as my number one strength on one of those workplace strengths assessments. (Maybe I was an AI in a previous life!) So I'm biased, but the point stands: context is king.

His argument: AI only becomes a reliable partner, rather than a generic tool, when intent (why we're doing this), specifications (what good looks like and where the limits sit), and context (the environment the product lives in) are working together. Miss any of the three, and you get output that's either off-target or hallucinated. Connect them, and an AI agent stops needing to be walked through the background of a task every time because it can pull its own intent, specs and context from a shared source instead of starting cold.

That shared source is what Andrew called curated data: complete, accurate, maintained and securely accessed, built intentionally ahead of time as part of the architectural runway rather than assembled under pressure when it's suddenly needed. He tied it directly to the cycle itself: intent and context feed outcomes, performance data feeds priorities, specifications feed outputs, feedback data feeds measurement and value. Nothing in the model runs without it.

I suspect a lot of organisations are heading for a 20/20 hindsight moment when they realise how much they've underinvested in this space. I've always said an enterprise's data is its greatest competitive advantage. In the age of AI, I think that's even more true.

Stay Tuned

Not much in this session was new to me, and I don't think that's a bad thing. Good frameworks should feel like validation of what good practitioners already know.

For those wondering how they will get up to speed with AI-Native SAFe, Andrew announced that an on-demand upgrade path will become available from 25th August, letting anyone with an existing SAFe certification upgrade to AI-Native SAFe. 

Session three was about ARTs, Teams and Roles. My take on it is here: So What is an AI-Native ART?

Here's what Microsoft doesn't make obvious: there are two different products. The first is Microsoft 365 Copilot Chat (Copilot Chat), which is included with most Microsoft 365 business subscriptions. The second is Microsoft 365 Copilot (M365 Copilot), which is a paid add-on. Both are called Copilot in the interface, which is where the confusion starts. As of early 2026, only around 3% of Microsoft 365 customers were paying for the full version. The other 97% have Copilot Chat.

There is a material difference between the two products, and it starts with the context window: the amount of information Copilot can hold in working memory at any one time. 

What is a context window?

Think of the context window as the AI's working memory for a conversation. It covers everything currently in play: your question, the AI's response, anything you've pasted in or attached to a prompt, and the history of the exchange so far. When a conversation exceeds that limit, the AI doesn't stop. It quietly drops the oldest parts of the conversation to make room for new input. You won't be told this has happened. The responses just start to get less detailed and sometimes shorter, more generic, and less useful, which is exactly what frustrates people.

I ran into this a while back on a client site. I was using their Copilot Chat because that was the GenAI tool I had access to in their ecosystem, and the document I was working on was their IP, so keeping it inside their environment was the responsible thing to do. I was trying to summarise a PowerPoint deck of around 30 slides, and it kept giving me partial responses, skipping slides, and dropping content. The harder I pushed, new chats, more attempts, the worse it got. I think I was being throttled. 

I later learned that the free tier shares capacity across everyone using it, and at busy times, Microsoft quietly pulls back on the heavier features without telling you. In hindsight, I was trying to do something that was beyond what Copilot Chat is built for.

In my experience, the free tier has less working memory than the paid version. Microsoft does not publish the figures for either product, so I can't quantify the difference. But if you have used tools with larger context windows, you notice it quickly. The practical effect is that Copilot Chat struggles with longer documents, complex multi-step tasks, and extended conversations in ways the paid version does not.

The second difference is what the paid version can see. Copilot Chat has no meaningful access to your organisation's data. It cannot search your inbox, find a file on SharePoint, check your calendar, or pull up what was discussed in yesterday's Teams meeting. There are limited exceptions depending on your organisation's setup, but as a general rule, if you want Copilot to work with your data, you have to bring the data to it manually. The paid version removes that constraint. It can search across your email, SharePoint, local files, meetings, and conversations to answer questions in context. Both know the world. Only one knows your work. If you are going to use Microsoft Copilot as your GenAI tool, access to your organisation's data is the thing worth paying for.

To check which version you have, look at the bottom left, under your name. The free tier says Copilot Chat (Basic) and gives you an Upgrade button. The paid one says M365 Copilot (Premium).

There are other limitations worth knowing about. The Researcher agent, Copilot's equivalent of a deep research mode, is only available on the paid version. If you are using Copilot Chat and cannot find it, that is why. Copilot Chat also cannot summarise your Teams meetings natively. You would need to manually obtain a transcript and upload it. Copilot Chat is no longer available inside Word, Excel, PowerPoint, and OneNote. It remains accessible through the standalone Copilot app and in Outlook.

None of this means Copilot Chat is useless. It does useful work within its constraints, and there is a reasonable amount you can do to get more out of it.

Before you start: Make sure you are signed in with your work account, not a personal Microsoft account. When you are, a green shield appears in the interface indicating Enterprise Data Protection is active. Your prompts and responses stay within the Microsoft 365 service boundary and are not used to train Microsoft's models. If you are signed in with a personal account, that protection does not apply. Free is relative. ;-)

The single most useful thing you can do is bring your data to it. Copilot Chat cannot access your files, but you can bring them to it. Upload a document, paste in the content you want to work with, or copy in an email thread. It is a manual step, but it works.

For long documents, what I've found works is asking about specific sections rather than expecting a full summary in one pass. Copilot Chat tends to prioritise the beginning and end of whatever you give it, so content buried in the middle is where things get unreliable. If the document is long, break it into parts and work through it in chunks.

Keep your conversations shorter than you might expect. If a thread runs long, ask Copilot to summarise the discussion before you continue, then use that summary to start a new chat. This resets the working memory and gives you a clean run at the next part of the problem.

Copilot Chat is well-suited to drafting and rewriting: emails, reports, decision papers, and proposals. It is also good for web research (with citations) and brainstorming. These are the use cases where I've found the free tier holds up.

Use it inside Outlook if you have it available. Copilot Chat retains some awareness of the email you have open, so you can ask it to help you respond without having to paste the thread manually. It is one of the few places where the free tier has some native context without extra effort.

For anything more demanding, it is a different story. If you want to use AI as a genuine thought partner, working through complex problems, synthesising across multiple documents, and building on a long conversation, the context window limitation will get in your way repeatedly. If you want AI that knows your work without you having to manually feed it everything, the free tier cannot do that. These are not workarounds you can prompt your way out of. They are product limitations.

The upgrade conversation is not complicated. In most organisations, it is an IT service request, not a technical project. What I typically see is that the conversation stalls not because of cost or complexity, but because no one has made the case for who specifically needs it and why.

Most of the frustration I hear about Copilot in Australian and New Zealand organisations comes down to this: people are using a tool they don't fully understand and blaming the technology when it falls short. Knowing what you actually have is the starting point for everything else.

From there, the next step is turning access into capability: see our Microsoft Copilot training.

Only 9% of Executives Are Seeing Value from GenAI Investments

The webinar opened with a finding from the 2026 Return on AI Institute study: only 9% of executives globally report seeing value from their generative AI investments. I'm not surprised by the number. It mirrors what we're seeing in the field. Organisations tend to fall into one of three patterns. Some give everyone access to Copilot, Claude, ChatGPT or Gemini, run a one-hour how-to session, and let people loose. Others issue Microsoft Copilot chat as the default and require a business case for anything beyond that. And some ban GenAI entirely (while everyone uses it anyway on their personal devices). At the individual level, the most prevalent use case seems to be coders using GitHub Copilot or equivalent, with most non-coders being self-professed dabblers.

The RoAI research attributes the lack of measurable value partly to the absence of a standard framework. This aligns with our observation that organisations with mature SAFe LPM practices are better at measuring the ROI on AI investments. SAFe has given them the habit of validating hypotheses before committing, and that discipline is being applied to their AI initiatives.

Not a Layer, a Reimagining

Andrew was clear that AI-Native SAFe is not AI layered onto existing SAFe. It's built on Lean and Agile foundations but recast from the ground up for the AI-Native organisation.

I think this is the logical next step, given that AI-Empowered SAFe has been the emerging storyline for about a year. That was the layering-on approach, and it made sense (it's what people knew, and it gave organisations somewhere to start). But there's real value in reimagining SAFe for an organisation where AI is genuinely native to how work gets done.

The thing I'm most glad about is that Scaled Agile hasn't forced everyone to make the leap at once. Core SAFe remains fully supported and is not going away. AI-Native SAFe sits alongside it as the evolution organisations adopt at their own pace. For most organisations I work with, that's exactly the right framing: something realistic to use today, and something to aspire to.

The Four Shifts to Achieve AI-Empowered Agility

Andrew recapped the four critical shifts required to achieve AI-Empowered Agility first shared at the SAFe Summit Amsterdam in March. I see these as helpful for organisations seeking to understand what needs to change for them to become AI-Native given their current state.

A New Role: AI Value Architect

This new role is focused on ensuring AI efforts translate into measurable results and provides coaching on AI adoption and fluency. This was flagged as a potential career path for SAFe Scrum Masters and SPCs. I find this genuinely interesting, and I'm curious to see the next level of detail. (Andrew said that this would be covered in a future webinar.)

New ART Events

Three new ART events evolve existing ones: PI Outcome Planning replaces PI Planning, Customer Demos replaces System Demo, and Sense and Respond is a new end-of-PI analytics event powered by AI. (I love the language of Customer Demos!) 

And an Evolved Continuous Innovation and Delivery Pipeline

The Continuous Delivery Pipeline becomes the Continuous Innovation and Delivery Pipeline and now spans discovery through go-to-market. I think including GTM in the pipeline will be a valuable enabler of flow. I haven't seen the details yet, but the direction makes sense.

Curated Data is the Foundation

Andrew flagged curated data as the single biggest predictor of AI success. My SAFe life started in the data domain. I spent over a decade in data warehousing, where curated, trusted, structured data was the foundation of everything. The rise of data lakes expanded what organisations could store and analyse, including unstructured and semi-structured data. AI-Native SAFe takes that a step further: fit-for-purpose data is the real issue now, and what "fit for purpose" means depends entirely on the use case. 

Stay Tuned

If you missed last night's session, the recording is available on the AI-Native SAFe Resource Hub. As is the link to register for the next webinar on June 30, "From Outputs to Outcomes with AI-Native SAFe”. Moving from outputs to outcomes has always been harder in practice than it sounds; it will be interesting to see how AI-Native SAFe approaches this challenge.

Update: I've written up the sessions that followed.

• Session two, From Outputs to Outcomes: What AI-Native SAFe Changes: the five-stage outcome cycle, OKRs and portfolio funding.
• Session three, So What is an AI-Native ART?: teams, roles and the validation bottleneck.
• Session four, What Happened to PI Planning in AI-Native SAFe?: PI Outcome Planning and Sense and Respond.

One of the most common questions we are asked - both prior to and during courses is: How do I know which SAFe training to take? Those who are new to SAFe want to know which one to start with. Those who already have one SAFe Certification want to know which one to take next. Given there are currently 17 SAFe certifications (and 6 Micro-Credentials) provided by Scaled Agile, Inc., this is a valid question!

15 of the 17 SAFe certifications are plotted on the SAFe Implementation Roadmap. While this informs where the course fits in the context of implementing SAFe and which classes should be included in an ART Launch, it is less helpful when trying to work out which class an individual should attend. 

Most SAFe certifications are role-based, which leads some people to think that the way to choose a class is to pick the role you have or aspire to and take the appropriate class.  While that is certainly one approach, it is not one I would recommend. To get the most out of your investment in training, you should take a considered approach to choosing which class or classes to attend. 

 

How do the Scaled Agile Certifications Differ?

Leading SAFe with SAFe Agilist (SA) Certification (2-days)

Technically, the target audience for Leading SAFe is people in leadership and management roles. This is the class taught to leaders at all levels, from front-line leaders to CEOs, in organisations that are already using SAFe and/or exploring adopting SAFe. When launching Agile Release Trains (ARTs), we like every people manager for every person on or impacted by the ART  to take this class, along with the ART leadership (Release Train Engineer, Product Management and System Architect) and Shared Services. 

Where possible, we recommend executive teams attend as a group: the conversation in the room is qualitatively different when peers learn together. Sometimes we warm up a subset of this group with the shorter SAFe Executive Workshop first, then bring them into Leading SAFe together. For executive cohorts in particular, instructor experience matters. You will likely only get one shot at this.

However, the Leading SAFe class is also the best way to get an introduction to SAFe.  I like to think of Leading SAFe as a “crash course” in the Scaled Agile Framework. It provides an overview of the big picture and covers four of the five SAFe Disciplines that help organisations develop the necessary skills and behaviours to implement SAFe effectively: Lean Portfolio Management, Team and Technical Agility, Product Development Flow and Leadership and Culture.

This class offers the most comprehensive coverage of the SAFe Principles and includes a PI Planning simulation. The current version of this course also introduces AI-Empowered SAFe. Those who complete the Leading SAFe course are eligible to take the SAFe Agilist certification exam. This is the most popular of the SAFe certifications. 

 

Implementing SAFe with SAFe Practice Consultant (SPC) Certification (4-days)

The most comprehensive SAFe course is the 4-day Implementing SAFe class, which includes SPC certification. This is the only class that covers all five SAFe Disciplines and the full SAFe Implementation Roadmap. This means if you want to be on the front line helping organisations implement SAFe, this is the course you want to take. This class is also taken by many people who want to train others in SAFe. While the SPC certification is the first step on this journey, experience with applying SAFe and delivering training is also an essential ingredient to becoming a successful SAFe trainer.

There are a couple of myths about this course that I would like to dispel. Firstly, the inclusion of Leading SAFe in the content creates the misconception that attending this class is equivalent to attending a Leading SAFe class. This is not true. When we teach a two-day Leading SAFe class, we are focused on introducing participants to SAFe. When we teach the Leading SAFe content in the context of Implementing SAFe, we are focused on helping participants become effective SAFe Practice Consultants, so it is a much deeper and more detailed conversation. This can be overwhelming for those new to SAFe.

The second myth is that Implementing SAFe is only useful for people who want to train others in SAFe. This is incorrect. This class is primarily for those leading and supporting an organisation's journey to implementing SAFe and launching successful Agile Release Trains.

The current version of this course also introduces AI-Empowered SAFe. Public Implementing SAFe classes can only be delivered by Scaled Agile Gold and Platinum SPCT partners.

SAFe for Hardware with SAFe Hardware Agilist (SHWA) Certification (2-days)

The SAFe for Hardware course is designed for engineering teams working in hardware-reliant environments who want to apply Lean-Agile principles to hardware development. The target audience includes systems engineers, product managers, program managers, engineering leaders, and hardware practitioners — mechanical, electrical, and otherwise.

The course covers how to develop solutions incrementally, build cross-functional Agile teams around hardware value streams, accelerate feedback loops using digital simulation, rapid prototyping and continuous delivery pipelines, apply multiple horizons of planning, and specify solutions incrementally using set-based design. About 40% of the course is dedicated to hands-on exercises, so participants leave with practical skills they can apply immediately.

For hardware practitioners new to SAFe, this course can serve as a standalone starting point. If you are in a leadership or management role, we recommend taking Leading SAFe first.

Lean Portfolio Management with SAFe Lean Portfolio Manager (LPM) Certification (2-day course with optional 1-day workshop)

The SAFe Lean Portfolio Management course is the only SAFe class that provides a deep dive into the Lean Portfolio Management Discipline. The course is structured as two days of training with an optional one-day Getting Started with LPM Workshop. When selecting a provider, it is worth checking whether they offer the optional Getting Started with LPM Workshop — not all public providers include it.

This class is primarily attended by PMO and VMO leaders and their team members. This course is also regularly attended by people outside SAFe environments who want to apply Lean Portfolio Management thinking in their organisations.

Leading SAFe is a highly recommended prerequisite for SAFe Lean Portfolio Management training, as it is assumed knowledge.  Participants in this course experience using the full LPM toolset in a simulated context.

SAFe Scrum Master with SAFe Scrum Master (SSM) Certification (2-days)

I am a Certified Scrum Master (CSM). Do I still need to do SAFe Scrum Master?

SAFe for Architects with SAFe Architect (ARCH) Certification (3-days)

SAFe for Teams with SAFe Practitioner (SP) Certification (2-days)

SAFe for Teams is designed to prepare all members of an Agile Release Train for their roles on Agile teams within the train. This class is primarily used when launching an Agile Release Train. Once the ART is up and running, new team members who are also new to SAFe should take this class.

This course provides an introduction to SAFe and Agile and an understanding of the roles on an Agile team and an Agile Release Train. Students get to experience breaking down features into user stories with acceptance criteria, estimating backlogs and participating in PI Planning. The class also teaches participants about the Scrum and SAFe events that SAFe Agile Teams participate in. The current version of this course also introduces AI-Empowered SAFe.

Ideally, teams attend as a team with their Scrum Master and Product Owner after the SM and PO have already completed SAFe training. Teams get significantly more from this class when they attend together rather than as individuals scheduled across multiple smaller classes — when people attend in isolation and return to their existing teams and projects, the learning rarely sticks.

Note: This course is rarely offered publicly. For an individual joining a SAFe team for the first time, Leading SAFe is an imperfect but widely available alternative.

SAFe for Hardware Teams with SAFe Hardware Practitioner (SHWP) Certification (2-days)

The SAFe for Hardware Teams course is the team-level equivalent of SAFe for Teams, designed specifically for engineering teams working in hardware and cyber-physical environments. Where SAFe for Teams prepares software-focused Agile teams to operate within an ART, SAFe for Hardware Teams does the same for mechanical, electrical, systems, and embedded engineering teams.

The course covers SAFe and Lean-Agile foundations; how to operate as a high-performing, cross-functional hardware team; PI Planning and ART events; continuous delivery pipelines adapted to hardware feedback loops; and flow metrics and relentless improvement. No prior Agile experience is required.

Like SAFe for Teams, this course is primarily used when launching an Agile Release Train with hardware teams. Once the ART is running, it is also a good starting point for new hardware team members who are new to SAFe.

Like SAFe for Teams, this course is rarely offered publicly. You will need to gather a group from your organisation to run it as a private class.

Agile Product Management with SAFe Agile Product Manager (APM) Certification (3-days)

Agile Product Management is designed for Product Managers.  It is recommended that participants have attended at least one SAFe course. This course is not overly SAFe specific, so we recommend Leading SAFe and SAFe Product Manager/Product Owner as prerequisites for those working with SAFe. This course is 70% focused on the Product Manager role and 30% on the Product Owner role.

This class has a strong focus on the Customer Centricity and Design Thinking elements of the Product Development Flow Discipline, as well as the Continuous Exploration component of the Continuous Delivery Pipeline. The SAFe POPM certification places greater emphasis on the Develop on Cadence, Release on Demand dimension.

Agile Software Engineering with SAFe Software Engineer (ASE) Certification (3-days)

The SAFe Agile Software Engineering course is designed for software engineers and technical practitioners who want to build quality into their work rather than test it at the end. We recommend Agile teams, including their Product Owners and Scrum Masters, take it together. Ideally, an entire ART takes it as a train.

The course takes an outside-in approach across three days: starting with flow, test-first thinking, and BDD; moving into modelling and shared understanding; and finishing with code quality, design patterns, and TDD. Participants build a personal Agile Software Engineering improvement plan throughout the class, adding to it at the end of every lesson and leaving with a practical set of actions to take back to their team.

We often run this course with ARTs that have completed a few PIs and are ready to level up their technical practices. The IP Iteration is a natural time to schedule it as the team is together, the pressure of execution is off, and the focus on relentless improvement is exactly right.

SAFe DevOps with SAFe DevOps Practitioner (SDP) Certification (2-days)

The SAFe DevOps course is, in many ways, more a workshop than a training course. It works best when a group of people from the same organisation attend together. Participants start by value-stream mapping their current development process, and then, over the remainder of the class, they identify opportunities to improve both cycle time and quality based on course content.

This class is suitable for all members of an Agile Release Train and works best when attended by cross-functional teams. We often use this course before an ART launch to create a shared understanding of the current way of working, identify opportunities to improve and define the backlog for the System Team. For pre-launch use, attendees should come in cross-functional groups that represent the way they work today — not their future SAFe teams. The goal is to map the current state, so you need people who know how the work works from idea to deployment.

This is also a great follow-up class for those with existing SAFe training who want to bring focus to their relentless improvement efforts.

SAFe Release Train Engineer with RTE Certification (3-days)

SAFe Advanced Scrum Masters with SASM Certification (2-days)

The SAFe Advanced Scrum Master course is designed for people with an existing SAFe Scrum Master certification to 'level up'. We recommend attendees have either taken SAFe Scrum Master or have experience with SAFe before taking this class. This course is an excellent choice for an RTE and their SMs to take together. We find the nine- to twelve-month mark after an ART launch is a natural time: far enough in to have real experiences to reflect on, but early enough to course-correct. Re-energising the Scrum Masters often has a flow-on effect to the teams on the ART.

This course has recently been refreshed and has a heavy emphasis on AI-Empowered SAFe. It covers improving flow, building high-performing teams, addressing conflict, improving ART performance, and empowering teams with AI.

Advanced SAFe Practice Consultant with ASPC Certification (4-days)

The Advanced SAFe Practice Consultant course is for experienced SPCs who are ready to take on more complex transformation work. Where the SPC certification covers the foundations of implementing SAFe, the Advanced SPC goes deeper into the harder problems: engaging executives, building a transformation strategy, unlocking flow at the portfolio level, and customising SAFe to contexts that don't fit the standard pattern. It also covers AI through the EDGE framework, treating it as a practical tool for the transformation work SPCs are actually doing.

This course suits SPCs who have been running ARTs for a while and are now stepping into broader transformation roles, or who are regularly working above the ART level with senior stakeholders and portfolio structures. It is also relevant to SPCs who find that the textbook answer isn't enough and want a more sophisticated toolkit for the conversations they're having with executives and organisations navigating real complexity. A Learning Lab in the final section gives participants the chance to apply everything in a simulated transformation scenario.

Certifications not listed on the SAFe Implementation Roadmap

Leading SAFe for Government with SAFe Agilist (SA) Certification (2-days)

In February 2025, Scaled Agile retired the SAFe for Government course and replaced it with Leading SAFe for Government, which carries the same SAFe Agilist (SA) certification as Leading SAFe.

The course covers the same content as Leading SAFe, contextualised for government audiences. The main differences are reframing around citizen and public value, guidance on responsible AI use in public-sector environments, and content on government contract structures, written primarily for a US federal context.

For most Australian government clients, we recommend standard Leading SAFe. The content is the same, the certification is the same, and the US government framing in the specialised variant doesn't translate well to the Australian context. For Australian Defence audiences, the military terminology and framing may make it worth considering.

SAFe Practice Consultant-T Certification (SPC-T)

The SAFe Practice Consultant-T certification is the highest level of SAFe certification offered by Scaled Agile, Inc. Earning the SPC-T is a multi-year journey. The certification is available only to SPCs who are full-time employees of Scaled Agile Gold and Platinum partners or of enterprises with an SAFe Enterprise subscription.

SPCTs are the only people authorised to teach the Implementing SAFe class. Public Implementing SAFe classes can only be delivered by Scaled Agile Gold and Platinum SPCT partners, so availability in Australia is limited.

You can learn more about the SPC-T program's candidate qualifications, requirements, and process by viewing the SPCT Program Handbook.

Where do the SAFe Micro-Credentials fit in?

Scaled Agile, Inc. started releasing Micro-Credentials in April 2024. These courses differ from the standard SAFe certifications. Each micro-credential is approximately two hours of self-paced learning followed by a half-day instructor-led session. They are typically delivered as private courses inside organisations that want to level up on a specific skill set.

There are currently six SAFe Micro-Credentials available:

SAFe Business Owner — A one-day course for executives and senior leaders who are Business Owners on an ART. Covers the five key Business Owner responsibilities: engaging with Lean Portfolio Management, aligning priorities and PI Planning, realising business outcomes, sponsoring relentless improvement, and leading by example. No pre-work required and no annual renewal.

Achieving Responsible AI — Designed to equip Agile professionals with the skills to implement AI responsibly in their organisations. Suitable for anyone interested in using AI in the workplace.

Advanced Facilitator: Value Stream Mapping — Teaches participants how to facilitate Value Stream Mapping workshops. Ideal for Scrum Masters, RTEs, and SPCs. We strongly recommend SPCs complete this micro-credential before delivering SAFe DevOps training.

Advanced Facilitator: Conflict & Collaboration — Teaches a framework for navigating conflict. Ideal for Scrum Masters, Product Owners, Technical Leads, RTEs, Product Managers, and System Architects.

SAFe for Government: Roles and Responsibilities (government audiences) — Covers the key Agile roles in a government context, how they map to PI Planning activities, and how to navigate common SAFe adoption challenges in government environments. Suited to anyone working in or with government organisations implementing SAFe.

SAFe Agile Contracting for Government (government audiences) — Covers how to structure government contracts to support Agile delivery, including Statements of Objectives, performance measurement using Agile metrics, and modular contracting approaches. Relevant to procurement officers, contract managers, project managers, vendors, and legal and compliance teams working in government contexts.

What are the AI-Empowered SAFe courses?

In 2025, Scaled Agile began refreshing its core SAFe courses to include AI content. The AI-Empowered versions add role-specific AI prompting techniques and responsible AI practice to the SAFe certification you are already training for. SAFe is the primary focus; the AI content helps practitioners do their SAFe work better. If you are taking any of these courses now, you are getting the AI-Empowered version.

The current AI-Empowered SAFe courses are:

• AI-Empowered Leading SAFe
• AI-Empowered SAFe for Teams
• AI-Empowered SAFe Scrum Master
• AI-Empowered SAFe Product Owner/Product Manager
• AI-Empowered SAFe Release Train Engineer
• AI-Empowered Implementing SAFe
• AI-Empowered Advanced SPC

Where does AI-Native training fit in?

AI-Native training is a separate programme from Scaled Agile, designed for organisations that want to achieve a measurable return on AI investment across the whole business — not just in technology teams. Where the AI-Empowered SAFe courses add AI into an existing SAFe context, AI-Native training starts with the business problem: what value are we trying to get from AI, and how do we prove it quickly? It is relevant across legal, finance, marketing, and operations, and you do not need to be running SAFe to benefit from it.

Pretty Agile offers all three AI-Native courses:

• AI-Native Foundations — the recommended starting point, including for those who have already completed an AI-Empowered SAFe course
• AI-Native Change Agent
• Leading the AI-Native Organisation 

Where should I start with SAFe Training?

The right starting point depends on your role and what you are trying to achieve.

If you want an introduction to SAFe, or you are in a leadership or management role — including project managers, program managers, program directors, portfolio managers, architects, development managers, product managers, and test managers — do Leading SAFe. It is the most popular and widely recognised SAFe certification, and the best overview of the framework.

If you are a Scrum Master or aspiring Scrum Master, SAFe Scrum Master is the right starting point.

If you are an Agile team member new to SAFe, SAFe for Teams is designed for you. If you are in a hardware or cyber-physical environment, SAFe for Hardware Teams is the equivalent. However, SAFe for Hardware Teams is rarely offered publicly, so you will need to gather a group from your organisation. Leading SAFe is the most practical alternative if you cannot, though it covers the framework from a leadership perspective rather than a team member's.

If you are a Product Owner or Product Manager, start with Leading SAFe before taking SAFe POPM. The POPM class does not cover the Lean-Agile Mindset, SAFe Principles, or PI Planning in depth — Leading SAFe fills that gap and you will get significantly more out of POPM for having done it.

SAFe DevOps and Agile Software Engineering are not recommended as individual starting points. Both are best run with a group from the same organisation and are more effective once you have some SAFe context. We cover how we use these courses in the descriptions above.

Which SAFe certification is best for executives?

For executives, the answer is almost always Leading SAFe. It gives leaders the whole-of-framework view they need to sponsor a transformation, without the delivery-level detail of role-specific courses. Where possible, run it as an executive cohort so leaders learn alongside their peers, with the SAFe Executive Workshop as an optional warm-up.

What about Implementing SAFe? Can I start there?

Scaled Agile now lists Leading SAFe and SAFe for Teams as recommended prerequisites for Implementing SAFe. We agree with the Leading SAFe recommendation — in fact, we've always held that view. Regarding SAFe for Teams, we think it is genuinely good preparation for the class, particularly if you plan to use your SPC certification to train others. That said, hands-on SAFe experience is a reasonable substitute. Taking Leading SAFe, or, in fact, almost any SAFe training class, prior to Implementing SAFe is a way to prime the brain for this intense learning experience. Bottom line — we don't recommend Implementing SAFe for beginners to Agile or SAFe.

I already have one (or more) SAFe certifications; what class should I take next?

What sort of consultant would I be if I didn’t answer that one with "it depends!"? ;-) While it is impossible to provide an answer for every possible scenario, there are some patterns that we recommend. Check out our SAFe Certification pathways or download the Pretty Agile SAFe Certification Pathways PDF.

No matter which class you choose to start or continue your SAFe learning journey, I hope you have found this little guide useful. ‘Til next time #StaySAFe.

 

-----
Updates

- First published 31 August 2020
- 1 September 2024 to reflect changes to the Scaled Agile curriculum.  

- 14 June 2026 to reflect changes to the Scaled Agile curriculum.  

Before the class

Do the pre-work

• Agile Basics
• What Is SAFe
• Lean-Agile Mindset
• SAFe Core Values
• SAFe Lean-Agile Principles

Get a good night’s sleep 

During the class

Remove distractions

Move around on breaks

Participate in class activities

After the class

The SAFe Certification Rules

Apply what you have learnt

Study for the exam

Ask yourself - “What would Dean do?”

Take the exam within 10 days

Focus while sitting the certification exam

Some team members tell us that they don’t see the point in doing both events as this is duplication. In some cases, this is due to a lack of understanding about the differences between the events. In other scenarios, the feedback is valid. Let’s unpack this.

Understanding the Iteration Review in SAFe

The Iteration Review in SAFe is inspired by the Sprint Review in Scrum. It is an individual team event held on the last day of the iteration. The scrum team hosts this event, which tends to be 30 to 60 minutes long and is attended by the individual team’s direct stakeholders. 

In the Iteration Review, SAFe Agile teams typically conduct a story-by-story walk-through of the iteration outcomes. The intent is to gather feedback from team stakeholders and provide transparency regarding the work that was and was not completed during the iteration. Ideally, there will also be time to explore some “what if” scenarios ahead of the next iteration.

The agenda is usually something like:

• PI Objectives
• Review Iteration goals
• Demonstration of completed stories and working software
• Stakeholder feedback
• Review of backlog items that were not completed 
• Risks & Issues
• Indicative backlog for the next iteration 

Understanding the System Demo in SAFe

The System Demo, on the other hand, is a whole of ART event that takes place between the last day of this iteration and the first day of the next iteration. While sooner is better, the timing varies depending on the ease with which the ART can build an integrated demo. The System Demo is typically an hour in duration and hosted by either the RTE or Product Management. The attendees are usually the same people who attended PI Planning, i.e. the ART and its stakeholders.

The purpose is to demonstrate the progress of the ART, as a system, towards meeting its PI Objectives. This demo is intended to show the integrated outcomes completed by the teams on the ART during the last iteration. This is usually linked to  PI Objectives and/or Features.  I like to think of this as a highlight reel. In early iterations, teams may not have completed Objectives or Features, in which case they demonstrate progress towards those outcomes, with the expectation that they are presenting both complete and integrated stories.  

The key benefit of a System Demo is how it mitigates risk. By demonstrating progress in an integrated environment that resembles production, the ART can provide proof that the complete system works, as opposed to “it works on my machine”. ;-)

If the ART backlog has features that were derived from epics, we often see the agenda structures by epic, which can provide a more cohesive narrative for the demo.  

What do we do if we can’t provide an integrated System Demo every iteration?

If an integrated demo in every iteration is technically (or practically) challenging, you should consider investing in a System Team. This team’s mission is to help the teams on the ART with integration and build the enablers to make it easier for them to integrate their stories and features in the future. This usually means making improvements to the continuous delivery pipeline with DevOps and CI/CD.

In the interim, how frequently can you integrate? Even once a PI would be valuable while you build the capability to integrate more frequently. 

In some scenarios, the cost of building an integrated staging environment just doesn’t make good economic sense. We recommend validating this assertion using the SAFe DevOps workshop to quantify the opportunity. If the business case still doesn’t stack up, we still think there is value in being able to demonstrate ART-level progress to the ART and ART stakeholders every iteration. We call this event the ART Show (rather than System Demo) so that it is not accidentally perceived as an integrated demo. 

Does there always have to have to be an Iteration Review and a System Demo?

This has to be one of the most frequently asked questions we get from teams on Agile Release Trains.  We see two scenarios in which both an Iteration Review and a System demo may not be needed. 

1. In the scenario above, the ART does not have an integrated staging environment that closely resembles production and, therefore, cannot produce an integrated demo.

2. When the work is demonstrated to the ART stakeholders in the team’s iteration review, it is from an integrated environment that resembles production. 

In both scenarios, the only differences between an Iteration Review and a System Demo would be the level of granularity and the stakeholders. The code base would be identical, either not at all integrated (scenario 1) or completely integrated (scenario). 

Our alternative for these scenarios is a blended approach we call an ART Show.

What is an ART Show?

An ART Show is a combined Iteration Review and System Demo. This is a whole of ART event consisting of back-to-back iteration reviews on the last day of the iteration. Each team is given a twenty-to-thirty-minute window to demo against their PI Objectives. Where multiple teams are working on an Epic, it is common for these teams to provide an overall demo of the epic's progress. 

As is the case with the System Demo, the audience is ART-level stakeholders, the people on the Agile Release Train, and the host is either the RTE or Product Management. Of course, there is an underlying assumption that the Product Owners have been progressively accepting stories throughout the iteration, so the purpose of this demo is to get feedback from the broader stakeholder base.

What are the Pros and Cons of an ART Show?

In our experience, ART shows are popular with Business Owners and stakeholders who are keen to understand the work spanning multiple teams. Also, subject matter experts who are trying to keep up with multiple teams! However, it does have some limitations. 

If the catalyst for your ART Show is the inability to stage an integrated demo from a staging environment that resembles production, then the demos will likely not show integrated outcomes. This could lead to a false sense of progress. However, if the alternative is no ART level demo, then there is a lack of visibility of progress to key stakeholders; hence, we prefer to hold an ART Show. 

The other challenge we have experienced with ART Shows is time. This can become a long event if every team is given 20 to 30 minutes to share. Especially for larger ARTs. This can result in less buy-in from stakeholders. 

One mitigation is to provide a clear timeboxed agenda, so people know roughly when the items they are most interested in will be demoed. Grouping teams working on the same epic or supporting the same stakeholders can also help foster collaboration. 

Where does the PI System Demo fit in?

If you have been paying close attention, you might have noticed there is also a PI System Demo. The PI System Demo is held at the end of the PI as part of the Inspect and Adapt event. I like to think of the PI System Demo as a celebration. Eight, ten to twelve weeks ago, the ART committed to delivering specific PI Objectives, and now let us show you all the awesome stuff we delivered! 

If you have been holding a System Demo every fortnight, the PI System Demo might seem repetitive; however, that is not the intent. Unlike the iteration-based System Demo, the PI System demo covers all Features/PI Objectives delivered across the PI. The PI System Demo should either include time for the Business Owners to provide the Actual Value for each of the PI Objectives or share the outcome if this conversation has already been had between the business owners and the teams. 

We would also expect the PI System Demo to attract a larger audience. For larger organisations, this might be the one demo your CXOs attend every PI. I have also worked with organisations that will hold this demo in an open area like a building atrium so anyone can learn about what the ART has delivered.

Balance the Benefits

Every SAFe event exists for a reason. Changing or eliminating SAFe events to suit a specific context is absolutely ok. However, before you start making changes, it is important to be clear about the purpose of each event and the value it provides. 

The Iteration Review is your team's opportunity to showcase their work at a detailed level, gather valuable feedback, and ensure alignment with their direct stakeholders. On the other hand, the System Demo provides a broader perspective, offering a platform to demonstrate the integrated progress of the entire ART and engage with a wider audience. When the situation calls for it, the ART Show can be a practical alternative, blending the best of both worlds. 

So, the next time you find yourself questioning the necessity of iteration reviews AND the System Demo, remember: It's not about duplication; it's about creating the right opportunities for feedback from stakeholders and alignment at the team and ART level. After all, success in SAFe is not just about doing things right—it's about doing the right things at the right time with the right people.

Kanban in SAFe Scrum Teams

Kanban and SAFe Cadences

Agile Team Roles and Responsibilities  in Kanban and SAFe

Why do SAFe Agile Teams Choose Kanban?

Operational Activities

Business and Infrastructure Functions

A Significant Portion of Backlog is Unpredictable

Can SAFe Agile Teams Move From Scrum to Kanban?

PI Planning for Kanban Teams

Can Kanban Teams Work in SAFe?

The Design Thinking article, with its double diamonds, represents familiar territory from a design process perspective but doesn’t talk about where UX designers fit in the dual operating system. The Lean UX article goes a step further and talks about both designers and agile teams, but it is still not clear how they should organise to deliver value.

SAFe also has a related community contribution: Lean UX and the SAFe Planning Increment Life Cycle by Natalie Warner. This article proposes a Lean UX Centre of Excellence (LUXCE) as an organisational construct for the application of Lean UX in SAFe. The underpinning premise is that most organisations don’t have enough UX designers to have one in every team. This certainly mirrors my experience. That said, the LUXCE approach didn’t feel like the right answer, perhaps because it looked a lot like a single-function team. 

Those who know me won't be at all surprised to learn that my next step was to revisit my copy of Lean UX (1st edition) by Jeff Gothelf and Josh Seiden. There is a whole chapter dedicated to Integrating Lean UX and Agile. While there is plenty of solid advice in there, that is well worth a read. I took one very simple message away: “For Lean UX to work in Agile, the entire team must participate in all activities…” ipso facto designers have to be part of the agile team. At this point, I am sold. If the solution being delivered by your Agile Release Train (ART) has a heavy user interaction component, you are probably going to need a UX designer person on every team. 

If that feels not quite right, you’re not alone: I had the same sense - not every team needs UX design. We also need to consider Team Topologies; after all, this is a conversation about team design! UX is one of the capabilities one would expect to find in every steam-aligned team.  In practice, I encountered three challenges when recommending this approach:

• “If the designers are split across the teams, how will we stay in alignment?” 
• “We don’t have enough designers.”
• “The agile team doesn’t have time to participate in design activities.”

To address the issue of alignment, I have three approaches in my toolkit that I apply in different contexts. 

• The first and most commonly used approach is to form a UX design chapter (or CoP) that meets a couple of times each iteration to share their work and explore challenges. 
• Forming a chapter usually involves identifying a chapter lead. In some cases, that chapter lead will join the ART leadership team (i.e., RTE, Product Management, and System Architect). This is the second approach and can be applied without forming a chapter if you prefer. 
• The third approach is to leverage the LUXCE concept and form an enabling team to support the designers (and the chapter) with standards and UX runway, similar to how SAFe Architects support Agile Teams. This is mainly applicable to large organisations with a significant design function. 

While this addressed part of the problem, the challenge of the limited number of UX designers continued to occupy my mind.

Last year, James McEvoy presented a session at the SAFe Summit Nashville: A Miracle Occurs - How We Found Design in SAFe. I was particularly interested in hearing from James, who leads a design function in an organisation using SAFe, so I turned up and sat in the front row! 

During the session, James shared that he, too, had found that many companies do not have enough designers to support all their agile teams. However, he went on to point out, with reference to Marty Cagan’s book Inspired: How to Create Tech Products Customers Love, that leading design companies do not have this problem! Leading design companies have an approximate ratio of one designer to every ten developers, and if you have this ratio, you would have enough designers to support the development teams. 

Inspired by James, I dug out my copy of Inspired (1st Edition) and reread the chapter on design. The way Marty Cagan explains the involvement of the designer underscores my belief that UX design belongs in the agile team. He says, “The interaction designer needs to be on hand and deeply involved all the way through the project, from the beginning to launch. Hundreds of detailed questions will come up during development and test—having an interaction designer there to make the right decisions immediately is critical;” Now that is a strong argument for including UX design in agile teams! If you don’t have enough UX designers, you need to solve that problem!

That leaves “the agile team doesn’t have time to participate in design activities”. While this may be true, do they have the time not to be involved when the alternative is a handoff? I decided to have a look at the third edition of Lean UX, released in 2021, to see if the thinking had evolved. I found that Gothelf and Sieden had doubled down, listing three structural elements that are critical to succeeding with agile and Lean UX:

• “A dedicated designer on every team.”
• “Design and discovery work is a first-class citizen of the backlog.”
• “Cross-functional participation in learning activities.”

I think this speaks for itself. This is consistent with our belief that for agile teams to be effective, they must have all the skills necessary to deliver on their mission, and they should collaborate as a team to understand the work and deliver a quality product. Remember—agile is a team sport!

So, where do UX Designers belong in SAFe? If you are serious about design and serious about agility, there will be UX designs in your stream-aligned teams. If you have the scale to warrant it, a LUXCE or enabling team could be added to support the designers with standards and UX runway. Not a particularly complex answer, however, one that is supported by texts that underpin SAFe.

Identifying the Need for Shared Services on an ART

One way to identify the Shared Services needs for an ART is to ask the Agile Teams what skills they need access to (that they don’t have) to be able to take a feature from idea to hypothesis evaluated. We like to include questions about external dependencies and subject matter experts in our feature definition workshops (also known as Feature Disco) that occur prior to PI Planning to help inform what capabilities should be considered for inclusion in Shared Services. 

Given the intent of having an ART is to accelerate value delivery, it is worth pressure testing both the ART's level of dependency on these skills and the availability of the people who provide them.  In our view, where there is significant demand for a specific skill, you should attempt to get someone with that skill set dedicated to the ART. 

We consider the level of demand to be significant when the ART indicates it is likely to use more than 60% of an individual’s time. If you get pushback on dedicating someone to the ART as they will be less than 100% utilised by the ART, have the person bring their other work with them onto the ART. In addition to removing a handoff for the ART, you will likely get better visibility of the overall demand for that speciality. For an example of how one customer found this approach “immensely valuable”, check out the PCCW Global case study.

Of course, it is likely there will be people or teams that meet the definition of Shared Services, but they are only needed by the ART on an ad-hoc basis. To distinguish this group from Shared Services, we call them External Services as they are external to the ART. 

Forming a Shared Services Team within an ART

If an ART has a quorum of dedicated Shared Services people, we have them form an agile team on the ART. (Similar guidance was added to SAFe as part of the 6.0 update). In practice, we have Shared Services teams on most of our ARTs. The intent is to ensure every person on the ART belongs to a team; after all, it is no fun and rather lonely being on an island.  

Ideally, this team has a Scrum Master; this is sometimes a team member or something the ART coordinator takes on. (Note: ART coordinator is not a formal SAFe role but one we frequently see included in ARTs.) 

___________________________________________________________________________

What is an ART Coordinator?

Program Managers who lead large programs are often supported by Program Coordinators. While an RTE is not a Program Manager, the breadth of the role is likely equivalent, so it is often a good choice to have an ART Coordinator to provide some logistical support to prevent the RTE, Product Manager and System Architect from drowning. 

__________________________________________________________________________

Participation of Shared Services & External Services in PI Planning

Practically, the Shared Services team is a team on the ART and an active participant in ART and Team events. When it comes to  PI Planning, Shared Services is unlikely to have its own backlog of features or a Product Owner. Instead, their work is identified as the agile teams' breakdown their features.  The team should use the ART Backlog priority order as informed by WSJF and the other agile teams on the ART will accept the dependency stories. They will still need to build a plan, write PI Objectives, and participate in the confidence vote. 

During PI Planning, the Agile Teams should include the relevant Shared Services folk in their feature decomposition discussions. If there is likely to be a lot of demand for people with a specific specialisation, it can be helpful to create a timetable to ensure all the teams get access to the specialist they are reliant on. Ideally, these specialists will have also been made aware of the feature, and they helped the team prior to PI Planning to get the feature the Definition of Ready (see feature disco) so they can jump in and help rather than slow the teams down with context-related questions.

External Services will also need to attend PI Planning and plot their dependencies on their own swim lane on the ART Planning Board. However, they will execute and deliver outside the ART. 

Integrating Shared Services and External Services During PI Execution

During PI execution, the Shared Services team members tend to attend specific agile team daily syncs rather than a Shared Services team sync. Some will also attend ART Sync. They also participate in team Iteration Reviews and support the System Demo (and/or ART Show). This pattern can also be true for some External Services depending on their way of working. It is not uncommon for External Services to act more like a supplier if they are not currently using SAFe or Agile. 

We see the use of Shared Services and External Services as enablers for ART flow. By identifying the necessary specialist skills and ensuring their availability, ART's can significantly reduce external dependencies and enhance their efficiency. Forming a dedicated Shared Services team within the ART fosters collaboration and ensures that all members are fully integrated into the process. Acknowledging External Services as teams or people with less day-to-day involvement in the ART results in fewer expectation mismatches

Why Would I Want a Product Advisory Group For My ART?

Enterprise Executives Who Want to be SAFe Business Owners

Key Product Management Stakeholders Without a Formal SAFe Role

Epic Owners Who Are Not Business Owners or Product Managers

Managers Who Are Responsible For the Technical Health of the Systems on the ART

What Does Product Advisory Do?

Contribute to Feature Definition Workshops

Prioritise the ART Backlog (aka feature WSJF)

Engage in PI Planning

• Context Briefings - Some Product Advisors provide briefings to the ART with respect to the customer segments or business units they represent. Where a Product Advisor is also an Epic or Feature Owner they may also provide the context briefing for these items at PI Planning. 
• Team Breakouts - If a Product Advisor “owns” a feature or has been identified as a stakeholder for a given feature during feature definition, the Agile Teams on the ART will likely want this Product Advisor to participate as a content authority or subject matter expert during the team breakouts. 
• Draft Plan Review - As ART stakeholders, we expect Product Advisors to be present for the Draft Plan Review, listen intently and ask questions where the messaging from the teams is unclear. (The same logic applies to Final Plan Review).
• Management Review & Problem Solving -  While this is traditionally the domain of the Business Owners, Product Management, System Architects and Release Train Engineers - if you have a Product Advisory group, you have them for a reason. In most cases, Product Advisory will attend this evening session and will be well placed to help the group resolve some of the challenges raised by the ART.
• Planning Adjustments - We like the leaders who made decisions and took actions in the Management Review & Problem Solving session to own those outcomes and communicate them to the ART.  Product Advisors can fall into this category, in which case we would expect them to be present and participate as needed.
• Business Value Rating of PI Objectives -  This is usually the domain of the Business Owners and frankly it goes much better when you have a smaller group of people trying to agree on the Business Value of PI Objectives. We usually let the Business Owners decide if they need the Product Advisors to join these sessions as a sounding board. In most cases, they don’t.
• ROAMing ART Risks - As with the Management Review & Problem Solving session, it is likely that Product Advisors will be able to assist with owning, mitigating or resolving risks. 
• Accepting the Plan - Most ARTs leave this to the Business Owners, but we have seen Business Owners invite the Product Advisors to participate in accepting the plan, often by asking for a “fist of five”.
• PI Planning Retrospective - Everyone who attends PI Planning should provide feedback on the event. The Product Advisory group is no exception.

Provide Feedback at the System Demo Every Iteration

Actively Participate in Inspect and Adapt

How Do Product Advisors Work with Product Managers

When is a Product Advisory Group Applicable

The Evolution of the Release Train Engineer Role

Where do Release Train Engineers come from?

Why would anyone want an Agile Release Tram?

How Small is Too Small for SAFe?

Use Case 1 – We don’t have five Agile teams

Use Case 2 – I have been burnt before, so I want to start small

Use Case 3 – We don’t have enough people for an ART right now, but we plan to grow

Use Case 4 – Some of our value streams have less than five teams

Use Case 5 – We have a couple of teams left that aren’t on the ART(s)

If I have an Agile Release Tram, am I still doing SAFe?

For more Agile Release Tram stories, check out my lightning talk from the SAFe Summit Berlin 2024.

Why do Agile Teams need a coach?

Why do Agile Teams need a facilitator?

What results should I expect to see from an effective Scrum Master?

Discipline 

The right process mattered. Disciplined planning procedures mattered. Without them, we would have never been successful.

–Jocko Willink and Leif Babin, Extreme Ownership

Team Flow

Team Flow describes a state in which Agile teams deliver a continuous flow of value to the customer.

– Scaled Agile Framework

Predictability

If you ask top executives what they would most like to see out of the software development process, many will answer “predictability.”

–Dean Leffingwell

Built-in Quality

Inspection does not improve the quality nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.

—W. Edwards Deming

Transparency 

Over our years of researching and working together, we’ve learned something about clarity that has changed everything from the way we talk to each other to the way we negotiate with external partners. It’s simple but transformative: Clear is kind. Unclear is unkind.

–Brené Brown

Real Teams

 ..we want real teams, not just groups of people who happen to work together.

–Em Campbell-Pretty

Understanding of how and why Agile works

We are uncovering better ways of developing software by doing it and helping others do it.

–The Agile Manifesto

Product Ownership

There is nothing so useless as doing efficiently that which should not be done at all.

– Peter Drucker

Can the Scrum Master also be the Product Owner?

Can a SAFe Scrum Master work across two teams?

So, do I have to have a full-time Scrum Master?

If being prepared for PI planning is required for a successful planning event so what do you do instead? 

What is Discovery? 

When do we do Discovery? 

How do we do Discovery?

1. Bring together the Agile Team (who has pulled the Feature for discovery), Product Management, System Architect and Subject Matter Experts (if required) for a conversation -- ideally around a whiteboard or similar online collaboration tool.
2. Ask “What do we know about the problem we’re trying to solve?” Product Management & System Architect(s) explain the feature & the business problem it aims to solve
3. The team asks clarifying questions & whiteboards the updated solution whiteboard drawing. Be sure to clarify and capture feature boundaries. 
4. Ask “What do we not know and need to know?” Take actions to resolve any outstanding big questions/concerns/architectural guidance
5. Estimate the work in story points 
6. Complete the Feature definition template together

The Provider

Is the provider a Scaled Agile Partner?

What is a Platinum SPCT Partner?

This is a partner that has a SAFe Practice Consultant Trainer (SPCT) on their team. According to Scaled Agile Inc. the SPCT certification is the most advanced certification you can achieve with SAFe. Partners with SPCTs will have the Scaled Agile Partner Platinum SPCT badge. While this is not a guarantee of quality it can be an indicator. If the instructor is an SPCT they should have a reasonable depth of experience with SAFe. 

 

“As is the case with any certification, you should carefully evaluate SAFe instructors and consultants, and make sure that they have demonstrated experience that is relevant to the role you are asking them to take on. Do not rely on certifications alone as a measure of the skills of a consultant or prospective employee. A notable exception to this is the SAFe Practice Consultant Trainer (SPCT) certification, which does require demonstrated experience with agile, software development or product management, training and consulting. If you’re hiring someone who has [an] SPCT certification, you can be confident that they do have experience in these areas, as well as experience with SAFe implementation at multiple organizations. However, SPCTs are in short supply. As of February 2020, there are fewer than 100 people worldwide holding this certification.”

- Gartner, “A Technical Professional’s Guide to Successful Adoption of the Scaled Agile Framework (SAFe),” Kevin Matheny, Bill Holz, 13 April 2020

How long has the partner been a partner?

How many classes has the provider run?

Is this provider charging a fair market price?

• How many instructors does the class have?
• Is the provider licensing the courseware and providing the exam for the course?
• Do they provide printed workbooks in addition to digital workbooks? 
• Do they work full time and spend their weekends training for “pocket money”?
• Are they collecting the appropriate taxes for the region that they are operating in?

How many instructors does the class have?

Are all classes guaranteed to run? 

The Instructor

Is the name of the instructor for the class listed on the providers website?

Does the instructor have any practical experience with SAFe?

• Attend an Implementing SAFe class.
• Pass an online multiple choice exam.
• Watch the online enablement videos for the specific course you want to teach and pass the online class exam.

How long has the instructor been a SAFe Practice Consultant?

Where is the instructor located?

Who are your friends, colleagues and LinkedIn connections recommending?

Chat

Video Conferencing

• Have your participants download and install the Zoom client. While Zoom is accessible through a web browser we have found the client to be more stable

• We have had some students not be able to enter  into a breakout room.  When we have experienced this issue we have asked the participant to run all the updates for their device and restart. This usually solves the problem. It doesn’t suggest we they try another device and this has worked every time,

• At first we thought participants could not move freely between breakout rooms, which really sucked for the PI Planning simulation in Leading SAFe. We tried a couple of hacks - having people come back to the main room so they could be moved to another room and people using Slack to communicate across rooms and/or request moves. This was ok-ish. As it turns out there is a much smarter option - make everyone a co-host and they can move themselves between breakout rooms  just like in the physical world! Just make sure to disable the record function if you don't want to empower all your new co-hosts to record the call!

Collaboration Tools

Facilitation

Working Agreements

• Video on
• Close all apps expect Slack, Zoom and Kahoot
• Close all browser tabs expect for Mural
• Use ELMO cards  (Enough! Let’s Move On)
• Ask questions - either in the call or in the #questions Slack channel
• If you have an off topic question add it to #parkinglot Slack channel
• Have fun
• Make connections
• Vegas Rules - What happens in the class, stays in class.

Participant Technology Set-up

Timing

“Thank you both so much. This was a fantastic learning experience. I could not believe how fast the time went by. Your delivery and preparation was exceptional. Having a break every hour made a huge difference.  I cannot understand why more facilitators don't do this!”

Feedback from a participant in Pretty Agile’s Implementing SAFe class of July 2020. 

Materials

What prerequisites apply?

Scaled Agile Inc. (the certifying body for all SAFe certifications) does not require mandatory prerequisites for any of the certified SAFe classes. This means that it is incumbent on the participant to determine if they have the prerequisite skills and knowledge to successfully undertake any given course and the subsequent certification exam. 

In the case of the SAFe Scrum Master, it is recommended that participants are familiar with Agile. Even if you are not familiar with Agile, when you register for a SAFe Scrum Master class, your training provider should provide you access to SAFe Studio, where you can access a series of introductory videos on Agile and SAFe.

How does the course content differ?

When should you take these classes?

When we launch ARTs, new Scrum Masters often have a steep learning curve, taking both the SAFe Scrum Master and the SAFe for Teams classes over a matter of weeks. Bringing them back together in a classroom environment about a year later allows them to take some time out to reflect on their journey and identify opportunities for growth. I find this class re-energises the Scrum Master and RTE team, which has the added bonus of re-injecting energy into the whole Agile Release Train. Running this training during the Innovation and Planning iteration is often a good choice. 

The SAFe Advanced Scrum Master class is also taken by Scrum Masters who are working with SAFe and looking to improve their personal mastery of the Scrum Master role in SAFe.

I hope this little guide helps you decide which class is right for your context. 

Why does physical distancing impact the delivery of in person SAFe Training?

Won't I be disadvantaged if I have to attend a virtual/remote class?

What about the social/networking aspect of in person training? Won’t I miss out on that?

So is the future of SAFe training online?

So how does SAFe training online work at Pretty Agile?

Do I still get a the course workbook and Pretty Agile swag?

What about "Zoom Exhaustion"?

What are people saying about Pretty Agile's SAFe training online?

"Highly recommended!!! Nothing like Em and Adrienne's experience and knowledge! Thanks for a great week!"

- Feedback from Online Implementing SAFe Participant

"I attended their first ever fully online SPC training online using Zoom for the main video conferencing, Slack for a backup text chat, channels and link sharing, and Mural for online work spaces for the practicals and I can't recommend their training and the methods highly enough. A few initial teething problems with the technology but amazing work to put it together and prepare in this new way of working. I call that a significant win."

- Feedback from Online Implementing SAFe Participant

 

"As one of the participants on the SPC training, I highly recommend Em and Adrienne  as excellent facilitators... 3 days of video conferencing so far, and it has been fully engaging. Excellent use of a range of technologies, especially for a first time online for such a hands on subject."

- Feedback from Online Implementing SAFe Participant

How efficiently and effectively the course was run in a new format (zoom, slack, mural) was testament to how well the Pretty Agile staff know the material and the SAFe framework.

- Feedback from Online Leading SAFe Participant

Thanks Pretty Agile. Great facilitation Melissa Hay & Claire Sanders. Highly recommend to any aspiring/transitioning PO/PMs or driving Agile transformation to understand how to optimise Product Management function.

- Feedback from Online SAFe Product Owner/Product Manager Participant

"I think both Adrienne and Em did a great job holding the attention of course participants in an online format - kudos to both of them! 

I appreciate that in an online environment there is more focus on the teacher and all participants rely more on the presenter, whereas in a classroom setting there may be more interaction amongst participants. So there was a lot more focus and pressure on both Adrienne and Em and I think they managed it fantastically. 

Em did a great job holding the focus of participants and engaging everyone, encouraging people to dig deeper into the material. I picked up lots of good skills by seeing her in action facilitating. 

Em and Adrienne are a great team, and I enjoyed having 2 trainers on the session."

- Feedback from Online Implementing SAFe Participant

Excellent real world examples help digest the course material and added context. Melissa and Claire were both really knowledgeable and did a great job at instructing this course in a format that was not the norm (but could be the new norm).

- Feedback from Online Leading SAFe Participant

Thank you to Em Campbell-Pretty, Adrienne Wilson and everyone else attended Pretty Agile's first online SPC training course. I cannot recommend Pretty Agile highly enough as a training provider for SAFe. Both instructors went above and beyond to ensure we had the best opportunities for learning.

- Feedback from Online Implementing SAFe Participant

Employee Net Promoter Score (eNPS)

Stakeholder Net Promoter Score (NPS) 

Cycle Time 

Frequency of Release 

Escaped Defects

Test Automation

Ratio of “Doers” vs “Non-Doers”

Market Performance

Cost per Story Point

ART Predictability Measure

Agility (or Agile Maturity)

Of course, this approach does not take into account that a team's capacity is not equal from iteration to iteration, as it is affected by both planned and unplanned leave.  I have observed that ARTs tend to solve for this by re-setting their capacity every iteration or PI using SAFe’s starting capacity for new teams - which drives me batty!

Frustrated by the misuse of SAFe’s starting capacity for new teams, I started to play with the concept of weighting velocity to improve the accuracy (not precision) of team and train planning and forecasting.  I have come to call my approach weighted velocity. It is a way of adjusting velocity information so that it more accurately reflects capacity. This entails collecting the attendance of data for a team or ART and expressing it as a percentage of the team's normal capacity.

For example, if a team usually has 8 full-time teams members and one was on leave for 5 days of the 10 day iteration then the team percentage attendance would be 93.75%, e.g. 75 days/80 days = 93.75%.  I then take the velocity for the same team (or ART) for the same period and divide it by the % attendance. For example, if the velocity for the given sprint was 45 points and the percentage attendance was 93.75% then the weighted velocity would be 48.

This approach can also be used to address the impact of working overtime on velocity as well. (Before all you agilists out there go on the attack, we all know there should not be overtime on an agile team!! and I tell my clients this all the time, but sometimes these things still happen…)  For example, the team has 8 full-time team members, and they all came in for a half day on a Saturday. The team would have attended 84 of 80 days, making their % attendance 105%. If the velocity for this sprint was 50 points.  The weighted velocity would be 48 (i.e. 50/105%).

By always weighting the team or ART's velocity, we remove the variation caused by planned and unplanned leave, providing a more realistic view of yesterday’s weather for planning and forecasting.  Perhaps more simply, we are reverse engineering what the velocity would have been if the team had been at full capacity (100%) for the iteration. Of course, when using weighted velocity as yesterday’s weather for planning purposes, I suggested taking an average over 4 or 5 sprints, then adjusting the number down for any planned leave using the same percentage of attendance approach used above.

I have also found weighted velocity to be exceedingly useful when building cost per story point models, but that is a topic for another blog!

The themes of the Agile Alliance's Agile2017 conference earlier this month can be summarized as gender, diversity, and the impact of cognitive biases and how to overcome them.

The week kicked off on Sunday, August 6, with a Women in Agile workshop hosted by Natalie Warnert, and diversity was an important topic throughout the week. Of course, there was also a lot of agile discussed at Agile2017, from the so-called Spotify model to the "no estimates" approach.

Astronaut Abby sets the tone

The workshop was keynoted by Astronaut Abby. Now, I had no idea who Astronaut Abby was, but all the pre-conference buzz led me to believe she was someone very special. I don't know exactly what I was expecting, but I was expecting an astronaut. You can imagine my disappointment when a college-aged woman was introduced. I felt robbed—she wasn't a real astronaut; she was a twenty-something dressed in a flight suit, someone who merely aspires to be an astronaut—specifically, the first astronaut to walk on Mars. Foolishly, I had sat in the front row—there was no escaping now.

Then Abby—Abigail Harrison—started to tell her story, and I went from disappointment to a state of awe. In 2015, at only 18 years of age, Abby founded the Mars Generation, a nonprofit with the mission of "making STEM cool again." In the last two years, the Mars Generation has helped 25 million people and provided 20 full scholarships to space camp. (This got me thinking that I may have seriously underachieved in my early 20s.)

The underlying message, though, concerned the support Abby has received in progressing her dream to become an astronaut from the women and men from previous generations of the NASA space program. That should serve as a reminder that we all can have a positive impact on girls and young women in underrepresented fields such as STEM. We just need to act.

The highlight of the open space that followed was a session led by Declan Whelan: "How to help men become better allies." I think asking the question is a great first step, and the advice from the women in the room was loud and clear: Acknowledge there is a problem, leave space for women to participate in discussions, and acknowledge and repeat contributions from women.

The workshop closed with three seven-minute keynotes from voices that had never had the opportunity to present on a national stage before. The perfect bookend to Abby's opening challenge to us all to "dream big, act big, and in doing so inspire others to act."

Weighing in on the "manifestbro"

On Wednesday morning, Jez Humble shone a spotlight on the issue of women in technology with a 20-minute takedown of James Damore's "manifestbro," a.k.a. the Google memo. Humble focused on Damore's core argument that differences in biology between men and women explain the underrepresentation of women in technology, noting that this is the same sort of logic that was used to justify colonialism and slavery.

Quite simply, he said, biology does not explain the underrepresentation of women in technology. The differences between the abilities of men and women when it comes to math are negligible, he noted. Underrepresentation is a product of the perception that women are less capable and the belief that innate talent is the main requirement for success. The problem, said Humble, is compounded when people believe the sorts of things put forward in Damore's memo.

Women have not always been a minority in technology, he noted. The first computer programmers were women. It was only in the mid-'80s that the number of women majoring in computer science started to decline. What changed was not biology but rather the perception of the work. Computer programming was no longer seen as clerical work, but as something difficult to master and therefore a stereotypical male activity.

One startling fact provided by Humble: When women move into a field, salaries go down, and when they move out of a field, salaries go up. Thank you, Jez, for acknowledging there is a problem/opportunity.

Lessons from the agilists

On Tuesday morning, Spotify agile coach Joakim Sundén and Spotify newbie Catherine Peck-Phillip presented "You can do better than the Spotify model." Sundén started by explaining that there is no Spotify model, a message that seasoned agilists may have heard from him and his colleagues before. However, he acknowledged that there is an industry perception that a Spotify model exists, a perception that most likely stems from Henrik Kniberg and Andres Ivarsson's 2012 paper on "Scaling Agile @ Spotify," Kniberg's awesome videos on Spotify's engineering culture, and numerous conference talks given by Sundén and others over the years.

Peck-Phillip shared her experience of joining the agile unicorn that is Spotify. To her surprise, agile at Spotify is not perfect and not everyone uses the Spotify model.

One of the most fascinating insights Sundén and Peck-Phillip provided was that the autonomy that is widely understood to be at the heart of Spotify's approach to agile is also the most frustrating aspect of life at Spotify. Perfect or not, there is no denying that Spotify is an extremely successful company. So what is its secret? According to Sundén and Peck-Phillip, it is never giving up on getting better. That is the real Spotify model.

Sundén's and Peck-Phillip's transparency in sharing the realities of agile at Spotify was appreciated by the audience. It is not often that a company shows its soft underbelly in a public arena, let alone a company as idolized in agile circles as Spotify is.

Turning up the good

Woody Zuill, who is perhaps best known for #NoEstimates and mob programming, presented "How to go from zero to sixty in 19 years: Accelerated learning on the path to agile." Referencing Leonard Mlodinow's book The Drunkard's Walk, Zuill noted that humans are wired to see patterns in random information.

This is driven by our need to feel in control and reinforced by a tendency to value information that validates our beliefs. Zuill asked, "What if we could increase the possibility of serendipity?" We could "turn up" what is already good, he said, by stumbling purposefully, taking small steps, and learning to see the good rather than fixating on the broken.

The learning hour

On Wednesday morning, Llewellyn Falco explained his latest experiment: the learning hour. This year, Falco, an agile technical coach for mob programming, added a learning hour to his standard coaching day. It's at 11 am every day and is open to everyone—one hour every day when people are not working but learning. The payoff, he said, is compound interest for productivity.

If each learning hour provides a 1% improvement in productivity, the result would mean a 5-minute improvement each day. After 6 months, productivity will have doubled. And most likely your competitors are investing nothing.

Check your head

The closing keynote, "Banishing your inner critic," by Denise Jacobs, was the perfect ending to the week. Her message was simple: Our inner critic is holding us back. That critical voice inside our heads is fueled by the fears we have about ourselves and triggered by the negative things people say about us. However, we have mental "power tools" that can help fight this: attention and focus, mindfulness, self-compassion, and neuroplasticity.

Jacobs went on to share examples of how to access and use these power tools, such as:

• Think like a scientist and question your inner critic.
• When your mind won't stop ruminating, squeeze a stress ball in your nondominant hand.
• When your creative flow is blocked, work with your hands for 15 to 30 minutes.
• Know your unique advantage.
• Be your own coach of awesomeness.
• And if you want to be rid of a negative thought, swipe left. Our brains are conditioned to associate this action with delete.

With memories of Jacobs' session fresh in mind, I'm off to curl up on the couch with a copy of her new book, Banish Your Inner Critic: Silence the Voice of Self-Doubt to Unleash Your Creativity and Do Your Best Work.

I hope you found this small taste of a week at the world's largest agile conference useful. With attendance for the Women in Agile workshop up about 25% from 2016, it shows there's a clear need for this sort of event. Join me in San Diego in 2018.

1. Chapter Leads would brief their teams prior to the event and provide guidance on the competency mix expected.
2. SMs & POs should not use the features that they want to work on as a way of encouraging people to join their squad. (Feature decisions should be made by the whole squad once it is formed).
3. There should be a tie-breaker process if a stalemate occurs. The suggestion being that chapter leads for the unbalanced competencies would provide some real-time coaching in the event of a stalemate.

Hi Em

 

Thought you would be interested in hearing about how self-selection went yesterday.

 

Pre event:

• I shared a pack the day prior to S-S that included your suggested things that team members should consider when selecting squads. This pack also included a details of the squad construct we were looking for. 
• Chapter leads also spoke to their respective teams prior to S-S.
• The approach I took with my chapter was to encourage them to have a plan A and a Plan B as well as keeping an open mind on all options – “whichever squad you land in, you will be working with great people and will have learning opportunities”
• I briefed POs and SMs to be very clear that they should talk about themselves, their style/approach and generally how they go about it. I also gave very clear steer not to talk about features.

At the event

• [The Head of] did an intro – very authentic, expressed a view that he felt anxious about how it might go and acknowledged that this would be the sentiment of many. He also reinforced that it was the train that voted to do the self-selection again (which is a good thing)
• I shared overview of process – I highlighted that the retro we did following the last S-S had defined a “tie-breaker” process if we reach a stalemate on balancing the train, but also highlighted that we really wanted to only use this as a last resort and expressed my confidence that the Train should be able to solve it.
• POs&SMs did a great job of making their “pitches”
• Started with a 15 minute round – after that round we had some “unders” and “overs” – I summarised the challenge that the train needed to overcome to balance the train
• Second round was 10 minutes – Got closer, with the outcome being to only require one final move – as I was playing this back a team member volunteered to move (under no duress)
• Congratulations to team on balancing the train for PI5 and beyond

 We will pull together the retro feedback, but a couple of themes that I observed that I think really helped.

• Having a target construct really helped – in the past we have said “a minimum of x  of one skill and y of another” – this time we were definite in construct we were aiming for
• Room set up – this was more by luck rather than by design. We had a relatively small room, so I facilitated “in the round” – there were no tables or chairs, just flipcharts dotted around the outside of the room. I think this really helped with the energy and dynamic in the room and forced people to stand by the squad that they had chosen in each round. This really made facilitation relatively easy.
• The only negative was that we overlooked bringing our partners into the process – whilst they could not really select to a squad (that has been pre-determined), they could have participated in the social contract drafting etc as well as going on the journey with us

 Thanks a lot for your guidance – I think that whilst we have probably invested significantly more time up-front in planning the event this time around, we have landed in a better spot.

Team Day Afternoon

We used the afternoon for some team kick-off activities. The new teams were given an hour to come up with team names and build a Team Product Box. Over the prior few weeks, the department had nominated a theme for the train and then voted to decide between them. After a very close battle between Game of Thrones and trains, the train theme won out. Strangely, of all the trains I have been involved with, this is only the second time a train has chosen a train theme for team names. (In this instance, this choice has ended up creating some confusion as newcomers have understood each team to be its own Agile Release Train!)

Lessons Learned

Don't assume everyone knows everyone

Be crystal clear on your expectations

When using self-selection for a feature team ART perhaps don't seed the teams with missions

Communicate earlier

• In the weeks prior to the Quick-Start:
  • the ART backlog is refined and prioritised (using WSJF), and;
  • the people who will be doing the work are grouped in teams of 7+/- 2 with a Scrum Master and a Product Owner
• Day 1 and 2 of the Quick-Start all the teams attend the 2-day SAFe for Teams training, sitting at team tables with their product owners. During the training they work with real features from the program backlog.
• Day 3 and 4 the train holds its first PI Planning event.
• Day 5 the Scrum Master and Product Owners attend role specific orientation training
• And then you start sprinting!

The very next week fate intervened and the entire ART launch plan was rendered null and void by the announcement of an impending organisational change. We couldn't form teams and launch the ART if we didn't know who would be in the department in eight weeks time! So we rescheduled the Quick-Start. Never one to be discouraged, I again put forward the idea of using self-selection to form teams. This time my approach was to suggest self-selection as a way to boost morale given the changing organisational landscape. I am fairly sure the department head thought I was completely delusional when I was adamant that we could trust people to make the right choices, but in the end he agreed. There was just one catch, based on my existing commitments we would need to hold the self selection event the day before the Quick-Start. And yep, you guessed it, at that moment the six-day QuickStart was born!

 

Our plan was as follows:

• Day 1 - Self-Selection & Team Building
• Day 2 & 3 - SAFe for Teams Training
• Day 4 - SAFe Scrum Master and Product Owner Orientations
• Day 5 & 6 - PI Planning

 

The 6-Day SAFe Quick-Start

 

Stay tuned over the next few weeks and I will share with you our journey as we prepared for Squadification, facilitated the Self-Selection event and delivered just in in time training, before rolling immediately into the most amazing first PI Planning event I have been involved with!

 

Check out Part 2 in this blog series Preparing for SAFe Squadification & Structuring the Agile Release Train

Me introducing Tribal Unity to Agile Denver

The Agile Denver Tribe

Me unboxing the very first box of books.

Me making sure that the books aren't printed in white ink!

I got the first signed copy of #tribalunity! Thanks @PrettyAgile !!! pic.twitter.com/OOHCOfGuiU

— lisacrispin (@lisacrispin) October 28, 2016

 

• Movement trumps Sitting: In order to learn the brain needs oxygen. The best way to get oxygen to the brain is to move.
• Talking trumps Listening: The person doing the most talking is doing the most learning.
• Images Trump Words: The more visual the input is the more likely it is to be remembered.
• Writing trumps Reading: The team will remember anything they write longer than anything you write. 
• Shorter trumps Longer: People will generally check out within 20 minutes.
• Different trumps Same: The brain quickly ignores anything that is repetitive, routine or boring. 

 

The first time I came across the Scaling Agile @ Spotify paper was when EDW Release Train Engineer Wayne Palmer decided that the EDW Agile Release Train would benefit from creating a series of “Guilds”. Despite Wayne's enthusiasm, I don’t think he got past telling us his great idea was “Guilds” before the rest of my leadership team laughed him out of the room, having quickly reached the consensus that “Guilds” sounded like something from Lord of the Rings and had no place on our Release Train! I remember Wayne invoking the power of Wikipedia in his eagerness to help us understand his vision. “According to Wikipedia, a Guild is a collection of artisans who are responsible for the practice of their craft, “ he argued. Resulting in only more laughter from the team. Not one to be easily deterred, Wayne took it on the chin and set about convincing me he was onto something...

• share knowledge
• create tools
• create training material and conduct training
• set standards and practices
• review changes in approach or technology
• take an outside-in view of the system

A Chapter “is your small family of people having similar skills and working within the same general competency area, within the same Tribe.”

“A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices.” 
Where a Tribe is “a collection of squads that work in related areas” and a Squad is “similar to a Scrum team”.
Noting that: “Chapters are always local to a Tribe, while a guild usually cuts across the whole organization.”

Bridging the Great Divide Between Business and IT: A Business Perspective

Key Challenges

1. Communication and Trust Issues: Historically, business and IT teams have struggled with effective communication, leading to mutual distrust. This distrust often manifests in a blame culture, where IT is seen more as a necessary expense than a valuable partner in achieving business goals.
2. Physical and Cultural Separation: The physical separation and cultural differences between these teams exacerbate misunderstandings. When business and IT operate in silos, the lack of informal interactions and shared experiences leads to inefficiencies and misaligned priorities.

Bridging the Gap: Solutions and Approaches

1. Adopting Agile Methodologies: Implementing Agile methodologies has been a game-changer. Agile's core principles of transparency, iterative development, and continuous feedback align closely with business needs. This approach encourages frequent communication and fosters a collaborative environment where both teams work towards common objectives.
2. Implementing Agile Release Trains (ARTs) and SAFe: The Scaled Agile Framework (SAFe) and ARTs have proven effective in synchronizing efforts across multiple teams. By fostering a one-team culture, these frameworks ensure that both IT and business objectives are aligned. The regular cadence and synchronization of ARTs facilitate smoother collaboration and improved outcomes.
3. Leadership and Transparency: Leadership plays a pivotal role in bridging the divide. Leaders who demonstrate vulnerability and transparency set a tone of trust and openness. By sharing challenges and working collaboratively on solutions, leaders can foster a culture of mutual respect and joint problem-solving.

Practical Steps for Alignment

1. Co-location: Bringing business and IT teams together physically can significantly enhance communication and collaboration. Even temporary co-location can lead to spontaneous interactions that help build understanding and trust.
2. Joint Problem-Solving: Encouraging joint problem-solving sessions allows both teams to contribute their expertise and perspectives. This collaborative approach ensures that solutions are practical and aligned with business needs, fostering a sense of shared ownership and mutual respect.
3. Clear Objectives and Metrics: Establishing clear, shared objectives and metrics ensures that both teams are working towards the same goals. This alignment helps to reinforce the strategic value of IT and ensures that initiatives are directly tied to business outcomes.

Conclusion

Anyway, back to Scrum and SAFe. Clearly, there are some differences. Scrum is silent on development practices. SAFe advocates Built-in-Quality practices inspired by XP. Scrum doesn't specify longer-term planning to be done on a cadence, although release planning appears to be a commonly accepted practice. However, on the whole, Scrum, as it is outlined in SAFe, seems to be the same Scrum one can learn in a CSM class. Both have a Scrum Master, a Product Owner and a development team. Both have daily scrums, sprint planning, sprint goals, sprint reviews and retrospectives. Note: SAFe replaces the term sprint with iteration in SAFe 4.0 and has used the term Team Sync for daily scrum since SAFe 6.0.

While “Core Scrum”, as articulated in the Scrum Guide, doesn’t talk about scaling, Mike did provide some guidance on how to scale Scrum. This included a scrum of scrums, aligning sprint start and end dates, a shared product backlog, and scaling the product owner to include Product Line Owners and Chief Product Owners. All these concepts are also included in SAFe, albeit in some cases with different names.

Accepting that there are some differences in terminology and that Scrum doesn't have a two-day team of teams planning event, I left Mike's class bewildered at why so many members of the Scrum community are so opposed to SAFe. Perhaps it is the introduction of the Portfolio level? It seems to me that the type of strategic planning enabled by the Portfolio level in SAFe in no way contradicts Scrum. I would simply observe that Scrum is focused on enabling software development teams and does not concern itself with how the organisation aligns its technology investments to business strategies and the consequential allocation of funds. I don't find this to be contradictory; it's just different.

Perhaps my business lens allows me to see things differently than those who grew up in IT. Whatever the reason, having now been through SAFe training with Dean Leffingwell and Scrum training with Mike Cohn, I just can’t see what all the fuss is about. After all, isn’t our highest priority “to satisfy the customer through early and continuous delivery of valuable software”?

• Setting up Successors for Success
• A Compelling Modesty
• Unwavering Resolve...To Do What Must Be Done
• The Window and the Mirror

Good to Great concepts

• The Key to the SAFe: Principles over Practices 
• Creating Agile Tribes: Herding CATs for Fun and Customer Delight with Jean Tabaka

Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___.

Once upon a time...

There was a very long queue at the University's student contact centre with lots of new students (some of whom were frustrated by the queue).

 

Every day...

Data management services received a Sisyphean pile of papers (which were received after much work logging papers + batched + dispatched....) and occasional papers would get lost, or data would be entered incorrectly. Sometimes huge boxes of papers dropped down from Singapore and other far away places.

 

One day...

 

The students rebelled! They demanded access to manage their enrolment online themselves - make this problem go away. We want access to Blackboard immediately, not after a few weeks! They also want credit to appear immediately, and wanted to know their timetable earlier so they could organise their work hours, child care and other parts of their life. ("Study is only part of my life!")

 

Because of that...

The University's numbers dropped, staff were leaving! "Yikes!" said the University! We better listen to the students and fix their problem once and for all.

 

Because of that...

The Academic Registrar and her team developed a roadmap, got funding and IT were engaged. And a spell was cast and made all of the enrolments process invisible - got the info they wanted, never had to go to the University's student contact centre, never heard of the Academic Registrar's team. Enrolment ongoing throughout their life cycle was seamless - they didn't need to be here physically to manage it. No more queues!

 

Until finally...

The only time they went to the University's student contact centre was to engage with them for high value services (and meeting other students who might become their future significant other).

The time I spent leading the EDW team at Telstra has been the most incredible experience of my life. I have worked with some truly extraordinary people who made every day fun (even when it was very challenging!) I will be forever grateful for the opportunity I was given as a business person to lead and grow a struggling delivery team into a world-class Agile Release Train.

As the General Manager responsible for the launch of the EDW Release Train, I was invited to speak at conferences across Australia and the United States. I got to share our story and inspire others to take the next step in their agile journey. During my travels, I met so many of my agile heroes that I felt like I was leading a truly charmed existence. Finding agile and the agile community has changed the course of my career.

So, after almost ten years at Telstra, over three years of Agile and two years of SAFe, I said goodbye to my beloved EDW Release Train. On my last day, my fabulous team blew me away with their heartfelt goodbye. It was Unity Day with a farewell to Em and Wayne twist. Things started in the usual way with “shout outs” and a ridiculous game called Torpedo, the point of which was to “have fun”.

By this time, it was becoming very clear to me that my team was a sadistic bunch. With tears still streaming down my face, my boss of five years, Julian Hebden was invited to take the floor and had his turn at making me cry.

 

 

The morning closed with a goodbye gift, wrapped in an A0 Scaled Agile Framework big picture. A polo shirt with “The Original and The Best EDW Release Train “ printed on the front and everyone’s avatars on the back. Again, I was speechless.

 

During the course of the remainder of the day various members of the team dropped by as I packed up my office.

 

“Thank you for making me agile.”
“Thank you for changing what it is like to work here.”
“Thank you allowing me to be part of the journey.”
“Thank you for the opportunity.”
Thank you for the experience”
“Good Luck, Em.”
“Go and change the world!”

So it was with a very heavy heart that I said goodbye to my amazing team. Their willingness to “drink the Kool-Aid” and come on this wild ride to launch Australia’s first SAFe Agile Release Train is something I will never be able to thank them enough for. It was an absolute pleasure to work with such a dedicated, driven and fun group of people. I can only hope that I am so lucky as to get an opportunity to work with such a great team again one day.

Goodbye card from the EDW Release Train

After two years at the helm,  I leave the EDW Release Train in the very capable hands of my friend and long-term lieutenant Megan Anderson. Thank you, Megan, for supporting me and the team through what has been a very emotional time. Look after my team and keep fighting the good fight.

As for me, it's onwards and upwards. My “Adventures in Scaling Agile” will continue with the launch of Pretty Agile Pty Ltd, a SAFe Consulting and Training Company focused on helping organisations succeed with SAFe and hopefully change a few more lives for the better.

“No, we will not pressure the development team to reduce the estimate. You need to trust the team.  If you do not have enough funding consider de-prioritsing some features.”

“No, the team will not work every weekend between now and Christmas.  We only work at a sustainable pace. If your project is critical let’s collaborate with other stakeholders to have your features prioritised appropriately.”

“No, we will not throw more “resources” at the problem.  Nine women cannot make a baby in one month!”

“No, you cannot “buy” teams. If your Epic is important to the company you will need to have it prioritised accordingly.”

“Yes, the plan has changed. We have learnt more about your needs.”

“Yes, the plan has changed. We have been unable to get time with the business feature owner. If this is important to you, you will make the right people available to support the team.”

In large enterprises where agile is starting out and the people on your first agile release trains are in the minority and traditional mindsets are the norm, splitting the RTE role into two may well be a better place to start for the sanity of the RTE and those who are dependent on him or her. 

As the year came to a close and we started scheduling the Christmas break, my leadership team decided I should run SAFe for Teams (previously known as SAFe Scrum XP) the first two days of the new year. I squirmed. It had been 10 years since I had delivered any formal training. Did I still have what it takes? What if I made a fool of myself? While I was panicking, the team was planning, and the next thing I knew, it was a done deal!

My reluctance, paired with my tendency to procrastinate, created a perfect storm. From the last weeks of December right up until the first day of training I walked a fine line between the last and least responsible moment. The first time I looked at the courseware, it was the last business day of 2013. The next time I thought about it was 31st December, when my subconscious rudely interrupted my Bali holiday by reminding me that I needed to have the courseware printed before the class - which was only 2 business days away!

Returning to Melbourne on January 1st, I spent the first business day of 2014 trying to find an open print shop. All I can say is, “Thank goodness for Officeworks!” The weekend was spent reading the courseware,  preparing my speaking notes and sniffing! No, my lack of preparation had not driven me to tears - I was getting sick. Never one to be deterred by illness, I soldiered on.

Opening the class, I explained that I understood that many of them had been on the train since the beginning, and while they may feel they knew the material, these two days were going to be about creating a level set and ensuring shared context. Then, I asked how many of them had been on Agile Fundamentals training. Less than a third! My heart sank, and the sense of guilt was overwhelming. How had I not known this? Why hadn’t I been more proactive about this training? Of course, with a class of 30 students and a packed two-day agenda, I had to park the guilt and focus on the task at hand. So I did.

The two days flew by, even with my slight cold turning into something a little more debilitating and my voice all but disappearing. The energy and enthusiasm of the group was inspiring. They questioned the material, debated its application and agreed on a multitude of standards that they wanted to apply to themselves and EDW delivery going forward. I could not have been prouder.

In my life as a business sponsor of software development programs, I spent innumerable hours in program meetings - project status meetings, RAID meetings, Steering Committees, Governance meetings, “Come to Jesus meetings”, you name it. When I was appointed to my first role on the delivery side of the fence, I thought running these meetings was essential. After all, every IT general manager I have ever worked with has followed this practice.

Everybody hated these meetings, particularly the three-hour Monday morning Program Review. Twenty-five people and a 100-page status report made for a long start to the week. The morning’s discussion would revolve around the true status of the Watermelon Projects (green on the outside and red on the inside) and the lack of action taken from one week to the next on the seemingly endless list of actions. From the day I inherited this meeting, my coach was on at me about getting rid of it.

1. The Feature Team Daily Stand-up
2. Sync Meetings per Specialty
3. Project Sync Meeting

9:15am Feature team Stand-Ups (aka Stream-Aligned Teams) Stand-Ups

9:15 am Leadership Team Stand Up

9:30 am  ART Sync

9:45 am Pipeline Services Stand Up

9:45 am Deployment Services Stand Up

• Pipeline Services - Get the right stuff on the train
• Development Services - Deliver the right stuff to the station on time
• Deployment Services - Get the stuff off the train
• Transition Services - Get teams ready to join the train
• Enterprise Services - Help the train operate within a mostly waterfall enterprise.

With an organisational structure in place, our next challenge lay in establishing our new ways of operating to become an agile program. We gave Pipeline Services the task of visualising the entire program - including the wagile and outsourced projects. We then reviewed the in-flight program of work and the pipeline. If a project had not already been outsourced, we considered it a candidate for delivery by the Agile Release Train. At the conclusion of this triaging process, we determined the last few projects we would outsource and committed to cease the practice of outsourcing deliverables from now on.

We initially had a couple of dicey moments with stakeholders requesting outsourced offshore delivery because they thought it would be cheaper. I offered the customer two options in these scenarios: (1) We send the project offshore. The customer pays the “cheaper” rate. But we take no responsibility for the quality of the outcome or the timeliness of the delivery; (2) The project is delivered by the EDW Agile Release Train, and I will guarantee a quality product within the timeframe and dollar range we quoted. Interestingly enough, no one ever chose option 1.

The projects that were deemed as destined to be delivered by the Agile Release Train were allocated to the pipeline team for inception work, in line with our interpretation of the analysis function in the Portfolio Kanban. The Pipeline team included several business analysts precisely for this purpose.

This turned out to be one of our early mistakes. Not only did this approach impede our ability to let go of our old working patterns, but we also found that when these projects were handed over to the feature teams, they came complete with a design and a bunch of technical rather than business features. This resulted in us moving to a model where the feature teams reserve 10% of their capacity each iteration for discovery work on new epics and to identify the features themselves. After all, as the manifesto says: “The best architectures, requirements, and designs emerge from self-organising teams.”

Today the Pipeline Services team is headed up by a Program Portfolio Manager and consists of four Project Portfolio Managers and a couple of System Specialists.  For a more detailed understanding of how the Project Manager role evolved into that of a Project Portfolio Manager, check out my earlier post: What Happens to Project Managers When You Implement SAFe? I realise that on paper, Pipeline Services could easily be confused with a traditional PMO. This is not our intent. Unlike a traditional PMO, this team’s mission is to provide services to the development teams and not to manage or govern them.

Another of our early mistakes was allowing the Pipeline team to push epics to specific delivery teams of their choosing. Over time we have transitioned to a model whereby the Pipeline team showcase their work (ready-to-discover epics) to their product owner (development services). The Feature teams can pull the priority features into their rolling four-iteration plan as required. We still don't have this practice as smooth as I would like it to be, with organisational politics often creating situations where work allocation begins to look a lot more like a push than pull; however, we are committed to continually refining the process.

Development Services is led by a blended Development Manager / Release Train Engineer and is the home of our six feature teams. For us, the Release Train Engineer (RTE) role, as articulated in SAFe, has never really emerged. Instead, the responsibilities have been split across the three services leads, leading some folks to see me as the RTE!

In the case of the Development Services Manager, he is the facilitator of our cut-down version of PI planning and our adaptation of scrum of scrums (from the Cocktail Party in Henrik Kniberg's Lean from the Trenches). He leads the train’s continuous improvement effort, drives the adoption of engineering practices and coordinates the train’s approach to communities of practice (based on the Chapters model from Henrik Kniberg and Anders Ivarsson's paper Scaling Agile @ Spotify). The Pipeline Services lead and her team look after the bulk of the other RTE responsibilities, including facilitating prioritisation, escalation of impediments outside the control of the development teams, managing risk and formal epic status reporting (where required).

One of the more unusual and potentially controversial aspects of the Development Services structure is aligning the Scrum Master role with line management accountability for their teams. While this may not sit comfortably with many agilists, for us, it has been a significant improvement to our prior state and provided better support to our people. While we have experimented with the size and shape of our feature teams over time, we have landed on eight being the right size - a Scrum Master, a Technical Lead, a Test Specialist and five T-shaped developers. 

It is worth noting that reducing team size was a key enabler for growing T-shaped developers, as the non-homogeneous nature of the work required by the feature teams meant that teams needed developers to work outside their specialisations to meet their delivery commitments.

The third component of the EDW Agile Release Train, Deployment Services, is led by our Release Manager. This team has three functions - release services, environments services and the system team.

Release services coordinate all our production deployments, including hotfixes. On behalf of the EDW Agile Release Train, they have the primary relationship with the Enterprise Release & Test Management function and EDW production support operations. The Environment team provide DBA services to the feature teams, including the provision of development and test environments. The system team (known as the Three Amigos) is responsible for building our automated deployment and continuous integration capability. (For more on how this team has helped improve software engineering practices, see my earlier post on applying business change management to software engineering.)

9am        Unity Hour
10am      Feature Team Planning
12pm      Lunch
1pm        Technical Alignement Huddle
1:30pm   ROAM
2:30pm   Dependency Alignment Huddle
3:30pm   Re-unification
4:45pm   Commitment

What worked well?

• Shared understanding across the group on the in flight and upcoming program of work
• Plans focused on finishing rather than starting
• Identification of cross team dependencies
• The energy and sense of camaraderie in the room and during the day
• The show opened on opening night!

What needs improvement?

• Planning!
• Air conditioning!
• Business participation!
• Planning at the right level of granularity

When I look back and think about how I would have reacted as a business sponsor if the IT Program Director had told me that he wanted the EDW Delivery team to down tools for an hour once a sprint to "play games", I fear I would not have been open to the idea. 18 months later I can't think of anything more important to the teams wellbeing than this one hour escape from reality at the beginning of every sprint.  I still remember the day I realised the difference Unity Day had made to the culture of the EDW Release Train. I was walking the floor and noticed that people were in the "wrong" team areas - then I realised that it wasn't people in the wrong space, it was people collaborating across the train, sharing knowledge and supporting each other. I couldn't wipe the grin off my face for days.

It is hard to do Unity Day justice via a blog post as you really have to see it to believe it. Hopefully this story and the accompanying photos have given you a taste and maybe you will try something similar with your own teams.

Santa is coming to Unity Day! Santa would like to know your Christmas wish for the EDW Release Train. One of Santa’s elves will place a wish card on your desk today. Please find a minute to clearly write one or two words with a Sharpie on your wish card  and bring it with you tomorrow morning where each of you will be able to share your wish with Santa and the broader team. Merry Christmas one and all!

"Thanks for today.  It was great to see how far you and the EDW team have come.  It has really helped to enforce the agile change ideas within my [Department] leadership group and show them what is truly possible if you put your mind to it ?"

• Direct the Rider - Find the Bright Spots. Script the Critical Moves & Point to the Destination
• Motivate the Elephant - Find the Feeling, Shrink the Change, Grow Your People
• Shape the Path - Tweak the Environment, Build the Habits, Rally the Herd

"What looks like resistance is often a lack of clarity."

"Find the bright spots.. What's working and how can we do more of it?"

"In almost all successful change efforts, the sequence is ... SEE-FEEL-CHANGE. You're presented with evidence that makes you feel something."

"Shrink the change." Not only does this help flow, but "When you engineer early success, what you are really doing is engineering hope".

Friday

Thursday

De-Mystifying Kanban: Understanding Its Many Faces Al Shalloway

Al provided a very thorough and complete explanation of the various flavours of Kanban. He covered: 

• Kanban as a signal
• Kanban as a Team Development Process
• Kanban’s Roots in Lean
• Scrum as a Manifestation of Lean
• Lean Kanban University (LKU) Kanban aka The Kanban Method
• Kanban Thinking or Lean-Kanban
• Getting Started with Kanban

Gaining Support for a Sustainable Agile Transformation Dennis Stevens and Mike Cottmeyer

Dennis and Mike believe Agile is about team and if you can't get to teams you fundamentally cannot get agile to work. When getting started with agile, figure out what is the right thing to form teams around.

When it comes to agile at scale, the challenge is how to coordinate multiple teams delivering output at the same time. You need to determine "what are the things that are shared, and what are the things that consume the shared stuff". At scale the performance of the team isn't as important as the performance of the corporation as a whole. Focus less on team velocity rather focus on cycle time at the program and portfolio level.

 

Dennis and Mike told us scaling is hard, because books tell us what it looks like but not how we get there safely.  You have to align the team, management and executive perspectives to create the safety for an agile transformation. If you are in a place where you don't have trust in the team it's probably because they haven't delivered because of the system around them. Overloaded teams will find it safer to say 'yes' and fail, than to say 'no' to more work.

 

When it comes to starting an agile transformation start by understanding the business drivers of the organisation, define the operational framework, introduce change incrementally, measure improvement and tie it back to the business drivers.  Most people in the face of good data won't make irrational decisions. Cultural shift is important but it takes time and requires safety, you have to create the operational model first. "You are not going to kumbaya yourself into an agile enterprise!"

 

<iframe style="border: 1px solid #cccccc; margin-bottom: 5px;" src="https://www.slideshare.net/slideshow/embed_code/25143903" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" sandbox="" allowfullscreen="allowfullscreen" loading="lazy"></iframe>

 

Agile2013 sustainable change from Dennis Stevens

 

The Language of Change Esther Derby

 

Everything touches everything. If we are trying to change one thing it always impacts another. How does language play into the success of change? How do people talk about change in your organisation?  Do they use words like: change management, drive change, create a burning platform, evangelize, cut the dead wood, clean house, roll out change, overcome resistance. When we use language it's not just the words that are active in our brains.  98% of our thinking happens at an unconscious level.

 

"You're going to cut the deadwood? Weren't these people all alive when you hired them?" - @estherderby #Agile2013

— Michael (Doc) Norton (@DocOnDev) August 8, 2013

We are awash in metaphor everyday. It is pervasive, everywhere we go, in every conversation we have. When we use metaphor it kicks off a process in our heads, a frame, with roles and scenarios, therefore we need to be careful and intentional about the language we use. The way we talk about change, for the most part, masks the complexity of what we are doing. When we use metaphor and kick off that script, it makes it more difficult to engage. Every change is different . You have to start where you are and find your own road. Every time we have a gap between our values and actions, cynicism and fear fills the gap.

 

There is always an emotional element to change. Denying the emotion keeps it in play. You don't need to fix it you just need to acknowledge it. People eventually adjust to change and reach a new status quo. The best time to make a change is when folks have successfully integrated the last change. The worst time is when things are in a state of chaos.

 

When we change the structure of an organisation we impact identity, status and affiliation creating resistance. When there is resistance we push hard and the resisters push back and don't feel heard.

 

People resist for a number of reasons, they don't trust the person behind the change  or they might think its a really stupid idea. When people don't feel like they are being heard they hold on harder. The reasons people may resist change are mostly pretty legitimate - to save the things they value.

 

Changing organisations changes people, impacting identity, status and affiliation. You need to provide support, empathy and time to learn.  If we want to succeed in change it requires trust. Trust must be given (not earned). Trust is not binary, it is always contextual and bounded. Trust is one of the reasons that change fails. People don't resist change they resist coercion. We need to connect. If we don't connect we don't have trust.

 

Esther recommends the following reading material on this topic:

 

Metaphors We Live By by George Lakoff & Mark Johnson
Facilitating Organization Change: Lessons from Complexity Science by Edwin E. Olson & Glenda H. Eoyang
Satir Change Model
Slow Ideas by Atul Gawande

Agile Business Intelligence & Data Warehousing Open Jam

Organised by Lynn Winterboer, the Agile Business Intelligence & Data Warehousing open space was an opportunity to talk with "esteemed authors" Scott Ambler and Ken Collier as well as a number of practitioners about the challenges specific to using agile in the data domain. The morning session was so successful it was followed up by "Lean Cocktails" at the end of the day.

Conference Party

 

Held at Nashville's Wild Horse Saloon the conference party was unlike any conference party I had been to before. Everyone was given a cowboy hat and bandana on the way in and it was not long at all before the line dancing started! While I chose not to line dance myself, Mia Horrigan and I enjoyed watching Matthew Hodgson join in the fun.

Read the next blog post in this series: My Agile 2013 Experience - Day 6 of 6

Wednesday

When NOT to Have All the Answers: Stop Giving Advice and Start Asking Questions 

Judith Mills  and Christopher Avery

Judith started by telling us about her addiction to giving advice and her realisation:

"If I was going to be successful, I couldn't be the expert; I had to change the culture. Changing the culture isn't about imparting knowledge, it's finding a way to tap into teams ... have them take responsibility," and she immediately had my attention.

 

Together with Christopher, Judith walked us through the responsibility process and how we respond to problems, moving from blame, to justify, to shame, to obligation. This is how we have been conditioned. If you are not familiar with the responsibility process, which I must admit I wasn't, here is the link to a one-hour video overview.

 

The main premise of Judith's presentation was that questions empower. When you ask questions, you are engaging someone, asking them to be creative, and honouring their intellect. When you give advice, you take choice away from your teams so they don't feel responsible.  Technical people are used to being the smartest people in the room; they can be a little socially awkward and not want to draw attention to themselves or ask questions. Christopher says,  "We need to create the culture where we are able to be vulnerable". This, of course, struck a chord with me, given my last blog post before Agile 2013 was about "Leading Through Vulnerability".

 

"The cool thing about responsibility is you can't make anyone take it, all you can do is offer it and allow it" - Christopher Avery

In closing, Christopher recommended reading. "Multipliers: How the Best Leaders Make Everyone Smarter" by Liz Wiseman.

 

Sketchnotes by Michele Ide-Smith

Hiring (or Growing) the Right Agile Coach 

Lyssa Adkins and Michael Spayd

Lyssa and Michael's session focused on the Agile Coaching Competency Framework and how it can be used as a tool for self-development, developing others or even deciding what sort of coach you need and assessing the competencies of potential coaches.

 

Lyssa showed a handful of videos of coaches she had worked with talking about how they had used the Agile Coaching Competency Framework,which can be found here. I have posted my favourite of these by Erin Beierwaltes below.

Enterprise Agility - A Practical De-Mystification 

Hendrik Esser, Jean Tabaka and Esther Derby

Hendrik, Jean and Esther's presentation was very different to the other sessions I attended. The three of them perched on stools at the front of the room, having a conversation, reminded me of a fishbowl (without the extra chair for someone else to join the conversation). They undertook to provide the audience with three perspectives on achieving Enterprise Agility. Given the presentation used a more conversational style, my notes are reflective of this and hopefully I have attributed the comments to the right speakers!

 

Jean Tabaka's recommended reading list for Enterprise Agility

 

The first topic, Flow, was introduced by Jean Tabaka. Jean said, "I don't think agile is sufficient on its own to deliver value to the customer,... I don't think executives should be talking about story points or velocity,... Good executives pay attention to "intrapreneurs". "The flow of value Agile" is the best way to learn quickly. We have to take a long view of the flow of value, start earlier than the team and look beyond effective deployment to the hands of the customer. In value stream flow, we watch: customer, cadence, capacity, clogs, cost and collaboration.

 

Collaboration across all different parties is essential. You are not going to be enterprise-level agile unless you are collaborating with upstream and downstream processes.   Collaboration doesn't happen on its own; you have to help it. For Enterprise Agility, we need to move from a language of cross-functional to cross departmental.  Hendrik Esser commented that "you need to look at the whole product life cycle" and Esther Derby noted, "The way accounting works and the way people are rewarded is keeping things the way it is".   Esther also mentioned that the Agile Alliance is sponsoring an initiative to look at an agile accounting approach.

 

Hendrik covered the second topic, Collaboration and Decision Making.  Collaboration is about abandoning contract thinking between different parts of one enterprise. Esther echoed this, commenting that "We need to adjust our plans so we can satisfy our customer rather than "you missed the date you won't get your bonus". We need to visualise uncertainty if we want to embrace change for example provide a range of possibly delivery dates rather than specific milestone date. Jean gave the analogy of Neo choosing between the red pill and the blue pill in The Matrix.  "People willing to embrace a sense of uncertainty are taking the red pill". Enterprise agility requires us to have a new way of measuring success and failure, different metrics other than points and velocity. In Jean's view, the only useful metric is one the team asks for to help itself understand how it's doing.  Esther pointed out that this holds true not only for development teams. Hendrik added at Ericsson "We measure our performance not our people".

 

The third topic was Eco-system, lead by Esther. If you keep replacing the individuals and get the same results it is a clear indication there is a system problem. Trying to "idiot proof" through policy or procedure almost guarantees you will get "idiotic behaviour". "I find job descriptions often get in the way of people collaborating", said Esther. We have a legacy of thinking of organisations as machines. This is not the type of ecosystem that enables flow, adaptability and responding to change. Trust begets transparency and transparency begets trust. Without this, decision making and flow breaks down. Trust is contextual not binary, and to get trust at an ecosystem level you have to give trust. What people don't know they fill in with their own fears.

The subject of building trust, brought some of Brene Brown's material from Daring Greatly to mind for Jean: "If you have shame and blame there is no possibility of innovation We are asking individuals to be vulnerable, to enable this the organisation needs to extend its vulnerability". Esther closed out this section with the following messages: "You need to start where you are. Trust grows incrementally. Once you start seeing systems, blame goes away. It's very powerful!"

KEYNOTE: Forty Years of Trying To Play Well With Others 

Tim Lister

Tim's keynote was a journey through his 40 year career as told through nine stories. This one of the handful of sessions that were videoed and posted on the Agile Alliance website. So rather than try to summarise it, here is the link.

Music City Concert Tour

 

 

I know you are thinking, wow, she made it to Nashville and saw some live music, sorry to disappoint but the Music City Concert Tour was the name of the conference event, held in the exhibit hall, Wednesday evening. While I didn't see or hear any country music stars, I did get a free flashing guitar pin - which made brilliant "gifts" for my leadership team when I got home.

 

As with all the conference social events, it was another great opportunity to meet people, such as Hendrik Esser, and catch up with people I had met in Boulder earlier this year, including Ronica Roth, Drew Jemilo and Jennifer Fawcett

 

After grabbing some dinner at one of the hotel restaurants, I headed to a gathering hosted by the guys from Leading Agile, Dennis Stevens and Mike Cottmeyer, where I scored a great (free) t-shirt. Thanks guys!

 

Read the next blog post in this series: My Agile 2013 Experience - Day 5 of 6

Tuesday

Agile Metrics: Velocity is NOT the goal 

by Michael "Doc" Norton 

Agile at Scale at Spotify

by Joakim Sundén and Anders Ivarsson

Be Agile. Scale Up. Stay Lean … & Have More Fun!

by Dean Leffingwell 

Continuous delivery? Easy! Just change everything. (Well, maybe it isn't that easy) by Steve Stolt and Steve Neely  

Tuesday Evening

The Agile Mindset  by Linda Rising

This session was definitely my highlight from Day 1. Building on a theme touched on by Mary Poppendieck and Torbjörn Gyllebring at Agile Australia, Linda explored the fixed versus agile (growth) mindset. This session was a sequel to her Agile 2011 Keynote, 'The Power of an Agile Mindset' which I can also recommend.

 

 

Linda's message was clear: mindset is not fixed, we are born agile and research has shown we can develop either a fixed or agile mindset. Stereotyping is dangerous, as those being labelled become believers in the stereotype (as illustrated by the "blue eye/brown eye" exercise). To foster an agile mindset, praise effort not talent eg. You worked hard on that! vs. You're so smart!". Failure is essential to learning.

 

Ice Breaker Reception

Sunday

In the next sprint, we also started with a team activity.  This time, everyone with "manager" in their title went to one corner of the room and paired up and appointed one person as the manager and the other as the worker.  Everyone else was to stand between the managers and the opposite corner of the room, creating a maze we would need to navigate our way through.

I paired with one of the scrum masters, and we agreed he would play manager. I don't think I will ever forget the painful process of being directed through the maze by my manager/scrum master - forward, backward, stop, left, right. It was not long before all the other pairs had completed the task, and there were just shy of 100 people laughing at me trying to complete the maze. Yet another horribly embarrassing morning for me.

As uncomfortable as those events were for me, with 20/20 hindsight, I can see how these moments helped me build such an open and trusting team. You see, vulnerability is the foundation of trust, and trust is the foundation of great teams. 

These days, vulnerability is something I am trying to foster right across my team. Just last week, some of my team were on facilitation training, and the question of what good facilitation looks like was tabled. One of the working groups suggested that a good facilitator creates safety, which led to a discussion on how to go about creating safety.

In response to this question, I found myself talking to the team about the power of vulnerability. I reminded them of how the Hakas and other Unity Day antics have brought the team closer together and explained that part of my motivation in inviting our stakeholders to participate in Unity Day was to begin the process of building trust through transparency and vulnerability.

While I know our culture isn't perfect, I am immensely proud of my team and their willingness to be vulnerable in front of each other and our colleagues from across the organisation. No matter where it started – “walking the walls” or “agile learning activities” - the openness of all members of the EDW Release Train makes it a truly special place to work. 

 

Since doing the Haka exercise – and aside from the fact that I lost my voice …  
Everyone across teams have been congratulatory of the other teams and their members. It has instilled a massive cross pollination of communication and engagement going on!!! 
The quieter team members from various teams across the department are having animated corridor conversations 
The level of talking and noise being generated in the different team areas has been much, much higher, even late into the night!  
Further, people are far less tense and defensive in the general discussions across the department.  People are open and honest, after having embarrassed themselves.  
Basically, the teams are showing greater interest, engagement and ‘hunger’ for what they do, and what they are about … 
How do you quantify all of this?  You don’t, but what I do know is that the teams are more galvanised, and have a much stronger sense of their own context … and being part of the greater whole; being EDW!!! 

• a 20-minute time box
• at the users' regular workplace (so you can see how real-world distractions impact usability)
• ask the user "can you achieve this outcome"
• do not watch the users (as this will impact how they work)
• video the test and encourage the user to talk through their thought process as they work (their self-talk will highlight the challenges)
• then watch the video with the user to better understand their experience

• Adrian Fittolani for his presentation on "Charting Scrum,"
• Bernd Schiffer for "Inspire Management"; and,
• eBay's Daniel Gu for "Scrumming with the World's Largest Data Warehouse"
• SMS's Martin Kearns on "Systemic Scrum - the lifeline of organisations"