|
||
|
|
|
|
||
To better explain what software agility is, it’s worth beginning with a description of what it isn’t. Software agility isn’t about
Big up-front requirements gathering and design
Hacking
High ceremony (i.e., lots of paperwork and bureaucratic hoops to jump through)
Low levels of communication
“Carrying” mediocre developers
Politics and secrets
Let’s take a quick look at each of these topics in turn.
Up-front requirements gathering and design are, of course, vital parts of any software process, and they have their place in an agile project. What agile practitioners are generally opposed to is the “pure waterfall” concept of eliciting all requirements and modeling the architecture in detail for the entire project before starting on individual sections. Instead, you gather together everything you think you’ll need just for the next iteration, and proceed with that. This approach is similar to the iterative and incremental process that has been developed in the Rational Unified Process (RUP).
Adopting an agile process isn’t (or shouldn’t be) a license to hack. Agile processes are typically high-discipline, and it often takes hard work and patience for developers to get the full benefit.
Sometimes the organization requires a high level of paperwork (e.g., change requests to be signed off on by three levels of management). If your organization doesn’t, then why bury yourself out of choice?
As with any process, agile processes benefit from teams that tell each other what’s going on, and that both talk and listen to the customer. Agile processes are very much opposed to “low-communication” environments—for example, environments that separate programmers into isolated cubicles.
Agile processes typically require high-caliber staff if they are to work at all. There is no place for slouchers and “bug jockeys” on such projects!
Agility places a big emphasis on increased transparency—that is, allowing the customer to see exactly what’s going on in the project at any time. If a project is behind schedule, the agile planning methods generally make it difficult to hide this from the customer. Although this might seem alarming at first, it has the very important benefit that you don’t find yourself storing up nasty surprises for later—in particular, on the day before the delivery deadline, having to tell the customer that it’s going to be at least another 6 months before any working software can be delivered.
Increased transparency also extends to individuals and teamwork. Because agile teams tend to work more closely together, it’s difficult for one team member to operate deviously (e.g., hanging on the coattails of more talented programmers and taking the credit for their work).
|
||
|
|
|
|
||