You might have noticed a heightened level of discourse in the agile software development community recently. There is always a healthy amount of naysayer banter about agile coming from those who have tried and failed, or those who have been forced to “be agile” and failed. Then there are those who use the phrase “We’re agile” but don’t know what it means. Over the last several months, you may have noticed harsh words about the state of agile coming from the pioneers and visionaries (and early adopters) of agile software development. 

Dave Thomas’ recent blog post, “Agile is Dead (Long Live Agility),” is a perfect example of this general discomfort, as is Tim Ottinger’s “I Want Agile Back.” These posts, however, are not all negative; I actually find them inspiring. Dave and Tim provided constructive ideas to move forward. But the fact that we are having this discussion shines light on the state of agile today. 

The biggest cause of intense mudslinging arguments seems to be enterprise agile or scaling agile. Organizations are addressing the need for business agility by adopting agile processes within software development and other departments. As a result, frameworks and approaches have emerged in support of enterprise agile and, with them, a “consultancy economy” has formed to ease the implementation.

This makes many in the agile community uncomfortable. The fear is that the consultancies and frameworks are providing management and process police what they always wanted: a heavyweight, control-oriented, certified process that has the word “agile” in it. This is exactly what the original anarchists who penned the Agile Manifestowere trying to address. 

Agile crosses ‘the Chasm’
As a coach in the field, I’ve seen reasons to be concerned. Software development teams scoff at the ideas of craftsmanship. The inspect-and-adapt loop is used as a management tool to force their views of improvement upon the teams. Even with this concern, I don’t view the frameworks or consultancies as the core challenge around the state of agile. 

Instead, the concepts of agile are at a stage of innovation discontinuity. In 2006, Diana Larson wrote that agile has crossed “the Chasm” that exists in the Early Adopters phase of Everett Rogers’ Technology Adoption Lifecycle. I agree that we are on the downward side of the Late Majority curve. If someone simply looked at the Technology Adoption Lifecycle, they might assume this means agile will die off and yield to the next best thing.

I believe agile falls into the category of a core technological innovation. When a core technological innovation reaches the Late Majority Curve, we see a new round of ideas that improve and change the original innovation, thus extending the life cycle. At this point in the curve, a bubble of sorts develops called innovation discontinuity. In this bubble, the original innovators demonstrate dissatisfaction to alterations of what they created, while the new innovators morph the technology to meet the current (and hopefully future) needs.

So the big debate is, have larger organizations adopting agile processes and practices pushed us into this round of innovation and subsequent discontinuity? Or was agile software development already in the bubble, with the ideas of enterprise agile exacerbating it? These questions will continue to be debated based on one’s own interests. In any case, the agile community has grown substantially, and we need to base ourselves in the values and principles of the Agile Manifesto that have served us well over the past 13 years.

In this period of innovation, we need to focus our learning and energy on several fronts. We need to renew the emphasis on good agile engineering practices and embrace the ideas of craftsmanship. Without this, agility does not happen.

We must practice relentless transparency; trust does not exist without it. We must get our executive and management ranks engaged. We must always put people first, as it is the people who get things done, not the processes. Finally, as Dave Thomas points out, we have to get back to agility. Assess where you are, take a small step toward your goal, adjust based on learning, and repeat.

Agile software development is not doomed. Some discourse is valuable; however, we need to ensure the resulting conversations create innovation, not decay. At the end of the day, all we want to do is make better software that customers value and that we enjoy creating.

Matt Badgley is the lean/agile coach and product consultant at VersionOne.

Guest Views are contributions by SD Times readers. Interested in contributing a Guest View? See the guidelines for the details.