We've talked about what agile development is, how to do it, and why people object to it, but the big question that remains is "Why Go Agile At All?" If you or your employer are considering a conversion to agile, you should know what to expect from the change.
Agile is a work system, not just a style of writing code or a set of tracking tools. It is a very disciplined and orderly way to work, and it is also a lot of fun. It is intense, requiring a high degree of personal involvement (which is why Agile teams cap their work weeks at roughly 40 hours).
- Improve Customer Involvement Agile methods put the customer in the drivers' seat. Customers choose which bit of functionality comes next, and when a feature is complete enough for their needs. Agile is intentionally customer-intimate, so customers and developers (including testers, tech writing, and customers) are on the same team. It is a strong alternative to an adversarial relationship
- Increase Quality Agile depends heavily on testing, both at the acceptance test level and at the unit test level. Tests are written constantly and run constantly. The legacy code you have lying about in piles may not be amenable to testing, so expect some early delays as the team converts it. These delays are more than offset by the lack of bugs (and days lost to bug-finding research) a few months down the road. Improved quality results in fewer customer complaints, reducing support costs.
- Simplify Releases Agile teams release early and often, and try to maintain their code base in a perpetually-releasable state. Tests and Continuous Integration ensure you don't have long dark times when the code does not run. Periodic integration hell and mad release rush are reduced, even eliminated.
- Increase Operational Awareness Agile teams keep their work-in-progress to a minimum, and track their progress on visible charts and the kanban wall. One can walk into the group work area and tell what tasks are in progress and how close they are to being completed. You can glance at a burn-down or burn-up and tell how close the team is to completing some critical functionality. It is an orderly and visible work system.
- Drive Down Risk
Agile teams work in tiny increments of functionality, not huge end-all features. This allows them to have working software ready early on. They do not necessarily produce software faster than non-agile shops, but it is in a usable state earlier. This means that the software can be used while it is being developed. It might even pay for itself.
Because software is usable so soon, features are assessed sooner. The Customer can see immediately if they are really as useful as he expected. Corrective steering is possible. There is a greatly reduced risk of building the wrong thing, or a gold-plated excess of the right thing.
- Reconnect With Geek Joy Boy, did I ever detest sitting through all-day meetings debating use cases or refining requirements documents in the name of JAD or RAD or RUP or whatever. Agile focuses on getting things done well and often, which according to studies is the primary factor that drives job satisfaction. Having working code nearly at all times is empowering. Having tests to rely upon is comforting. Having steady progress is refreshing. It is great to be making real progress (learning and coding) all of the time. It's why many of us chose this vocation.
The most common reason does not appear on the list above, "What we were doing was not working." That is a reason to change from what you were doing, but not necessarily a reason to change to anything in particular. If you are considering a change, consider whether you want the qualities listed here enough to give Scrum and/or XP a shot.