Four things to make SAFe work and the 5 risks to watch out for

Scaled Agile, the company behind the Scaled Agile Framework (SAFe), provide a transparent way of implementing it’s agile framework. It starts with training everyone, including leaders and executives, and setting up Agile Release Trains of 5-12 teams. Once that’s established, it’s time to do a 2-day big-room planning event so that teams can plan their next 6 Sprints.

Implementation, though, has many traps. To get the most out of SAFe, here’s four things to be aware of.

1. Setting up teams

It takes time to get things rolling

SAFe has a 1-week rapid implementation pattern that involves training everyone and then launching into its 2-day big room planning event called “Program Increment (PI) Planning”. For most organisations, though, more time is needed to make the change from Waterfall to agile.

Most organisations take a while to prepare their Features

SAFe represents a way of working that is foreign to many organisations that are used to big, upfront design, and long requirements gathering phases. Moving from Waterfall to identifying “just enough” to start teams Sprinting can take time.

“Perfect is the enemy of good [enough]” – Italian proverb (1770)

If you’re used to spending 6 months creating your product roadmap or project gantt charts, be prepared to spend about 3 months working out what Features you’ll take into the first PI Planning event. Prepare about 12 Features. Anything more is overkill at this time. Release Trains rarely deliver more than a dozen Features in their first PI.

As soon as PI Planning is over, it’ll be time to immediately start to work out the next Features for the next PI.

After 12 months, Feature definition and preparation should only take a few weeks, and it should be done by Product Owners and their teams as part of:

• Backlog Refinement – Preparation for upcoming Sprints and PIs, conducting user research, refining and defining User Stories, investigating code, doing some high-level design.
• Sprint Review* – Where they get feedback from stakeholders on the Increment they’ve created and what their future needs are.

* SAFe refers to the Sprint Review as the Iteration Demo.

Teams take a while to “form and storm”

In some organisations, managers choose which people will go into what team. Often, this process can take weeks. There are many rapid team design patterns, however, that can be used, including “squadification“, to create teams. In as little as 1/2 a day, you can easily organise people into a dozen teams and get them working the next day.

Once a team is formed, it takes one team about 3-months for its members to learn how to work together as a team, with team goals, and team-based work over individual tasks delegated by a manager.

Self-organisation is harder than it looks

Self-organisation doesn’t mean chaos or that teams don’t need managers. Self-organisation requires managers to set guardrails for what teams can and can’t do, the decisions they are permitted to make themselves, and the rules for doing so.

For SAFe, self-organisation of teams involves managers to be clear on the rules of the team’s delivery:

• Deliver an Increment of Done work every Sprint.
• Work from the Team Backlog and not from any other list of priorities.
• Make work transparent and up-to-date in the Sprint Backlog.
• Inspect and adapt progress daily.
• Work within the rules of SAFe’s Scrum/XP hybrid.
• Hold each other to account for a commitment to quality.
• Work as a single team, with a single goal, not as a group of individuals. This includes the Product Owner.

Agile IQ® helps with reporting on SAFe® capability maturity

Agile IQ ® creates a data-driven culture of agility. It tracks every part of your agile culture to help you improve productivity, reduce costs, stay motivated, and see how small steps make a big impact in your ability to pivot to changing market and stakeholder needs.

LEARN MORE ABOUT AGILE IQ®

2. Defining Features and setting up the Program Backlog

Many organisations employ Business Analysts and UX practitioners to define requirements, get them approved, and then start work. This can take many months. In this model, no delivery work happens until everything is defined upfront.

To start working with SAFe, a Release Train only needs enough Features to commence its first Program Increment (PI) Planning session. Most of the time, this will be approximately 12 Features. 

There’s a risk to using upfront design to defining Features

The problem with the “design first” approach, is that it’s predominantly analysis-driven instead of product-management driven. There’s often no Product Manager who decides what to focus on and what could be of value. Instead, designers spend their time researching and designing everything to ensure they understand what “could” be built instead of what adds most value to the business, stakeholders, and users at this point in time. As a result, the cost of delay increases. Opportunities that can be seized now are delayed until the research and design documentation has been completed.

Ultimately, design without delivery has no value.

Where to start

If you start with Water-Scrum-Fall as the first step in implementing an Agile Release Train, try the following:

1. Form an agile team with the designers and analysts — including working with agile roles, timeboxes, events and artefacts like backlogs.
2. Get them to work in Sprints, with an Increment of work, e.g. Complete Feature definitions, that they can potentially hand over to the Product Manager for their Product Backlog.
3. Have a plan to retire the design team. After 3-6 months, when the team is Sprinting well, disband the team and place the capability into agile teams.
4. Ensure that design is product-management led and that research is a team sport, not just a UX/BA activity defined as a User Story.

Ultimately, ensure that the design team understands that the plan is to devolve their team to reduce time to market for the Agile Release Train. Embedding their capability into agile teams will achieve this outcome.

3. Release Train Governance

Agile Release Trains have three critical roles:

• Product Manager – Accountable for the product/service, the Train’s Product Backlog, manages the budget, and when to release value.
• Release Train Engineer – accountable for the Release Train’s agile capability.
• Managers – accountable for functional capability, but not work delegation.

Product Manager

Product Management is not like Project Management. Its lifecycle and focus are very different. Where project management focuses on delivery and then handing it over to the project owner at the end of the project, in product management the owner is the one who steers the direction of work themselves with a focus on prioritisation of value.

In a nutshell, the SAFe Product Manager’s responsibilities include:

Delivery

What’s of value to the organisation and to users? When should it be released? How does the Release Train report to executive on the impact its Features are making and the outcomes it’s achieving?

Budget

How much do we spend delivering the Features?

Value and Cost of Delay

If the Release Train focuses on Feature A it will be at the cost of delivering Feature B. What is that impact? Is that the right thing to do? Is it the most valuable thing to do at this time?

Agile Product Management

The Product Manager also needs to work within the guardrails of SAFe. The Release Train Engineer’s (RTE) role is to help them do this.

Cost of Delay is a major factor in prioritisation of the Features in the Product Backlog in SAFe. The Product Manager should continuously assess what Features will add the most value in the shortest time possible and then prioritise the Product Backlog accordingly.

At the beginning of every PI, teams gather for 2-days with stakeholders to create their plan for the next 6 Sprints. They take the Features from the top of the Product Backlog and decompose them into their Team Backlogs.

Release Train Engineer (RTE)

The Release Train Engineer isn’t responsible for delivery. They are responsible for the effectiveness of agile across the whole Release Train. If you don’t ensure the Release Train Engineer is accountable for teams doing agile well across the whole Agile Release Train. Scrum Masters are accountable for the effectiveness of Scrum at a team level. Scrum Masters should, therefore, have a line of reporting to the Release Train Engineer.

Without someone being accountable for agile at all levels in the Agile Release Train,  business agility, and agile capability maturity, will simply drop, and people’s behaviour will revert to Waterfall practices.

Things to keep in mind:

• The Release Train Engineer is accountable for the agile capability maturity of the Release Train. They should be reporting on what they are doing to grow the Release Train’s agile capability and its current level of maturity. Agile IQ is a great way to do this.
• The Release Train Engineer facilitates the Release Train’s agile events, like Scrum of Scrums, PI Planning, and the Inspect & Adapt workshop. There’s lots of preparation that’s involved in each of these events, particularly in researching and selecting the best facilitation pattern to use relative to what’s happening in the Release Train’s environment.
• Coaching stakeholders is an important part of the Release Train Engineer’s role.
• Improving how the whole Agile Release Train operates from an agile perspective is key to success.
• Helping teams address problems, remove blockers and impediments to achieving their goals is done through Scrum Masters. When teams don’t have the authority or power to address an issue themselves, the Release Train Engineer is a logical point of escalation.
• Scrum Masters should report to the Release Train Engineer, accounting for how effective their own team’s Scrum practices are.
• If the Release Train Engineer stops being the chief of the Scrum Masters and focuses instead on delivery, they’ll turn the role into a traditional Project Manager. They’ll then start to manage time, cost and delivery, at the cost of the very capability that achieves delivery at a lower cost, lower risk, and improved throughput.

Managers

Managers have a critical role to play in an Agile Release Train.

Things to keep in mind:

• Spotify called their managers “chapter leads”. They were accountable for improving the capability for delivery, but not assigning work.
• People need someone to go to that look after performance management, HR, the practices and standards of a particular capability. Managers perform this role.
• Managers are also part of agile teams. You don’t want your quarterbacks on the bench. They contribute to the outcome of their team as well as supporting functional roles across teams.

4. Managing the risks

Every year, the State of Agile survey highlights the transformation risks of agile adoption.

The top risks identified by the State of Agile Survey, year after year, are typically the same:

Change resistance

You can’t treat SAFe’s adoption as a methodology adoption. The reality is that you’re about to change people’s work behaviour. Be prepared to have executive, leadership, Product Manager and Release Train Engineer be a critical part of championing adoption using a framework like Prosci ADKAR and then continuing to support continuous improvement once the setup is done. Essentially, because agile helps to support an organisation to pivot to change, continuous improvement is needed to ensure this ability is maintained and even grows.

Management participation

If managers aren’t also Sprinting, the “do what I say, not as I do” behaviour paradox will set the wrong example for teams. If teams see that not everyone has to work in this way (including managers), they’ll find excuses to not do agile.

Inconsistent practices

Inconsistent practices impact the ability of an Agile Release Train to work as a single delivery machine. Inconsistent practices and terminology result in:

• Miscommunication about why the organisation is moving to agile and using SAFe.
• Miscommunication about expectations about delivery and how teams work together with SAFe.
• Misunderstanding about what is required in SAFe and Scrum events, like Daily Scrum or the Inspect & Adapt end-of-PI event. Is the Daily Scrum a status report to the Scrum Master or is it about inspecting progress toward the Sprint Goal and adapting the Sprint Backlog? Why shouldn’t teams extend Sprints in order to complete work? What happens when work doesn’t get to Done?
• Misunderstanding about agile roles compared to project roles.
• Misunderstanding about how to work with Scrum, XP or Kanban (e.g. Kanban is more than just visualisation of work, it’s about optimising flow).

Ultimately, inconsistency reduces the Release Train’s agile capability maturity, including its ability to pivot to change and improve throughput and quality. Inconsistency often happens when organisations hire different agile coaches and contractors who don’t keep up-to-date with industry trends.

While initial training can help to get everyone on the same page quickly, the key to maintaining consistency is to ensure that it’s ultimately the Release Train Engineer and the Scrum Masters job to maintain the agility of the Agile Release Train, stay aligned to industry trends, and not get stale. 

Management support

Traditional managers tend to delegate work and then report upwards on its progress. It’s easy for Agile Release Trains to fall into this habit. When Spotify went agile, it turned managers toward owning and improving their domain of capability. Engineering managers became capability leads responsible for maintaining and uplifting the capability, being responsible for line management, and people’s individual skills uplift. This type of management support creates an environment where management are held to account for the capability that drives the Agile Release Train instead of directing people to do work and handing out tasks.

Experience

One of the big areas for agile adoption failure is lack of experience. How can you know how to successfully set up, establish, run and maintain an Agile Release Train if you’ve never done it before?

The key here is not necessarily to hire capability in the form of contractors (their capability walks out the door when their contract expires), but to find experienced practitioners with the highest level of industry recognised qualifications who will then invest and grow the Agile Release Train’s capability until it gets to a level of sustainability.

Conclusions

After setting up some of Australia’s largest, and most complex large-scale programs, including the ATO’s Tax Time and Superannuation Agile Release Trains, we have empirical evidence that shows a clear link between cost savings and reduced time to market can be gained when Agile Release Trains take account of governance, adoption risks, set-up time, and Feature definition. 

We’ve found an Agile Release Train can get up and running within about 3 months, with delivery at a sustainable and predictable pace within 12-18 months. Do achieve these outcomes, though, takes experience to know how SAFe’s pieces can best fit together in a specific environment.

SAFe® Success Stories

More than 20,000 organisations worldwide are using SAFe®. Learn more about the organisations that ZXM has helped and the outcomes we’ve achieved, including the ATO, Clean Energy Regulator, AUSTRAC, Department of Industry and Department of Education. READ STORIES