Oh darn! You’re in trouble. You’ve been working on this huge project for a while, with one or more Scrum teams, and management wants to have an answer to one or two questions: “When will it be done” and/or “What will it cost us?”. Despite your best efforts to convince management that it doesn’t work this way in Scrum, you’re hard pressed to provide a date and a budget. What will you do? Which answer will appease management and be compatible with an Agile approach?
The background of questions like these is usually risk management. Traditionally, risks in software development are addressed by providing a budget and a deadline for a (presumably) fixed scope of functionality. The assumption here is that we are capable of predicting upfront how much time it will cost us to implement a given set of requirements. In a sense, we also assume that we can control and predict the influence of a vast number of factors that affect our project (context, knowledge, team composition, coding skills, technology, communication, etc). Overwhelming, and undeniable, evidence from other projects has shown us that software development doesn’t really work this way. Projects - even fairly short ones - are fraught with uncertainties, complexities and difficulties well beyond our control and capability to predict. And this is the reality, not the theory, that Agile software development is trying to address with a wholly different way of managing risk.
You can’t blame management for wanting to limit risks. It’s part of their job, and what they’re held accountable for. In their shoes, you'd probably be asking the same questions. But by providing a budget and a deadline for a large set of functionality, we are performing in “Risk management theater”. We’re fooling everyone into believing that, despite the nature of software development, we can still offer a fairly accurate budget estimate and/or deadline and be accountable for it as well. The hard truth is that the budget will very probably turn out to be wrong, and important deadlines will not be hit. And everybody knows this, especially management. They’ve seen this happen with every other project. Ironically, this is exactly why the're asking these questions about budget and deadline ...
So, what is a good response that fits with the reality of software development (and the Agile philosophy)? We can’t just tell management that they’re asking the wrong question, right?
Let’s explore the background for the right answer for a bit. Agile software development, like Scrum, makes risks manageable by not putting all your eggs in one basket. Instead of providing a big upfront estimate for something we haven’t worked on yet, we are urged to deliver small, useful and valuable increments of a product in a steady pace instead. If these increments are as production-ready as possible (or preferably even taken into production), the risk of project failure decreases significantly. This is easy to understand; the more often you have a small (but workable) part of a product, the smaller the chance that the entire project will fail. Perhaps budget will run out at some point (this will happen), or a particular deadline will pass (this will happen), but this will not cause our previous increments to lose their (business) value and usefulness all of a sudden.
The right answer to the question about scope, budget and deadline is not to go along with the line of thinking that’s behind it. Unless you want to perform in “Risk management theater”. Instead, offer management a better way to manage the risks of a project. It’s nice that they’re willing to give you a large bag of money and a lot of trust that you can pull it off, but it’s better to give them a process that guarantees a steady pace of working software. Instead of upfront trust, you can offer them a visible and transparent process like Scrum that allows for frequent change and makes visible the progress of teams on a transparent backlog. Scrum will not magically make your project succeed, nor will it prevent mistakes and failures, but it will make them less costly because you can detect them more frequently as part of the iterative nature. Any manager worth his/her salt will see the value in this approach, and how it makes risk management in an agile environment much more feasible.