Agile Arguments, Part 3: Arguments from Time and Money
In this part 3 of my Agile Arguments series, I’d like to tackle the very common question — whenever the word ‘agile’ is mentioned among people who have budgetary control of some sort — that goes something like, ‘With Agile, how can you ever budget for time or money on your project?’
The answer is, “It’s simple, you budget for time or money.” Agile methodologies don’t simply ignore this fact. In fact, they are centered around this key issue. With Agile, delivery and delivery often is key. The point being that the more often you deliver and the more often you solicit input into the process, the more often you will be able to a.) gauge that process’ progress and b.) make course corrections as necessary. Don’t delay the hard decisions to the end when they will necessarily be big and costly. Make the hard decisions early and as often as necessary. They will be much less costly this way.
At least in my mind, the most effective way to deliver software in a time- or money-boxed scenario is to not spend a bunch of time up-front planning and designing, but to start coding what you know to be true today so that, at the very least, you have something to show for your efforts. Better yet, let’s plan to do what we know right now and leave our options open as much as possible in the future. Let’s decide which features we know are important to do now and do them in such a way that it will be easy to modify or even toss them when we get more clarity and perspective further down the road.
If we know the time-box ahead of time, it will be easy to carve that time into slices and plan for the decision-making points ahead of time. As time progresses, more and more tough decisions will have to be made by stakeholders, business managers, and developers alike. Previously, it has been my experience that when the late-game panic started to set in, everyone made a push to cram as much stuff into the final release as possible, forcing the product team to work ridiculous hours to attempt delivery of these unrealistic and typically unattainable goals. Eventually the product team burns out and quality plummets, resulting in a rather sloppy, cobbled-together poorly operating system at the end that hardly anyone is happy with. I don’t know about you, but this is not what I consider a ‘success’, even if some business value was attained in the end. Whatever victory was achieved was a pyrrhic one and certainly not sustainable.
At this point you may be thinking: Ok, the iterative decision-making cycle sounds good, but won’t the churn in the code cause more delays and be more inefficient than big design and planning up front? How can you sustain major changes to the underlying functionality of the code without incurring huge productivity losses? This is a very important and necessary question. The answer is: Using traditional software design and architecture techniques, you can’t! Or rather, any benefits realized by the iterative decision making cycle will be eaten up in spades by the churn and the inefficiency inherent in classic up-front planning and big design and architecture.
A new discipline will be required of the developers. The design and architecture must take into account the possibility of radical change. It turns out that these disciplines already exist, and many of the hard problems have already been discovered and solution tactics developed.