Scaled Agile Frameworks – Coordinating Multiple Agile Development Teams 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. At K&C, we’ve seen big demand for our ‘controlled agile’ variation on fixed price agile. 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)

SoS (Scrum-of-Scrums)

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.

Scaled Agile Frameworks: A History of Development

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.

A Brief Overview of the Scaled Agile 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.

The Scaled Agile Framework (SAFe)

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.

SAFe Strengths:

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 SAFe Risks/Concerns: Multiple hierarchy levels

Not “agile enough”

Rigid 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.

Large-Scale Scrum (LeSS)

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. 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. LeSS Advantages: 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 LeSS Risks/Concerns: “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.

Scrum-of-Scrums (SoS)

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 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. SoS Advantages: Simplicity

Does not require additional roles

Low cost of implementation SoS Risks/Concerns: 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.

Which Scaled Agile Framework is Most Popular?

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.

How to choose your scaled agile framework?

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.

Scaled Agile – Key Takeaways