How To Scale The Scrum Framework (Distributed & Large Scrum Projects)? This Might Surprise You!
The Scrum Framework - as described so far -
works best for a single Scrum Team in one
location. However, in reality, a singular Scrum
Team often cannot implement a project entirely,
or the team members have to spread over
multiple locations.
As a consequence, the number of teams has to
increase with various distributed teams. In many
instances, we have also been observing that
those teams are distributed in geographically
distant locations or continents.
There are numerous reasons which motivate
organizations to distribute their teams across
different locations:
- Technical Reasons: Some knowhow to build
separate components of the software are not
locally available in the headquarters,
- Expertise Reasons: Some capabilities related
to the execution of different software engineering
activities are not locally available. For
instance, test automation, user interface design,
or integration of in-house software
to the software of other vendors can require experts outside the headquarters,
- Size-related Reasons: The project takes more
people on board to deliver it to its clients in a
predefined timeline. If this is the case, then the
project organization will need more members
than it can conceivably fit one single Scrum
Team. So the Scrum Team has to be distributed,
- Business-related Reasons: Use of human
resources from lower-cost locations or enabling
the continuity of work by using engineers
from different time-zones could build a good
business case.
As communication is an integral part of the
Scrum Framework, all Scrum Team members
should pay attention to overcome the challenges
to deal with working within a distributed project
environment. Furthermore, all team members
should have access to communication tools,
including audio/video conferencing and
screen sharing tools.
These commonly used project management tools
support teams to enable healthy and continuous
communication. Those can include product backlogs,
sprint backlogs, incident lists, knowledge/
news sharing tools, and so on.
Project Organization:
Multiple Teams
The simplest way of expanding the Scrum Framework
while working in a larger-scale project
setup is to increase the number of teams in the same
location.
If multiple teams need to work together to
implement a project, it is best to grow the
number of teams progressively.
What does this mean to you?
Multiple Teams in a Single Location
In most organizations, progressive growth is
more manageable than launching ten different
new teams in one go. The best practice is to start
with a single Scrum Team. After a few successful
Sprints, one or two additional Scrum Teams can
join the project. Once you ensure that these
multiple Scrum Teams (See more about Multiple Scrum Teams) work together well, you
can keep on adding further Scrum Teams to your
distributed project organization.
Increasing the Number of Teams
There are two typical ways of creating new
Scrum Teams:
You split an existing Scrum Team into multiple
teams and add new Scrum Team members
where and when necessary,
You construct a new Scrum Team from
completely different engineers who haven't
involved the project so far.
Splitting an existing Scrum team has the
advantage of leveraging the Scrum Team
members who are already knowledgeable and
who have already experienced with the
ongoing project.
Therefore, those new teams are usually at least
at some degree productive as soon as they're
formed. The major drawback of this scenario is
that the existing and fully functional Scrum Team
has now been split into two teams. That could
always cause some issues with the motivation of
Scrum Team members. Especially if those
changes are happening without an in advance
announcement and justification from senior
leadership, and when the team members are
mentally and technically unprepared.
When adding completely new teams, these
already existing teams can continue with their
Sprints without any interruption and extra
integration effort. However, it will take longer to
build up the necessary know-how and momentum to
ramp-up the entirely newly formed Scrum teams.
Independent from the decision on how you add
new Scrum Teams to your organization bear in
mind the following principles:
- Start with a small number of Scrum teams,
- Increase the number of teams gradually,
- Ensure the continuity of work and smooth
delivery of software and business value during
the times of change and growth,
- If there're significant problems that hinder
productivity and continuity of work, first focus
on fixing them rather than the expansion with
new Scrum Teams.
Project Organization:
Distributed Teams
The major complexity of multiple teams manifests
itself when the new Scrum Teams have to
be distributed over various locations.
Communication barriers between people, coordination
difficulties of work, and misunderstandings
of joint project norms across teams are
only a few of many when it comes to mentioning
this complexity.
Multiple Teams in Multiple Locations
The consequences of not addressing these
challenges are severe.
Companies have to count billions of dollars of
wasted IT budget because of the lack of their
skills in Organizational Leadership and
Scaled Scrum Expertise.
There are four critical suggestions for you to
cope with these challenges:
- You ensure that new Scrum Team members
are trained in the Scrum Framework as a
Scaled Scrum Expert,
- You ensure that new Scrum Team members
are introduced to the project adequately, so
they have a proper understanding of what
they're serving for. Not only technically but
also from a professional business value point
of view, so they can make decisions in their
work to increase the value of their contribution,
- You ensure that the project norms are established.
Similar to a single Scrum Team, which
has its norms of how to communicate, how to
plan, how to get the work done, a multiple
project team organization should have its
higher-level norms too. So these teams can
communicate, plan, operate, solve problems,
and deliver client and business value together.
- You ensure that the new team members do at
least temporarily work together with the
experienced project members. That could
require remote site visits and on-the-job training.
That's totally fine and even desired.
Thanks to this approach, the knowhow can be
smoothly transferred, and the two-ways and
personal dialog between people in different
teams and locations can be established.
Virtual Teams
Another option of a distributed Scrum Team is
having its members spread over multiple
locations. Such a team is called a "Virtual
Team".
The main challenge here is to ensure flawless
communication among the team members.
Scrum Team members must still need to conduct
all Scrum Rituals (Scrum Events) to coordinate
their work, but now they have to do this while
not all of them are present in the same room.
Virtual Teams
Scrum Team members co-located in the same
location should still work together in the same
room. And yet, they now have to rely more on the
use of collaboration and communication tools.
They can join the Scrum Events from the same
meeting room to connect to the other half of the
virtual team via video conferencing technologies.
Scrum Product Owner Team
As we have covered many times in this material
so far, regular communication between the
Scrum Product Owner and the Scrum Team is
crucial for the successful delivery of a project.
We need to ensure that the Scrum Product
Owner is always available to Scrum Teams
located in different locations. Therefore, it is
often necessary to have multiple Scrum
Product Owners working together. Ideally,
there is one dedicated Scrum Product Owner
for each team.
The Scrum Product Owners should then build a
dedicated "Scrum Product Owner Team" to work
together effectively. One of the Scrum Product
Owners should be assigned to the role of the
"Chief Scrum Product Owner”.
He or she is responsible for ensuring that:
- The correct product is built to satisfy the
demands of its client,
- All Scrum Product Owners collaborate efficiently,
and they enable their teams to build the
business and technical value for their clients.
Since the Scrum Product Owner Team is
responsible for the complete requirement
engineering, it is beneficial to have other
competencies and stakeholders in this team.
Those can include the representatives of the
business case, relevant stakeholders, enterprise
architects, and technology architects.
All Scrum Product Owners should work within a
single large Scrum Product Backlog containing all
stories relevant for the project. Each Scrum Team
is responsible for delivering some of these user
stories. And yet there will be still instances of
specific user stories that require the attention
and deliverables from multiple Scrum teams.
Component vs Feature Teams
When distributing work among different
teams, we can make the teams accountable
for specific software components or features.
That is why we call them "Component Team" or
"Feature Team."
Component Teams
When using Component Teams, each team is
only responsible for the implementation of
dedicated components from the overall
system. To finish a user story, it is usually
necessary to split the user stories into smaller
pieces to implement them within a single
component. The dependencies between the
components of these Component Teams make
continuous integration an inevitable part of
successful deliveries.
Scrum Product Owner Team
Thus, a feature cannot be usually delivered
within a Sprint because its implementation
depends on the deliverables from user stories of
other teams.
That results in increasing batch sizes and lead
times of ongoing, not yet integrated work. That
doesn't sound so good, because Scrum Teams
should target delivering shippable software
increment in smaller batch sizes and shorter
lead times.
The advantage of component teams is that they
make it easier to focus on and build expertise
about architectural and design details of
particular components. That could be
massively beneficial for components that
require discovery and innovation.
On the other hand, the members of component
teams do only specialize in individual components
of the whole system. They could lose
their bird-eye view and business necessity of
features.
Keep in mind that our clients do not
compensate us to deliver components, but
features with which they will execute their
businesses. Without this relentless focus on
features, overall optimization, and integration of
software might take extra time. Since decisions of
component teams tend to optimize single
components, those decisions can construct
invisible bottlenecks for the success and
performance of the overall solution.
Component Teams
Feature Teams
Feature teams are fully responsible for the
implementation of user stories as they're
specified within the Product Backlog. The
teams do no longer need to be divided for
various components. Each Feature Team is
responsible for delivering a fully-functional
feature and a business value associated with this
feature.
Feature Teams
Members of feature teams possess cross functional
skills. They act as autonomous as it is
possible to deliver fast. The advantage of
feature teams is that the team maintains the
system-knowledge, and this makes it easier
for them to integrate their features with the
rest of the system.
However, for feature teams, it may become more
challenging to build sufficient know-how about
components. Furthermore, bringing up an
autonomous feature team that can deliver fast
and independently takes time as building an
interdisciplinary functional team is not that easy.
And yet, these are the high-performer teams
which get the job done in most organizations,
probably including yours.
How Do We Choose Component
Teams vs Feature Teams?
In practice, most of the large organizations use
both dedicated Component Teams and Feature
teams too.
Component and Feature Teams
Team C, on the chart, is a Component Team. It
provides planned and on-demand infrastructure
services to other teams that function as Feature
Teams. Team C does not directly implement
end-to-end user stories per se. They deliver
the requirements of the user stories committed
by the Feature Teams.
That allows the minimization of the number of
qualified people in Feature Teams with the
know-how of those components.
The Scrum Master In The Distributed
Project Environment
In a distributed project environment, the role of
the Scrum Master is even more essential. In
those project configurations:
- There will be extra effort required to align the
teams on the values of the Scrum Framework,
- It will take longer to establish individual team
and project norms (standards) which influences numerous teams,
- Last but not least, there will be many
impediments due to the increased number of
dependencies between teams and their deliverables.
One important rule to bear in mind that the
Scrum Master should physically locate where his
or her team is. Otherwise, it will be almost
impossible for the Scrum Master:
- To remove the impediments for his team,
- To Establish their norms, and
- To help them to improve their use of the Scrum
Framework.
The best practice is to have a Lead (Primary)
Scrum Master to guide the overall use of the
Scrum Framework across multiple teams.
In other unit Scrum teams, which form the larger
Scrum organization, someone should be acting
as a local Scrum Master too.
Share It With Your Colleagues and Friends to Help Them Learn:
How To Scale The Scrum Framework (Distributed & Large Scrum Projects)? This Might Surprise You!
|
|
|
|
|
|
|
SCRUM INSTITUTE™
