Agile product funding
Agile Product Funding and Teams
I’ve talked before about the problems with project teams and project funding. To summarise:
- projects are generally short-lived affairs, and can often leave a mass of technical debt and half-finished work behind them
- project teams are generally short-lived affairs, and project managers can willfully set them on death marches, since the team will be disbanded soon anyway and everyone will move on to some other death march
- the team has no long-term connectivity to a product or feature and thus is unlikely to build up domain knowledge and emotional investment in the product or feature.
So what’s the answer?
Product teams, not project teams
Traditional software delivery is done with project teams, usually in a matrix structure. That means that people report to both a line manager (who is usually a leader of people with the same skillset, e.g. testers report into a test manager) and a project manager (who will have a bunch of people from different skills and capabilities reporting into the project they are running). The line manager does the “people management” stuff (i.e. career development, succession planning, leave, performance, etc.), and the project manager does the “work management” stuff (tracking scope, risks, issues, money, etc).
This might seem sensible but it has big problems:
- the manager responsible for a person’s career plan and development have no connection to that person’s work
- people have no long-term connection to a product or feature
- the line managers can screw projects or project managers by shuffling people around at will.
The solution is to use something like the Spotify model, where you have tribes and guilds.
Tribes and Guilds
Tribes are product / feature / capability teams. A small cross-functional team that looks after the end-to-end delivery and management of a specific product or part of a product. Guilds are a collection of people who all share a similar set of skills and interests: e.g. database or iOS development or product management. Guilds have chapter leads who are basically people responsible for improving the overall performance of the people in the guild. But they are not part of a particular tribe or responsible for feature development.
This is a win-win situation: you can build up dedicated teams responsible for the long-term ownership of a product or feature, but you also have communities of professionals with specific skills and interests, headed by what are really “practice leads”.
Product funding, not project funding
So that’s the organizational structure side of things. What about funding?
Traditionally, IT work is done as part of project budgeting, a process where funding is released for one or more projects over the course of a financial year. This is a terrible system for a number of reasons:
- the funding is in large chunks and is tied to large complex business cases, full of unreasonable assumptions and missing information
- the process to secure the funding is long and cumbersome
- the team is expected to spend all of the money and deliver the project, even if partway through it turns out to be a bad idea
- the funding is tied to specific benefits which are in turn tied to specific features, all mapped out 12 months in advance
- there is, therefore, no room to pivot or innovate.
Agile product funding to the rescue!
Agile product funding
I propose a simple system where small cross-functional teams are assigned to workstreams that have a continuous flow model of funding.
There are four funding decisions that can be made: Seed, Fund, Retire, and Kill.
Seed
A team is given funding for three sprints, to build up a prototype or MVP and gather learnings. These learnings can inform subsequent decisions (likely either Fund or Kill).
Fund
A team is given funding for two sprints of work on the feature, to maintain and extend it. Over time, the proportion of activity spent on maintenance versus new development will gradually shift. I think two sprints is fair because having a team constantly living one sprint away from running out of funding is tough. It can often take a sprint to wind-down, retire and hand over a feature. I talk more about this below.
Retire
If a product owner feels it is no longer worth adding new features to a product or capability, but it is worth keeping around, they can choose to retire it. It means basically switching to a maintenance mode. Ideally, the team that built it should still own it. They will just have to factor in 10% or 20% or whatever of their time to keeping it running, fixing incidents, and so on. So it will require some funding but a lot less. It can also be handed over to a production support team, but that is generally an unhappy situation.
Kill
This is the final decision to shut a product down; no more funding. Keep in mind though that killing itself is work with a non-zero cost and should generally take at least a sprint (change management, comms, data cleanup, retiring domains, etc). A lot of organizations forget this and leave things in a horrible half-dead state. Kill it properly!
How the Agile Funding process works
The senior product owners should be working with all product owners in their portfolio to continually review their products. The process is to continuously monitor and forecast the value of these products and to put together a set of decisions for each sprint to seed, fund, retire or kill. Obviously, if a team moves into Kill mode, it will become freed up to Seed the next sprint. So there should ideally be a backlog of product ideas that teams can move on to at relatively short notice.
This is the first article I’ve written on this topic, and it’s a hard one. There is also not much material on this topic, so I’m figuring this out in my head as I go.
If you have ideas or questions, please send them my way. I will probably revisit this article as I figure more of this out.
