First there was the agile manifesto: a revolution in our ability to deliver customer value through software. Agile taught us to take small steps and constantly assess our progress against a sometimes moving target. The benefits were obvious, but the agile manifesto intentionally didn’t say anything about how to organise delivery teams in the context of a wider business.
For that, we’ve historically used the idea of a “project” - a collection of people with a sometimes unclear mission, a project manager, a budget and usually an ambitious date to deliver by. It clashed with agile because usually too many things were fixed too early in the life-cycle, but smart organisations also noticed that projects tend to clash with each other:
they require the same people
have technical dependencies on one other
functional overlaps
all want to go into production at around the same time
fight each other for limited capital investment budgets
Organising a delivery portfolio around products instead of projects has major benefits:
No Dependencies - the delivery team scope is the whole product, i.e. the thing that the customer will experience. This means any change on the web site, back-end, billing system, is owned by the team. No endless meetings about dependencies.
Managed Resource Conflicts - of course specialist skills may still be required by multiple teams. But because a team manages their own scope, when they don’t have access to that resource they can work on the next most important thing. No more time lost to waiting for people to become free.
Speed - a team that has a clear mission moves faster. A large problem in enterprise projects is people join not really knowing what their objective is. Not only does that waste time but it’s highly demotivating.
Customer Centric - what, really, is the most most important thing in any delivery? The customer, obviously. Some would say sales revenue, and you get that from having more or better customers. Some would say efficiency, and you get the luxury to work on that if you have revenue from customers. Purpose? (comes from customers). Beat the competition? (steal their customers). It’s all, directly or indirectly, about the customer. The problem with projects is it’s often hard to work out who the customer is. Or, if it’s the actual customer, then many projects don’t own enough of the end to end experience to really understand what good looks like. In a product team, it’s obvious.
Companies that are mature in the product space are organising around products. And even creating funding models for them without the usual end of year crunch and squabble to work out which projects to fund. Strategy becomes easier too because it has to centre around long term targets, the customers and the products they interact with.
Roles in product teams are still agile but holistically so. Product developers, analysts, and owners need to think in very customer-first terms, build requirements around tested hypotheses and constantly question where the next most valuable feature lies. It’s not a direct switch from project thinking and that’s why we at Productbase put so much effort into finding experienced delivery people who get it.
If you’d like out find out more please drop us a line.