by Bas Vodde
In a good and evolved LeSS adoption, there are no projects in product development.
— Bas Vodde
In LeSS, development changes from project-based development to product-based development. What does that mean in practice?
Project-based development uses the concept of projects for managing work. A project has a goal, a relatively fixed scope, an expected timeline, and is funded and prioritised as one whole. When a project is over, it is over. If you want new work to be done, you’ll need to fund a new project. Management often assumes projects are independent of each other, while that is rarely true when they use the same technology infrastructure.
In product-based development, the construct and concept of projects is not used. Instead, we define a product broadly. Then we speculate about the large features we might want and put these on a roadmap. A Product Roadmap is a high-level view of a Product Backlog. The product is funded as a whole based on the value of the currently speculated features. Teams work from the one Product Backlog until the product ceases to exist. A release is simply a point in time where we decide to ship what we have right now. Ideally, this happens as often as is feasible.
Key shift:
From funding temporary projects → to funding a long-lived product.
Unfortunately, for many companies, ditching project-based development is too large of a change as their entire funding and governance models are project-based. In that case, what can you do? It is possible to create project-based funding and reporting while doing product-based development. It has its drawbacks, but it is a reasonable intermediate strategy until a change in the governance model is possible to be discussed.
How does it work? The company still plans and funds projects like they’ve always done. Then we take the scope of each of these projects and smash them together in one Product Backlog. However, each item has a project associated with it. This is hidden (as it is irrelevant) towards the teams. The teams work from the one Product Backlog without ever being aware of the existence of projects. Teams might even work on multiple projects in the same Sprint without being aware of that. But because each item is still associated with a project, we can create traditional project reporting as if there are projects in development.
Important:
Teams see one Product Backlog.
Projects exist only for funding and reporting.
I’ve seen this being used in several companies, especially banks and insurance companies as they tend to be project-heavy. In order for this to work, at least one change is required. When funding and deciding on projects, they should have no assigned fixed people to these projects. This change can be different as people in companies want to secure ‘their’ project by having dedicated ‘resources’ on them… Hence, this simple change often requires a lot of discussion but it has been done before.
Eventually, we would recommend getting rid of projects completely. Keeping projects (even just for funding) causes a lack of flexibility in your development and an unnecessary additional complexity. In a good and evolved LeSS adoption, there are no projects in product development.
RSS feed