Keep IT SAFe and Sound: Applying Principles of Scaled Agile Framework to the Real Projects

Scaled Agile Framework (also known as SAFe) is a method of adapting lean-agile practices to a large-scale project or several related projects.

There is a number of other approaches to scale Agile practices:

• LeSS (Large-Scale Scrum)
• Agile@Scale (Agile at Scale)
• Scrum of Scrums (or "meta Scrum").

SAFe is a popular framework due to a clearly defined toolset, roles, and responsibilities, deadlines, and metrics. There is a large community sharing ideas for Scaled Agile implementation from scratch or transforming already existing projects. The framework is a kind of add-on for SCRUM, which helps to manage of 5 or more interconnected teams and remains flexible enough.

Why does SCRUM need these add-ons? The optimal size of teams in SCRUM is 3-9 people including a Product Owner (PO). For large-scale projects that may not be enough. While team expansion is ineffective, more teams are created to remain agile. SCRUM or Kanban principles help to organize processes within each team. However, they hardly offer working solutions for syncing multiple teams and building communication between them.

Meet SAFe

Scaled Agile Framework is a kind of compromise between Lean and Agile productivity and RUP predictability. It provides a clear and relatively lightweight experience for a team of software developers. From its first version released in 2011, the framework has been developing to version 4.6 at the time of writing this article.

With the inspiration for successful SAFe implementation cases at HP, IBM, Philips, and other popular companies, Qulix initiated adapting core SAFe value in a couple of major projects mostly in the area of banking and financial product development.

For example, a Bank requires a number of teams:

• iOS development
• Android development
• back-end development (bank processing services)
• Internet banking (website development)
• software development for data terminals/ATMs.

In addition, the business has marketing (advertising) expectations for the launch of new functionality (for example, new accounts or deposits). SAFe is a methodology for all team cadence based on planning iterations for 3 months ahead. It helps identify dependencies between teams, for example, tasks on the critical path, and so on.

Basically, SAFe looks like a puff-pastry made of various Agile methodologies. It works on three levels: Team, Program, and Portfolio. The 4th level (Value Stream) is recommended for XXL teams and extremely massive solutions.

The framework helps us synchronize delivery, collaboration, and alignment. It supports systems and software development and focuses on assisting our customers to solve the most challenging scaling issues.

The three steps of the SAFe implementation roadmap are system thinking, lean development, and agile development.

Below you can see a basic Scaled Agile Framework layout. It is the nearest to what Qulix implements in its projects:

©Scaled Agile, Inc.

A strategy is where it all starts. Then SAFe enters the game at the Portfolio level on the customer’s side. At this level the framework is about lean portfolio management, priority directions of business development, distributing budgets to Agile Release Trains (ART).

An ART or a Program Increment is formed according to defined Epics. They may represent the entire direction of business development, for example, Payments, Loans or Loyalty Programs - if we talk about banking product development. These are further broken down into a number of features or sub-epics added to the Backlog. This is a core planning activity that leads to building a Program Increment.

Why Increments are called Trains?

Perhaps, this vivid comparison simplifies the explanation of the concept to businesses. It means that if the Epic doesn’t fit in this Train, it will be added to the next one arriving in a minute (read: in the next Program Increment) sharp.  

Portfolio

The Portfolio Backlog is filled with Epics. In a perfect scenario, each portfolio component receives a number of metrics used to track progress. The level is connected with the other ones due to regular syncs between teams, ranging from every two weeks to at least every month. These syncs are necessary to remain on the same page and exchange statuses and KPIs.

Program

The Program level requires coordination between Release Managers, System Team and Product Owners on the customer’s side and Product Managers or Team Leads on the contractor’s side.

What is true about PI planning in SAFe is that Increment Planning divides Epics or Features into sub-Epics (if needed), allocates them by Sprints and assigns teams. It also indicates possible relations between the tasks. It helps all process participants consider the risks. It’s important that teams get an overview of the business context, product vision, architecture vision and features planned.

One level down each team is going to work on tasks or stories independently, but SAFe provides closer interaction between the Team Leads, POs, and Release Managers at each stage than SCRUM does. This interaction can optimize work with the codebase and prevent conflicts at the git branch merging right before the release. The teams at SAFe take responsibility for implementing not only specific features assigned to them but the features of the entire increment as a whole.

Team

According to the Agile Manifesto, “individuals and interactions are over processes and tools”. Well, try sticking to it when the development and testing are carried out by dozens or hundreds of specialists. “Challenge accepted.” - answers SAFe.

As we mentioned above, SAFe splits the entire development timeline into sets of iterations within a fixed timebox - a Program Increment for each SCRUM team. Program Increment Planning uses synchronization and cadence to build “a team of teams” including business representatives and other stakeholders, to limit Work in Progress (WIP) and provide valuable ideas to discuss at Retrospectives.

At Qulix the Scaled Agile Framework is modified according to the needs of specific projects. Several teams may work in Kanban with their own release schedule, but in technical communication with SCRUM teams.

As for these SCRUM teams, everything is clear: they have standard team size, 2-week sprints, and ceremonies. What’s different?

• teams are no longer independent modules,
• the sprints are interconnected within Product Increments (the number of sprints in each PI may vary, depending on the project),
• there is more transparency for the customer.

At this level, the story may be equal to sub-epics or be a smaller unit. For example, for the epic “Savings and Deposits”, sub-epics would be “Opening a new bank account”, “Deposit showcase” or “New widget”. Stories can be the same, or the “Deposit showcase” can be divided into several tasks.

Daily meetings inform Team Leads and/or Scrum Masters on processes, potential blockers, and risks. Communication between the teams becomes a priority aimed at backing up timely releases.

It’s a smart idea to evaluate and compare stories by using story points. If the task is estimated with 8 or more story points, it would be better to divide stories into smaller ones to ensure continuous delivery.

When We Use Scaled Agile Framework?

• When each team is used to Agile methodology but finds it difficult to сooperate with other teams, facing blockers, delays and even failures for timely delivery;
• When it’s time to scale Agile across the project or company, but it’s difficult to assign managing roles;
• When it’s necessary to align teams to build a consistent strategy across separate business departments (from Portfolio to Program and Team levels) and improve product time-to-market.

Any Perks of Implementing SAFe Principles?

• The process becomes easier to embrace: Agile Release Trains help planning a little bit ahead without losing control over the ongoing processes. Businesses enjoy having additional layers of oversight, so the dialog with the software development company becomes easier.
• In Scaled Agile Framework there are a lot of tools available, for example, Kanban, Gemba or WSJF.
• The teams are more confident in providing estimates on the delivery.
• All participants leverage more options for face-to-face communication and collaboration.
• Visual boards are great to support focus and promote transparency of the processes: now the teams are better informed about each other’s plans for a couple of sprints ahead. Qulix is implementing SAFe in Jira.
• Simultaneous and interconnected performance of multiple teams makes it possible to carry out intermediate synchronization - a System Demo.

Why It’s Hard To Be SAFe:

• The framework is quite difficult to be implemented on the ‘as is’ basis, so it requires adaptations to every single project.
• Extra time and expenses are required to switch to this framework and ensure sufficient communication between all project participants.
• Additional coordination and control make SAFe popular amid larger companies. But it’s somewhat ironic that it resembles the good-old Waterfall model that is widely criticized today.
• As SAFe emphasizes the general overview of the project, it may lead to longer planning cycles and stricter roles in development cycles. It requires additional efforts to make sure the framework principles don’t run counter to the idea of fast and continuous delivery.

Bottom Line: Is It Worth Playing SAFe?

Just like with other methodologies, there’s no clear answer. It’s about educating yourself on available options for the unique need of the company and/or its projects. Qulix is adopting key features, testing them and giving teams time to settle in. There are a lot of how-to’s to be addressed, for example:

• how to check if SAFe is measurably benefiting the project
• how to ensure a smooth transition to this framework
• how to plan SAFe-style portfolio budgeting and a lot more.

SAFe Framework elements (Team, Program, and Portfolio) is a step-up for key Agile and Scrum concepts. The same roles, the same value, and ceremonies, but this time scaled up for the larger team size and responsible ROI.

However, key framework principles are quite successfully applied by Qulix to a number of projects. We embrace the fact Agile is not a destination, but a continuous journey including experiments and enhancements in SDLC. If the process isn’t working properly, we change it. Qulix management is always on the lookout for opportunities to make a better value of customer’s time and on continuous process improvement.

To learn more about the Qulix approach to projects contact us at  request@qulix.com or visit our website.