A note on the various approaches to scaling Scrum.
LeSS was created by Bas Vodde and Craig Larman from practical experience in scaling up Scrum, see their Scaling Lean & Product Development (2008) and Practices for Scaling Lean & Agile Development (2010), and founded as the LeSS Company in 2014.
1. Large-scale Scrum is Scrum. Multiple-team Scrum, not multiple Scrum teams.
LeSS is not only about coordinating multiple teams to build one Product but also about transforming the organization by applying System thinking and lean thinking.
Nexus is a free extension to Scrum, coming from scrum.org themselves it is perhaps the lightest and uses the most scrum-compatible terminology. Nexus defines a Nexus Integration Team and practice which helps to bind together the work of 3-9 scrum teams working on a single Product Backlog to build an Integrated Increment. Nexus does not define the wider organisation structure or opine on how to run an Agile transformation project.
Both Scrum and Nexus should be implemented in their entirety:
Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
Although implementing only parts of Nexus is possible, the result is not Nexus.
Spotify “model” (Tribes, Squads, Chapters & Guilds)
Documented in a 2012 paper by Anders Ivarsson and Henrik Kniberg, role names from the Spotify model are now appearing in job adverts. The core activity is in co-located multi-disciplinary Squads with a horizontal dimension for sharing knowledge, tools, and code.
The Spotify approach adopts Poppendieck Lean principles for software development – ship a Minimum Viable Product and tweak it:
Think it, build it, ship it, tweak it.
The DSDM Agile Project Framework
DSDM is mature, practical and essentially free to use.
DSDM started in the UK in the early 1990s as a management framework around RAD development, and DSDM’s Arie van Bennekum was one of the Authors of the Agile Manifesto which started the shift from RAD to Agile.
DSDM has been tuned from decades of experience to provide a practical approach to project delivery in the real world.
DSDM’s approach and style has always been founded on an underlying ethos of common sense and pragmatism. It may be useful to clarify the meaning of these words:
Common sense – “sound practical judgment independent of specialised knowledge or training; normal native intelligence.”
Pragmatism – “action or policy dictated by consideration of the immediate practical consequences rather than by theory or dogma.”
People: The DSDM project framework defines roles and responsibilities rather than organisational structure:
DSDM roles don’t require hiring new people and expensive training and certification programs, but rather identifying within the current organisation who needs to do what for the project to succeed.
One person may perform several roles, depending on the size of the project and organisation, and is it not mandated how these roles fit into the organisational structure.
In this respect DSDM does not require a transformation project but recognises that the project needs to be delivered now within a real-world organisation.
Products: DSDM is quite clear about what products (including documentation) should exist when, who they are for, what roles should approve them and whether they are a milestone product or an evolutionary product which will be maintained and updated going forwards.
Scrum and Timeboxes: DSDM defines the project management process from business case to post-project. Within that the iterative development part of the project may be run as a DSDM Timebox or a Scrum Sprint, both of which have a lot of similarities if you look past the terminology.
DSDM has always recognised that an agile approach may not be applicable in every case and defines success factors and a suitability filter now called Project Approach Questionnaire.
SAFE SCALED AGILE FRAMEWORK
SAFE provides complete patterns for implementing Lean-Agile development at a variable number of levels defined as [Portfolio], [Large Solution (previously known as Value Stream),] Program, and Team.
SAFe was launched in 2011 and is continuously updated with 4.5 released in June 2017 as SAFe for Lean Enterprise reflecting the scope extending beyond the IT department. SAFe4.5 also covers processes for Lean UX, Scalable DevOps and Continuous Delivery amongst others.
SAFe is particularly in demand for its approach to Agile Transformation at the organisational level. A SAFe 4 Certified Program Consultant (SPC) is a SAFe implementation professional responsible for training leaders, change agents, consultants, and team members to drive a Lean-Agile transformation at enterprise scale. Key areas of competency include designing a SAFe implementation, launching and facilitating an Agile Release Train (ART), and extending the Lean-Agile portfolio by launching additional ARTs.
The methodologies above have different starting points or viewpoints for their approach which are not necessarily incompatible:
DSDM Agile Project Framework is a project-centric view of a project lifecycle – also applied to business initiatives not just IT projects. When applied to IT, management and budgeting processes which are heavily geared towards projects, may tend to lead towards costly replacement projects rather than Product evolution.
LeSS takes the Product management viewpoint with Whole Product Focus and Systems Thinking: “Customers want the product, not a part”, “Customers care about the overall cycle time and flow, not individual steps.”
Nexus shares the single Product backlog but focusses on the Team interaction necessary to achieve the common goal.
The Spotify approach adds the dimension of knowledge interchange and sharing of best practice across the organisation.
SAFe adds the Enterprise-level transformation and perhaps requires it: it might not be meaningful for an individual team leader or project manager to implement “SAFe” within their scope (though at team level Scrum is certainly compatible with SAFe), instead each department should have the management-level commitment and contribution to the Agile Release Train.
In 2001 the Agile Manifesto was written by representatives from Scrum, DSDM, XP and different leading methodologies.
In 2017 different practitioners came together again to create the Agnostic Agile Oath to confirm a commitment to focus on the end result rather than one methodology and to acknowledge that:
one framework is not the answer, and the ‘what’ and ‘how’ should be suited to customer context and to a wider strategic vision. – agnosticagile.org
Disclaimer: I am a community member of DSDM, I worked on DSDM pilot projects in the 1990s and produced the DSDM4 online manual in 2001.
I’ve omitted DAD (Disciplined Agile Delivery) and no doubt many other valuable and interesting points.
LESS-Nexus-Spotify-DSDM-SAFE: Which scaled Scrum? A note on the various approaches to scaling Scrum. LESS Large-Scale Scrum LeSS was created by Bas Vodde and Craig Larman from practical experience in scaling up Scrum, see their Scaling Lean & Product Development (2008) and Practices for Scaling Lean & Agile Development (2010), and founded as the LeSS Company in 2014.
