Most Common Challenges of Introducing Scrum to Large Corporations

Due to a number of factors, Scrum has become the framework of choice for the majority of teams and organizations which decide to introduce Agile. For smaller companies that operate with a tiny number of teams, the process of adoption is not that difficult and, in most cases, it comes down to how well the people will respond to it.

In large corporations, this is not as easy and
the process is often beset from every direction which results in either
adopting some sort of a pointless Scrum/old practice hybrid or rejecting Scrum
altogether.

The following are the most common challenges
of introducing Scrum to large corporations, together with a few ideas on how to
overcome them.

Established Hierarchy

Large corporations almost invariably have a
clearly structured hierarchy which allows them to organize the enormous amounts
of work and coordination between innumerable departments and teams. It is
simply a necessity.

In such highly structured environments, the
introduction of self-organizing, mostly independent Scrum teams is often met
with resistance from various levels of management.

One of the most common problems is the
disruption that Scrum brings to the traditional project management practices
and project managers. Namely, in Scrum, the responsibilities of the project
manager are divided between two roles – the Scrum Master and the Product Owner
(read more on the Scrum Master vs Product Owner responsibilities division).

There are a number of ways to approach this
issue, but the reality is that, in many large corporations, the introduction of
Scrum challenges established hierarchy, producing an understandable pushback.

This is further complicated by the issue of
reporting to various levels of management hierarchy, which will be further
discussed later.

Lack of Executive Backing

In order for a corporation to even start
introducing Scrum to the organization, there has to be an initiative which can originate
at different levels.

For example, the initiative can originate from
a single software development team whose members may have had some experience
with Scrum previously. Alternatively, it can come from a department head or
even someone from the C-suite.

Ideally, the whole upper management would
champion the idea, but we have to be realistic.

Without executive backing (or at least
explicit buy-in), Scrum teams will have to battle too much, alone. They might
get over-managed by someone from the middle management who does not understand
the point of Scrum. An executive might feel that the team should show far too
much improvement in far too little time. Another team might be inundated by
requests for all kinds of stats that it would not even keep as a Scrum team and
reports that are equally alien to Scrum teams.

A strong, effective executive sponsor can
mitigate the majority of these “assaults” on Scrum teams or even prevent them
altogether.

Complex Interdependence

Large corporations are complex machines with a
huge number of moving parts which have to operate in unison in order not to
disrupt the overall functioning of the system. This involves innumerable
processes, practices and collaborative efforts which can easily be disrupted by
the introduction of something as novel as Scrum.

If the corporation in question operates in highly regulated industries such
as healthcare or finances, there are even more interdependencies to worry
about, including fully external stakeholders.

At the very core of Scrum is delivering the
product incrementally and iteratively. Such delivery may be too much for these
complex corporate systems to handle, especially if Scrum is being piloted on a
very limited number of teams.

There are ways in which this can be somewhat
remedied. For instance, a Scrum team might be assisted by an outside
traditional project manager who will act as an added layer of protection for
the team (often referred to as delivery manager). A political ally of some
kind. There are also certain frameworks that address this issue specifically,
such as Large-scale Scrum, or LeSS for short.

Reporting and Documentation

It is unrealistic for large corporations to
function without certain systems for reporting. They need those in order to
evaluate the performance of various teams and departments and they need them
for future projections.

Scrum is intrinsically averse to reporting and
the statistics and data Scrum teams track are often not compatible with
standard corporate reporting. This can, unfortunately, lead to a variety of
negative outcomes – from the increased pressure on the Scrum team to act in a
non-Scrum way to bad blood between teams that adopted Scrum and those that did
not.

Something similar can happen in regards to
documentation. Namely, large corporations employ copious amounts of
documentation for a variety of reasons, the least of which is not the complex
level of interdependence covered earlier.

While the
official Scrum Guide does not mention documentation
explicitly, the agile, iterative nature of the framework is ill-suited to
comprehensive documentation

When it comes to addressing this problem with
reporting and documentation, it is essential to strike a balance where the
Scrum team is not being pushed into anything that would go explicitly against
the framework and render the whole exercise pointless.

At the same time, it is important to recognize
that a large corporation of any kind will probably be unwilling to let the
Scrum teams operate outside all corporate documentation and reporting systems.
Once again, an outside ally in the form of a project manager might be a good
solution.

Closing Word

Successfully introducing Scrum to large
corporations is not an easy thing to do. The challenges are many and they may
even seem insurmountable. However, with some executive sponsorship, a lot of
organizational buy-in and realistic expectations, it can be done – just check
out Google’s ongoing list of companies that use Scrum.

Jug Babic is a marketer at VivifyScrum, the company behind the eponymous Agile project management tool.