SAFe

The scaled agile framework also known as SAFe is a lean-agile framework designed for quick and coordinated product releases. How different or similar is it to scrum? Why do they go for SAFe?

For the ease of understanding, let’s imagine a retailer having it’s IT wing work on their shopping website. There is a team that work on it’s product page, another on it’s account and payment pages, another one on inventory and the last one on search and recommendations. (In real case there could be many more teams).

In classic scrum world, these four teams would be part of their own scrum team with their defined sprint length and release cycle. In this case, the teams may have different release days and that can go as an impediment to the other team, especially if they have a dependency on the other. Product page team is looking for a feature from the inventory team, which the inventory team might be doing after the product teams current release cycle. This delays the dependent functionality on product page. Standards and architectural guidelines may also differ from team to team.

Now when the IT organization looking to release a bigger program like an enhanced user experience, it may find this way of delivering as a challenge, as the focus is not the same for different teams. Decisions towards customer satisfaction also will have an impact if teams works in a distributed way.

SAFe or scaled agile is for matured scrum team’s and enterprises to take on some of these challenges. In SAFe, essentially there are three logical levels in the way it works.

Team level

Teams at this level is the equivalent to a scrum team. So our organization will have four teams in this team level. Teams usually follow scrum, or kanban methods. Consider here they use scrum. They all will have the same sprint length typically of two weeks. There will be usually five sprints before there is a release. This increases possibility for every team to release the combined product increments together.

Each team starts the sprint with sprint planning. Then there is daily scrum, sprint review and sprint retrospective at every sprint. Teams consist of scrum master, product owner, and development team. The team has a team backlog, which has user stories to work on towards creating product increment. Team may follow behavior driven development or test driven development to accelerate the processes.

Program level

This level provides the scaling for teams looking to push their increments at the right pace in to the release cycle which is called as agile release train(ART). Program level coordinates a number of agile teams to be in the agile release train. Usually there is a release engineering team, management team, business team and architects that helps building common platforms, guidelines, and all the necessary support to release the combined incremental product.

Program level provides the roadmap to the teams for the next ART cycle through release planning event. To start with a release cycle, all teams must get an understanding of their common goal, which is the release planning ceremony. The objective is to give correct guidance on what all are to be made as part of product increment on to the release.

Top objectives are listed, and a program backlog are identified during release planning. Features, program backlog, roadmaps are created by program level. Teams takes program backlog as an input to create team backlog.

There is an architectural runway, which is to pave the track for release trains with architectural solutions. A continuous delivery pipeline is maintained by program level, that will help scrum team with automated build process, automated integrations tests , tools and technologies for release etc. This is an accelerator to the train.

Every sprint will have a scrum of scrum meeting to know the progress and impediments at each team level, and about any dependencies with other teams. At the end of every sprint, there is a review of increments done by teams. After four such development sprints, there is a special hardening sprint to integrate, test and for competency improvements. Release retrospective, necessary changes to the ART, release plan for next cycle etc are done during this sprint.

All the four teams are now moving together with same cadence towards the same ART. Any team’s product increment not making to the ART, will have to look and make it to next release train, of course with the identified dependency and impacts.

So here lets consider new program goals about an enhanced user experience given to all four teams through release planning, and they all work at the same time towards getting their increments to the release cycle. They now follow guidelines on what they need to do, what dependencies are there with other teams, when that is expected and how they have to integrate and test during hardening sprint etc.

The release planning guidelines, hardening sprint are things that classic scrum fails to suggest to the team for scaling up.

Portfolio level

Portfolio level is usually the strategy defining level on the values needed to the organization, its budgeting, timelines etc. Staff and team inclusions, technology and modernization of systems, budgets for these changes… will be done. A protfolio level may decide on agile release trains for multiple programs, solutions to improve etc. Value systems are defined and budgeted to promote growth. Portfolio level follows the kanban way where the epics on values and solutions are formed. This can go in as inputs to the downstream.

In our example, a new value stream could be for launching customer rewards or promotions to prime customers, which includes online shopping too. So the release times for the new program, solution level needs, the synchronization with existing values, and budgeting on to the program has to be at the portfolio level. Overall, this is the level that helps driving the other two levels.

With this you might notice that SAFe provides quick product increment releases with high quality; however, this is making agile development slightly process-heavy.