(Let me be clear up front: this is a potentially controversial post. It proposes radical change in the way we do things. But I feel strongly about it, and I think this needs to be said.)
Over the last few years, departments have been encouraged to adopt agile ways of working and service design thinking. Everywhere you go now, you can find multidisciplinary agile teams working on services, and making great progress. I'm part of one of those teams in Defra.
It's taken a few years for this new approach to catch on, but now it's caught on, the teams love it, and it’s delivering great user-centered services.
What hasn't changed in that time is the way everything is funded.
The traditional approach is to write a business case and create a project. Funding is found for that project, for a fixed period of time. When the predicted timeframe ends, so does the funding.
You can see the problem here: just as with designing services up front in a huge specification document, planning projects in extensive detail up front can lead to real problems. In real life, service development is complicated and unpredictable. The whole point of agile is that you find out what users need instead of making assumptions. But when it comes to funding, we're still making assumptions about how long each piece of work will take, and how much it will cost.
The result is friction between the teams doing the work and the people agreeing the budgets. That friction gets in the way of delivery and slows us down.
What's wrong with funding projects
Using the traditional project-based funding method, projects are given a finite length and budget. Changes within the scope of the project typically mean we have to go back to the approvals board (the decision-making body that decided the budget in the first place) to ask for more money or more time. The development of a service may be split up into multiple projects, or may be completed as one. Or it might be stopped completely.
The project model says: “We can predict what we'll be doing for the next few months, how much that will cost, and the benefits we’ll get from that work.”
The reality is that this was never true for either traditional or agile development. Predictions can be made at a high level at best, but typically plans are out of date within weeks, not months or years. The funding model assumes nothing will change. But things always change, and the funding mechanism isn't flexible enough to cope. There's no easy way to increase or decrease the budget, or to change the direction of development.
The project model says: “We can have a high degree of flexibility over how and where we spend our money.”
The cost of starting up a new team is rarely taken into account when putting together a case for funding. This means that to someone approving funding, the cost of stepping down a team by discontinuing a project isn’t taken into account. The implication of this is that if a funding request is turned down, then the money won’t be spent. But as long as we have permanent staff, those staff will carry on drawing a salary. Relying more heavily on contractors is not a solution - that just adds to the start-up costs for new projects, as well as the ongoing cost of staff turnover.
The project model says: “Approvals boards are best placed to decide on the direction a service takes.”
Approvals boards are made up of very senior, very busy people. They rarely have the time to decide the direction service development should take. (It's hard for them to have time to attend things like show-and-tells and user research sessions too.) Agile methods promote empowerment of teams, so ideally, a full time member of the team (the product manager, for example) should be responsible for making these decisions. By shifting product decisions to the teams, we free up time for the approvals boards to focus on wider strategic planning (more on that below).
In summary: the agile ways of working we're encouraged to adopt are weighed down by governance that is far from agile.
Why it's done this way
When you stop and think about it, you can see why projects are funded like this.
Agreeing project budgets up front provides certainty. There's only so much money in the pot, so if you have multiple requests for funding you can decide which ones have priority. You can see how the various projects align strategically with what you are trying to achieve. You can decide how many projects you can afford to fund in a single year.
But the reality is that none of those things are certain.
The certainty is an illusion. Real-world problems will interfere with plans and budgets. Projects will fail, because they break out of the rigid constraints they were devised under.
Funding teams instead
What if we changed our funding model? What if we started with teams, rather than projects?
I think we'd achieve more if we:
- allowed teams time to learn, grow and mature
- gave them a pipeline of work to tackle
- let them decide whether each piece of work is cost-effective, and progressing well
- let the team leaders decide whether continued investment in the team is cost effective
Under this model the role of the approvals boards would change: instead of project-by-project control, they focus on the wider strategy. They’d prioritise what’s in the pipeline, work with teams to decide when they should move on to the next item in the pipeline, and decide when we need to scale up and build more teams.
Let's make funding more flexible
We’ve updated the model of development, moving from projects to agile service design, but we haven’t updated the funding model to go with it.
That disconnect is slowing us down. It restricts our ability to develop great services. If we thought about funding in the same way, and started to fund teams to work their way through pipelines of work, I think we'd cut down on that friction and make better progress with transformation.
The good news is: senior people are already thinking about this, and taking steps to change it. I hope to be able to write another post here in a few months with an update on progress.
31 comments
Comment by Clare Sherwood posted on
David, this is the model that the I want to fish team have tried to take They've got some great examples that support your blog. Great blog by the way.
Comment by David Thomas posted on
Thanks Clare. I've had an email from Mark Sherwood already so I'm looking forward to hearing how they were able to take this approach, and how it has worked for them.
Comment by Claudia Wootten posted on
David you have made some well argued and strong points in this blog. Well done. I really do agree with a lot of what you say. Do you think the Product Ownership model, cradle to grave ownership of a service/product could be a way forward. Fund the standing team as a matter of course and they can be supplemented through initiative funding when bigger items of need are required. ? This way you build a team of product experts who have a guaranteed future together and who are invested in the success of the product/service from delivering backlog items to smooth running and invested in the team itself.
Comment by David Thomas posted on
I would definitely with this approach. I think having continuity in the Product Owner role is one of the most important parts of building a service team.
I would be slightly wary of initiative funding. My thought would always be, how quickly can the additional people joining the team fit with the people who are already there?
How quickly you can scale up and down for such an initiative would be very dependent on the size and stability of the core team, but there should always be some flexibility as requirements change.
Comment by Marc Humphries posted on
David, love your blog and agree with your reasoning and view. Hope to see a follow up blog soon.
Comment by allan kelly posted on
Great!
This is broadly the approach I've been advocating for a while - Team Centric Development, or Stream Based, or, the most controversial title #NoProjects.
I've settled down to calling it Continuous Digital because in a "digital world" all change is going to be technical, you need to keep doing it. Within that teams need to be "value seeking" and governance needs to be based on results. In fact, it all looks a lot like the venture capital model.
If you ping me I'll happily send you a copy of my work-in-progress book about this, Continuous Digital, https://leanpub.com/cdigital/
Comment by David Thomas posted on
Thanks for the reply Allan.
I like the name Continuous Digital. I think emphasising the importance of continuity is crucial. Like anyone in the Agile world I believe in the importance of embracing change, but that also comes with understanding the cost of it. That is why most change should be incremental.
A copy of your book sounds great too. I'll drop you an email.
Comment by ylorph posted on
I agree with the gist & reasoning of this article.
But from a business perspective, I don't think a (particular) team needs to be funded .
What needs funds is the process of solving the problems & it's pipeline of work
Thinking in those terms allows/forces everyone involved, decision makers & teams, to talk to each other, prioritize & allocate the funds to a specific bunch of work with a shared understanding of why & how .
Comment by David Thomas posted on
Thanks for the comment.
I absolutely agree that a pipeline of work is crucial to making this work, and I think the governance involved in the approach I'm suggesting is to do the prioritisation you describe.
I also agree that what needs funding is solving problems, but I think that teams are the main tool we have for solving those problems. This is why I think funding teams and then allocating them work is the way forward.
It feels to me like we're in agreement in what we're after though, a prioritised list of problems to solve, with continual funding to complete that list. But as a Delivery Manager, I would say that a continually funded set of teams will be the most effective way of solving that list of problems.
Comment by Daniel Penny posted on
David, This seems eminently sensibly especially given the often extreme longevity of the full system lifecycle.
With a team that's knowledgable, and in place, long term iteration can actually be of real user benefit - rather than "completed" projects being seen as technical debt, and the users' ongoing needs relegated to 3rd-party turn-around times and costs.
Comment by David Thomas posted on
Thanks Daniel.
I've often seen the situation you've described as a strong push-back against delivering value early. I've worked with business teams where there is a (not unreasonable) fear of losing the development team they're working with as soon as anything is out the door.
Re-phrasing all development as continuous improvement should work to combat this. After all, even greenfield work is just continuous improvement on a blank slate.
Comment by Dale Mellor posted on
At the moment we have a matrix structure: organizations (universities and businesses) run teams, and teams run portfolios of products, from where funding comes. I happen to think that on the whole this is the best way to do it, but I think we don't give enough momentum to successful teams but funding bodies seem always to be trying to disintegrate them along with the bad ones.
Comment by David Thomas posted on
Thanks for your comment Dale.
I think the willingness to disintegrate teams is understandable given the project based mindset. When working this way it seems like there is little cost, and perhaps even a cost saving in breaking up a team.
Those of us who work in the teams though see the cost of breaking up teams, which is why it is the project mindset that has to change.
Comment by Michelle Brockley posted on
David, great blog. The funding approval challenges become increasingly complex when you are involved in a project with funding streams from a number of different budget holders in different areas of the business!!
Comment by Frieda Davies posted on
This is a great blog and really outlines the challenges within Defra to deliver value when surrounded by constraints. As said this way of funding is not supportive of user needs- yes it allows us to deliver them but not to be flexible with our learning and testing of the possible outcomes. I hope that there is a way forward that allows the satisfaction of managing funding, transparency of delivery and most importantly continuing to deliver successful services.
Comment by Kevin Hall posted on
interesting Blog 🙂 it may be argued that we don't fund projects in the way described even now. Many departments articulate their vision for the future, the kinds of outcomes they would like to achieve, the benefits of doing these things, and the budget needed to achieve these things. Through the planning processes senior managers will either agree or disagree with this and appropriate funding will be made available. Projects are just a structure to manage and control delivery of these things. Part of this will be the justification of spending part of the funds that have been made available, usually this is done via the production of a business case. If there is valid justification, permission is provided to spend the funds made available right up front. Digital teams therefore should have funds available to them (if the case was made during the planning process) and IF they can justify why the funds should be spent on the things they want to spend the money on they can crack on and do the work. There are constraints I know, our annual planning process doesn't help, but there are probably some very simple things we can do right now which will help improve the way we deliver our digital services. Happy to be involved in any further discussion
Comment by David Thomas posted on
Thanks for the comment Kevin.
I think the main issue with what you describe comes when you look at teams justifying what they want to do.
If a team fails to justify what they're doing, they're still being paid for. So only allowing them to work if they justify what they are doing, doesn't save any money, but does result it teams spending a lot of time and money justifying their existence, rather than developing services.
There needs to be a shift from only doing work when it's justified (which is an impossible goal) to maximising the value from the money we want to spend.
Comment by Andrew Graham posted on
Thanks for taking the time to put this together David. It is a well thought through and compelling argument.
I agree that the challenge with current 'project' funding models is that they provide a spurious level of confidence in assumptions over the costs, benefits and the nature of the service itself before we know enough about our users' needs and the services we need to transform to address them.
I also believe that the current funding models are a reason that many projects that should fail are not allowed to (or do so really slowly and painfully) because there is too much financial and emotional investment in defining what the service will look like and the associated costs and benefits at too early a stage in service delivery.
Comment by David Thomas posted on
Thanks for the comment, I'm glad you enjoyed it.
In the short time I've been here I've actually seen a fair bit of the opposite to projects being too slow to fail. I've seen a fair few Discoveries which have had positive outputs but not gone ahead. This is because it is easier to justify a Discovery than an Alpha or Beta.
Whilst it is important that the output of a Discovery can be stopping work, that should be as a result of the Discovery, not just a result of continually shifting priorities.
Comment by Adrian posted on
Good point with much wider implications than you raise I think. Working local government teams have been stripped back to the bone due to all the funding cuts, so now various things can't be handled by those teams. Any need for development or transformation or even work to support individual initiatives becomes hard to do, so project teams get setup. These project teams have no particular connection or experience with the topic, the lines of management are different and the thinking behind it all is not connected. At times this leads to duplication of effort, a lack of understanding of what a project is doing from the 'business as usual' people, a lack of understanding of the day-to-day realities by the project people and at the end of it, something is hopefully delivered and the 'business as usual' people are potentially expected to pick something up and carry it on with little understanding of what it is.
Were the usual teams funded better a lot of this could probably be handed more efficiently, get a better outcome and be more integrated but there are the same funding issues you raise.
Comment by David Thomas posted on
Thanks for your comment Adrian.
What you describe is why keeping teams stable and working on the same thing should be the norm.
It should be possible to change what a team is working on, but as this loses all the knowledge that team has built up, this should be seen as unusual at the least.
It should also be possible to break up a team, but this has a huge cost implication in terms of losing the shared ways of working from that team, so should be seen as an extremely drastic course of action.
As you describe though both are too common.
Comment by paul collinge posted on
A good and very well written blog. What if we were to think of each new digital initiative as a start-up. It is the team and their track record angel and VC investors back as much as the business idea - so I agree the focus on team is key. But to get the funding even in the early stages you need a vision, an outline proposition and a business case. The start-up then grows and passes through different funding phases. As the entity matures the funders change, the sums of money increase, and so does the scrutiny and burden of proof. Three thouhts crossed my mind (1) can you consider early stages such as discovery and alpha as ''research budgets'' before the full business case kicks in with beta - this would allow for more flexible financing approaches (2) can you apply commensurate controls to each phase for senior management oversight (who are afterall accountable to the tax payer for their spend decisions) (3) Finally it is rare to find teams who follow the journey all the way through from initiation to large entity - different skills are needed as the business/service matures - so its creating teams but flexibly using resources from the respective profession communities - maybe these are the teams to fund to build, retain, and develop your baseline capability
Comment by David Thomas posted on
Thanks for your comment Paul.
I like the Lean Startup/Enterprise approach described and I'd be interested to see it in action within government.
A couple of things I'd want to focus on though is that teams are encouraged to fail numerous times before they're moved on to a different business area. One crucial part of of the VC based approach is that teams are essentially trying to prove a series of hypotheses, but failing to prove a hypothesis shouldn't result in funding being withdrawn.
I'd also want to avoid the idea that funding gets withdrawn if a team fails to prove their worth. If the area a team is working on really has no value they need to be reassigned, withdrawing funding doesn't save money (they still need paying), but does have a cost (an experienced team is broken up).
Regarding your other tree points:
1) I'd agree that business cases in Discovery and Alpha should be more limited and there is government guidance to that effect (https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent/agile-digital-and-it-projects-clarification-of-business-case-guidance).
2) I think the nature of those controls should change. Given that we can't easily scale up or down the amount we are spending (people have contracts that need to be honoured), senior management need to focus on justifying why the work we are doing is the most valuable, and why they need more or less money to do it.
3) I agree about the need for flexibility with teams as well. So whilst teams should be continually funded, and they should broadly stay the same, undoubtedly over time they will need to change and evolve as different skill sets are needed.
Comment by Katy posted on
Completely agree. Thanks for writing and publishing this 🙂
Comment by Doug Balfour DDTS IOC posted on
Whilst I don't agree with many of the assumptions and statements, the arguments are well thought out and considered.
I fully endorse the view that there is a better way of doing things and full credit to David Thomas for bringing this do a wider audience and stimulating the debate.
Comment by David Thomas posted on
Hi Doug,
Thanks for your response. I'd be really interested to know which of the assumptions you disagree with. I tried to give an accurate representation of the current state of play as if I didn't the argument for change would be a weak one. So if I have misrepresented anything I'd be keen to know what.
Cheers,
David
Comment by Max Gentleman posted on
I agree with the premise on the article - but I'm left with an open question:
How, then, do you prioritise which initiative should take priority over a different one? The business cases with [mostly wrong] long-term benefits are far from idea but it does put a number by which senior executives prioritise the work.
It we take that away, what levers do I have available for doing initiative A instead of initiative B.
Perhaps what you're proposing is simply removing any notion of funding from the business case but still having business cases which try to argue for the potential benefits - i.e.: cost reduction - of the initiative.
Would love your thoughts on this.
Comment by David Thomas posted on
Hi Max,
Thanks for your response.
It's certainly a complex question so I probably won't manage a very complete answer here, but I've got a few thoughts on it.
My first is that I'd take those decisions away from senior executives. Having very senior people making decisions based on limited and inaccurate information is going to be worse than less senior people taking decisions based on more complete information. Benefits of development are often hard to quantify which means that senior people with limited time do end up making decisions based on poor quality estimates. People with more time and more engagement will be able to make better decisions.
My second is that I would move away from business cases for large pieces of work. If development is done incrementally (with releases every couple of weeks), then it becomes possible to judge a team not based on what it promises but on what it has released.
I'm certainly not against forward planning and an estimation of benefits. This is crucial to allow prioritisation of work. However I think the current approach to this ignores the limitations of forward planning and benefits estimation.
For a more detailed description of this kind of decision making approach I can heavily recommend the Lean Startup and Lean Enterprise books. They go into a lot of detail as to how you should be selecting what initiatives take priority.
Hope that helps,
David
Comment by Hakon Rostad posted on
Great blog.
Any update on funding of agile teams?
Comment by David Thomas posted on
Hi Hakon,
Sorry for the delayed reply. We've made some progress, but there have been a fair few challenges along the way. I've finally got round to blogging about this though: https://defradigital.blog.gov.uk/2018/05/21/funding-teams-is-hard.
Enjoy!
David
Comment by Raj Kissy posted on
Hi David,
I agree with the post.
In order for organisations (public and private) to adopt this approach, they need to essentially put trust in the process and Product Management function. This is easier said than done because the people who normally control the money, are the same people who have been business sponsors in the past and made a fair few assumptions over time (and more importantly are scared of change, as it may feel like they are being removed from the system, when in-fact it just allows them to make the decisions based on User Research etc).
Personally speaking, having a mature Agile/Product Management mindset with a real appetite for User Centricity is the only way majority of the organisations are going to survive the post-internet world (https://www.youtube.com/watch?v=yVIe1MOpiHU, this is why your post is so relevant in todays age).
Thanks
Raj