I encounter plenty of companies (large and small) that are still trying to decide about agile software development: Does it really work? We already have software that works; why change? Agile software seems to require so much engagement between business product people and development teams. Is this really necessary? Can it work for us?

I get it—Change is Hard. So let’s look at these questions.

Does it really work? Of course it really works! Agile software is smaller, simpler software with faster development/modification/improvement cycles. Agile (and closely related Lean and Iterative) development strategies have significantly higher success rates and lower failure rates than traditional development strategies. This has to be an improvement.

We already have software that works; why change? This is a complex matter that could change over time. Your software may meet the expectations of your business products people, but this doesn’t guarantee that your IT people are happy with it. Complex software is difficult and expensive to maintain on the backend, and getting ever more so. Consider also the longevity of the software engineers that produce and maintain your software. Top-notch software engineers know the world is migrating to agile. They are already learning (or have learned) agile. You will not likely be able to retain them if they do not get a chance to exercise and demonstrate their agile skills. Likewise if your existing talent leaves, you will have great difficulty attracting top-notch replacement talent if you are hiring them to do old-school development.

Understand too that agile does not necessarilly mean throwing out all your legacy code. In several cases, I’ve had pretty good success using agile strategies to refactor legacy code. Often anywhere between 30% and 70% of legacy code and legacy logic can be re-used (but maybe only in small chunks).

Agile software seems to require so much engagement between business product people and development teams. Is this really necessary? Well, umm… YES. This is actually true for software development in general. The top six contributions to software project failure are incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations, lack of executive support, and changing requirements. All but one of these reflect some form of inadequate engagement between the business products people and the development team(s). Software developers and business people tend to have very different cultures and experience. Business people typically have insufficient knowledge of backend requirements and the details of design, and software engineers often have a poor understanding of user experience. This is precisely why top-down, ‘my way or the highway’ approaches to software development usually fail. The only way you really get past the developer/business culture clash is to have developers and business people working shoulder to shoulder daily. Agile has this kind of engagement built in.

Can it work for us? Every situation is different (or as we often say in the software world: ‘the devil is in the details’). It is perfectly normal for an enterprise to customize agile development for its particular needs. For example, agile development usually produces only lite documentation. This is sufficient for most purposes. However if you need specific kinds or levels of documentation content, you might want to establish software coding policies to guarantee that the necessary documentation content is produced. Adapting software development for your specific needs is an important job that requires a good software architect. But this is true for both traditional software development and agile development.

Agile development is probably exactly what your enterprise needs. But don’t spend too long deciding about agile. Chances are your competitors are already making the switch.