Agile development is a software development methodology that has been embraced as a highly effective antidote to the workflow bottlenecks that cost organisations huge amounts of time and money. But many organisations have more, sometimes many more, than just one agile software development team working on different parts of a larger project. The failure to effectively synchronise the workflows of multiple agile development teams leads to exactly the same kind of expensive bottlenecks as were all-too frequent pre-agile. In this article we’ll delve into the details of these scaled agile frameworks to coordinate multiple teams, which is best suited to which conditions and a practical guide to the best practice implementation.
The established scaled agile frameworks that can, correctly employed, hugely increase the output and cost efficiencies of multiple agile software development teams are:
-SAFe (Scaled Agile Framework)
-DAD (Disciplined Agile Delivery)
-LeSS (Large-Scale Scrum)
Each of these are approaches is tailored the end result of more efficient and profitable day-to-day management of people, tasks and projects. But the conditions under which each will be the most effective methodology vary. Let’s explore each of these distinct scaled agile frameworks, setting out their strengths and weaknesses and the kind of agile development project they are best suited to in greater detail.
Innovation, development and evolution have been demonstrated to show notable acceleration in the context of a stressful ‘needs must’ pressurised environment. War has brought untold misery to humanity. However, it is also no coincidence that it, and just the threat of war, has also been the catalyst for a huge percentage of the most significant technological innovations in the history of human civilisation.
While agile software development teams and their management are fortunately rarely forced to work within a military context, they do often work under significant pressure. And pressure situations that have thrown up the need to find the most effective solution to avoiding productivity bottlenecks have historically led to the evolution of new scaled agile frameworks that deal better with the particular context.
Since the publication of the Agile Manifesto in 2001, countless agile software development teams have been trained on, and work to an Agile-based approach. But the first iteration of the agile approach focused on small software development projects involving a single team.
The 2007 publication of “The Enterprise and Scrum” by Ken Schwaber was a response to the growing adoption of agile by larger companies and the application of the methodology within the context of larger, more complex software development projects. More specific scaled agile frameworks that addressed the particular needs of different multi-team development projects followed with 2008 publication of the LeSS (Large-Scale Scrum) methodology by Larman and Bodde, followed in 2011 by Dean Leffingwell’s SAFe (Scaled Agile Framework). These scaled agile frameworks focus on synchronising multiple teams working on the same project as well as the integration of support teams using the Kanban methodology.
*Kanban is a visual workflow management methodology pioneered by Toyota in the 1940s. The highly visual qualities of a Kanban approach facilitates better communicate on what work must be done and when. It also standardises cues and refines processes, reducing waste and maximising value.
Agile development scrum frameworks are used in complex environments where cause and effect are not always immediately obvious and outcomes unpredictable. The Kanban approach is used for complicated systems based on rules and deterministic processes. Both can be used, or combined within a scaled agile framework. Let’s take a closer look at these different frameworks.
Each of the scaled agile frameworks has its particular strengths and inevitable weaknesses. But which best suits the different kinds of project that your agile software development teams might work on at different moments? Let’s profile the 4 usual suspects, breaking down their key qualities, strengths and weaknesses. Specific development project circumstances might also mean the best methodology might be blend of the approaches and techniques typical to the different scaled agile methodologies so don’t be afraid to do so where appropriate.
SAFe promises big corporations with big development projects a "big picture" scaled agile framework “from the box” It is one of the most popular scaling solutions for projects that involve more than one agile development team – usually at least several. The SAFe scaled agile framework is, however, widely considered to be resource and cost hungry in terms of the level of technical expertise it demands.
-Integrated set of engineering practices
-Standardisation of planning and execution process synchronisation between a large number of agile development teams
-Definition and standardisation of roles in large scale enterprises with multiple levels of hierarchy
-Quick launch without changing company's structure
-Possibility to choose Agile framework (Scrum, Kanban, XP, etc) on the agile development team level
-Multiple hierarchy levels
-Not "agile enough"
Use Cases For A SAFe Scaled Agile Framework
Intel implemented the SAFe scaled agile framework between 2012-14 in order to scale 5 agile software development Scrum teams to 33 between 2012 and 2013 and then to 170 Scrum teams by 2014. Development was completed over 2-week sprints and 8 Release Trains (ART) were deployed within only 2 months.
Hewlett Packard, Swisscom, Cisco, Tomtom, Sony, Fitbit, KLM, Philips are just some of the other big names that to have adopted the SAFe agile scaling framework in their companies.
When & where to apply the SAFe Agile Scaling Framework
SAFe is recommended for big companies who work with multiple project portfolios.
LeSS represents a throwback to the roots of the Scrum framework and the Agile approach. It focuses on flattening the hierarchy, removing communication inefficiencies. A PO (product owner) (or Area PO in the case of LeSS Huge) is always in direct contact with the different agile development teams and guides them from a business strategy perspective. The LeSS approach promotes the creation of all-round feature agile software development teams as opposed to functional silos, allowing teams to deliver business value independently.
One important issue to mention: LeSS adoption requires investment in organisational change and the education of individuals as well as an Agile mindset shift on a personal level.
-Minimal set of rules
-Strong Product Ownership scaling potential
-Facilitates an innovative, open-minded and motivated environment
-Promotes strong principle alignment
-Provides distinct models for medium and large organizations: LeSS and LeSS Huge
-"Radically agile" approach
-Opposition often encountered from middle-management jostling for influence
-Difficult to integrate in big traditional organisations with multiple layers of hierarchy
Use Cases For A LeSS Scaled Agile Framework
Interestingly, one of the biggest and best examples of LeSS adoption is that of Nokia Networks. It was initiated in 2005 by Craig Larman and Bas Vodde, who originally developed the LeSS framework, via a Scrum pilot. Nokia subsequently adopted LeSS at an organizational level in 2007, incorporating agile software development teams totalling circa. 500 people across two R&D sites. Nokia’s was a LeSS Huge scaled agile framework deployed “by the book” with Requirement Areas, Area Product Owners, Feature Teams, etc.
Other notable companies that have adopted LeSS and LeSS huge scaled agile frameworks include Huawei, Ericsson, JP Morgan Chase, Bank of America, UBS and Telecom Australia.
When & where to apply the LeSS scaled agile framework
LeSS is recommended for medium-sized companies working on their own product or start-up, or the R&D departments of larger enterprises. As it focuses on feature teams instead of functional teams, the LeSS approach means agile software development teams are able to work faster.
SoS or Scrum-of-Scrums was the first agile scaling framework and dates back to 2001 and the birth of agile as a software development methodology. Following daily scrum meetings, teams’ ambassadors or scrum masters gather for a further meeting referred to as a scrum of scrums or meta-scrum.
SoS focuses on cross-agile development team dependencies for established Scrum teams. The methodology is not considered a scaled agile framework approach in the true sense.
-Does not require additional roles
-Low cost of implementation
-Limitations in scaling and documentation
-Imperfect solution to inter-team dependencies on a larger scale
-Possibility of roll-back towards status meetings
Use Cases For A Scrum of Scrums (SoS) Scaled Agile Framework
The first documented instance the Scrum agile methodology being scaled was at IDX Systems in 1996, 5 years before the Agile Manifesto was even published. IDX’s approach was to turn the entire organization into the kind of interlocking set of agile software development team Scrums the later became known as the Scrum-of-Scrums framework. Every part of the organization was team-based, including the management team, which included VPs, directors and architects.
When & where to apply the SoS scaled agile framework
SoS is only recommended for small organisations with a small number agile development teams.
Currently, the SAFe Scaled Agile Framework is the most used of the four most popular methodologies.12th State of Agile data indicates that 30% of all scaled agile methodologies adopted by organisations in 2018.
As agile development is iterative & incremental, it is strictly context-based and the most effective framework to adopt will be different depending upon the particular situation. When choosing a scaled agile framework, it is advisable to take a flexible approach, choosing a skeleton of basics and principles that can then be adapted to the exact case.
One of the best examples of how a company tailored a scaled agile methodology to their specific needs is that of Spotify, the Stockholm music streaming start-up that ‘disrupted’ the legacy music industry
Spotify scaled agile framework case study
Spotify identified a number of elements of the Scrum framework that weren’t working well for them. So they decided to break some Scrum roles, artifacts and events. That resulted in their own tailored scaled agile framework (often referred to as the ‘Spotify framework’).
However, while the Spotify Agile framework is definitely a great example of how to tailor a scaled agile framework to the needs of a specific context, copy and pasting it would be a mistake for most organisations. Why? There are several complications which make it a difficult methodology to integrate without wholesale organisational reform. One of the complications is the need to set up a ‘squad’ (an independent group of people, self-empowered but working together in the same location).
In most cases, the best solution for an enterprise-level organisation with multiple agile development teams will be to opt for an ‘off the shelf’ scaled agile framework.
In summary, since agile development doesn't naturally scale well, large organisations tend to scale Scrum to an Enterprise Level. And that’s the basis for all scaled agile frameworks. Scaled agile frameworks bring numerous benefits to large corporations and other organisations that need to coordinate multiple agile development teams. By placing the emphasis on collaboration, transparency and trust among agile development teams and management, scaled agile frameworks can significantly boost employee engagement, improve productivity, speed up time to market and generally lead to better quality.
However, to achieve maximum benefit, ensure you’ve chosen the most appropriate scaled agile framework for your business. This is, however, complicated by the fact that there is no “one size fits all” approach. SAFe is holistic, but it comes with mulitple levels of hierarchy, and as a result, can be rigid; LeSS embodies a minimalistic set of rules and lets you create an innovative, open-minded and motivating environment but big organisations with several layers of hierarchy will find fully adopting it difficult. SoS is simple and cheap to implement but is limited when it comes to scalability and documentation.
All thing considered, which one these scaled agile frameworks would you choose? Not sure? K&C has a wealth of experience from the hundreds of agile development projects we’ve worked on across the full spectrum of scale and complexity. That experience can help you choose the best scaled agile framework on the basis of your needs and the particular context. Give us a call.