Lecture
Scaled Agile Framework (also known as SAFe) is an agile software development framework that allows agile methodologies to be used in large teams of more than 50 people. The framework was created by Dean Leffingwell at the company Scaled Agile .
Scrum, Extreme Programming and other agile development methods traditionally do not go beyond the team level. In contrast, SAFe provides a single, unified view of the work being done from the point of view of company executives, allowing them to drill down into details as needed to analyze and identify patterns. SAFe consists of three levels: the team level, the program level, and the portfolio level.
A team in SAFe can consist of 8-10 people and is cross-functional, meaning it has all the competencies needed to develop software, from gathering requirements to deployment. Several teams create what SAFe calls a "release train" built around a single program. This project or program of projects corresponds to a separate line item in the organization's budget. For the organization's executives, it is a small project that can be discussed on its own. By a portfolio, SAFe means the full set of programs that use the entire organizational budget allocated to software development. According to SAFe, it is recommended to create a single portfolio management office responsible for the development strategy, investments and budgeting of the set of projects .
SAFe version 4.0 added a division into two types of framework implementation: three-level and four-level. The three-level approach is used for smaller teams of no more than 100 people, or for several programs of similar size that do not require significant interaction. The four-level approach is suitable for solutions that require the involvement of several hundred specialists, and in addition to the three standard levels it includes a fourth level called the "value stream" .
SAFe is a framework . It is not a set of rigid rules. Like any good framework, it requires thoughtful tailoring to your specific situation. The documentation available at Scaled Agile clearly emphasizes this dynamic.
There is one "rigid" aspect in SAFe, and rightly so. The 10 SAFe principles are considered immutable. As mentioned above, these principles are considered best practices from the world of Lean and Agile. These guiding statements are principles, not practices . SAFe explicitly allows individualized practices as long as they are not at odds with the principles.
Scaled Agile Framework( SAFe ) is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. Along with Large-Scale Scrum (LeSS), Disciplined Agile Delivery (DAD) and Nexus, SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team. SAFe is provided free of charge by Scaled Agile, Inc., which retains the copyright and registered trademarks.
SAFe promotes alignment, collaboration and delivery across large numbers of agile teams. It was developed by practitioners and for practitioners, drawing on three primary bodies of knowledge: agile software development , lean product development and systems thinking .
Originally, the main aim for the scaled agile framework was to develop a common view of how work flows from product management (or other stakeholders ) to customers through management , program and development teams. In collaboration with other members of the agile community it was gradually refined, and then first formally described in a 2007 book. The framework continues to be developed and published, with an academy and an accreditation scheme supporting those who seek to adopt, sustain or train others in adopting SAFe.
Since the first release in 2011, five major versions have already been released [10], and the latest version, version 5.0, was released in January 2020. [11]
Although SAFe is still considered the most widespread approach to scaling agile practices (at 30% and growing) , it has also been criticized for being too hierarchical and inflexible. [15]
SAFe is a layer cake of various Agile methods. At the bottom level is almost traditional SCRUM, with typical two-to-three-week sprints and teams of 3-9 people including the Product Owner. All the typical rituals are there, from the daily meeting, the standup, to the post-mortem, the retrospective. There is, however, one key difference. The team stops being a fully functional independent module. And the sprint stops being an independent slice of time with a complete life cycle. Sprints are combined into Program Increments, usually consisting of 5 sprints. That is, if in classic SCRUM we built something the customer does not like, we make a course correction in the next sprint, whereas in SAFe we keep heading toward the cliff until the end of the Program Increment, in the worst case for the next 4 sprints (of course, I am exaggerating).
At the next level we have trains, the so-called Agile Release Trains. To manage the 5-sprint periods, new roles appear: the system architect (the one who owns the architecture, meaning it is no longer the team), the product manager (the one who manages the product, rather than the Product Owner, who goes to the PM for advice), and the RTE, the very same PMP from the distant world of waterfall. Some practices from Kanban are applied here, in particular the board and the way of assigning priorities, and overall the principle of measuring the historical performance of teams (velocity) is retained, projecting what will be built by the end of the time period, as opposed to the approach of making estimates and setting deadlines for an already fixed scope. One of the innovations is that the last sprint of the 5 is declared organizational, and during it huge meetings are held (all the teams together, which means 100 or more people), technical debt is analyzed, plans are made for working out the architecture, and the work of all the teams is synchronized.
Above the train level we have coordination between departments, directors, and the customer. Here there is more borrowing from Lean Agile, but the same Kanban tools are kept. This is where the economic feasibility of changes is analyzed. Ideally, any change goes through a preliminary analysis in which a measurable hypothesis about the upcoming change is put forward (for example, if we move an online store from a data center to the cloud, then by quickly scaling 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 under a billion dollars, this may be the topmost floor. Work plans for 12-36 months are also created here (hello, five-year plans of quality, quantity, and so on).
Above the large-systems level comes portfolio management. Funds are allocated among the various lines of the business. Lean portfolio management is used: based on the company's development strategy, directions are chosen from which a return can be obtained. Decisions are made here about buying or merging with other companies, creating new lines of business and closing old ones. The budget is regularly adjusted and reallocated (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 against them. As at the 3 previous levels, there are special rituals for synchronization, usually every two weeks, where statuses and key indicators are exchanged.
Strategy comes first. How it is defined, however, the framework does not describe.
Should you adopt it or not? I believe that if you have a choice, then no: it is better to reduce the dependencies between departments and projects. But if you have no choice and need to manage a huge project, then it is quite acceptable.
There is nothing in SAFe that even remotely resembles RUP. SAFe is Agile on steroids, scaled for the enterprise. RUP is a bridge between Waterfall and Agile. SAFe has no outdated phases or gate reviews. Frankly, the only thing SAFe and RUP have in common is that both are product development frameworks that help teams succeed. And that is a good thing.
SAFe represents advanced, evolved, mature Agile thinking, for the entire enterprise.
Development teams typically refine their backlog two to three iterations ahead, but in larger organizations the product marketing team needs to plan its market commitments and customer conversations well in advance. [16] They often work at a very high level, 12 to 18 months out, and then plan three months of work jointly with the teams. [17] Development teams will still do detailed refinement two to three iterations ahead, and only put detailed task plans in place for the next iteration. [18]
While development teams have a number of structures that define how they should be agile, there is very little of this for management. SAFe provides many of the same principles, such as creating cross-functional groups, for the groups that deal with more abstract levels of responsibility and planning (product and portfolio). [19] SAFe has also been criticized for combining too many disparate practices. [20]
In Scrum, the Product Owner is expected to take responsibility for the full product lifecycle, including the return on investment of development decisions as well as performance in the market. In large-scale development, the organization wants visibility into many backlogs, for example from a Product Manager. [21] Although SAFe assumes that the Product Owner role coincides with Product Management, it has nevertheless been criticized for separating Product Owners from the development organization. [22]
Agile frameworks are intended to give the development team the ability to be autonomous and free to work out how they work. SAFe recognizes that at the scale of many dozens or hundreds of development teams, complete self-organization of groups becomes increasingly chaotic. [23] It therefore imposes some constraints on this, so that where teams work on the same product, their results can be better synchronized for a joint release, although this is one of the areas in which SAFe has been criticized. [21] [22]
The SAFe planning cycle recommends including an additional iteration after a release, so that teams can improve their practices and be ready for the next planning stage. Earlier releases of SAFe also designed this as a hardening iteration, that is, to stabilize or harden the product before release. This was driven by the difficulties of working with large integration environments, in which dependencies meant you could not test everything until the very end. SAFe was criticized for this because it represented an element that hindered agility or was Waterfall-like, but it fit the minimum 90-day steps, which make up 13 weeks, and if you run two-week sprints you need six of them plus a week of planning or a hardening cycle. [24] This is not included in the latest releases of SAFe.
According to its authors, SAFe is based on ten core concepts that derive from existing principles of Lean and Agile, as well as from observations: [25]
SAFe version 5.0 has four configurations: Essential, Portfolio, Large Solution and Full: [26]
Scaled Agile offers certifications covering different areas and levels of knowledge. [27]
Scrum of Scrums
RUP (Rational Unified Process)
Scrums
Comments