People who are passionate about Scrum usually don't love 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.” ❌
They are believed to be the opposite of what we're trying to do with the Scrum framework.
But is that 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.
Scrum 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 Scrum 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.
The Scrum Guide also explicitly refers to 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 shut down. It can be very short or very long. Either way, many adjustments will be necessary along the way. This requires that we combine long-term and 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.
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 approach is to start with what you have and make it work in a way that supports empiricism. ✅
Project managers can also 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. They can make the lives of the team members way easier!
So, even though I support long-term product thinking, changing this by 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 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!
For more details, check this article by Christiaan Verwijs.