For large software development projects involving up to a 100 to several 100s 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 (SAFeTM) 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”
See below the overview pictures for SAFe (www.scaledagileframework.com) and LeSS (less.works).
Right off the bat, we 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 only the original Scrum roles of PO, SM and Team.
As an example, SAFe offers the role of Program 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.
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, the Product Owner team, which provides a pool of POs for every Scrum (large or small scale) effort, and 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. This 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, 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 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 PI demo at the end of each PI, and a general Inspect and Adapt session, which is a scaled up version of a sprint retrospective.
In contrast, LeSS remains faithful to just the usual sprints of Scrum, with the following additions:
- Sprint Planning happens in 2 stages. The 1st 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 8 story points to 1 staff-day.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 to prioritizing projects (represented as Epics in SAFe) for the organization and budgeting for them in an Agile manner. In its latest version, SAFe 4.0, there is an additional, optional, level for Value Streams below the Portfolio level – it is usually relevant to projects with hundreds, or thousands of participants.
In contrast, LeSS does not delve into portfolio management: it only offers techniques that can be compared to the Program and Team layers 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, LeSS 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.
- 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, 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. However, it does show 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, albeit at the cost of perhaps appearing too process-heavy. However, it is perhaps more palatable for a typical traditional large organization 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.