This article was first published in 2014. At that time, and to some extent still today, we saw a high level of anxiety and pushback to what was happening in the agile community. With the emergence of enterprise frameworks, specifically the Scaled Agile Framework, there was a general feeling that the monetization of intellectual property has taken over. And, the intent of the original Manifesto for Agile Software Development was under attack. Agility would be lost forever. Good news, almost ten years later, agility is a predominant way of working and the concept of frameworks is treated just as that — frameworks. Please give this article a read, and let me know, do you think we are in another wave of innovation?
Unless you’ve been under a rock, you might have noticed a heightened level of discourse abounds in the agile software development community. There is always a healthy amount of naysayer banter about Agile coming from those that have tried and failed or those that have been forced to “be agile” and fail or those who use the phrase “we’re Agile” and don’t know what the hell it means. But, if you’ve been paying attention over the last several months, you will have noticed more and more harsh words and general discomfort about the state of Agile coming from the pioneers and visionaries (early adopters) of agile software development.
A couple of examples are “Agile is Dead (Long Live Agility)” by Dave Thomas and Tim Ottinger’s post “I Want My Agile Back.” Now don’t get me wrong, these posts are not really negative, in fact, I find them inspiring and you might too. Dave and Tim provide constructive facts and ideas to move forward. But just the fact that we are having this discussion shines a light on the state of Agile today.
So does the elevated level of scrutiny and general unhappiness in the software development community mean certain doom for Agile Software Development? I’m certain it does not.
The emergence of the Evil Enterprise
The most prevalent driver of angst that is causing intense, partisan political arguments are the concepts around Enterprise Agile or scaling agile. It is well known, that organizations need to address their Enterprise Agility — which means organizations can adapt rapidly and efficiently in response to business and or market changes. In fulfilling the need for Enterprise Agility — large organizations are working to adopt agile processes within software development and other departments. A number of frameworks and approaches have emerged to address the Enterprise Agile needs and as a part of this movement, a consultancy economy has formed to help implement the frameworks. This makes agile software development purists uncomfortable. The fear is that the only thing the consultancies and frameworks are doing is providing middle management and PMOs what they always wanted — a heavy-weight, control-oriented, certified process that has the word “Agile” in it. This is exactly what the original anarchists who wrote the Agile Manifesto were trying to change.
As a coach in the field, I’ve seen reasons to be concerned. A couple of examples I’ve seen are where some software development teams scoff at the ideas of craftsmanship, or the inspect-and-adapt loop was being used as a management tool to force their views of improvement upon the teams. Even with my concerns, I don’t view the frameworks or consultancies as the core challenges around the state of Agile.
The Curve
Instead, I think the concepts of Agile are at a point of innovation discontinuity. In 2006, Diana Larson wrote that Agile has crossed “The Chasm” that exists in the Early Adopters phase of Everett Rogers’ Innovation Adoption Lifecycle. I would definitely agree and I believe that we are on the downward side of the Early Majority curve. If someone simply looked at the Innovation Adoption Lifecycle, they might assume that this means Agile will simply die off and yield to the next best thing. The problem with this belief is that it has been demonstrated that as a core technological innovation reaches the crest of the Early Majority curve — a whole new round of innovations emerge that improve and or change the original innovation; thus, continuously extending the lifecycle. At this point in the curve, a bubble forms — this bubble is called innovation discontinuity. It’s a bubble where the original innovators demonstrate dissatisfaction with changes in their invention, while the new innovators morph the technology to meet the current and, hopefully, future needs of a changing market.
It can be debated as to whether or not the move by large organizations to adopt agile processes and practices has pushed us into this round of innovation and subsequent discontinuity. Or, was agile software development already in a period of innovation discontinuity and the ideas of Enterprise Agile have just exasperated it? At the end of the day, it doesn’t matter — what does matter is that the agile community has grown substantially, and we need to base ourselves on the values and principles of the Agile Manifesto that have served us well over the past thirteen years.
At this point of innovation discontinuity, we need to focus our efforts and learning energies on several fronts. We need to renew the emphasis on agile engineering good 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 — education is not enough. We must always put people first in that people are how things get done, not the processes. And finally, as Dave Thomas’ blog points out, we have to get back to the core of Agility — assess where you are, take a small step toward your goal, adjust based on learning, and repeat — all the while, making change easy with all decisions made.
Conclusion, “Long Live Agility”
I firmly believe Agile Software Development is not doomed. And it is imperative that if you are one of those who believe ardently in the founding values, principles, and practices of Agile Software Development — that now, more than ever — get involved in the community. Some discourse is valuable; however, we need to make sure the resulting conversations drive innovation not decay. At the end of the day, I think all we want to do is make better software and solutions that customers want to buy and that we enjoy making.