The following is the first in a series of blogs aimed at providing a concise comparison of the most salient features of the leading Agile scaling frameworks. Hopefully, this information will help you choose the framework that is most suitable for your organization to meet their business needs.
For large software development projects involving up to a 100 to several 100’s of software developers, analysts and testers, the inherent techniques of agile methodologies such as Scrum or XP prove inadequate for effectively managing the progress of such enormous effort.
In this blog, we look at a quick comparison between two leading frameworks for scaling the Agile approach for large software development projects: Scaled Agile Framework (SAFe 4.5) and Large-Scale Scrum (LeSS). Each has its strong points that may fit different organizational situations of large software product development.
Let’s get started: the “Big Picture”
Right off the bat, you can see that while the SAFe Framework appears more comprehensive, it also appears more process-heavy. In fact, the inventors of the LeSS framework are proud of its acronym indicating less process, less artifacts, and fewer roles, remaining faithful to having mainly the original Scrum roles of PO, SM and Team.
For example, SAFe offers the role of Product Manager, who is in charge of setting the priorities and overall scope of functionality to be delivered by a Program containing many Agile teams. The Product Owner in SAFe performs the usual Scrum role for up to a couple of Agile Teams that typically work from a similar/shared backlog.
In contrast, LeSS offers the regular Scrum role of Product Owner (PO) for up to 8 Teams. This is because in LeSS, the PO is not a liaison with the end-Customer: the Teams get to interact directly with the end-Customer to understand the details of the requirements, giving the PO the opportunity to focus on the overall priorities and scope for up to 8 Scrum Teams.
Hence if an organization can afford the opportunity for the Agile Teams to interact directly with the end-Customer LeSS can be a good fit in this particular aspect. Otherwise, SAFe can accommodate both the Team-direct and the liaison-PO situations.
The Inventors of LeSS very much believe that culture follows structure. To that end they offer LeSS not just as a practice to scale up the Scrum approach, but as a direct impetus for change of organizational structure. The picture below shows what LeSS advocates for organizational structure for up to 8 Scrum Teams working together to develop a software product in order to provide what an Agile culture needs from an organization to succeed.
In this picture, you can see that there are no functional departments (e.g. development vs. testing) or a PMO. Instead, in addition to the Scrum Teams, there is the Head of the Product Group, which LeSS views (as it views all other managers similar to the “Toyota Way”) as a teacher of those reporting to him/her, there is the Product Owner team that provides a pool of PO’s for every Scrum team (large or small scale) effort, and then there is the Undone Department.
The latter is a curious thing. In LeSS, a permeating theme is that the Teams are supposed to do everything needed to put a high-quality software product in the hands of end-Customers: from analysis to development to testing to packaging, all while coordinating with other Teams. All of that is represented in the Definition of Done of the Teams. But it may take the Teams a few years to mature to that set of comprehensive capabilities. Hence the Undone Department is a placeholder for resources that fill in for whatever the Teams are yet to be able to do (e.g. DevOps) until the Teams mature.
In contrast, SAFe does not advocate drastic organizational change as emphatically as LeSS. It presents its approach for adoption even with the current organizational structure, and lets the organization take its time deciding when it may want to restructure to be more efficient with Agile. That’s not to say that LeSS presents its approach as an “all or nothing deal” – it just emphasizes structural change in the organization more strongly than SAFe does.
Differences in Planning
SAFe stipulates that sprints should be grouped in sets of 4-5 consecutive sprints, each set being called a Program Increment (PI). And while the Teams (and the Product as a whole) are expected to demonstrate incremental achievements at the end of each sprint (i.e. completed Stories), it is at the end of a PI that complete “Features” of the software product are expected to be available. SAFe, however, maintains the option of releasing on-demand any time during a PI with the Features, or even Stories, that happen to be complete at that point in time.
Planning in SAFe happens in a 2-day session at the beginning of each PI, in addition to the usual sprint planning at the beginning of each sprint. In the PI planning session all the Teams working together in what SAFe calls an Agile Release Train
(ART) attend to commit to delivering a set of Features for the PI, and to have each Team present a plan showing which stories (which are children of Features in SAFe) the Team plans to complete for each sprint in the PI. Finally, in addition to the usual sprint demos and retrospective, SAFe has an overall Inspect and Adapt Workshop (analogous to the Sprint Demo and Retrospective) at the end of the PI which includes a PI demo, Quantitative Measurement, and a Problem Solving Workshop that dives into deeper root cause analysis than a normal Sprint Retrospective.
In contrast, LeSS remains faithful to just the usual sprints of Scrum, with the following additions:
- Sprint Planning happens in 2 stages. The1st stage is attended by 2 representatives of each Team, which do not usually include the Team’s Scrum Master. This stage decides which items from the common Product Backlog each Team will develop. It also has cross-team estimations to unify the estimation numbers. This is in contrast to SAFe, which suggests normalizing cross-Team estimations by equating a story point to a story that would take ½ day to code and ½ day to test.The second stage of sprint planning is the same as sprint planning in regular Scrum.
- Each sprint review is held with all Teams as a “science fair”, where each Team has a station to demonstrate its accomplishments for the sprint. Attending stakeholders can visit the stations in which they are interested.
- The Sprint Retrospective is held in two stages: the first being the same as regular Scrum; the second is for the overall progress of the software product being developed by the Teams.
As represented in the top level of the SAFe “Big Picture” shown earlier, SAFe offers a comprehensive approach of prioritizing “projects” (represented as Epics or a set of related Epics in SAFe) and budgeting for them in an Agile manner. In its latest version, SAFe 4.5, there is an additional, optional, level for Large Solutions (shown below the Portfolio level in the aforementioned diagram) – it is usually relevant to projects with hundreds, or thousands of participants comprising multiple Agile Release Trains.
In contrast, LeSS does not delve into Portfolio Management: it only offers techniques that can be compared to the Program and Team levels of SAFe.
2 Versions of LeSS
LeSS has two versions: the one we saw earlier for 2 to 8 Teams, and Less Huge for more than 8 Teams, depicted below.
LeSS Huge is formed by having several regular LeSS frameworks working in parallel with each other. The most notable addition in LeSS Huge is making each regular LeSS belong to a separate Requirements Area with its own Area Product Owner (APO) under the overall Product Owner.
If you were thinking “Well, isn’t an ART the same as a Requirements Area?” you’d be partially right; a similarity is that the Product Backlog relationship to the Area Product Backlog is analogous to the relationship of a Portfolio Backlog to a Program Backlog in the sense that items on the former are coarser grained than items on the latter. However, one of the differences is that an APO is still only one for 8 Teams, whereas the SAFe PO covers very fewer Teams.
Other Differences between LeSS and SAFe
LeSS can appear to offer one seemingly shocking advice (which is not offered by SAFe): Don’t scale! (But if you have to scale, use LeSS J). It advocates that even very large software products can be built more successfully by a relatively small Team of co-located master programmers and testers. They cite at least one example on their website (less.works) of a huge software project that followed a torturous path to completion. When the overall project director was asked if he were to do it again, what would he do differently, he said that he’d pick the 10 best programmers and have them build it all. I can cite a more recent example with the Affordable Care Act, where a traditional government contractor put an enormous number of resources on the project that failed miserably. Later, about a dozen master developers and testers were put together in a house to work on fixing the ACA, which they did within a period of several months. (See http://www.theatlantic.com/technology/archive/2015/07/the-secret-startup-saved-healthcare-gov-the-worst-website-in-america/397784/)
- Whereas SAFe is generally tool-neutral from a specific vendor perspective, SAFe does encourage early and often automation as much as possible, utilizing the system team to support that.
LeSS, on the other hand, strongly recommends that you not use automated tools until after your organization becomes quite proficient with LeSS, opting instead to use manual resources like very big white boards and wall charts. Otherwise, LeSS declares that if you automate a mess, you get an automated mess. And even after the Teams become proficient with LeSS, it recommends that you only use open source tools, which you can easily jettison if they don’t work out for you, without losing high-dollar investments in them.
- SAFe takes a more customary view of the role of Scrum Master. In SAFe, the SM is pretty much a permanent role with the Scrum Team and does a lot of intra-Team and inter-Team coordination. In LeSS, the SM is first and foremost a Teacher. He can fade away from the day-to-day Team dynamics once the Team becomes proficient in the Scrum and LeSS approaches.
- In SAFe: Epics, Capabilities, Features and Stories are explicitly handled as integral parts of the SAFe backlogs. LeSS, on the other hand, only talks about coarser vs. finer grained Backlog Items, staying faithful to Scrum by relegating Epics, Features and Stories as instruments of XP, which is not part of Scrum proper.
The quick comparison between LeSS and SAFe in this blog is by no means comprehensive. Yet it shows SAFe to be more wide-ranging in offering processes and roles to handle the development of software from the highest profile levels down to the individual Agile Team for large-scale Agile efforts, while making those roles and levels configurable according the organization’s needs. Furthermore, for a typical traditional large organization it is perhaps more palatable to begin to adopt SAFe than LeSS, since the latter strongly advocates some major changes to the structure of the organization as early as possible in the adoption of LeSS.