- Let's discuss Scaled Agile Frameworks.
Agile at scale
is seen as the organizational approach to agility.
It allows to maximize benefits of Agile delivery
and avoid challenges,
similar to the ones that were experienced
by the transformers.
Scaled Agile implementation change the whole company culture
to support the value of Agile Manifesto.
Focus on people, on business outcomes, on being comfortable
with iterative planning and iterative delivery.
It also focused on business and technology
working together to delight their customers,
on prioritizing the value delivered over reports,
about the work being done, those red charts.
It focused on including team-level collaboration
between cross-functional teams and many other principles,
and this can be done in many different ways,
and these ways have been summarized
in several well-known Agile scaling framework.
So let's review those frameworks one by one
and then compare them based on the type of the organization
that they're most suitable for.
There are multiple Agile scaling frameworks.
The most popular include Scaled Agile Framework or SAFe,
Large-Scale Scrum or LeSS,
Disciplined Agile Delivery, DAD,
the Spotify Scaling Model, Nexus, and Scrum@Scale.
So let's briefly describe each
of those frameworks and compare them to each other.
Let's start with the Scaled Agile Framework, or SAFe,
because it is by far the most popular
Agile scaling framework.
SAFe is the world leading framework
for scaling Agile across the enterprise.
It's used by hundreds of world's largest companies.
It overall sustains and drives faster time to market,
dramatic increase in productivity and quality,
and improvement in employee engagement.
The way SAFe is designed, it has a concept
of a scaled Agile release train.
Agile release train, or ART,
integrate sprints within multiple teams
within the organization and delivers them
to the customer in a structured way.
SAFe also talks about other teams
such as product, marketing, sales
being part of our delivery to the customer.
The authors of SAFe, Dean Leffingwell and Drew Jemilo,
released SAFe in 2011.
Their goal was to meet the changing needs
of large organizations,
and since conditions changed rapidly
in those organization, frameworks such as SAFe emerged
since then to help businesses improve solution delivery
for their enterprises.
The key settings for SAFe include American Express, FedEx,
Chevron, MetLife, Lockheed Martin, PepsiCo,
Cisco, Capital One and many other companies.
Now let's talk about Large-Scale Scrum or LeSS.
The creator of LeSS is Craig Larman.
According to him, Large-Scale Scrum
is a new and improved Scrum,
and it's not Scrum at the bottom of each team.
Instead, it is about figuring out
how to apply the principles, purpose, elements
and elegance of Scrum solution in a large-scale context
as simply as possible.
Compared to SAFe,
LeSS is very simple, it's very fast.
If you have Scrum for one team,
you have Scrum or Scrums for multiple teams.
If you have one product owner for one team,
then you have product owners for multiple products.
Like Scrum and other truly Agile frameworks,
LeSS is barely sufficient methodology,
especially for high-impact reasons.
It was invented in 2005,
and since then, it is focusing on clients
who applied their frameworks for scaling Scrum,
Lean, and Agile development.
The key studies include JP Morgan Chase, Ericsson,
BMW Group, Bank of America Merrill Lynch,
Nokia, John Deere, Alcatel, and many other large companies.
Now, let's talk about
the Disciplined Agile Delivery, or DAD.
That enables team to make simplified process decisions
about incremental and iterative delivery.
It builds on many practices invented in Agile, Lean, XP,
and other software delivery methodologies.
Also, it looks at the people first
learning-oriented environment
to make scaling easy and efficient
at the organizational level.
It was invented in 2012
based on the book "Disciplined Agile Delivery:
A Practitioner's Guide to Agile Software Delivery
in the Enterprise,"
which was written by Scott Ambler and Mark Lines.
DAD is a mean of moving beyond Scrum.
It doesn't work for huge organizations,
but it works well for medium-sized companies.
Since 2012, DAD has been redefined as a toolkit.
So it can be combined with any other scaling framework.
This toolkit consists of
Lean, Scrum, Kanban, LeSS and SAFe.
All of those elements include techniques of modeling
test-driven development and other practices
to make Scrum and Agile successful at the company level.
Let's take a look how Spotify scales its agility.
It is a unique model,
but it takes all the Agile considerations
into account really, really well.
So the heart of the model is a squad.
These are people on a squad.
One of them could be
a UX designer, a few of them could be dedicated testers.
The others could be developers and so forth.
All together, they create a squad.
This is squad 1.
A group of squads working on one product
is called a tribe.
Together, they produce one specific product.
For example, media player.
This is a tribe.
There are multiple tribes.
So this is a media player tribe.
This is the personalization that saves all the playlists
and allows to exchange them, similar structure.
Here is tribe 2.
It has also squads.
The number of squads could be different.
Let us say it is a larger tribe, so it has
six squads and so forth.
Those teams are cross-functional.
We show that here, there are developers, testers,
user experience designers, user researchers,
whoever is needed to deliver functionality end to end,
but then on a specific team,
there could be people of similar competency.
On this team, there is another user experience designer
and here is another user experience designer.
So all together, they create a chapter.
A chapter has usually its leader.
The head of UX design for Spotify for this specific tribe
could be within or could be outside of this chapter.
This person is working with other designers
on defining techniques, competences,
role expectations, tools, and everything else
to establish consistent
and continuously improving UX practices
across the whole tribe,
and eventually scaling at the whole company level.
Similarly, for the testers, there will be
lead manager for testing,
and this person will be responsible
for developing professional skills, practices, tools,
everything else that makes those team members successful.
Now, throughout the whole company,
people may be interested in different topics.
See, this developer is interested in Agile.
They want to understand what's the difference
between Scrum and Kanban, what is Scrumban?
What are other methodologists that are interested in Agile?
This person is interested in Agile, this person,
and a few people here in different roles as well.
So all together, they create a guild.
Guild is not confined to a specific tribe.
These are people who either want to move
into Agile coaching role or this Scrum Mastering role
or they just want to learn more about it.
There is another guild.
Those people are interested in DevOps
or continuous deployment, test-driven delivery
and similar techniques.
Those people create DevOps guild.
So this way, two things are accomplished.
First, as you can see, you can scale this model
anyway you want, you can create multiple tribes.
Each of them will be responsible
for its own product or product feature.
At the same time, it empowers team members.
Anything they're interested in,
let us say this user experience designer
wants to grow into quality manager.
So this person becomes part of the guild
to learn more about quality management
and joins others who may be in this role already
or maybe they're similarly interested and creates a guild.
A guild may have a conference.
It may meet on a regular basis.
They may share experience and so forth.
This is empowering model and also extremely flexible,
and the final thing I want to mention here,
that for each of those specific squads,
they pick which model they want to follow.
It could be that this person does Scrum,
and this person does Kanban
and this person wants to experiment a little bit
so they do Scrumban.
It is up to them.
No one tells them which specific methodology
they have to choose.
Here is the Agile scaling model at Spotify.
Now, let's talk about Scrum@Scale.
Scrum@Scale is a relatively new framework
that was developed by Scrum Alliance,
and it's a natural extension of the Scrum framework.
Its goal is to empower organizations
to achieve business agility
and deliver value to their customers.
Within this framework, Scrum teams operate consistently
within "The Scrum Guide" and also it focuses on tenets
and principles of "The Scrum Guide,"
as well as Agile Manifesto,
and the products there could be hardware, software,
integrated systems, processes, services, and so forth.
Scrum@Scale enables transformation at the divisional
or department level and scales it to a company.
They call it actually a scale-free architecture.
Now, let us talk about the last,
but not the least framework, which is called Nexus.
The Nexus model was developed by Scrum Alliance
and it actually is becoming increasingly popular.
It's a very simple framework.
It implements Scrum@Scale across multiple teams.
Usually, it's applied to three to nine teams
that are working in a common development environment
on one product.
So it focuses on incremental iteration
and combined increment every sprint
with minimal dependencies.
Nexus promotes value.
It's a scaled framework that does not say too much
about stakeholders or the product that they have to deliver.
It focuses on cross-functional teams,
which they consider the prerequisite of Nexus.
They are looking at Scrum experience and Scrum environment
in promoting transparency,
continuous integration, and relentless improvement.