Which Agile Scaling Framework should you trust for your Distributed Agile Delivery?

Add the existing context of business demand for the same local talent in an already sparse resource pool and it’s clear that the CIO has a big decision to make. While the technology and tools have evolved to facilitate geographically distributed working, there are several popular scaled Agile frameworks to choose from. Which one is right for your organization?

What scaled Agile frameworks are out there?

The latest State of Agile report (14th Annual State of Agile Report, 2020) describes a number of methods and frameworks used for scaling Agile. However, for the purposes of this post, we will only be reviewing the most popular five, which account for over 60% of company approaches to scaling Agile. These are:

• Scaled Agile Framework (SAFe)
• Scrum of Scrums (Scrum@Scale)
• Enterprise Scrum
• Large Scale Scrum (LeSS)
• Disciplined Agile Delivery (DAD)

While each method is a separate take on scaling Agile, this blog focuses on how each of the five addresses the question of distributed Agile and its implementation within a large-scale enterprise.

Scaled Agile Framework (SAFe)

SAFe supports distributed Agile methods on a cultural and organizational level. It explains the need for teams and their members to be self-organizing so that there is a correct level of planning and trust on the part of each team member, ensuring they complete everything required for a successful delivery. Communication too is a strong focus, from Increment Planning and onwards throughout the project. SAFe also makes it very clear that to support distributed team members the correct infrastructure has to be in place. To this end it lists basic requirements from high bandwidth to the correct tools, as well as commitment to ceremonies and having over-lapping core work hours to support daily alignment, while also covering communication, work visualization and ideation.

You might opt for SAFe if your organization needs a prescriptive framework for how Agile should be scaled throughout the enterprise. This framework extends from the top portfolio level where leaders set the vision, financials and strategy, through to how to structure and combine Scrum teams into the most effective IT delivery approach.

Scrum of Scrums (Scrum@Scale)

While this framework does not define a formal stance on distributed Agile, it does recognize the benefits of non-co-located teams to “reach talent otherwise unavailable” and to add additional flexibility to an organization’s resource pool. However, co-location is always recommended for clearer communication and team alignment. Returning to the distributed Agile topic, the available solutions that would address this are not specific and, for the most part, are the same as those in the foundation of Scrum – but simply scaled up. An example of these are the daily ceremonies that are used for alignment and communication, only scaled up. So, it’s like the Scrum of Scrums, where one person from each Scrum can discuss inter-dependencies and align with wider teams.

Overall, the framework doesn’t provide much guidance for distributed Agile. However, it does suggest the need for organizations to organically acquire a new operating model and provides a very light model to achieve this through an Executive Action Team (EAT) for a successful Agile transformation. As such, while on the light side for distributed material, it does provide a key point on the need to evolve the operating model to support new ways of working.

Enterprise Scrum

Within Enterprise Scrum there is a mention of how teams and roles can be structured depending on size and this includes ‘virtual’ teams. Furthermore, the distribution of roles can be expanded beyond the Scrum team. For example the Business Owner and Scrum Coach roles, which are historically seen as individual roles, become more flexible, with the framework giving the option of assigning the role to many in one Scrum or even into whole separate teams, depending on the context and structure pattern. The framework does mention that culture and mindset are the most important aspects of Scrum and Enterprise Scrum. No process, framework or methodology is any good if it is not “powered by the will of people”, which to begin with is a challenge. Overall, the framework provides some light options for distributed teams and roles but is very generalized and does not go into much detail around when, why or how this distribution should be implemented.

Large Scale Scrum (LeSS)

Within LeSS, co-located teams are part of the framework structure, however, there is no requirement that all teams should be in the same geographical location. So, while there is no approach for a geographically distributed team, LeSS does make a strong reference for the need for strong communication between teams. There is also a strong recommendation for each team to take responsibility for understanding the intra-team dependencies. Solutions mentioned include the observance of sister-team stand ups and alignment meetings between teams. Another element that the framework suggests is the creation of a mentor community. This is where an ‘expert’ resides within a team and teaches any interested members how a certain component works across the teams, so that they can leverage the overall knowledge.

The LeSS framework does provide multi-national organizations with a direction on the coordination of multiple distributed teams. However, it fails to address the challenge of distribution within a single team. Ultimately, it is a useful framework for organizations not challenged by sparse resource pools, or that already have dedicated teams in place.

Disciplined Agile Delivery (DAD)

Unlike the previous frameworks, DAD gives a good insight into the benefits of geographic distribution and how it goes hand-in-hand with growing deliverable complexity (e.g. requiring resources that might not be readily available for co-location). And, while the recommendation is co-location as best practice, especially for teams, it does cover strategies on how to reduce the risk associated with distributed teams. The framework provides options on how to organize teams around a single deliverable (e.g. breaking down a team by components, features, etc.), providing advantages and disadvantages for each option. Furthermore, team tools are also mentioned to facilitate information sharing and long-distance communication (even if some of the published tools are a little outdated). This gives the framework the most robust guidance around distributed Agile and covers a number of distance working scenarios, as shown by the IT Project Success Rates Survey (Scott Ambler & Associates, 2018).

Conclusion

Each framework provides guidance for a successful distributed IT delivery to a lesser or greater extent. SAFe provides strong guidance in distributed planning and is the preferred model for scaling due to its didactic approach. However, when looking at overall execution of distributed Agile, DAD needs to be taken into consideration for its further depth into ways of operating distributed teams. Overall, however, there are still questions that frameworks do not answer when looking at what structural changes a business will have to go through to support this way of working. Until recently, co-location had been the preferred way of working to limit delivery challenges. However, as Agile scales up and technology further breaks down distance, it is no surprise that some distributed teams are already perceived to perform better than co-location (Scott Ambler & Associates, 2018).

Going forward, CIOs  will need to consider how best to ensure they have the correct Op-Model to support distributed Agile. What’s clear, is that due in part to the impact of Covid-19, the paradigm is shifting and distributed Agile is certainly here to stay.

What’s next?

Read our blog Industrial and agile: How to be both? for recommendations on successfully transforming into a distributed Agile model.

If you’re interested in finding out more about Capgemini’s view on the future of global Agile, take a look at the Inventive IT paper Simultaneous transformation. It discusses how organizations are embracing distributed Agile and transforming with an inventive operating model.

---

Author

Patricio Herrera Perez Ipar

Management Consultant

Capgemini Invent