Scaling Scrum: Mission Impossible or a walk in the park!

Introduction

What does scaling Scrum mean? Scaling Scrum is a challenge that many enterprises face due to multitude of factors – growing complexity of the projects, changing needs of the organization, increase ROI, need to justify investment, or simply to appear to be following a truly Agile method. Whatever the motivation or the reason behind trying to scale Scrum, enterprises quickly discover along their journeys that scaling Scrum is actually quite different from initial implementation of Scrum. And, realize that it is quite difficult indeed. While the initial implementation of Scrum would be fairly simple and not demand much, the implementation of Scaled Scrum is anything but simple.

A single instance of Scrum implementation has a straightforward path – 1 scrum team that takes work from the product backlog, performs the necessary sprints in accordance with Sprint cadence to create an usable increment of product at the end of Sprint, adds unfinished or newly discovered tasks back to Product backlog as Technical debt and moves on along the same cycle.

Scaled Scrum, on the outside is exactly the same. Selected user stories from a product backlog provide the scope of work for a Sprint, where the goal is to produce an usable increment. The difference lies within. Within the Sprint/s however, the product owner or the project owner has chosen to implement multiple scrum teams, using any number of different compositions or structures.

All of the basic cadence of Scrum – the values, artifacts, roles, and meetings of Scrum apply, whether Scrum implementation is singular in nature or scaled up. These principles remain inviolate for the purposes of controlling risk, increasing predictability, generating creativity and productivity, and creating transparency.

Image Credit: K&C

Scrum – What to expect!

Scaling Scrum is a hands-on, get-dirty down on the floor, all-hands-on-deck, sleeves rolled up model where team members figure out one instance and nuances out of other instances of scaling Scrum that might work for their projects, releases, initiatives, or organizations.

As more Scrum teams come together to work on a Product Backlog, the number of people, their interactions, inter-working dynamics, complexities, and non-linear events increase. The situation is like too many vegetables simmering in a pot – you can guess but never accurately estimate how many flavors are one too many. For similar reasons, the relationship between productivity/creativity and the number of Scrum Teams is not clear. Product Owners employing multiple Scrum Teams need to carefully weigh the benefits and costs.

Techniques for organizing and selecting Product Backlog items, resolving dependencies and integrating work, and creating “done” increments are evaluated. Since every development situation is different (domain, people, technology), every set of techniques is unique and often has to change with time.

Scrum is designed to work best in an environment which fosters complex adaptive systems which exhibit intelligent goal seeking behavior. Scrum is designed to support an object-oriented component architecture.

A. Early Implementations

One of the first implementations of Scaling Scrum was studied in IDX systems (later known as GE Healthcare) in 1996 – 2000 period.

Managers self-organized company into teams
Managers became team leaders
Directors ran Scrum of Scrums
VPs became leaders of sites with multiple Scrum of Scrums
Grew to over 600 developers
Virtual architecture teams
UX team and Integration team
External experts verified that production doubled company-wide

Source: Scaling the business by scruminc.

Using Scrum at scale is another term coined at Microsoft following their extensive experience with Scrum here and here. At the same time, virtually all other top product and software application companies have realized the huge benefits of doing Scaled Scrum.

B. Team Structure and reporting

The first step to scaling is to form teams focused on features in order to maximize the user experience and speed of iterating on working software.

Every team has a product owner assigned and a professional Agile Coach who drive process improvement across the company working directly with senior management team.
A very important factor to account for is location of the teams. Team co-location is crucial, however not always practical. If distributed teams cannot be avoided, extra steps need to be taken to induce the feeling of co-location by measures like periodic get-togethers, reliable and prompt communications, etc.
Teams need to have clear autonomy and Scrum master must work with the team to remove impediments. Scrum master assigned to the team gets measured on process improvement and timely removal of impediments.
Regular communications and meet-ups between the teams and are crucial to disseminate information and provide autonomy as well as relevance to teams. Cross dependencies can also be resolved better and faster this way.
Cross functional teams are comprised to provide feedback to the community of practice they belong to. Communities of practice are generally the organization of resources according to their skillsets. For example, all Java resources may belong to the ‘Java practice’ in an organization, if the organization has such a setup, from where they are assigned to different projects. While in a project, resources report to project management as well as their respective community of practice.

Image Credit: Knowledgehut

Scrum – Frameworks

All SAFe scaling frameworks share some common patterns: Scrum implementations at team level, multiple teams sharing same product backlog, planning done as collaborative exercise across teams, and the general principles of pull and self-organization.

Scrum teams can be organized in many different ways, contingent on the framework used. There are number of frameworks that are available out there today. In this article we provide a brief on most of these frameworks for scaling Agile – LeSS, SAFe, and Scrum@Scale, DAD (Disciplined Agile Delivery) and Nexus

All Scaling Scrum frameworks start with cross-functional, self-organizing Scrum teams. The teams dissect and slice requirements into the smallest possible measurable tasks and increments that can be developed independently. Teams are expected to focus on self-learning, technical and process excellence such as doing continuous integration and automated regression testing to ensure that new code pushes don’t break any existing functionality. At the end of every sprint the teams should have a potentially deployable product, called an ‘usable increment’. The frameworks also encourage the use of Lean principles to optimize flow.

A. LeSS (Large Scale Scrum)

LeSS is a framework for Scaling Scrum that comes from two practitioners – Craig Larman and Bas Vodde, based on their work in the financial and telecommunication industries.

LeSS is defined by approach of minimalistic nature in supervision as well as use of processes, i.e. use as little processes to get multiple Scrum teams to work with each other well enough. LeSS consists of a hand full of rules, and also has guides and examples for how to customize these rules as the organization grows.

Perhaps in some ways LeSS is a larger reflection of how an ideal Scrum implementation is supposed to work. LeSS recommends that there be multiple Scrum teams with the same product owner and shared product backlog be maintained to promote consistency and predictability. Scrum teams should be long-term, cross-functional teams. Sprints should be synchronized to represent a product-level sprint leading to one usable integrated product increment at the end of the sprint.

A LeSS Scrum Master typically encounters complex large-scale problems and s/he needs to resist the urge to resolve them with equally complex solutions. Instead, the scrum master should leverage the spirit of Scrum and find simple ways to empower people to resolve their impediments. This approach leads to large-scale, yet simple, solutions.

Image Source: Less.works

LeSS is characterized by a single product owner with one product backlog, and several teams, each with its own sprint backlog. The Product owner is the owner of the complete product backlog and typically there are no divisions of the product backlog, unless using a methodology like LeSS Huge.

LeSS is the purest version of Scrum with only notable difference coming during the planning stage. As compared to Scrum which notes that there be 2 planning meetings for each scrum, LeSS recommends that the first sprint planning meeting be the joint meeting where user stories for product level usable increment is finalized (finalizing a product level Sprint Backlog), while the second part of the planning meeting is used by each team to produce their own specific Sprint Backlog.

B. SAFe

In the words of Dean Leffingwell, SAFe® is a freely revealed knowledge base of proven, integrated patterns for implementing Lean-Agile development. It provides comprehensive guidance for work at the Portfolio, Large Solution, Program, and Team Levels.

SAFe approach gained prominence post 2012 and has had 4 major updates since its initial release in 2011. Currently, the available approach is SAFe 4.6 launched in October 2018.

SAFe approach is a quintessential reorganization of the work with the aim of maximizing the speed of product or service delivery from initial idea to release and from customer feedback to enhancements and improvements. SAFe approach is based on organizing work in to value streams based on the repetitive nature of work performed. Each value stream has got its own organization of release team, called The Release Train. This ‘Release Train’ generally comprises multiple Scrum teams working together to deliver a component of ‘usable increment’ of the product. The ‘usable increments’ from all the Release Trains and Value streams then is combined to become a product increment.

SAFe methodology is further available in 4 different configurations dependent on the needs and size of the organization. The 4 different configurations vary considerably in terms of complexity and inter-play of components as well as the focus areas. These are:

C. Scrum@scale

Scrum@scale looks to tackle the problem of Scaling Scrum through questioning the ways of working and analyzing various choices to find the right approach to suit the context.

Scrum@scale is defined as follows:

Scrum@Scale (n): A framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value.

Scrum@scale imbibes all the principles of Scrum methodology – light structure, minimum bureaucracy and process controls, simple to understand however difficult to practice, needing regular and sustained cadence.

Scrum@scale contains two interlinked cycles: the Scrum Master cycle and the Product Owner cycle. These 2 cycles work in an interwoven way to provide a powerful framework to coordinate the efforts of multiple teams along a single, desired path.

Source: Scrum@scale guide

A set of the teams that operate within the project or have a need to coordinate comprise a “Scrum of Scrums”. The Scrum of Scrums is a “team of teams,” which hold a Scaled Daily Scrum (SDS) event with a representative from each team (usually the team’s Scrum Master, although any person or number of people may attend). The SDS exists to coordinate teams and remove impediments to delivering value.

The Scrum of Scrum must include all capabilities needed for product release at the level of Scrum of Scrums. That means that the Scrum of scrums should have the capability to look at the small goals and impediments while looking at the big picture all the time – to the point where it becomes ingrained in the team’s DNA.

Scrum of Srcums is at the heart of Scaling Scrum approach as laid out in Scrum@scale. The Scrum of Scrums team works independently as a release team and must be able to deliver value to its customers. To achieve this effectively, Scrum of Scrums has its own artifacts, roles and events – Scrum of Scrums daily standup, Scrum of Scrums retrospective, Scrum of Scrums review, etc where participants from all the Scrum teams attend, led by Scrum of Scrums master.

Scrum@scale also lays down the concept of Executive Action Team which is a super-body of Scrum of Scrums of Scrums operating within the organization. The purpose of establishing this super-body is to create an Organization level backlog of Agile initiatives (prioritized list of various initiatives) and aid in resolving the organization level impediments that hamper the achievement of these objectives.

Scrum@scale essentially views the entire organization as a super scrum team, something of the sort of a Scrum Master organization, transposing the agile operating system from project / program / product level to organization level.

D. Disciplined Agile Delivery (DAD)

DAD or disciplined Agile Delivery is characterized as is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), and Unified Process (UP), amongst other methods. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.

E. Nexus

According to the definition available at Scrum.org Nexus is an exoskeleton that extends Scrum to guide multiple Scrum teams on how they need to work together to deliver working software in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies.

To start a Nexus, organizations should first:

Identify the teams in their Nexus
Form an initial Nexus Integration Team
Have a single Product Backlog
Have a definition of “Done”
Identify a Sprint cadence

Just like Scrum@scale, the Nexus approach has its own terminologies, artifacts and resources. Nexus Daily Scrum, Nexus Retrospective, Nexus Review, Nexus Integration team, Nexus Sprint Backlog, Nexus Sprint Planning.

A representation of Agile Map

Conclusion: Scaling Scrum is a challenge!

As team sizes grow, organizations grow and their needs become more complex, bigger and more complex impediments arise along the road. The role of Scaling Scrum is to provide a framework to continually identify and remove dependencies created by increased complexity.

Scaling Scrum, like implementing Agile Scrum methodology is a matter of choice. Many organizations have reaped tremendous benefit and even more continue to do so. However, the primary integration point of Scaled Scrum is within the culture of an organization. The complexity of an organization’s hierarchy and culture defines the kind of products and applications it produces. In the words of programmer Melvin Conway:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

— M. Conway

An easy example of this can be seen through the website of a company, where it is often noted that the complexity, content and structure of the website depends on the demands of the internal teams rather than the needs of the users.

The Second challenge to successful implementation of Scaled Scrum comes from communications. As software projects grow in size and complexity, so do the teams of engineers that develop and maintain them. Brooks, in his seminal work, “The Mythical Man Month” discussed coordination as one of the key problems of running a software project with many developers. The coordination effort required to help each member of a team stay in sync and keep a project on schedule is enormous.

Early indicators of software quality are beneficial for software engineers and managers in determining the reliability of the system, estimating and prioritizing work items, focusing on areas that require more testing, inspections and in general identifying “problem-spots” to manage for unanticipated situations. Often such estimates are obtained from measures like code churn, code complexity, code coverage, code dependencies, etc. But most analysis often ignore one of the most influential factors in software development, specifically “people and organizational structure.” Read this paper for more information on the study conducted at Microsoft to analyze the above: Empirical software engineering at Microsoft Research

Generally speaking, LeSS is considered a good starting point for organizations who are relatively inexperienced in their Scrum adaptation. LeSS scales up with minimum addition of processes and leads to significant gain. On the other hand, implementation of an approach like SAFe demands a high organization maturity and experience of implementing Scrum. Implementing SAFe is generally for full scale Agile organizations and requires high degree of commitment and focus. Scrum@scale is a good approach for organizations with several scrum teams in place which want to focus on finding things and areas to improve.

In the end, choosing a methodology depends on the context and the situation, with the most important principle – ‘improving how to work together’.

Scaling Scrum: Agile and Agility