SAFe or Scaled Agile Framework

What is SAFe?

What is Agile, many people know. An even greater number of people involved in IT use terminology. Even more who heard about Agile.

Not everyone who confidently uses the term Agile for communication, criticism, for that; to present your team or company in the best light, for example, what is the difference between SCRUM and Agile; and often put an equal sign between these two different concepts. But not so long ago in 2015, SAFe also appeared. What is it and why is it needed?

One of the important advantages and disadvantages of SCRUM, I consider the prescribed command size is 7 + -2 (or 3-9 more recent data from the Scrum Guide ) including the Product Owner.
Of course, 9 highly skilled and well motivated professionals are capable of much, but sometimes there is a need to build something with more hands, heads, eyes and brains after all. Inflating teams is bad, so their number needs to be increased, and here there is a problem of communication between the teams, SCRUM itself does not offer any solution for synchronization of work. There are attempts to use SCRUM at the management level of SCRUM teams (this is how Jeff Sutherland advises to do - one of the authors of Agile manifesto), there is a Large Scale Scrum, there is a Disciplined Agile Delivery, there is a lot more that, but there is also a SAFe - Scaled Agile Framework.

SAFe is a framework for managing a company where coordination of work on a certain project or related projects for 5 or more SCRUM teams is required. Those. this is a kind of add-on for SCRUM that allows you to manage teams of 100 or more people

Benefit?

First of all, of course, the methodology is needed by those who sell it and are engaged in training. Dave Thomas (another one of the authors of Agile manifesto) spoke well on this topic at GOTO 2015 in his presentation of Agile is Dead

In the second place, program management departments. Those who were previously involved in project management received PMP certification, drew Gantt charts and implemented the concept of hard-soft management (soft side to management and hard to performers). The fact is that in a typical SCRUM there is no function for them, in SAFe there is one. The same applies to all sorts of architects. In SCRUM for them there is no function in SAFe - there is a career path.

Further, it can be beneficial to those business owners where managers work on large, devouring a huge number of man-hours projects and cannot (sometimes for objective reasons) make these projects independent.

Many developers with below-average qualifications, because often in order to do something they need to be exponentially larger than those of the most experienced and motivated professionals.

In the whole industry. Since the number of developers doubles every 5 years (see uncle bob's future of programming ), resulting in the fact that at any given time at least half of the developers have less than 5 years of experience. If the trend does not change, and apparently it does not change, then it requires processes that prescribe and formalize their working functions, the mechanisms of interaction between participants and the whole process.

The essence

SAFe is a layer cake made from various Agile methods. At the lower level, there is an almost traditional SCRUM, with typical two to three weekly sprints, teams of 3-9 people including Product Owner. All the typical rituals, ranging from daily planning - standup and ending with the analysis of flights to the restrospective. Although there is one key difference. The command ceases to be a fully functional independent module. And the sprint ceases to be an independent period of time with a full life cycle. Sprints are combined into Program Increments consisting of usually 5 sprints. Those. if in the classic SCRUM we didn’t build what the client likes, then we correct the course in the next sprint, then at SAFe we continue to go towards the edge until the end of the Program Increment in the worst case the next 4 sprints (of course I will exaggerate).

At the next level, we have trains - the so-called Agile Release Train. To manage 5 sprint segments, new functions appear - a system architect (the one who owns the architecture - that is, it is no longer a team), a product manager (who controls the product, not the Product Owner, the latter goes to PM for advice) and RTE - the same PMP from the distant world of waterfall. Here, some developments from Kanban in particular are applied to the board, a method for assigning priorities and generally remains the principle of measuring the historical performance of commands (velocity) and projecting what will be built at the end of the time interval as opposed to the approach with estimates and assignment of deadlines for the already fixed functionality ( scope). One of the innovations is that the last sprint out of 5 is declared organizational and during it there are huge meetings (all teams together - and this is 100 or more people), technical debt analysis is carried out, plans are worked out for the design of the architecture and the work of all teams is synchronized.

Above the train level we have coordination between departments, directors, and the client. There is more borrowing from Lean Agile, but the same tools from Kanban are being saved. It analyzes the economic viability of the changes. Ideally, any changes go through a preliminary analysis where a measurable hypothesis about the upcoming change is put forward (for example, if we make an online store from a data center to the cloud, by quickly increasing capacity at the peak of seasonal sales we can increase the number of transactions by 10%) and then this hypothesis is either confirmed or not. For companies less than a billion dollars - this may be the very last floor. Work plans for 12-36 months are also created here (hello five years of quality, quantity, etc.)

Above the level of large systems is portfolio management. Distributed funds in various areas of business. Lean portfolio management is used, using the company's development strategy, directions are chosen from which you can get a return. It makes decisions about buying or merging with other companies. Creating new business areas, closing old ones. The budget is regularly adjusted and assigned (as opposed to quarterly or annual plans). For each component of the portfolio, a set of more or less standardized metrics is established and then everything is evaluated by them. As well as at the 3 previous levels there are special rituals for synchronization every two weeks (usually) - there is an exchange of statuses and key indicators.

At the head of the whole strategy. How it is defined - the framework does not describe.

pros

1. A significant number of very good tools (WSJF, Kanban, Gemba, etc)
2. The steps for SDLC are formalized and prescribed, starting from writing code (TDD is prescribed) ending with the execution of static scanning and CI / CD and feature toggle. Whether each of the practices is good or not is another matter, but at least there is a plan and everyone follows it.
3. The process can be understood, explained and implemented.
4. Each person in the framework of this process receives quite a strictly defined function.
5. Increases the transparency of the company for those who work in it.

disadvantages

1. Quite a long time to respond to the mismatch of reality with expectations
2. A huge amount of money and money is spent on communication and meetings.
3. Frequently recommended solutions within the framework are outdated.

Embed or not? I believe that if there is a choice, then no, it is better to reduce the dependence between departments and projects. And if there is no choice and you need to manage a huge project, then it is quite possible.