Two of the major frameworks gaining traction to enable organisations to scale agile practices across the enterprise are the Scaled Agile Framework (for enterprise) (SAFe) and Large Scale Scrum (LeSS). There are many similarities between the frameworks, with their core principles derived from Agile, Scrum and Lean, but they differ in some fundamental areas. After completing the Large Scale Scrum Certification and SAFe Program Consultant Certifications, coupled with my experiences in agile software development and agile change initiatives at enterprise scale, I’ve tried to capture some of those differences here.
One of the key differences is how the frameworks aim to tackle agile adoption. SAFe is a blueprint for the enterprise, it is well-defined and prescriptive, with a great deal of information available to practitioners including a set of training courses to assist with rolling out change. LeSS, on the other hand, aims to provide principles, rules and guidelines, and encourages practitioners to conduct experiments to discover what works for their organisation. SAFe looks at the whole system from the top down – defining roles and processes at three levels: portfolio, program, teams. LeSS looks from the inside out, starting with one Scrum team and expanding as teams are added.
Everything you need to be SAFe
SAFe is a fully-fledged framework for the enterprise and encourages you to implement the whole framework as a starting point, including the introduction of new roles, teams and working groups – even if your scale is limited to just one release train. When the system is up and running you may discover areas that can be omitted for your organisation or the level of scale required. At the team layer, Scrum is used as a building block for the framework, and new processes, roles, artefacts, and ceremonies are introduced above and around Scrum at the portfolio and program layers.
This means that in SAFe, while the guidance covers all aspect of the framework and encourages all areas to be implemented – it does mean that, through necessity, almost anything can be “optional” if it doesn’t suit your organisation or the scale you are working to.
LeSS is more
LeSS takes the opposite approach and suggests you “build your method up instead of tailoring it down”. In LeSS, nothing is optional – all components are mandatory for effective implementation. This is because LeSS is Scrum scaled, with only one additional ceremony (the Overall Retrospective). Scrum is the foundation and for each element they ask “Why is it there, and how do we achieve the same purpose on a larger scale”. The framework is more simple than SAFe and it relies more heavily on the practitioners’ understanding of core agile, lean and systems thinking concepts.
So is LeSS more? Well, like most things in agile, it depends on your context…
Bloated processes versus reliance on individual behaviours
If adopting SAFe, depending on your context and scale, there is the potential that some processes may be unnecessarily cumbersome for your needs. Too many people may be involved, the length of meetings too long, the cadence not fit for purpose. From my experience, this can mean that people are not talking to each other early and often, instead waiting for the ‘meeting’. Artefacts have a tendency to create “busy work” and the specification of roles and responsibilities can create dependencies and reliances that artificially inhibit flow.
However, without some of this formalisation in the framework, as per LeSS’s approach, more responsibility falls on individual behaviours to ensure that the right conversations are happening at the right time, involving the right people – and then that action is taken based on those conversations. While this is conceptually aligned with agile’s principles of self-organisation (individuals and interactions over processes and tools) and may be fine for organisations where members are experienced in agile, from what I’ve seen in larger organisations that are new to agile, or have teams with mixed previous experiences, it can also present major adoption challenges.
Regardless of the model implemented, the system must respect the principle of continuous improvement. With this being a focus, shortcomings of either model within your context can be improved. Bloated processes, artificial dependencies, and unnecessary work can be eliminated. Where communication or action is lacking – this can be addressed.
This is openly promoted within LeSS, using the Shu Ha Ri method.
- Shu — Follow rules to learn basics
- Ha — Break rules and discover context
- Ri — Mastery and find your own way
Focus on continuous improvement, or Kaizen, is also a principle of SAFe and so adaptation is encouraged, and necessary. However, opportunities for program wide improvement present less regularly.
Time required for adaptation
One of the key benefits that I can see in LeSS over my experience with SAFe is the more regular cadence for program-wide integration. SAFe has a program cadence of approximately 8-12 weeks which means that the first overall retrospective is held almost 2-3 months after kick-off. There are good reasons for this, considering the breadth of the stakeholder group and hence the investment required for the ceremony, but it does mean that there is no structured opportunity for all the teams to work on some of the key challenges in agile at scale – dependency minimisation and management and identifying effective team structures.
LeSS has an Overall Retrospective at the end of each sprint which is a great chance for the team as a whole to identify, triage and start to act on problems which affect flow. I believe that increasing the cadence of overall retrospectives when first adopting SAFe would be a great practice. Note that in both models, the reliance is on team members to be able to identify, articulate and then openly and honestly discuss any issues.
Lubricating the wheels of change
One of the key differences between the two models is the approach to change. Change Management is a challenge, particularly in larger organisations where changes to roles, responsibilities and job titles are more regulated. LeSS is a pure scaled version of Scrum, with a very small set of roles – Product Owner, Scrum Master, Developer. The lack of broader roles and responsibilities, whilst more effective from a flow perspective, potentially presents a major barrier to the introduction in the enterprise.
Many large organisations have vocal and influential Project Management Office and Architecture teams – SAFe aims to bring these stakeholders on the journey by providing them with roles in the framework and educating them about new ways of working. LeSS, on the other hand, presents more of an end state: where cadence and predictability have superseded traditional plan based management and architecture emerges from self-organising teams.
SAFe provides its practitioners with detailed training materials and an approach to adoption – SAFe Program Consultants teach their Leading SAFe course (for executives), their SAFe Scrum/XP course (for team members) and their SAFe Product Owner course (for product teams) as part of introducing a new Release Train. LeSS relies more on the practitioners’ experience and skills to support change initiatives, and aims to be simple and lean so that ideas emerge.
In my experience the skills and aptitude of the team and the nature of the environment will dictate which of these approaches is better – an adaptive and empowered team in an open environment will likely respond best to LeSS, teams in more traditional and structured environments with complex and tightly coupled legacy applications will likely respond better to SAFe.
Choosing your weapon
Whichever framework is selected, it should be viewed as a model to help get you started. Focus must remain on ensuring a working knowledge of the principles of the framework and the methodologies behind the framework, and a commitment to continuous improvement to make sure that the organisation is moving towards the ideal. There is nothing ‘wrong’ with LeSS or SAFe, they both present a major leap forward compared to traditional large batch, plan-driven software development. Choose the one that best fits your needs and then adapt it to your environment and people.
