Do Annual Budgets Hurt Agility?

Ken Teegardin

Desktop application development is traditionally done in waterfall development mode. Specifications and requirements are gathered over a period of months before being unleashed upon a “pool” of developers for implementation. Development times run into thousands of man days after which a “beta” product is released to the QA team (or perhaps some very brave customers). After another thousand days of bugfixing, you slap a product version onto a shrink wrapped box, burn the CD-ROM and ship.

While it may be hard to believe, this is how the majority of software development has been done for almost half-a-century. The older the company, the better the chance they follow this exact release cycle. There are annual budget meetings to determine which departments and projects will gain the largest developer pools. It’s excruciating to watch these behemoths try to introduce agile into such an environment and I believe budgets are toxic to agile development!

Yes, we know that budgets have an extremely important place in every day business. This is how we plan our operating costs, growth and future development projects. However, when budgeting meets project management, there is no way to be agile. Take the following statement: “If we aren’t allocated these 10 resources tomorrow, there is no way we can finish this project within 12 months.”

Try to wrap your head around that sentence. Finishing the project says nothing about a customer release. And what exactly are these “10 resources”? Mainframes executing COBOL statements? Project managers frantically waving Excel spreadsheets? Developers attending specification meetings? Can we so easily secure next year’s release just by offering up these resources like lambs upon the project manager’s sacrificial altar?

My almost instantaneous answer to such a hollow statement is “Given these 10 resources and 12 months of development, you will never be able to ship a quality product.” And the reality is probably even more bleak – they won’t be able to ship anything at all!

Think about 12 months from now. It’s so far away. We can take our time building a sound architecture, something that will be infinitely scaleable, meticulously documented and a joy to use. See? Scope creep has happened already without a single line of code being written!

If you aren’t challenged to regularly engage the user, to ship your code at least once a month, you fall into a false sense of security – a dangerous reality distortion field is emitted from your project that can even have detrimental effects to projects that rely on yours.

Not all desktop applications follow such a cycle. Google has pioneered regular release cycles on the desktop with it’s Chrome browser (4-6 week release cycles). Now, if only we could get a glimpse inside of their PM process.

What do you think of annual budgets and their effect on scrum?