How to Approach to Transition From Scrum to SAFe

Implementing functional Scrum teams into an organization is a challenge by itself, and many are constantly failing on this step. However, once you have multiple highly dependent teams operating within the same product or value stream, you need something stronger.

It is necessary to utilize a scaling framework covering the Scrum teams. Giving them processes and rules to follow in order to get synchronized with each other, aligned, and don’t get lost along the way.

Often you end up with Silo teams, which basically mean standalone scrum teams that work towards their local goal but have barely a clue about the ultimate common goal of the whole program. This is where the Scaled Agile Framework (SAFe) comes into play.

What is SAFe?

SAFe is an approach that applies an agile framework and processes to the hierarchical organizations of the past. It covers the structure levels and processes, but instead of recreating them, it reintroduces a second system in an organic way that is familiar to most of the existing stakeholders of the original system.

SAFe is built around several core values.

Alignment

• All scrum teams need to understand the vision and strategy and what is the ultimate goal they are marching to.
• Connect strategy between the teams and lead them to joint execution.
• Communicate with the teams with a unified common language they can easily understand.
• Constantly check whether the teams understand the goals and vision.
• The teams need to be customer-centric, and they should understand who is the customers and what they need. Update the strategy to reflect that.

Transparency

• Create an environment where everybody can work at their best and without the lack of trust.
• Communicate openly your arguments and facts. Be direct and honest, and do not hide important facts in front of the teams.
• Fail fast and turn mistakes into learning moments. If something turns out to be not successful, realize it soon and learn from it. Then, change your strategy.
• Visualize the work that you are building so that everybody can better understand.
• Provide ready access to needed information.

Respect for People

• Emphasize what it means to be human. Do not treat people as resources.
• Value diversity of people and their opinions. Support honest feedback.
• Grow and educate people through coaching and mentoring.
• Embrace that your customer is the one who consumes your work.
• Build long-lasting partnerships within the teams and outside of the teams.

Relentless Improvement

• Build an environment where solving the problems is motivating the teams.
• Reflect on how you did last week and identify what can be done better next time.
• Take the facts as the single most important argument for improving things.
• Provide time and space for innovations. Give the teams the opportunity to experiment and try out different routes, even if they are not the safest ones.

SAFe brings a layer of collaboration and communication to scaled Agile systems. It does not replace the individual Scrum Team Sprint Activities you do today.

A key part of every SAFe is the Agile Release Train (ART). It is a long-living, stable team of Scrum teams (typically up to 12 separate teams) that regularly brings new incremental functionalities after each sprint release. They develop, deliver, and support one or more solutions in a workstream.

Roles of the SAFe

SAFe relies on people with different sets of responsibilities. Sticking to the expectations for the roles is the crucial factor that will determine how successful the implementation of the framework will be. It’s therefore also important to understand what those roles are and what their purpose is.

#1. Agile Team

Agile teams are cross-functional, which means they can cover the whole area they are implementing within the team itself. They are also self-organizing entities that define, build, test, deploy, and release increments of value.

Each Agile team has the skill set to execute on their agreed and committed scope. The team implements that scope by increments each sprint in a predictable manner. The predictability is crucial because only then can the team commit to delivering concrete objectives in concrete time. Communication and delivery are the crucial values the team shall constantly improve.

The agile team is a fundamental part of Program Increment (PI) Planning sessions to create stories within and plan them within Sprints. Finally, they commit to their own PI Objectives.

The Scrum Master coaches the Agile Team and facilitates team meetings. They remove impediments and protect the team from outside influence. They participate in Scrum meetings as part of the ART.

The Product Owner (PO) is another special member of the team. PO is the voice of the customer and has a direct influence on the stories and their prioritization. The PO communicates with other POs to define and prioritize stories in the teams’ backlog.

#2. Product Management

Product management sits above the scrum teams and takes care of the alignment between the teams. They need to cover the following responsibilities:

• Meet business goals by ensuring development teams create feasible and sustainable products and solutions.
• Understand the customer needs and ensure products are completed to a defined customer perspective.
• Ensure there are enough ready features in the backlog at all times.
• Support the flow of work through the program boards and into the program backlog.
• Determine the scope of the next program increment by providing the priority to the features the teams have created. Product management is ultimately responsible for the definition of the next PI.

#3. System Architect / Engineering

The engineering team analyzes and develops the agreed content of the backlog stories. They are the expertise part of the team, and they cover the following responsibilities:

• Create and maintain the Architectural Runway so that new features can use the technological enablers.
• Actively participate in Program Increment Planning. Be present during System demos at the end of each program increment.
• Work with agile teams to implement new architecture enablers. Only this will allow the teams to build new features.
• Help agile teams to define high-level design solutions and decisions. Suggest alternative solutions and the best approach for proof of concept activities inside the agile teams.
• They create an architectural runway. It’s a definition of technological enablers ready to be consumed by features that are defined by respective teams.

#4. Business Owners / Stakeholders

Those are the teams external to the Scrum teams, but they still play an important role in the SAFe framework in every stage of the execution.

Before PI Planning:

• Provide input to backlog refinement activities.
• Participate in Pre-PI Planning as needed.
• Ensuring that business objectives are understood and agreed to by key stakeholders of the train, including the Release Train Engineer (RTE), Product Management, and System Architects.

During PI Planning:

• Provide the business context and vision for the upcoming PI.
• Participate in the Draft Plan Review and assign business value to team PI Objectives.
• Participate in the Management Review and help to resolve problems that will lead to the acceptance of the Final Plan.

After PI Planning:

• Actively participate in maintaining business and development alignment as priorities and scope inevitably change.
• Help validate the definition of Minimum Viable Products (MVPs) for Program Epics and guide the pivot-or-persevere decision based on the delivery of the MVP.
• Attend the System Demo to view progress and provide feedback.
• Attend Agile team Sprint Planning and Sprint Retrospective events, as required.
• Participate in Release Management, focusing on scope, quality, deployment options, release, and market considerations.

#5. Release Train Engineer (RTE)

RTE organizes the activities of the people and teams within the ART. This is the role of a Scrum Master for the whole program. The following are the main responsibilities:

• Manage and optimize the flow of value through the ART.
• Establish and communicate the annual calendars for Sprints and Program Increments (PIs).
• Be the moderator of PI planning meetings.
• Organize teams and help them create a summary of their identified PI Objectives. Transfer the teams’ objectives into the overall PI Plan objectives.
• Get together the teams to communicate and resolve risks and dependencies between each other.
• Connect Product Management, Product Owners, and other external stakeholders together to align the parties on their common strategy.
• Orchestrate the Inspect and Adapt workshops with the target of continuously improving already existing processes and activities.
• Evaluate the current maturity level of the agile methodology adoption across the teams and define the follow-up action items to improve teams going forward.

#6. Leadership

Leadership defines the strategy for the program and gives the teams all the tools and support necessary to enable their work. Ultimately, they define the system where all the rest work. That’s why it is crucial to have a management team that gives the team the right purpose and values definition. Their primary responsibilities are the following:

• Lead by Example.
• Adopt a growth mindset.
• Highlight the values and principles of SAFe.
• Develop people.
• Lead the change.
• Foster psychological safety.

Program Increment (PI) Planning

PI Planning is a two to three-day event with the goal to understand and commit to the work for the next program increment. This might be the period of next quarter, for example.

Product management owns the prioritization of the features identified during the PI planning. Agile teams own capacity planning, story creation, estimation, and commitment to the PI objectives.

PI planning is essential to SAFe. If you are not doing the PI planning, that basically means you are not doing SAFe.

PI Process

PI Planning starts with some inputs on the table. Each workstream will collect their needs and ideas on what they would like to build next for their products. Then they bring it to the PI as an input:

• Top 10 features to implement next,
• ART Backlog of ready to formulated epics or features,
• Vision of the Product Owner.

The discussion starts between the different workstreams. Each of them presents their visions and features. They highlight what is important to implement next and what they need in order to succeed while doing that. This might mean several different things:

• Enablement is delivered by other workstreams in order to let them proceed with the features.
• Dependency on other workstreams and the necessity to make ordering a priority.
• Current issues that are present in the system and that need to be fixed first in order to continue.
• Staffing challenges for the team. It might be several key roles inside the team are still missing for the content implementation the features require.
• Budget constraints prevent your workstream from executing the vision in the given timeline.
• Any other risks, issues, assumptions, or dependencies the team can recognize and broader discussion across the rest of the SAFe teams is needed in order to align on the common goal.

PI Walkthrough

The PI planning itself is often split into several days, typically two to three days, where the agenda can be as follows:

Day 1

• Discuss the statement of the business and key upcoming objectives that form the overall program vision and strategy. Leadership owns this part and clearly communicates to the team.
• Place all the features from workstreams on the table and prioritize them in alignment with the common vision.
• Step into the Architecture vision and define the main objectives of the development requirements. Highlight the technical challenges and agree on resolving the impediments across the teams.

Day 2

• Explain the planning process in detail to the teams. Outline the expected outcomes once the PI is closed.
• Do the Team Breakouts for the first time during the planning. The team goal is to create draft plans and identify impediments and risks.
• Once the breakout is finished, the teams shall present and review the draft plans they created in front of the other teams.
• The next step is for the management, where they review the plans and give directions to problem-solving initiatives that follow next. Adjustments to the plans are made based on challenges, risks, and impediments.

Day 3

• Start the day with planning adjustments that are now in line with the previous day’s management meeting.
• Teams will develop the Final Plans and refine Risks and Impediments. Business owners will assign business value to the team objectives.
• Next, teams will present the final plans in front of the whole audience.
• The remaining program-level risks are discussed, and ROAM (resolved, owned, accepted, mitigated) risk information is applied.
• Teams vote for their confidence in the program increment planning results.
• If the votes are too low or overall confidence is still low, additional planning takes place.
• After the PI Commitment, the RTE plans retrospective for the teams to discuss how the planning was going and what to improve for the next round. Leadership states what’s going to happen moving forward alongside final instructions.

PI Outcome

The ultimate outcome of the PI planning is the list of features planned for completion as per sprints within the next PI period. All known dependencies have an exact plan for how to resolve and unblock progress for the features.

Teams will commit to their objectives and scopes. If there are additional objectives that aren’t necessarily part of the list, treat them as uncommitted objectives. Those can still be potentially resolved if time and resources permit it.

Teams will document and track all risks of the program and will have an exact plan for how to deal with them.

Teams will also capture every retrospective idea they came along with in their retrospective meeting and mark them as learning lessons for the next PI planning session.

As for the teams specifically, there are few concrete expectations, such as:

• The teams commit to objectives with business values.
• The teams will calculate their capacity per sprint so that they can better estimate the feasibility of the roadmap content.
• They also consider the actual load per each sprint.
• The stories are taken to the concrete sprints of each workstream based on the provided capacity.
• Teams vote for confidence in the PI plan and content to deliver.

Conclusion

This does not need to look obvious, even after reading all the facts above, but I can tell you that transforming a large organization into SAFe is an extremely challenging task. Yes, in some cases, it might look like a mission impossible. Even though some of those basic principles are applied, it usually takes many iterations in order to convert to a state where you can safely say you are now SAFe :).

Very often, progress is ruining some old-school hierarchical principles and rules, which are just not going to die no matter how hard you try. You can have extensive PI planning and results of some kind, which you can even name trustfully. But what does it really mean if the workstream teams are just not going to operate in proper agile methodology?

I can only tell that there is no place for hybrids here. You are either in – with all the right processes, people, and mindset, or you are out if at least one of the methodology aspects is not really met.

Naturally, before you even consider the SAFe implementation, just be clear on the fact that you already mastered the Agile team’s principles and ways of working. Not just from the leadership perspective, but let the teams vote and express their honest opinion. You might be surprised by the results.

Next, check out good learning resources for agile certification.