Project versus product mindset
I’ve talked a bit recently about project management and project managers and some problems in this area. More specifically:
- Traditional project managers don’t care for the long-term interests of the team
- Traditional project management isn’t interested in the long-term benefits of the project after it has been delivered
- Project management is designed for project work, and much software development is product work.
So what’s the solution? It’s about changing from a project to a product mindset.
Product teams instead of project teams
I think we need to move large organisations in a shift away from projects and towards products.
Most large organisations are either still operating on Waterfall, which means they have separate functional “component” teams (which is a bad thing, as I explained in this article). Or they have moved to some form of agile, and established cross-functional teams.
But the Scrum teams are usually a random collection of people hastily put together to work on Random Project X, followed by Random Project Y, and so on. The team have no stable link to any function or application.
The project manager can drag them through hell to deliver Random Project X, then disappear to another project, while another project manager comes along and sends them on a death march to deliver a completely different project.
Teams should build and own a “product”, in perpetuity
In Amazon, they have small cross-functional teams that build, own and run a small piece of functionality, which we can call a “product” (it’s not a product in the traditional marketing sense of the word, it’s more likely to be a feature in a website or application). They build it from scratch, deploy it to production, and look after it like it’s their own child. These are product teams, not project teams.
Product management instead of project management
Traditional project management has some failings, which I talked about here. One way to overcome these failings is to not think of work as a large series of discrete projects, with sharp beginnings and ends. But rather as a number of continuous workstreams based around products. And stable teams work on each of these workstreams.
The teams (including the product owner and “product manager”) are responsible for the long-term care and value of the product. Not in terms of what was delivered for a particular “project”, but in terms of how much value the product is providing to the business, year in and year out.
This will help get us away from situations where a project can come along, deliver something of little or no value, leave a big pile of bugs and technical debt, and run off into the distance, patting themselves on the back because “we delivered the scope, on time and on budget”.
Product funding instead of project funding
Instead of work funded via big “projects”, with specific features and benefits defined up-front attached to that funding, we should move towards pipelines of funding assigned to various “products” or workstreams. And those workstreams are prioritised based on how valuable and strategic that work is expected to be.
It is up to the product owner and product manager to use that funding wisely, adjusting as they go. Locking funds into pre-defined benefits and features gives teams no scope to pivot as they discover new information.
If you want to know more, I wrote an article about how “product funding” might work.
Scrum is for product development, not project management
One of the most common misconceptions in agile softwares development is that Scrum is for “project management”. More specifically, for “agile project management” (whatever that means – Jim Highsmith wrote a good book on it but the jury is still out on whether it is even a thing).
Scrum is actually a framework for product development, not project management. They sadly don’t spell this out very clearly in the Scrum Guide. But you can see it easily if you read between the lines.
Teams work from a Product Backlog, not a Project Backlog or Project Plan. Teams have a Product Owner, not a project manager. Each sprint, teams produce a Product Increment, not a project milestone.
Projects start off with all the scope defined and a plan to get there. The scope and plan can change, of course, but projects assume you know at the beginning all the things you need to do to achieve success.
Scrum is based on empiricism, which assumes we get knowledge from experience. So we will only figure out most of what we need to know, on the journey there. Not at the beginning.
So Scrum assumes and is based on product management. On the idea that we are building a product, starting from scratch, and figuring it out as we go. Based on the feedback we get from creating product increments.
Conclusion
Agile and Scrum are based on uncertainty and empiricism. On the assumption that we don’t know everything in the beginning. And that our work will continue in perpetuity. Do you think Facebook will one day finish their “Project Facebook”, and declare that there will be no more work done on Facebook? Since the project to build it is completed? Not a chance in hell. These big products will continue until their parent firm dies or collapses. Product thinking and product mindsets are completely different from project thinking. So make sure to get your head around these ideas before you start trying to bash an agile product square peg into a project management round hole!
