Have you ever watched a home renovation show on television? I’m thinking of shows like Love It or List It and Property Brothers (both on HGTV). The specifics vary but they use the same general approach to managing renovation projects.
The work crews are given a fixed time period and a fixed budget to complete a major home improvement project. The time period is usually on the order of 3-6 weeks. The budget is usually in the tens of thousands of dollars but can go higher. The crews are required to stick to the budget and the deadline — no excuses.
Of course, unexpected issues often arise. There may be a major electrical, plumbing, or even structural issue that ends up adding substantial time and cost to the project. But, because time and cost are fixed, something that was planned for the renovation project must be reduced or omitted.
In other words, the scope has to change to meet the time and budget goals. There are two major options available:
- A less important section of the home may be left untouched to free up funding for the more important areas; or
- Parts of the project may be scaled back using less expensive materials and/or faster work methods.
There are often “all-nighters” near the end of the project to meet the final objectives. While, “all nighters” are generally a bad idea, they make sense when used sparingly and in times of dire need.
What does this have to do with agile software development?
I hope the answer is self-evident. Software projects always have time and budget constraints too. No one has an unlimited supply of time or money. While some software developers may argue that the software “…will be ready when it’s ready”, in business, that attitude doesn’t fly. Deadlines are often very real with severe consequences for not meeting them. As for money, once it runs out it’s game over. Go find another job.
The only aspect of software projects that can truly vary is scope. (Unless you want to let quality float and risk shipping crapware.) Agile teams make frequent decisions about what to include and what to exclude in order to meet time and budget goals.
You see, letting the project scope float is not some kind of sinister agile concept. It’s actually widely used in many kinds of projects. Even new building construction projects encounter delays and unexpected events that add time and cost. Owners may choose to absorb either but most often, they will adjust scope to keep their commitments and maintain high quality standards.
Lesson learned: Stop trying to lock down time, cost and scope at the outset of a software project. It’s a fool’s errand. It doesn’t work in physical build projects like home construction and it doesn’t work in software development either.