Projects are most of the time considered part of a system for creating and delivering value. According the PMBoK® Guide other components in such a system also often contain portfolios, programs, products, and operations. Together these components create deliverables that, once used, produce outcomes. And outcomes can create benefits – gains realised by the organisation.
The difficulty for a customer and a project team with the concept of ‘project’ is that a project team is typically not accountable for the value delivered. A project, by its very nature, is finite. It stops. And it stops more often than not at a moment when the value is not yet shown. It stops when the deliverables, the outputs, are made available for use; sometimes extended with a guarantee period. Moreover, once a product is in use, there are new insights on how to make the solution even better. Only by then the project is finished. So change requests, or new projects, need to be initiated.
So what about projects then? Do we have to forget about them all together?
Let’s have a look at what the Scrum framework has to offer as a system for delivering value.
First of all the Scrum team is accountable for value. More precisely, the Product Owner accountability, which is part of the Scrum team, explicitly states that “The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team”. In order to achieve this, close interaction between the users and the team is needed, so that there is a mutual understanding of what is valuable, followed by a validation that the intended value is indeed achieved.
Secondly, the Product Backlog, stating the ScrumGuide here: “is an emergent, ordered list of what is needed to improve the product”. This Product Backlog exists as long as the product is being used, as long as it is not decommissioned. Any requests, be it big or small, to improve the product, enter the Product Backlog. There is no end to it, until the product stops existing.
Let’s look at some scenarios.
A small change is needed to a product. It is expected to take maybe a couple of weeks by one team.
A project focussed organisations would need to launch a change request. Once approved by a Change Advisory Board (CAB) or similar, a support or maintenance team is expected to take up this request.
A product focussed organisations would add this smaller change in its Product Backlog. Which would then be further refined as needed, and implemented alongside other needs. This by the team(s) working to keep improving the product.
Another scenario is that a big change is needed to a product. It is expected to take over a year, and multiple teams will work on it.
A project focussed organisations would launch a new project, and have a new team (or multiple) assigned to it.
A product focussed organisations would add this big initiative as an item in the Product Backlog. Which would then step-by-step be refined, and implemented alongside other needs for this same product. The team(s) working to continuously improve the product would take up this need.
A third scenario: there is a really big change needed, and multiple products in the organisation are impacted.
A project focussed organisation would launch a new project, probably even a program, and have new teams assigned to it.A product focussed organisation would talk with the different product managers involved (a.k.a. Product Owners), and each of them would add the necessary changes to their own Product Backlog. The teams working to continuously improve the product would take up this need.
In this third scenario, the remark I often get is: “But hey, these changes need to align. It all has to go into production at the same moment!”.
My first thought is then: are these then really separate products, or has an artificial split taken place because of whatever reason, but certainly not having taken the end-user into account… And in fact, should this then be one single product…?
Exceptionally, (I assume, never had it honestly…) there are hard dependencies between products.
Given the accountability to maximise value is in the hands of the Product Owners, let them align. They know their markets, they are adults, so they can figure out how to best deal with these dependencies.
In case we are talking about technical dependencies (which is a very strong indication these should be one single product…), let the developers align.
Summary:
Scrum deals with projects and change requests for a product by adding these big and smaller items to the Product Backlog. The regular teams, used to working on it, and therefore having a good understanding about the product, take up the work as ordered in the Product Backlog, alongside other needs that are already listed in that same Product Backlog.
Prompt:
Evaluate within your organisation how much changes are still required after a project is finished. Inspect who is implementing these changes, and how knowledgeable these people are about the reasons that led to the architectural structure, to the user interface, and to any of the product aspects.Evaluate what would be a better approach making professional use of the Scrum framework and what a first good step could be.
I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact.
If you want to take a deeper dive into the concepts we are covering in this blog series, then surely check out our Professional Scrum MasterY workshop. We have some scheduled in the coming period.
Don’t want to miss any of these blog posts? Have the “From PM to PSM” series weekly in your mailbox.
Wishing you an inspiring read and a wonderful journey.
Scrum on.
Steven
__________
Project Management Professional (PMP)®, PMBOK® Guide, PMI® are registered marks of Project Management Institute, Inc.