Why “project funding” and “project budgeting” does not fit an Agile world!
You all might have seen companies playing this “Agile” game and tell everyone in the organization to try to be Agile, and when a real…
Why “project funding” and “project budgeting” does not fit an Agile world!
Image from: https://businessagility.institute/
You all might have seen companies playing this “Agile” game and tell everyone in the organization to try to be Agile, and when a real opportunity comes along, like a new idea that needs to be “validated” to see if it is viable or not, the first thing people try to do, which could often take for weeks is “Estimate” the effort and go through the “Budget Approval” process!
Now the question is, what are we “Estimating”? all the hypothetical ideas that someone has? How do we know we need all these features?
The main problem with project funding is that, you’re funding a predetermined set of features or capabilities.
Scope is fixed. You’re judged on whether or not you can deliver those specific features with the money available.
That thinking effectively prevents agility.
In an agile world, you fund the teams, give them a strategic direction, and let them work!
You continuously assess the state of the product and make decisions about whether or not to continue or change direction.
If the product is not working out, then the teams work on something else!
Don’t get me wrong here, we are not saying Business doesn’t need to know what we are doing, what we learned. They are working with the team all the time!
In fact, this approach requires active and continuous business involvement!
In an Agile world, there is no “Project Status” meeting that tracks: Red, Yellow, Green statuses which is primarily based on the “Scope delivered” and the “Milestone date” promised initially. If there is any meeting to update status (which there shouldn’t be any, since everyone is knows all the learnings!) it should be reporting “what we learned so far” and “are we going to pivot or persevere”
You don’t just check milestones once a quarter. It’s a radically different way of working/thinking for many (most?) organizations.
Now people are going to ask, well, how do we figure out “our time to market” if we don’t have fixed scope and up-front planning and estimation in an Agile context?
That’s easy, I have a simple answer for you: A day or two!
In a waterfall org, you figure “time to market” by estimating your giant up-front plan and design. Agile shops don’t have those.
Also, since I have you here let me go on another quote here:
A “project” is an up-front plan.
If you are developing a software product, I recommend getting his User Story Mapping book:
User Story Mapping by: Jeff Patton
If you liked this article, click the👏 below so other people will see it here on Medium.
Let’s be friends on Twitter. Happy Coding :)
Cheer!