Myth: You Can’t Do Projects With Scrum
In this series of posts, we—your MythBusters Christiaan Verwijs and Barry Overeem—address common myths and misunderstandings. Thea Schukken created the great visuals.
Want to listen instead of reading this blog post? Listen to it here.
People who love Scrum usually don’t feel much love for projects. It's like the proverbial red cloth to a bull. This is reflected in the strong statements from passionate Scrum practitioners, such as “Scrum is about products, not projects” or “Projects have no place in Scrum.”
Yet, many organizations work with “projects.” What they exactly mean by that word varies hugely, but it is usually considered a long-running group of activities toward achieving some goal. We’ve found that if you aim to create as much resistance as possible, starting a crusade against everything called “project” is a good way to do so.
In this edition of our ongoing series of Scrum Mythbusters, we address a myth that seems to be about words. “Products” or “projects,” who cares? But words have meaning and exist within a broader context. The purpose of the Scrum framework is much broader and deeper than merely changing the words we use to talk about work. And if you find yourself charging at everything that sounds like “projects,” you may be missing that bigger picture.
What is a project?
Before diving into this myth, it's helpful to have a working definition of what we mean by “project.” In our work, we notice that people tend to define projects as long-running activities where 1) the scope of what needs to be delivered, 2) the budget to make this happen, and 3) the date when it needs to be delivered are all fixed. Other characteristics that people often mention are that 4) projects only deliver at the end and 5) can last forever.
The Project Management Institute (PMI) defines a project as “a temporary endeavor to create a unique product, service or result.” Wikipedia defines it as “Any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned to achieve a particular aim.” Neither definition fixes scope, budget, and deadline. Neither specifies that something is only delivered at the end or that it lasts forever. So, we seem to be talking about different things.
Formal definitions aside, even the most ardent project manager will acknowledge that fixing a project's budget, scope, and delivery date is a naively optimistic approach to the complex it represents. As it turns out, both PRINCE2 and the PMI Institute start from the assumption that projects represent complex work and are unpredictable and risky. So it seems that many Agilists have an extreme definition of “project” in their head than what is usually meant, making it an easy straw man to beat.
“Where the Scrum framework relies on empiricism (learning from experience), plan-based approaches like PRINCE2 rely on rationalism (learning by reasoning) — two fundamentally different approaches to managing risk.”
Projects and project management
So, although projects are not antithetical to the Scrum framework, how their uncertainty and risk are often managed is. Plan-based approaches like PRINCE2 and PMI rely more on upfront planning and governance to control risks. The Scrum framework works from the principle that no amount of upfront planning can control risk or release a product in small and valuable increments. Scrum uses each release as a feedback loop to adjust the course. Where the Scrum framework relies more on empiricism (learning from experience), plan-based approaches like PRINCE2 rely more on rationalism (learning by reasoning) — fundamentally different approaches to managing risk.
Busting The Myth
For some good Mythbusting, we always like to start with the source. One look at the Scrum Guide already offers a helpful perspective to think about how projects can be understood within the Scrum framework:
“Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something.”
The Scrum Guide also talks explicitly about products rather than projects. There is a Product Owner and a Product Backlog, not a Project Owner and a Project Backlog. There are several good reasons for this:
- Products are more tangible. That connects them more strongly to the idea that you’re delivering something of value to users;
- Products have a lifecycle. No one knows when a product will reach maturity or when it is shut down. It can be very short or very long. Either way, a lot of adjustments will be necessary along the way. This requires that we combine long-term with short-term thinking. If we make shortcuts now, we’ll have to pay for them later. But we also have to deliver something soon;
We don’t mean to say that projects don’t deliver value to users or encourage shortcuts. We merely point out that ‘Products’ evoke a more productive narrative as they are necessarily connected to users, continuous change, and value.
Tips for making projects work with Scrum
So, suppose you find yourself in an organization that works on projects. One strategy is to crusade to banish projects from the lexicon. A much more productive one is to start with what you’ve got and make it work in a way that supports empiricism. Here’s what we like to do:
- Make the scope of the project transparent on the Product Backlog and change it as new insights emerge;
- Consider what would be necessary to guarantee a valuable and high-quality outcome of the project, and embed this in your Definition of Done;
- The project budget determines how much work from the Product Backlog can be completed. When it runs out, and when there is value in implementing more, it can be extended as necessary;
- Every Sprint results in a Done increment delivered to stakeholders as a milestone and achieves a critical business objective. Feedback is used to adapt the Product Backlog as needed;
- There is a Product Owner, a Scrum Master, and a Development team. And they have a full mandate over all decisions concerning the project (or the part of the project) they’re working on;
- Create a roadmap for your project by putting the Product Backlog on its side. This tells you in what order things will happen;
- If there is a Project Management Office or Steering Committee, work with them to make the above possible. As results start flowing, the need for extensive planning will decrease;
- Project managers can be a great asset to Scrum teams. Provided they respect the Product Owner and the Scrum Master in their roles, they can help coordinate with stakeholders, deal with organizational politics, and remove impediments;
“Project managers can be a great asset as part of Scrum teams.”
The conversations you have while doing the above will be far more productive than fighting against using the word “project.” Or by claiming that everyone “needs to adopt a product mindset instead of a project mindset” (whatever that means). If you start with what you’ve got and work empirically, you'll notice that all those things will begin to change.
“Becoming ‘word police‘ is rarely a good way to engage people in changing their behavior and understanding of how things work.”
Concluding thoughts
We made a mistake in the past to start correcting people on how they talk about work. Whenever someone mentioned “project”, we would correct it to “product”. With a pedantic tone, we would explain that “we’re building a product here, not doing a project” (with an implicit “you silly”). But is this the proverbial hill to die on? It seems to us that there are far more critical conversations to be had, like:
- How can we ensure our stakeholders are involved in the project?
- How can we use each Sprint to deliver a tangible outcome — the Increment — that we can inspect with stakeholders?
- How can we start removing the impediments that are making this hard for us?
These conversations matter and are likely to drive change towards a more product-oriented approach implicitly. Rather than meeting people where you want them to be—and where you obviously won’t find them—you meet them where they currently are.
Becoming “word police” is rarely an excellent way to engage people in changing their behavior and understanding of how things work. Instead, it's far more likely that you will only create resistance by being pedantic about what people are used to. By doing so, you will close conversations instead of opening them. Ultimately, that’s what inspecting and adapting is all about.
