By Jug Babic
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.
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.
Regardless of where it originated, it is crucial that the initiative has the backing of the executive-level sponsor of some kind. Namely, studies show that Agile projects with an effective sponsor succeed in 72% of cases, while the success rate drops to under 30% when such a sponsor is absent.
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.
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.
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.
Jug Babic is a marketer at VivifyScrum, the company behind the eponymous Agile project management tool.