Over a million developers have joined DZone.

Do Annual Budgets Hurt Agility?

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.”

Creative Commons License Ken Teegardin

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 awway. 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?

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Daniel Ackerson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}