I was recently talking to a senior leader at a large manufacturing company. We were talking about how much he liked Scrum. It had ‘changed his life,’ he said, ‘It is a shame it is only aimed at Product Teams.’ Of course, I responded, ‘Scrum can be used by any team with a goal.’ The discussion quickly descended into the use of the word product in Scrum. And how that word can alienate teams that do not consider themselves product teams. For example, we talked about marketing teams, drug discovery teams, R&D teams, and service teams. They would all gain value from using Scrum, but what is their Product?
The debate about the use of the word product within Scrum is not a new one. However, the Scrum Guide update in 2020 and the increasing interest by IT organizations to align to a Product Model have increased the relevance of the discussion.
Product or Project or Something Else?
When Scrum was created over 30 years ago, one of the driving motivations was to move away from a work-pushed-down approach to one where teams had more opportunity for ownership. Traditional project-based approaches are management and work-driven, reducing team member involvement in the solution. Using a poor, illustrative example is like the difference between telling someone to walk 100 meters and telling them the goal is to climb that hill. Project approaches tend to focus on the tasks, and in large complex projects, those tasks become very disconnected from the objective or each other. Of course, a project could be more outcome-oriented, but the reality when Scrum was created was that most project approaches focused on decomposing work and optimizing throughput to specialized resources.
I will not discuss the difference between projects and product teams, as Joca Torres did a fantastic job in his medium article. In this article, he highlights the time-based focus of projects and the outcome focus of product approaches. This describes the difference in a nutshell.
Ultimately, Scrum used the term Product to reinforce that work is not the focus, but outcomes are. The Product is incrementally produced or modified one Sprint at a time. The Product has users and value, and the Product Owner owns decisions about the value that can be obtained from changes to the product, described in the Product Backlog.
Can Scrum be used for Project Work?
Of course, and in fact, many Scrum Teams are working on projects. The inquiry, however, exposes an interesting question. How are teams aligned? Are teams aligned around a skill, for example, software development or testing? Or are teams aligned to systems or processes, for example, claims or application RP150? In many organizations, teams are assembled from multiple departments. Those teams include all the skills necessary for that phase of the project. And because of the ‘lumpy’ nature of work, individual team members will be on multiple projects at any time. As the number of projects increases for any individual, team ownership reduces.
Defining Product
In the 2020 update of the Scrum Guide, the product is defined.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The phrasing of this definition is important. It describes some things that any team needs to be effective.
- A bound problem space - It is tough to get going if you have infinite scope. Knowing the boundary of your product sets some guardrails for the team.
- Knowing your audience - Delivering value has many stakeholders, users, and commercial organization customers. A clear understanding of the bound problem space enables teams to discover those interested parties.
What is missing from the definition is word value. Value is a crucial element in any formation of a product. It, on its own, must provide measurable value to someone. Value is crucial for the Scrum Team as it allows for another dimension of understanding a Product.
Product provides clarity and focus.
Thirty years ago, project management approaches and software development methodologies ruled the work landscape. The use of the word product sets Scrum apart from the other approaches. It also sat well with the early adopters of Scrum, who were, for the most part, product companies. But over the last thirty years, as adoption has increased instead of diminishing value, the word has provided additional clarity, and if you take the idea seriously, it can also focus by encouraging better alignment for Scrum Teams to customers, users, and outcomes. If someone asks me why Scrum is only about Products, I would say it enables:
- A definition of the boundary of the work and outcomes sought
- A conversation about value and what success looks like
- Help in defining the right stakeholders and users
- Improved clarity on how this work depends on other capabilities inside and outside the organization
- Organizations to look more generally at how Scrum Teams are aligned and what team members are working on
- A review of what might be better suited to project or product work
Using the word Product, like so many other words in Scrum, provides an opportunity to review how you work and the environment you work within. Rather than debate if this is a Product, Project, Service, or some other type of work, use this as an opportunity to help frame the work, better align the team to outcomes, and think about what value.