Selling Scrum to Skeptics: Budgets

Scrum and agile (note the lowercase!) development techniques have been around for a few years now, and prominent companies use it in some form or another. However, I’ve seen multiple instances where clients and management alike will derail the whole notion of Scrum! It pains me to see it, so here’s a Part 1 (of many more to come) to help convince skeptics that Scrum can be good for you (just like apples!). This post will focus on a common concern I’ve heard: “Scrum seems nice and all, but how do we manage budgets?”

First off, budgets in Scrum are easy to track (maybe it’s too good to believe!). To try to better explain it, here’s a slightly different tack: developers scope out some incremental feature set to be built in a specific time period (the Sprint!). Think of that as our “box” of stuff that will be made. After the team runs a few Sprints, the output is generally predictable to a certain degree, effectively “box-able”. At that point, the Product Owner decides, do I want to invest in the “box” that the team scoped? Is there another set of stuff that you want to put in the “box”? And thus, the bottom line: whatever you choose, you’ll know with a generally predictable confidence that you’re investing a specific dollar amount for some return. And here’s the kicker: you can walk away if you don’t like where it goes after only two to four weeks! Could you say that about any other software project managed via traditional waterfall-ish techniques?

Second, big upfront estimation is passé. Too often, developers and project managers alike get asked for estimates that turn into budgets. Those budgets then magically inflate over time to become multiples of the original “number”! When you ask a team to create something new, you can certainly ask them to take the smartest way to create what you want. However, that’s not the same as knowing exactly what needs to happen. Whether it’s a stubborn remnant of classical project management thinking, or perhaps an inability to get away from trying to know everything, it just won’t work with new products. Here’s how you deal with it: what you should actually do is to understand what kinds of unknowns your initiative has. The unknowns you find out (via uncovery, but that’s another post for another day) offer you a level-setting opportunity for yourself and the team. Work with the team to understand what work needs to be done to answer the myriad of questions that you believe puts you into a position to “really build something for a version 1.0”. That will give you enough information to approximate an R&D budget, in effect. As with any initiative, there also needs to be a solid business case and an expectation of revenue, which is the counter-balance to your R&D budget. In other words, you have just created a cost-benefit analysis to justify some amount of spend for research and development!

Third, experienced engineering teams know that forming-storming-norming-performing is real. In my experience, good teams really take 6 to 9 months to come together and start to be star performers together. They’ll finish each others’ thoughts, challenge each others’ thinking, and create great things. From another perspective, people don’t just plug-and-play easily just because the skill set might be there. And so I would posit that the smallest unit of resource “currency” is really a team-Sprint (defined as the number of people multiplied by the number of work days in a Sprint), not a person-day. Yes, in a way, this does “lock” you into a unit of measure that’s relatively large, but the reality is that teams are here to stay. Once you’ve invested the time to let a team gel, don’t waste it by disbanding them at the first sign of new priorities. Instead, use the benefits of an effective team to estimate and drive budgeting decisions for the work that needs to get done. Leverage their expertise (domain or otherwise) to help you track and spend time and money wisely.

Conclusion: Budgets are easier to digest in Scrum than you might think. The smallest unit of measure should be a team-Sprint. Estimation isn’t that hard with effective teams, and changes to the budget can be handled much more easily! And best of all, if something doesn’t work, you don’t have to wait months to change direction; it’s a lot smaller now.

Comments are closed.