Font: Erwin
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.
I agree with what you say but you should make it clear that this list is focused on developers, not customers. You could write a similar list that argued in terms of what the customer gains from agile.
ReplyDeleteI totally agree with Niklas. I would suspect the customer gains would include "increased ROI" or something with "value", which is absent in the developer-focused list.
ReplyDeleteIt is not entirely focused on developers, nor entirely on customers. I consider the Customer a developer ("whole team" philosophy), and sometimes don't make that clear. I could rephrase some of this to help.
ReplyDeleteFor instance, Increased Customer Involvement sounds very customer-oriented to me.
Increase in quality also is a customer benefit, and of course the customer writes tests so it involves him intimately.
Operational Awareness and Driving Down Risk are almost entirely of benefit to customers rather than developers. The body of the "Drive Down Risk" paragraph is about receiving working code sooner and steering effectively, which is Customer work.
Connecting with Geek Joy sounds like a software developer, but there is a "joy of building" that is part of the process for customers as well.
I did not really use the V word here. Nor did I mention ROI because I'm not sure, personally, that ROI is really the consideration it is made out to be. They are more nebulous ideas than the ones presented here, and I felt less driven to include them. I could be convinced otherwise.
An index card has limited size. I am certainly eager to make improvements. Yet in this case we am not making an exhaustive list but instead showing the few items we felt had the greatest, most continuous, most real payback in an agile process.
Please feel free to correct or convince me.