- Immediate Risks
- Two Cautionary Tales
- Avoiding the Pitfalls
- A Final Reminder
Avoiding the Pitfalls
Taking a careful look at some of the failures I’ve described shows a few similarities:
- Massive, world-shaking change without experimentation.
- Expecting to have your cake and eat it too: All features, on time, on budget, on schedule, regardless of how realistic that schedule is.
- Implementation of Agile techniques without a belief in the core philosophies of responding to change and not planning everything up front.
When an organization implements Agile in a "big bang," all-or-nothing way...well, that is possible, but the results are unpredictable. They’re trying to develop in a new way on a project that’s never been done before, and the technical term for that is an experiment. Typically, you don’t want to use an experiment on a bet-the-company project, which is what many Agile projects end up becoming.
There is an alternative to declaring exactly how all development will be run, from this day forward, without ever trying it: Experiment on your existing projects. One place to start is with automated testing. If your team is constantly modifying the same codebase, automated testing can pay for itself very quickly by lowering the overall testing burden. With automated testing in place, the team has a safety net, which can enable true iterative development and quick releases.
Another way to be more Agile is to simply make decisions that conform more closely to the Agile manifesto—that is, decisions that value the following:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Add small, incremental changes to the way you develop software (your "methodology") that support these values. Agility is not yes-or-no; it’s more-or-less—and don’t let anyone tell you otherwise.