This chapter covers project management at an organizational level, referred to as Scaled Delivery. It compares project and portfolio management with scaled Agile approaches, including Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), and Scrum@Scale. We discuss the complexities of large-scale project delivery, including enterprise-level prioritization, project and product portfolio management, organizational alignment, and related organizational structures, as well as organizational culture and mindset. We also cover the concept of organizational Agile transformation and successful patterns (pilots, change management models, communities of practice), as well as teamwork and innovation at the enterprise level.
In Chapter 9, we covered the topic of delivery beyond software products. We demonstrated that project management covers all areas of work, including marketing and finance, human capital management, the service industry, and beyond. It covers cultural aspects of project management and organizational change management, leadership, and influence without authority. It also addresses traditional management areas, such as budget management (“beyond budgeting” principle), risk management via impediment resolution, and procurement management.
In this chapter, we will describe Agile at scale. So far, we’ve primarily spoken about Agile mindset and Agile implementation at a team level or in specific organizational functions, such as IT, marketing, HR, Finance, and so on. This final chapter of this book is focused on organizational agility. It covers organizational culture, organizational alignment, dependency management, and the role of leaders in Agile organizations. It also describes primary Agile frameworks, such as Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Disciplined Agile (DA), Nexus, Spotify model, and Scrum@Scale.
What Does Agile at Scale Mean?
Software development teams have proven that implementing Agile frameworks, like Scrum and Kanban, lets them deliver solutions to customers faster, with more predictability and higher quality, and gives them the ability to react quickly based on customer feedback. Implementing Agile at the individual team level is relatively easy, but it is much more challenging to implement Agile across multiple teams in a large organization.
Agile at scale is defined as the ability to drive Agile at the organizational level by creating Agile culture and mindset and applying Agile principles, practices, and outcomes throughout the whole organization. This is extremely important because in large organizations, it is almost impossible to succeed in Agile implementation without scaling agility. Let’s review the following example.
A software delivery team decided to implement Scrum at the team level in their company, a large bank. In their previous organizations, three out of seven members worked on Scrum teams, and they were excited about team empowerment and collaboration with their customers in an Agile environment. They shared their experience with other team members and introduced them to the Agile Manifesto and Scrum Guide. Initially, other team members were skeptical and did not think that team self-organization would work in a large financial services company. However, they decided to be open-minded and try it out. The first thing they did was to get support from their functional managers, who did not mind them trying some Agile practices as long as the team members delivered high-quality software on time and kept them in the loop. They asked for weekly updates and offered help and advice to the team members. This was a helpful first step.
Next, team members selected one of the developers, Anthony, as their part-time Scrum Master. Anthony was excited because he was always curious about the whole end-to-end process of software delivery, was people-oriented, and was interested in customer outcomes. He immediately set up the basic Scrum cadence every two weeks: Sprint planning for two hours on the first day of a Sprint with their stakeholders and customer representatives, daily Scrum meetings for 15 minutes every day, Sprint Review session for an hour at the end of the Sprint, and a Retrospective to finish the Sprint by discussing the opportunities for the team to improve their practices. He also added weekly product backlog refinements sessions for an hour each so that the team focuses on creating a high-quality product backlog with the user stories and technical tasks defined at least one Sprint in advance.
At that point, it was clear to the team that they needed a dedicated Product Owner. They had a business analyst on the team, Anna, whom they asked to become a Product Owner. However, Anna did not feel that she was ready for this role. The Product Owner needs to own the product working with multiple stakeholders, including most senior ones. This person needs to be empowered to make product decisions, work with marketing and sales to promote this product, and realize commercial benefits. Anna suggested during their Scrum meeting to reach out to their business stakeholders to find someone with the right level of experience.
To remove this blocker, Anthony reached out to their internal business stakeholders, and they delegated one of the subject matter experts, Lena, to join the team as the Product Owner. Lena did a great job making herself available to the team members, and they together established a consistent and successful delivery pipeline. They invited stakeholders and their functional managers to the Sprint Review sessions, where they discussed the outcomes of the Sprint and demoed working software that they were able to deliver during the Sprint. The stakeholders provided immediate responses and suggestions, which Lena frequently prioritized for the upcoming Sprint so that when the stakeholders came back in two weeks, they saw that their suggestions and ideas were already implemented. This created a short feedback loop and built a lot of trust with the business.
The team, which selected the team name “Transformers” because they were transforming the way of working and delivering software to their customers, was providing weekly updates about the number of user stories and tasks completed, bugs resolved vs. created, and functionality delivered to their managers. In four Sprints, functional managers said they did not need those reports because they could see all up-to-date information in Jira, the tool that the team selected to manage their work. Without this overhead, the team became even more productive. This did not mean that everything was perfect. Sometimes, they would get a blocker that they did not expect with a new tool, the solution that had to be tweaked based on security review, and other reasons, and miss on their Sprint commitment. They learned not to get upset with it and turn every challenge into an opportunity and to discuss these concerns and inefficiencies in their Retrospective to find ways to do it better next time.
As a side product of this transition, team members were happy and committed. They felt that rather than getting tasks, they were given a direction and the freedom to make their choice in terms of implementation details, sequencing and planning their work, and self-organizing their team delivery. They also felt that there was almost no overhead in the way they managed their work compared to their prior experience of weekly management reports with RAG (red-amber-green) project status and a lot of explanations they had to provide. They worked at a sustainable pace vs. their prior weekend heroics and were motivated by showing their work to the users and hearing their direct appreciation and feedback. Compared to high attrition on other teams within the organization, no team member has left since their Agile adoption started, and on the opposite, multiple people within the company heard about their team and were reaching out to them, indicating that they’d like to join.
- 1.
Management required long-term plans with every activity detailed out, with timelines and deliverables listed up front with their red, amber, or green (RAG) status. The Transformers team’s iterative delivery reports listing features delivered and planned for one full quarter ahead were not seen as sufficient or informative, as management struggled with interpreting burndown charts and roadmaps.
- 2.
Legal and compliance departments were hard to engage with less than four-to-eight-week notice, so many features, while they were delivered within a short time frame, were not being released awaiting legal or compliance review. Once reviews were provided, there were frequent changes requested, at which point a set of user stories would go back into the upcoming Sprint, disrupting Sprint structure and challenging incremental delivery.
- 3.
There was a similar pattern with software dependencies on other teams that did not practice Agile delivery. Even though Transformers did their best to decouple features they delivered from a software architecture standpoint, they did not build software in a vacuum. Whenever there were integration requirements, shared data structures, or other consumer services delivered by their peers, they had to be part of the long-term (over one quarter) planning efforts and engage in multihour planning discussions while committing to deliverables they would have to produce months ahead. Those efforts were rarely fruitful, in their experience, as these plans would change within weeks after planning based on things they learned as they engaged in writing code.
In addition to all these challenges, the attitude toward Transformers within the organization was not that positive. Some of their peers thought they were just trying to stand out and make life more difficult for others around them. Some of the managers were clearly annoyed by their lack of enthusiasm related to advance planning. It was easy to understand – the managers had to plan a year ahead based on the annual budget cycle, so incremental planning was seen by them as an impediment. The Chief Software Architect was taking Transformers’ newfound agility almost personally because she saw it as a threat to the Architecture Board that she chaired. The concept of emergent design in an Agile environment challenged the whole existence of this group and all related processes, as she thought. Their organization’s CTO used to say that “perception is reality,” and the perception was that there is no planning in Agile, no architecture, and no collaboration outside of the team. Everyone felt that Agile was the wrong way for their organization to go, and the Transformers team was restructured with team members individually assigned to different projects.
Agile at scale is seen as the organizational approach to agility, which allows to maximize benefits of Agile delivery and avoid challenges, similar to the one experienced by the Transformers. Scaled Agile implementations changed the whole company culture to support the value of the Agile Manifesto: focus on people, business outcomes, being comfortable with iterative planning and iterative delivery, business and technology working together to delight their customers, prioritizing value delivered over reporting about the work being done, including team-level collaboration between cross-functional teams, and others. This can be achieved in many different ways, which have been summarized in several well-known Agile scaling frameworks. Let’s review those frameworks one by one and then compare them based on the type of organization those are most suitable for.
Topic for a Group DiscussionIn groups, discuss the challenges that Transformers faced in their company. What could they have done to overcome those challenges? What possible scenarios do you see for the future of this team and the whole organization? Which of those scenarios are most likely?
Summarize your discussion in the following format and order your list by probability from the most probable outcome to the least one:
Scenario ID | Description | Driving Factors | Impact | Probability (%) |
- 1.
Scaled Agile Framework (SAFe)
SAFe is the world’s leading framework for scaling Agile across the enterprise. Used by hundreds of the world’s largest organizations, SAFe sustains and drives faster time to market, dramatic increases in productivity and quality, and improvement in employee engagement. SAFe is designed to help businesses continuously and more efficiently deliver value on a regular and predictable schedule. It provides a knowledge base of proven, integrated principles and practices to support enterprise agility [1].
Dean Leffingwell and Drew Jemilo released SAFe in 2011 to help organizations design better systems and software that meet customers’ changing needs in large organizations. Since the need to respond to changing market conditions increased rapidly, new frameworks such as SAFe emerged to help businesses improve solution delivery across their enterprises. SAFe is currently one of the most popular scaled Agile delivery frameworks and continues to evolve. The case studies include American Express, FedEx, Chevron, MetLife, Lockheed Martin, PepsiCo, Bosch, Cisco, Capital One, NHS, Intel, Vantiv, Philips, and many others [2].
- 2.
Large-Scale Scrum (LeSS)
According to its creator, Craig Larman, Large-Scale Scrum (LeSS) isn’t new and improved Scrum. And it’s not Scrum at the bottom for each team, and something different layered on top. Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly Agile frameworks, LeSS is a “barely sufficient methodology” for high-impact reasons. This framework is based on the 2002 Craig Larman’s book Agile and Iterative Development [3].
LeSS was invented in 2005 by Craig Larman and Bas Vodde, who worked with clients to apply their framework for scaling Scrum, Lean, and Agile development to big product groups. Their case studies include JPMorgan Chase, Ericsson, BMW Group, Bank of America Merrill Lynch, Nokia Networks, John Deere, Alcatel-Lucent, and many other large companies in multiple industries across the world [4].
- 3.
Disciplined Agile Delivery (DAD)
DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices invented by advocates of Agile software development, including Scrum, Agile modeling, Lean software development, and others. DAD evolves the enterprise way of working (WoW) in a context-sensitive manner with this people-first, learning-oriented hybrid Agile approach [5].
The primary reference for Disciplined Agile Delivery is the 2012 book Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise written by Scott Ambler and Mark Lines [6]. In particular, DAD has been identified as a means of moving beyond Scrum. It provides a mechanism that not only streamlines IT work but, more importantly, enables scaling. Since 2012, DAD has been redefined as a “toolkit” to help teams make context-appropriate decisions. This toolkit could be considered a super of all other available frameworks, including Lean, Scrum, Kanban, and even parts of scaled ones, such as LeSS and SAFe. It includes techniques, such as Agile modeling and test-driven development. Some analysts do not even consider it a separate scaled approach, more of a comprehensive set of tools and techniques [14].
- 4.
Spotify Scaling Model
The Spotify model isn't a framework, as Spotify coach Henrik Kniberg noted since it represents Spotify's view on scaling from both a technical and a cultural perspective. The Spotify model champions team autonomy so that each team (or Squad) selects their framework (e.g., Scrum, Kanban, Scrumban, etc.) This model was made popular by Henrik Kniberg and Anders Ivarsson [9].
The secret to the popularity of this model lies in two primary factors: First, organizational topology is one of the most confusing aspects of scaling Agile, and the concepts of tribes, squads, chapters, and guilds provide a scaled repeatable solution to it. Second, the model preserves an Agile mindset with team self-organization, collaboration across the organization, the bottom-up mindset, and team empowerment. It introduces continuous improvement without constraints, which other, more prescriptive frameworks do not offer.
- 5.
Nexus
The Nexus model developed by Scrum Alliance is becoming increasingly popular. Nexus is a simple framework that implements Scrum at scale across multiple teams to deliver a single integrated product. It can be applied to three to nine Scrum teams that are working in a common development environment and are focused on producing a combined increment every Sprint with minimal dependencies.
“Nexus promotes value instead of expansion. It is a scaling framework that does not say that much about stakeholders. It guides the Scrum teams on how to prosper and resolve coordination issues.”
A cross-functional Scrum team is the prerequisite of Nexus. Possessing knowledge and having worked in a Scrum environment gives you an edge to work with Nexus. It promotes and ensures transparency, continuous integration, and relentless improvement.
“Working in a shared environment where work is constantly being integrated into one final product guarantees continuous integration.” This eliminates the need for a Scrum of Scrums meeting, which is an essential part of other scaling frameworks [12].
- 6.
Scrum@Scale
Scrum@Scale framework developed by Scrum Alliance is a natural extension of the Scrum framework. Its goal is to empower organizations to achieve business agility and deliver value to their customers. It is a framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex problems while creatively delivering products of the highest possible value. These “products” may be hardware, software, complex integrated systems, processes, services, etc., depending upon the domain of the Scrum teams.
Scrum@Scale enables the transformation of every division, department, and service in any organization and can efficiently coordinate an unlimited number of Scrum teams through its use of a “scale-free” architecture. Scrum@Scale naturally extends the core Scrum framework and was created by Jeff Sutherland, the co-creator of Scrum [15].
The following is a detailed review of each of these frameworks.
Scaled Agile Framework (SAFe)
According to the 14th State of Agile Report by CollabNet [10], the Scaled Agile Framework (SAFe) continues to be the most popular scaling method cited by respondents, increasing 5% over last year and outpacing the number two choice, Scrum@Scale, by 19%.
SAFe provides guidance for all the levels of the enterprise that are actively engaged in solution development: Team, Program, Large Solution, and Portfolio. The result is greater alignment and visibility across the organization, connecting the business strategy to execution, enabling better business results faster and with a higher degree of predictability and quality.
The Scaled Agile Framework (SAFe) is a set of organization and workflow patterns intended to guide enterprises in scaling Lean and Agile practices. SAFe is made freely available by Scaled Agile, Inc., which retains the copyrights and registered trademarks.
SAFe promotes alignment, collaboration, and delivery across large numbers of Agile teams. It was developed by and for practitioners by leveraging three primary bodies of knowledge: Agile software development, Lean product development, and systems thinking.
- 1.
Take an economic view.
- 2.
Apply systems thinking.
- 3.
Assume variability; preserve options.
- 4.
Build incrementally with fast integrated learning cycles.
- 5.
Base milestones on an objective evaluation of working systems.
- 6.
Visualize and limit work in progress, reduce batch sizes, and manage queue lengths.
- 7.
Apply cadence (timing); synchronize with cross-domain planning.
- 8.
Unlock the intrinsic motivation of knowledge workers.
- 9.
Decentralize decision-making.
- 10.
Organize around value.
The primary reference for the scaled Agile framework was originally the development of a “big picture” view of how work flowed from product management through governance, program, and development teams, out to customers. With the collaboration of others in the Agile community, SAFe is progressively refined. The framework continues to be developed and shared publicly, with an academy and an accreditation scheme supporting those who seek to implement, support, or train others in the adoption of SAFe. The SAFe framework website features the “big picture” graphic [11]. It provides a visual model of the framework and is the primary user interface to the knowledge base. Each icon of the image is clickable and offers access to extensive SAFe guidance. The configurations support a full range of development and business environments and the foundational principles, values, mindset, roles, artifacts, and implementation elements that make up the SAFe framework.
Starting from its first release in 2011, already five major versions have been released [10]. While SAFe continues to be recognized as the most common approach to scaling Agile practices (at 30% and growing), it also has received criticism for being top-down and implementing enterprise-level governance that limits team self-organization.
Large-Scale Scrum
LeSS consists of the LeSS Principles, the Framework, the Guides, and a set of experiments. All of these are also available on the following website: http://less.works. LeSS is different from other scaling frameworks in the sense that it provides a very minimalistic framework that enables empiricism on a large scale, which enables the teams and organizations to inspect-adapt their implementation based on their experiences and context. LeSS is based on the idea that providing many rules, roles, and artifacts and asking the organization to tailor it down is a fundamentally flawed approach, and instead, scaling frameworks should be minimalistic and allow organizations to fill them in.
Large-Scale Scrum is Scrum
Empirical process control
Transparency
More with less
Whole product focus
Customer-centric
Continuous improvement toward perfection
Systems thinking
Lean thinking
Queuing theory
LeSS offers two configurations: Basic LeSS for two to eight teams (10–50 people) and LeSS Huge for more than eight teams (50–6000+ people).
- 1.
One requirement area at a time focused on a requirement area within the larger product
- 2.
Gradually expanding the scope of work of the team, Definition of Done, and the product definition
This allows an organization to build team experience with LeSS, expand throughout a product area, and gain management support before scaling LeSS throughout the whole organization [12].
Basic LeSS focuses on the team and the key Scrum roles: the Scrum product owner who is responsible for the product vision and direction, Scrum development teams who are responsible for product creation and delivery, and Scrum Master who helps the team with continuous improvement and coaching. One area that LeSS expands upon is the role of the manager and how they assist the team with removing barriers for continuous improvement and autonomy.
The Area Product Owner of LeSS Huge assists and coordinates with the overall Product Owner and is critical to bridging the business needs with the technical team. The Area Product Owner does the same work as the Product Owner, but with a more focused and limited scope for the team they support. The Area Product Owner specializes in customer-focused tasks and acts as Product Owner for product-focused feature teams.
Disciplined Agile Delivery (DAD)
- 1.
DAD picks up where Scrum leaves off. DAD describes how all Agile techniques fit together, going far beyond Scrum, to define a full Agile solution delivery life cycle. Like Scrum, the DAD addresses leadership, roles & responsibilities, and requirements change management. Unlike Scrum, DAD doesn’t stop there; it also addresses other important aspects of software development such as architecture, design, testing, programming, documentation, deployment, and many more. In short, DAD provides a much broader understanding of how Agile development works in practice, doing a lot of the “heavy process lifting.”
- 2.
DAD is pragmatic. The DA toolkit provides choices, not prescriptions, enabling teams to easily tailor a strategy that reflects the situation. To do this effectively, teams need to understand the process-oriented choices they have and what the trade-offs are. DAD makes these choices explicit through its process-goal-driven approach.
- 3.
DAD supports both Lean and Agile ways of working (WoW). DAD supports several delivery life cycles including a Scrum-based Agile life cycle, a Kanban-based Lean life cycle, two continuous delivery life cycles, a Lean Startup-based exploratory life cycle, and a Program “team of teams” life cycle. Teams find themselves in unique situations, and as a result, one process size does not fit all. Even in small companies, some teams are taking an Agile approach, some a Lean approach, and some combinations thereof.
- 4.
DAD is based on empiricism. For several years Scott Ambler, Mark Lines, and many other contributors to DAD worked in or visited hundreds of enterprises around the world in a wide range of industries and environments. DAD, and the DA toolkit in general, captures the proven strategies adopted by these organizations, describing the strengths and weaknesses of each strategy, and providing guidance for when and when not to apply them.
- 5.
DAD provides a solid foundation from which to scale Agile. DAD supports the successful scaling of Agile and Lean techniques in several ways. First, its full delivery lifecycles and breadth of software development advice answers how to successfully apply Agile in practice. Second, its goal-driven approach provides the required flexibility for tailoring your Agile process to meet the challenges faced by Agile teams working at scale. Third, DAD builds in many foundational concepts required at scale, including DevOps, explicit Agile governance, and enterprise awareness.
- 6.
DAD describes strategies for organizing large and distributed teams. DAD describes several strategies for organizing large or geographically distributed teams. It describes a range of options for scaling the approach to Agile and Lean software development.
- 7.
DAD teams deliver solutions, not just software. DAD recognizes that the software we develop runs on hardware, which may need upgrades, and is supported by documentation. The stakeholders may also need to evolve their business processes, and sometimes even their organizational structures, to address the new needs of the situation that they face. DAD teams deliver solutions that comprise software, hardware changes, supporting documentation, improved business processes, and even organizational changes.
- 8.
DAD is evolving. DAD practitioners are continuously learning about and experimenting with new Agile and Lean strategies. These learnings are constantly being applied to evolve DAD” [7].
DAD promotes the “Shu-ha-ri” Agile learning strategy originating from martial arts and starting by building a strong foundation (Shu – learn). As people’s knowledge deepens, they progress to a stage where they can demonstrate a deeper understanding of the range of strategies available to them (Ha – reflect). Finally, once they’ve achieved a proficiency (Ri – transcend) in disciplined Agile, they can extend and improve upon disciplined Agile techniques by sharing their earnings with others.
“Discover A Goal-Driven Approach to process-related Decisions
Disciplined Agile teams are guided through choosing their way of working (WoW) via straightforward process goal diagrams. Better process decisions lead to better outcomes. Because each Agile team is unique, the DA toolkit helps organizations find a way to effectively tailor the way that they work to best face that situation.
Adapt for Each Situation: Guided Continuous Improvement (GCI)
By understanding that every practice has trade-offs and works well in some situations and poorly in others, the DA toolkit helps organizations identify the right process for the moment at hand.
Unlock the Capacity to Scale Agility as an Enterprise
A Disciplined Agile Enterprise (DAE) can sense and respond swiftly to changes in the marketplace with organizational culture and structure that facilitates change within the context of the situation that it faces” [8].
Spotify Scaling Model
The model, described previously in Chapter 6, is called by the company’s name (Spotify), where Agile coach Henrik Kniberg and his colleagues came up with several groundbreaking ideas [9]. They were very clear in stating that they did not invent this model. Spotify, like any other company, was evolving fast, and this article provided a snapshot of their current way of working. This model allowed Spotify to become a fascinating company that transformed the music industry. In its first six years, the company generated 15 million active users and over 4 million playings. They referred to this product as a “magical music player in which you can instantly find and play every song in the world.” When Alistair Cockburn, one of the signatories of the Agile Manifesto, visited Spotify, he’s reported to say: “Nice – I’ve been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see” [9, p. 1]. So what was this model that allowed Spotify to grow exponentially while disrupting the global music industry?
- 1.
Squad: A squad is similar to a Scrum team and is designed to feel like a mini-startup. They are a cross-functional team; that is, they have all the required skills to design, develop, test, integrate, deploy, and release to production. Similar to Scrum, they are a self-organizing team. At Spotify, it was not prescribed whether a squad should use Scrum, Kanban, or any other framework; this was up to the team members to decide. Each squad includes a Product Owner who makes prioritization decisions and serves as the voice of the customer and an Agile Coach who helps them identify impediments and coaches them to continuously improve their processes.
- 2.
Tribe: A tribe is a collection of squads that work in related areas, such as the music player or back-end infrastructure. The tribe is seen as the “incubator” for the squad mini-startups. Tribes have a large degree of freedom and autonomy. Each tribe has a tribe lead who is responsible for providing the environment for the squads within the tribe so that the collaboration is successful and all squad-level dependencies are coordinated. Tribes are sized based on the concept of the “Dunbar number,” which says that most people cannot maintain a social relationship with more than 100 people or so. When groups get too big, there are more bureaucracy, constraints, and management overhead – everything that is referred to as “waste” in Lean.
- 3.
Chapters: Chapters and Guilds are created to avoid the loss of “economies of scale.” This includes two categories: reusability when several squads need the same tool or build similar functionality (e.g., a payment system for all Spotify products) and best practices sharing between professional groups, for example, test automation or new programming languages and technology stacks. This challenge is resolved by having Chapters and Guilds, which serve as a glue of keeping the company together. A Chapter is a group of people having similar skills and working within the same general competency area who meet regularly to discuss their area of expertise and their specific challenges, for example, the testing chapter, web developers, or the back-end chapter. The chapter lead is the line manager for their chapter members, who are responsible for professional development, compensation, and promotions.
- 4.
Guilds: A guild is a more organic and wide-reaching community of interest, a group of people that want to share knowledge, tools, code, and practices across the whole organization, for example, an Agile Coach guild. This allows for company-wide cross-pollination in building the best practices between different tribes.
Spotify Scaling Model
Many analysts, including the creators of this model, do not consider Spotify an Agile scaling model. Spotify implemented a scalable matrix organizational structure well suited for Agile companies; however, this does not cover the “ways of working,” which are described in the “Spotify Engineering Culture” videos reviewed in Chapter 9. Together, this would create a framework; however, it was never described comprehensively and has not been positioned as one. This was not the intent of Henrik Kniberg and his colleagues, who wanted to share Spotify’s best practices rather than building a prescriptive model. They made it very clear that while this is the way Spotify worked at the time this was shared, it was relevant to a specific company at a specific point in time, and others should use it as an inspiration for building an Agile mindset and Agile culture, rather than a prescriptive framework.
Nexus
The Nexus Agile scaling model created by Scrum Alliance is designed for a combination of three to nine Scrum development teams working off a single product backlog used by all of the teams, and it builds on the foundations of Scrum. The core of the Nexus framework is the integration team that consists of a Product Owner, a Scrum Master, and one or more members from each team. The purpose of the integration team is to coordinate the work of all the Scrum teams to be sure their completed work intermeshes together and is in harmony and not in conflict. The need for an integration team becomes even more essential the larger the number of Scrum teams all working on the same project using the same product backlog. The stated goal of Nexus is to minimize cross-term dependencies and integration issues [17].
Nexus is a framework for developing and sustaining scaled product delivery initiatives. It builds upon Scrum, extending it only where absolutely necessary to minimize and manage dependencies between multiple Scrum teams while promoting empiricism and the Scrum values.
The Nexus framework inherits the purpose and intent of the Scrum framework as documented in the Scrum Guide (www.Scrumguides.org). Scaled Scrum is still Scrum. Nexus does not change the core design or ideas of Scrum, leave out elements, or negate the rules of Scrum.
Nexus adds to or extends the events and artifacts defined by Scrum. The duration of Nexus events is guided by the length of the corresponding events in the Scrum Guide. They are timeboxed in addition to their corresponding Scrum events. Nexus events are attended by whichever members of the Nexus are needed to achieve the intended outcome of the event most effectively. A Sprint in Nexus is the same as in Scrum. The Scrum teams in a Nexus produce a single Integrated Increment.
It helps the Scrum teams forecast which team will deliver which product backlog items.
It identifies dependencies across those teams.
Where needed, each Scrum team will continue their own refinement in order for the product backlog items to be ready for selection in a Nexus Sprint Planning event. An adequately refined product backlog will minimize the emergence of new dependencies during Nexus Sprint Planning.
The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum teams within a Nexus for a single Sprint. Appropriate representatives from each Scrum team and the Product Owner meet to plan the Sprint. Nexus retains the Daily Scrum to identify any integration issues and inspect progress toward the Nexus Sprint Goal. Appropriate representatives from the Scrum teams attend the Nexus Daily Scrum, inspect the current state of the integrated Increment, and identify integration issues and newly discovered cross-team dependencies or impacts. Each Scrum team’s Daily Scrum complements the Nexus Daily Scrum by creating plans for the day, focused primarily on addressing the integration issues raised during the Nexus Daily Scrum.
The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the done Integrated Increment that the Nexus has built over the Sprint and determine future adaptations.
Since the entire Integrated Increment is the focus for capturing feedback from stakeholders, a Nexus Sprint Review replaces individual Scrum team Sprint Reviews. Nexus Sprint Retrospective is held to plan ways to increase quality and effectiveness across the whole Nexus. The Nexus inspects how the last Sprint went with regard to individuals, teams, interactions, processes, tools, and its Definition of Done. In addition to individual team improvements, the Scrum teams’ Sprint Retrospectives complement the Nexus Sprint Retrospective by using bottom-up intelligence to focus on issues that affect the Nexus as a whole. The Nexus Sprint Retrospective concludes the Sprint [18].
Scrum@Scale
Scrum, as originally outlined in the Scrum Guide, is a framework for developing, delivering, and sustaining complex products by a single team. Since its inception, its usage has extended to the creation of products, processes, services, and systems that require the efforts of multiple teams. Scrum@Scale was created to efficiently coordinate this new ecosystem of teams. It achieves this goal by setting up a “minimum viable bureaucracy” via a “scale-free” architecture. Dr. Jeff Sutherland, co-creator of Scrum, developed Scrum@Scale based on the fundamental principles of Scrum, Complex Adaptive Systems theory, game theory, and object-oriented technology.
Scrum@Scale is described in the Scrum@Scale Guide [15]. According to the Guide, “Scrum, as originally outlined in the Scrum Guide, is focused on a single Scrum Team being able to deliver optimal value while maintaining a sustainable pace. Since its inception, the usage of Scrum has extended to the creation of products, processes, and services that require the efforts of multiple teams. In the field, it was repeatedly observed that as the number of Scrum Teams within an organization grew, two major issues emerged:
The volume, speed, and quality of their output (working product) per team began to fall, due to issues such as cross-team dependencies, duplication of work, and communication overhead
The original management structure was ineffective for achieving business agility. Issues arose like competing priorities and the inability to quickly shift teams around to respond to dynamic market conditions
Linear scalability: A corresponding percentage increase in delivery of working product with an increase in the number of teams
Business agility: The ability to rapidly respond to change by adapting the initial stable configuration
Scrum@Scale helps an organization to focus multiple networks of Scrum Teams on prioritized goals. It aims to achieve this by setting up a structure which naturally extends the way a single Scrum Team functions across a network and whose managerial function exists within a minimum viable bureaucracy (MVB)” [15].
Scrum@Scale introduces two cycles, Scrum Master Cycle and the Product Owner Cycle, and brings them together to establish successful delivery of value. It is a lightweight organizational framework based on a network of teams. This framework addressed the complex adaptive problems of a large organization while creatively delivering products of high value to the customer. These products could be physical, digital, complex integrated systems, processes, services, and any others.
According to Agile Alliance, Scrum@Scale has been successfully implemented at implementing these concepts at GE, 3M, Toyota, Spotify, Maersk, Comcast, AT&T, and many other companies [16].
Other Frameworks
There are multiple other Agile proprietary frameworks, such as Crystal Clear, cPrime’s Solutions for Agile Governance in the Enterprise (SAGESM) [13], Agile Portfolio Management (APM), Enterprise Scrum, Lean Management, and others. Each of them is adopted by 4% or less of all companies scaling Agile.
Comparison of Scaled Agile Frameworks
In the 14th State of Agile Report, the following statistics are provided for Agile scaling methods and approaches: “The Scaled Agile Framework® continues to be the most popular scaling method cited by respondents (35% this year compared to 30% last year). As a percentage of all responses, SAFe® outdistances the next nearest response, Scrum of Scrums, by 19%” [10, page 14].
Agile scaling frameworks, methods, and approaches according to the 14th State of Agile Report [10]
General organizational resistance to change
Not enough leadership participation
Inconsistent processes and practices across teams
Organizational culture at odds with Agile values
Inadequate management support and sponsorship
Lack of skills and experience with Agile methods
Insufficient training and education
Lack of business/customer/Product Owner availability
The pervasiveness of traditional development methods
Fragmented tooling and project-related data/measurements
Minimal collaboration and knowledge sharing
Regulatory compliance or government issues
Comparative Overview of Agile Scaling Frameworks
Type and size of the organization | Methods and practices adopted | Specifies portfolio management and business prioritization | Establishes a collaborative dependency management mechanism | Professional association that endorsed the framework | |
|---|---|---|---|---|---|
Scaled Agile Framework (SAFe) | 50–124 people in an Agile Release Train, scaling indefinitely | Scrum, Kanban, Lean, DevOps, XP Practices | In detail: Lean portfolio management and business prioritization based on Value Stream Mapping (VSM) | Advanced dependency management starting with long-term planning | Scaled Agile Academy |
Large-Scale Scrum (LeSS) | LeSS Huge allowed for thousands of people | Scrum primarily | By scaling product management | Via structured ongoing collaboration | LeSS practitioner groups |
Disciplined Agile Delivery (DAD) | 200 people or more | Full toolbox: Scrum, Agile modeling, Unified Process, XP, TDD, Agile | Focuses on technical practices | Via collaboration | Project Management Institute |
Spotify Scaling Model | Around 300 people | Allows the team to make a choice of any Agile framework | Via Tribe-specific accountability and the role of product management | Organic | N/A |
Scrum@Scale | No limitations imposed; however, successes are limited to several hundred | Scrum | Product Owner collaboration | Via Scrum of Scrums | Agile Alliance |
Nexus | Three to nine Scrum teams | Scrum | Product Owner collaboration | Advanced dependency management via an Integration Team | Scrum Alliance |
Five key questions to review:- 1.
What are the most popular Agile scaling frameworks?
- 2.
Which framework resonates with you and why?
- 3.
Why do you think SAFe is the most popular Agile scaling framework at this time?
- 4.
What is the benefit of using an Agile scaling framework vs. implementing Scrum or Kanban?
- 5.
Which Agile scaling framework is best suited for a medium-size company with ten Agile teams? For a large company with 100+ employees and multiple product lines?
Organizational-Level Agile Transformation
- 1.Implement organizational-level Agile transformation as a change management activity, in accordance with John Kotter’s organizational change principles [20]:
✔ Create a sense of urgency
✔ Build a guiding coalition
✔ Form a strategic vision and initiatives
✔ Enlist a volunteer army
✔ Enable action by removing barriers
✔ Generate short-term wins
✔ Sustain acceleration
✔ Institute change
- 2.
Start by defining clear drivers for change and measurements of success with the organizational leadership. Agree to the Agile scaling roadmap, and define timelines and expected outcomes. OKR framework is a helpful mechanism in defining success.
- 3.
Get people within the organization excited about scaling Agile. Explain the value of self-organization and cross-functional teams. Share experiences from other companies of similar size in their Agile transformation at scale and set up Scaled Agile training for the model of your choice that fits the organization best.
- 4.
Start initiatives that address major pain points. This is easy to do with a value stream. Show the business impact of scaling agility is faster incremental delivery, business and technology collaboration, team ownership, and positive outcomes.
- 5.
Show success of these initiatives. Be vocal and communicate on multiple levels. Create internal case studies. Launch metrics and make progress at scale transparent to everyone. Celebrate successes and build Champions groups and communities of practice, which organically support the scaling efforts.
- 6.
Sustain acceleration via expanding scaled Agile practices throughout the organization, with the help of the Champions team. Ensure there is a well-defined career path and career progression for all Agile roles (Scrum Master, Product Owner, any other new role, such as Agile Product Manager or Agile Coach) and define the learning path for people in these roles.
- 7.
Enhance and continuously improve Agile scaling culture and practices via Retrospectives, a short feedback loop with your customers, metrics review with Agile organizations, continuous contact with the leadership, and an Agile mindset.
Topic for a Group DiscussionBased on what you know, which Agile scaling framework would the Transformers team from the case study in this chapter use most effectively and how would their Agile scaling roadmap look like?
To summarize this chapter, Agile is mostly impactful at scale, that is, in large organizations. However, special mechanisms are required to build and sustain Agile implementation at scale, such as dependency management between teams, consistent prioritization mechanisms, alignment of value streams and Agile delivery teams, and many others. Agile scaling frameworks discussed in this chapter provide different ways of accomplishing this goal while maintaining team-level agility.
Key Points
- 1.
Agile at scale is defined as the ability to drive Agile at the organizational level by creating Agile culture and mindset and applying Agile principles, practices, and outcomes throughout the whole organization.
- 2.
Agile at scale is seen as the organizational approach to agility, which allows to maximize benefits of Agile delivery and avoid challenges, similar to the one experienced by the Transformers. Scaled Agile implementations change the whole company culture to support the value of Agile Manifesto: focus on people, business outcomes, being comfortable with iterative planning and iterative delivery, and business and technology working together to delight their customers. This also includes prioritizing value delivered over reporting about the work being done, team-level collaboration with cross-functional teams, and others. This can be achieved in many different ways, which have been summarized in several well-known Agile scaling frameworks.
- 3.
SAFe is the leading framework for scaling Agile across the enterprise. Used by hundreds of the world’s largest organizations, SAFe sustains and drives faster time to market, dramatic increases in productivity and quality, and improvement in employee engagement. SAFe is designed to help businesses continuously and more efficiently deliver value on a regular and predictable schedule. It provides a knowledge base of proven, integrated principles and practices to support enterprise agility
- 4.
According to its creator, Craig Larman, Large-Scale Scrum (LeSS) is about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly Agile frameworks, LeSS is a “barely sufficient methodology” for high-impact reasons and provides a toolbox for scaling Agile delivery.
- 5.
Disciplined Agile Delivery (DAD) enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of Agile software development, including Scrum, Agile modeling, Lean software development, and others. DAD allows to evolve the enterprise way of working (WoW) in a context-sensitive manner with this people-first, learning-oriented hybrid Agile approach.
- 6.
The Spotify Scaling Model was not invented by Spotify and was never defined as a model; however, Spotify built practices that allowed for rapid scaling based on value delivery. This model is being implemented by many organizations of different sizes, based on the organizational matrix of squads and tribes that allow scaling Agile delivery while maintaining autonomy. In the Spotify model, squads and tribes provide autonomy, while chapters and guilds provide economies of scale.
- 7.
The Nexus Agile scaling model created by Scrum Alliance is designed for a combination of three to nine Scrum development teams working off a single product backlog used by all of the teams, and it builds on the foundations of Scrum. The core of the Nexus framework is the integration team that consists of a Product Owner, a Scrum Master, and one or more members from each team. The purpose of the integration team is to coordinate the work of all the Scrum teams to be sure their completed work intermeshes together and is in harmony and not in conflict. The need for an integration team becomes even more essential the larger the number of Scrum teams all working on the same project using the same product backlog. The stated goal of Nexus is to minimize cross-term dependencies and integration issues.
- 8.
Scrum@Scale was created to efficiently coordinate this new ecosystem of teams. It achieves this goal by setting up a “minimum viable bureaucracy” via a “scale-free” architecture. Dr. Jeff Sutherland, co-creator of Scrum, developed Scrum@Scale based on the fundamental principles of Scrum, Complex Adaptive Systems theory, game theory, and object-oriented technology.
- 9.
In the 14th State of Agile Report, the following statistics are provided for Agile scaling methods and approaches: “The Scaled Agile Framework® continues to be the most popular scaling method cited by respondents (35% this year compared to 30% last year). As a percentage of all responses, SAFe® outdistances the next nearest response, Scrum of Scrums, by 19%.”
- 10.
No matter which Agile scaling strategy is being used, there are some principles that need to be always maintained. These include leadership buy-in, defining metrics and success criteria up front, continuous improvement via organizational-level Retrospectives, and focus on dependency management and Agile culture.