Agile Development – Scaling Scrum
SAFe (scaled agile framework), Nexus Scrum, LESS (Large-Scale Scrum) and Scrum@Scale
Introduction
The evolution and adoption of agile software development methods in companies in recent years is undeniable. Today, many IT companies are already adapting to this new way of thinking and are quickly moving towards adopting agile, if not the whole, most of the techniques and culture disseminated by the agile philosophy.
But as the adoption of such methods grows, new challenges, with varying degrees of complexity, begin to emerge. For example, the challenge a large company will face to efficiently coordinate a large number of developers and all those involved in large projects, helping them meet the business goals set by the organization. Aside from being obvious that this will not be an easy task, Scrum itself discourages the formation of development teams with more than nine members.
However for larger projects, there is in agile methods, the scalable concept. Scalability is the ability to adjust or adapt the framework to work needs with a larger volume of people and teams in parallel.
In this article we will present four frameworks that allow us to scale the agile methods within this scenario of large development projects.:
- Nexus
- Safe
- Less
- Scrum@Scale
Nexus
To help companies solve problems of scalability, Scrum.org launched the Nexus. It is a framework to scale Scrum, whose main purpose is to assist in the coordination of several Scrum Teams (3 to 9 members) when they are working on the development of a single product.
The Nexus consists of rules, events, artifacts, and roles very similar to those provided in the Scrum framework. The most obvious difference is that more attention is given to the dependencies of the involved Scrum Teams, so that they form a single, consistent gear in order to successfully deliver a ready and integrated increment at the end of each Sprint.
The Nexus recommends adopting at least 3 and at most 9 Scrum Teams, and forming a Nexus Integration Team.
Nexus Roles
Nexus Integration Team
They are responsible for ensuring that a ready and integrated increment is delivered at the end of each Sprint. They are responsible for resolving the technical and non-technical issues that prevent the Scrum Teams from reaching their goals. The Nexus Integration Team has the following roles:
- The Product Owner
- A Scrum Master
- One or more Nexus Integration Team Members
They can be part of the Individual Scrum Teams (except the PO), though they need to prioritize the activities inherent in the Nexus Integration Team.
Product Owner of the Nexus Integration Team
As in a Nexus there is only one Product Backlog and in Scrum there is only one Product Owner (as a rule) for each Product Backlog. The responsibilities of the Product Owner remain basically the same:
- Maximize the value of the developed product in an integrated way;
- Constantly prioritize and refine the Product Backlog.
Scrum Master of the Nexus Integration Team
It is responsible for ensuring that the Nexus is understood and its rules are met. It can be part of one or more Individual Scrum Teams within a Nexus.
Members of the Nexus Integration Team
Nexus Integration Team Members are responsible for training and mentoring the Nexus Scrum Teams to implement and learn about continuous integration practices and tools, automated testing, and so on. In addition, they train the Scrum Teams on the development standards required to achieve an integrated, expected quality increment at the end of each Sprint. Just like the Scrum Master, if your obligations are met they can join one of the individual Scrum Teams.
Nexus Events
Nexus events are the same as in Scrum. Even the time-boxes remain proportionally the same. Therefore, we will always have in each Sprint – in addition to Scrum events for each Individual Scrum Team (except Sprint Review) – a Nexus Sprint Planning, a Nexus Sprint Review, a Nexus Sprint Retrospective, and a Nexus Daily Scrum.
The innovation is that – although Schwaber has recommended investing about 10% of Sprint time in refinement and in the Scrum Guide there are only a few allusions on the topic of Product Backlog – it appears in the Nexus Guide, a specific topic for refinement predicting several levels within a sprint.
Nexus Artifacts
Practically the same artifacts foreseen in the Scrum framework were maintained. Product Backlog, Nexus Sprint Backlog and Built-In Increment.
The difference is that the Nexus Sprint Backlog was created to compose all the Sprint Backlogs of the individual Scrum Teams. In addition, it aims to evidence dependencies and track the workflow during Sprints. It is updated daily in the Nexus Daily Scrum.
A Nexus Goal must be set at each sprint. This goal is unique, and should be pursued and attained jointly by all Scrum Individual Teams.
The Definition of Ready is the responsibility of the Nexus Integration Team, since it is they who must guarantee an Integrated Product Increase at the end of each Sprint.
The biggest strengths are:
- It magnifies Scrum beautifully by providing what Scrum’s main author and Nexus, Ken Schwaber, calls an exoskeleton.
- It keeps the “stuff” to a minimum, so it’s concise and fairly quick to learn.
- It does not seem to cover other organizational considerations, such as organizational structure, in the way LeSS does.
- Nexus is heavily focused on this integration role.
Their weakness would be:
- Lack of widespread adoption.
- Limitation on number of teams
- It has a single Product Owner, which may not be enough for a scaled project.
SAFe
SAFe is an acronym for Scaled Agile Framework. It is a model created by Dean Leffingwell and maintained and evolved by Scaled Agile Academy.
SAFe is based on Scrum, XP (Extreme Programming), Lean and much field experience, for the implementation of agile practices in large scale. It recognizes what typically has worked well in the work of agile teams, in the way of doing program management and in the agile way to handle a portfolio of organizational demands.
SAFe provides a set of practices to help large organizations answer questions such as: How to run agile in contexts involving multiple teams? How to synchronize the work of these teams? How to coordinate the results of geographically distributed teams? How to prioritize demands on robust and dynamic products? How to scale an agile architecture? How to deal with the risks of a complicated project in an agile way? How to be agile and conform to governance models?
One of SAFe’s strongest characteristics is that it recognizes the way an organization is. This within a large company means that SAFe introduces the agile philosophy in the organizational culture and helps the company to generate results, without hitting the existing structure and roles or even with the current social glue in the organization. So, from a strategic point of view, being a model that respects the way of being and culture of organizations, SAFe has helped the agile movement to reach companies and in spheres that we have never been able to reach before.
What differs from SAFe of other agile approaches.
SAFe is Scrum-like, adopts XP with a standard approach to the team, and is strongly inspired by Lean thinking for a leaner approach to the product portfolio. So much more than differences, SAFe has things complementary to all these approaches.
But of course SAFe is not just a mix of such practices and approaches. SAFe offers in logical connection how to connect the company strategy (high level) to a really agile (and vice versa) development cycle. SAFe introduces a number of different activities, rules, and roles to the pure approach of Scrum or XP. These peculiarities are distributed mainly in the Program and Portfolio levels. For example, if we look at how SAFe does portfolio management, we will see that we have more specific roles for the job at that level, so in addition to the strong work of Program Portfolio Management, there is also the role of Epic Owners.
The biggest strengths are:
- This model is not just Scrum, but Agile. For example, you have a Kanban process in the top portfolio section.
- SAFe is a generally tool-neutral.
- In SAFe, Scrum Master is a very important role in the Scrum team and does a lot of intra-team and inter-team coordination.
- In SAFe: Epics, Features and Stories are explicitly treated as integral parts of SAFe backlogs.
Weaknesses:
- SAFe is more comprehensive in offering processes and roles to handle software development, at the cost of perhaps appearing heavy on processes.
- SAFe contains many good ideas. However, adopting the complete package is a bit tricky.
LeSS
LeSS was thought to scale an agile team, it retains many of Scrum’s practices and ideas. As well as complete, multidisciplinary, self-manageable teams, a Product Owner and a single product backlog. With LeSS, all teams are in the same sprint to deliver an increment for the product in common with each cycle.
As in Scrum, LeSS has the same events during the sprint, but there are some adaptations to make it scalable. Let’s see in practice:
Planning meeting
The planning meeting, for example, is divided into two parts. Being the first part in which the Product Owner presents all the items to be developed in the sprint and its priority. The teams or their respective representatives should discuss the items and clarify any doubts.
In the second part, the teams divide the stories and define how the shared work will be coordinated. It is important to remember that teams must find opportunities to work together and learn from each other.
Daily meeting
The daily meeting is held independently by each team, although a member of team “A” can participate in the meeting of team “B” in order to increase the sharing of information.
Sprint Delivery Meeting (review)
All teams must be present at the review meeting and each one must present what was given in the sprint. In this way, everyone will see the product completely.
In addition, it is strongly recommended that customers, users and stakeholders participate in the meeting.
Retrospective
Just like in planning, the retrospective also has two stages, each team should have its separate retrospective meeting normally. Then the Product Owner, the Scrum Masters, and one or more team representatives take a general overview, summarizing the two or more teams.
Two types of LeSS
There are two types of LeSS: LeSS and LeSS Huge.
LeSS Huge is formed by having several regular LeSS structures working in parallel with each other.
The biggest strengths are:
- Similar to Nexus, LeSS focuses heavily on Scrum-of-Scrums.
- Uses practices and principles of other methodologies such as: more with less, product focus, customer focus, continuous improvement, Lean thinking, etc.
Their weakness would be:
- The creators of LeSS strongly believe that culture follows structure. For this, they offer the LeSS not only as a practice to broaden the Scrum approach, but as a direct impetus for organizational structure change.
Scrum@Scale
Scrum is considered as a faster and iterative method of applying agile culture to a business landscape and as an agile methodology focuses on regular delivery rates. By concept it is an extension of Scrum’s core framework that can scale to larger organizations, and is also a great solution for businesses of all sizes.
Scrum at Scale naturally extends Scrum’s core framework to provide hyper productive results across all industries (not just T.I), including software, hardware, services, operations, and Research & Development.
Scrum at Scale’s modular approach helps properly size the agile culture to align the entire organization to share the same goals in the project and process. Another relevant point is that this modular approach provides an appropriate scale according to the company’s culture and the reality it lives. Because it is modular, developers and team members can adopt modules that are interesting to the project and can promote the application of specific modules in specific environments.
Scrum at Scale has a high level of efficiency when dealing with teams that live in the same environment or geographic location and one of the important points of this framework is its ideal team configuration as a single agile team, unlike SAFe. Another important point of Scrum at Scale is its ability to align the organization towards a shared set of goals.
These advantages make Scrum at Scale an ideal framework to apply to specialized business processes that have a high level of customization, especially when it comes to nontraditional environments.
This advantage is ideal for companies that have a strong organizational culture and need to apply agile culture in accordance with that organizational culture.
According to the Srum@Scale Guide, it is:
- Light – As little paperwork as possible;
- Easy to understand – Consists of Times Scrum only;
- Difficult to master – It is necessary to go one step further and implement a new organizational model;
Why Scrum@Scale?
Scrum @ Scale is a framework for scaling Scrum. Radically simplifying the scale using Scrum to scale Scrum.
Scrum has been designed with only one Team in mind to achieve its optimum capacity while maintaining a sustainable pace. In the field, it has been found that as the number of Scrum Teams within an organization grows, the speed of these teams begin to fall (due to issues such as dependencies between teams and duplicate work). ). It became obvious that a structure to effectively coordinate these teams was needed to achieve linear scalability. Scrum at Scale is designed to achieve this through a free-to-scale architecture.
By using a free-of-scale architecture, an organization is not required to grow in a specific way, determined by an arbitrary rule set; instead, it can grow organically based on its needs and the pace of sustainable change that can be accepted by the groups of individuals that make up the organization.
The simplicity of the Scrum at Scale Framework is essential for a free-to-scale architecture and carefully avoids the introduction of additional complexity that will cause Time Productivity to decrease as more Teams are created.
Scrum at Scale is designed to scale the entire organization: all departments, products and services. It can be applied across multiple domains in all types of organizations: industry, government or academics.
Conclusion
The differences between the four large scale frameworks are subtle and important. It is not the same task that makes a Scrum Master in an environment that uses SAFe than in one that uses LeSS. In the first, his work is more management, while in the second, he is expected to be more of a coach.
Compared to Scrum at Scale, SAFe may not be as customizable and here is a disadvantage. This comparison with Scrum shows that SAFe has a more complex structure and adds more processes, layers, functions and tools to project value deliverables.
That is why it is interesting that those organizations that are practicing agility at scale define, understand and communicate what their expectations are regarding roles and their functions within the agile practice.
Comparing these four frameworks, it is important to study them to identify which ones are more suited to the company’s processes, guaranteeing value to the business, seeking a better environment for the teams, less waste, which consequently will bring a better financial result.
Any of these methods that are used to apply the agile culture in the company should be chosen according to the work environment, project specific goals and even the company structure. Thus, the advantages and disadvantages of each of the frameworks are the important points to decide on your application.
The truth is that none of the four structures presented fully meet any type of company. And as already said, it is very important to know the four (or more) to identify when and where to apply the framework that best suits.