Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve complex problems with an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths. In this series of posts we — your ‘Mythbusters’ Christiaan Verwijs & Barry Overeem — address common myths and misunderstandings. The great visuals are by Thea Schukken. You can find previous episodes here.
Want to listen instead of read to this blog-post? Listen to us reading 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 that we frequently hear in our work with passionate Scrum Teams, like “Scrum is about products, not projects” or “Projects have no place in Scrum”.
And yet, the reality is that many organizations work with “projects”. Now, what they exactly mean by that word varies hugely, but it is usually considered a long-running group of activities towards achieving some goal. We’ve found that if your aim is 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 wider 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 is that a 4) projects only deliver at the end and that they 5) can last forever.
Interestingly, the Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken 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 they last forever. So we seem to be talking about different things.
Formal definitions aside, even the most ardent project manager will acknowledge that fixing budget, scope and delivery date for a project 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 that they are unpredictable and risky. So it seems that many Agilists have an extreme definition of “project” in their head than what is normally meant by it, and that makes 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 themselves are not antithetical to the Scrum Framework, the way that their uncertainty and risk are managed often 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 as well as releasing a product in small and valuable increments. Scrum uses each release as a feedback-loop to adjust course. Where the Scrum Framework relies more on empiricism (that is learning from experience), plan-based approaches like PRINCE2 rely more on rationalism (that is learning by reasoning) — two 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.”
Other than that, the Scrum Guide specifically talks 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 is going to 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 to value.
Tips for making projects work with Scrum
So suppose you find yourself in an organization that works with projects. One strategy is to go on a 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 budget of the project is what 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 that is delivered to stakeholders as a milestone and achieves an important business objective. Feedback is used to adapt the Product Backlog as needed;
- There is a Product Owner, a Scrum Master, and Developers. 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 as part of 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 that you have while doing the above will be far more productive than fighting against the use of the word “project”. Or by claiming that everyone “needs to adopt a product mindset instead of a project mindset” (whatever that really means). You’ll notice that if you start with what you’ve got, and you work empiricism in, all those things will start 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 the 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 really the proverbial hill to die on? It seems to us that there are far more important conversations to be had, like:
- How can we make sure our stakeholders are involved from the very start of 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 to do?
These are the conversations that matter and that are likely to implicitly drive change towards a more product-oriented approach. 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 a good way to engage people in changing their behavior and understanding of how things work. Instead, it's far more likely that you only create resistance by being pedantic about what people are used to. By doing so, you close conversations instead of opening them. And ultimately, that’s what inspecting and adapting is all about.
