Over the last year Defra has started making the transition from focussing on projects to focussing on teams. The results of this have been great. More stability has meant work gets done more quickly, meaning we can deliver more great services for our users. “Focus on teams, not projects” even made it to the top of our list of digital principles.
I recently read a blog post from Public Digital which referenced our discussion on funding teams over projects. They changed the wording slightly, to “Fund product teams, not projects”. This struck me as a huge improvement.
What’s the difference?
Funding teams rather than projects was initially interpreted as having stable teams that could pick up a variety of different work. We could gain the benefit of having stable teams who worked well together, but also have the flexibility of refocusing them on the highest priorities.
Product teams will work on a single service or set of services indefinitely. They will combine expansion of services, adding new features to those services and maintenance on those services.
So what’s the benefit?
On the face of it we seem to be losing a lot of flexibility in using product teams. There are however huge benefits in this approach:
Greater stability
The big benefit of funding teams rather than projects was the improved performance that came from stable teams. The same applies if those teams carry on working in similar areas. Domain knowledge is hugely important when developing services. It’s a huge overhead if you need to relearn the domain each time you start a piece of work.
Proper maintenance and continuous improvement
If teams are continually dragged onto new things they never really get the chance to maintain and improve software. Not only does this result in lower quality software, but it also makes it harder to release minimum viable products. Who wants to see the minimum released when they know they’ll lose their development team the next day?
Reduced duplication
Usually when a new team approaches a problem they will start building from scratch. If you keep having new teams working in the same product area, they’re more likely to keep building new versions of the same thing. This results in lots of overlapping and similar pieces of software. This is both a maintenance headache, and a poor experience for our internal users. If a single team is made responsible for both the legacy software, and the new service replacing it, the result will be simpler for everyone.
Reduced legacy software
A good definition of legacy software is any software that’s not actively maintained. Any time a team stops working a service and moves onto something new, their knowledge of that service starts decaying. Eventually, as people leave the team that knowledge will disappear completely. By keeping teams working in the same area, we can retain knowledge for longer, and working with legacy software will be less of an issue.
A different way of working
Currently each year Defra figures out what its priorities are from an IT perspective. These priorities are then parcelled up and made into projects. This approach still works well with funding teams instead of projects. Instead of creating a new team for each project, you simply hand the project to an existing team.
Product teams would involve a very different way of working. Instead of working out our priorities annually, we would have to figure out what set of services we need to provide for the long term. We’d also want to group these together into products. We may have several services offering permits, but if possible we only want to build one permitting system.
How to fund this way of working
A big snag with this approach is how to fund this. Currently most IT development is funded using capital funding. This means that there is a short term commitment to invest an amount of money on building something. Revenue funding - that is an ongoing funding stream - is used to provide maintenance for systems at a much lower level. This model fits well for engineering projects. You invest a large amount to build something up front, and then pay less to maintain it.
It doesn’t work so well for IT projects. Funding product teams would mean investing a consistent amount of money over the lifetime of a service. If that service was something core to Defra, then that would mean investing a consistent amount of money for the lifetime of Defra.
Whilst this is undoubtedly a huge change in our way of funding, the change to a more agile way of working demands this.
This is how successful organisations do things
Changing to funding product teams would be a big change for our department. But it would be a big change that brought huge benefits. There would be less duplication, better use of legacy systems, and more consistency in service delivery.
The change to the approach to funding may prove a blocker to this approach, but if anyone unsure about whether it’s a good idea should consider this question: what do the tech giants of the world do? Does Google have an annual review to decide whether or not to do some development on their search engine? Does Amazon regularly parcel out work on their trading platform to a variety of different teams across the whole of their organisation? Or do they have a set of specialist teams working indefinitely supporting and expanding their core offerings?
I’ve spoken to people working for both of those organisations, and I know the answer is very much that they work with product teams. I think it’s something we should try.
