I’ve talked before about the problems with project teams and project funding. To summarise:
So what’s the answer?
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 solution is to use something like the Spotify model, where you have 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”.
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:
Agile product funding to the rescue!
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.
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).
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.
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.
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!
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.