The most important decisions managers make involve effective use of money. Money is the language of limitations. Managers talk in terms of budgets and projected costs and ROI, but what they’re really talking about is how to do the most they can to ensure the company succeeds. The choices they make involve risk, and the tools they employ to manage their companies manage that risk.
An Agile organization has shifted its approach to risk management and achieving the highest level of success. They don’t just employ Agile methods, they speak the Agile language. They throw away from the language of Gantt charts, earned value, and time to complete and embrace the language of incremental business value, burndown charts, and fast failure.
Why? Because it is more effective, and more honest.
I’ve developed lots of project plans based on a solid work breakdown structure (WBS). But a project plan and WBS work best when the methods and materials are well-known. In software development, you’re always working on the cutting edge. If you’re not on the cutting edge, you buy the software off the shelf. You only make software when what you need hasn’t been done before. And when you’re doing something new, you have to work in small increments that deliver value.
You plan out a series of these increments to get you to your ultimate goal. You then build an increment measure the actual value against the expected value so you can decide whether to continue or stop. If you decide to continue, it’s because the work you’ve done so far has validated your decision. If you stop, you’ve decided the value isn’t worth the cost, and you can immediately direct your limited resources to something else.
Sometimes when you stop you scrap the project. Sometimes you simply scrap further enhancements and you’re left with a tool that doesn’t do everything you originally thought, but represents a sound investment of your limited resources – a success. And either way you learn something about the assumptions you used to make the decision to approve the project. Compare that to traditional methods where you either succeed or fail (more often fail), and you often don’t know why.
This isn’t about implementing a methodology, it’s about changing the way you think. And it has only positive implications to making key project decisions.