Scrum is not too simple for your project, your project is not simple enough for Scrum
“Our product is too large to release every Sprint” or “The work we do in this organization is too complex for Scrum” is something we often hear from participants in our workshops or the clients we help. Interestingly, people often seem to quite proud of this complexity.
Complexities from the field
I recently had the pleasure of providing an introduction to Scrum to several large teams (30+ people) from large companies. These teams had been struggling with a variety of large projects over the years. It was increasingly difficult to manage the project, the scope, the required resources and the quality of the codebases. Here are some of the complexities they struggled with:
- All projects featured a large number of people working on the same product, but spread across internal and vendor teams;
- Most of the teams were specialized. There were usually one or more development teams, a testing team, a functional application & support team and a number of people that worked on preparing the requirements (in various levels of detail);
- All projects required a large number of connections to and from other systems, both inside and outside company boundaries (and control);
- All projects involved highly business-critical (and often innovative) products;
- As is common in larger companies, there was a fair amount of bureaucracy and hierarchy going on in the background that influenced the project (like availability, procedures, protocol and politics);
It’s obvious that a planned approach is a recipe for disaster in these volatile, constantly changing environments. Every plan, no matter how well it is crafted, will be outdated upon execution. The teams acknowledged this, and looked to Scrum as a viable alternative. It’s no wonder that Scrum is often presented as a remedy for large projects, with its focus on empirical control (over control through plans) and iterative delivery as a means of getting very frequent feedback.
The problem(s) with Scrum for large projects
And it might well be. But when I talk about Scrum with teams that are working on large projects, I’m a bit surprised by a particular class of arguments that I often hear. The gist here is that complicating factors of a project are used to argue that, in one form or another, working software can’t be delivered in short sprints. Like not being able to add integration and regression testing responsibilities to the development team because some outside team has to do this (because of skills or organizational / contracting reasons). Or not being able to have short sprints because one team has to do development, and another has to test functionality in the next sprint. Or not being able to forego detailed specification and documentation because of procedures and the vast number of people involved. Or not being able to attend Daily Scrums and work with stable teams because people are always working on multiple projects. In all of these cases, my response is that Scrum is a framework that prescribes a set of artifacts, roles and events for developing software and that it does not provide pre-packaged solutions for integrating testing procedures, working with part-time employees, external contractors, organizational politics and hierarchy. This is up to the team.
This response sometimes opens the door for another class of arguments; that Scrum may well be too utopian for the real world of large projects because it ignores many of the complicating real-world factors. The underlying assumption here is that these factors can’t be controlled, simplified, changed or removed altogether. Although I understand where this argument is coming from, I also think that it misses the lesson that Scrum is trying to teach.
Why Scrum is a good choice
I’m sure that everyone agrees that there is a positive relationship between the complexity of a project (as expressed by the number of factors that influence it) and the chance of (expensive) failures. Experience tells us that in a complex environment, the best way to avoid costly mistakes is by very frequent inspection of the process and the product in order to correct as early as possible (the ‘fail early, fail often’ principle). This focus on rapid feedback necessitates a process that churns out working software as frequently as possible, which is made possible by the Scrum framework. And this process should be as simple as possible.
Because Scrum is about simplifying the process of software development. There is one Product Backlog for every product, one Product Owner, one Scrum Master and one Development Team. This group of people, grouped into a Scrum Team, is enough to frequently deliver working software. Everything else adds complexity that inhibits the frequency by which working software can be released. To some, this may seem like an (over-)simplification driven by the (unrealistic) ideal that you can ignore the rest. But I think that its simplification driven by the realization that the best way to develop software sensibly is by working with a simple model.
People that argue that Scrum is unsuited for (large) projects because Scrum doesn’t address the complexities and intricacies of their projects should do well to realize that leaving said complexities in place is always going to negatively impact the ability to frequently inspect (and adapt) progress. And this increases the chance of project failure and costly mistakes, no matter what method, framework or approach is chosen.
And yes, Scrum is also only a framework. It acknowledges that there is no one perfect Scrum implementation. No silver bullet. Every team, every organization must find it’s own best-fitting implementation, especially in the face of scaling. But the important thing to understand is that every compromise, omission or addition to and from the Scrum framework will likely negative impact what Scrum is trying to achieve and what’s ultimately good for business.
The wrong question to ask for large projects, and the right question
So in the end, the wrong question to ask is ‘How can we scale Scrum to fit our project?’. The right question is ‘How can we simplify our project to fit Scrum?’. This moves the focus away from impediments and factors that can’t be easily changed to questions like ‘How can we split up a project into meaningful, self-contained, products?’ , ‘What steps can we remove from the process?’ and ‘How do we organize our work around these products and their teams?’. This puts the team on a more fruitful and more rewarding path towards continuous improvement.
What are your thoughts on Scrum and large projects? Have you run into similar arguments? What are your experiences? I’m always looking forward to hear your thoughts.
