Is Agile really dead?
David Thomas, one of the authors of the Agile Manifesto, is famous for his quote that “Agile is Dead!” If you haven’t seen his speech on this topic, it’s well worth the 40-minute investment of your time. (Agile is Dead) David Thomas also wrote an article on this subject, titled Agile is Dead (Long Live Agility) that offers a quicker summary of his views.
In his presentation, Dave Thomas chastises the community of agile consultants and methodologists who claim they have the best set of agile-based rules and practices in the industry. To put it mildly, he’s not a fan of overly complicated rules and organizational structures, and he’s not a fan of so-called best practices.
Moreover, he notes that agile is not what you do. Agile is not something that can be sold or given away. Instead, agile is an adjective that describes a general characteristic of how we expect to accomplish something. In other words, we can move or work or act in an agile manner, but agile is not a thing that we are we are doing.
In contrast, agility is the noun that expresses the state of our ability to act in an agile manner. From David’s point of view, we do not practice agile or work on agile teams. Instead, we can work with agility (i.e., develop software in an agile state of nimbleness), and we can use specific methods and tools to improve our agility. But we can’t do agile (verb) or be agile (noun).
And you thought you left high school English behind!
The origins of agile
The term agile came out of the software development community as an adjective to describe a characteristic of software development, as articulated in the Manifesto for Agile Software Development (a.k.a. The Agile Manifesto). Witten in February 2001, the authors met to discuss the commonality of their views as practitioners of so-called ‘lightweight’ software development methodologies. The output of the meeting was an articulation of four values and twelve principles that enable the development of software in an agile manner.
If you haven’t read the Agile manifesto, I encourage you to do so. But, for this article, let me net out what I believe the term agile and the values and principles of the Agile Manifesto amount to in terms of real-world activities. Agile software developers work in small teams to build, test, and release incremental value in frequent, iterative releases, always staying focused on the current needs and priorities of the customers. That’s a lot to say in one sentence, so let’s break it down a bit.
What is agile software development?
We now know to develop software in a customer-centric manner, delivering incremental value rapidly through frequent releases. The iterative and incremental development process provides abundant opportunities to assess progress against current customer priorities and make appropriate course corrections. Building small increments of new or enhanced functionality allows us to test more quickly and more often, which minimizes bugs and defects while simultaneously improving development efficiencies.
Along the way, we’ve come to learn that we work best when operating in small, autonomous, and fully self-contained teams that minimize communications, work integration, and dependency issues associated with the network density problems of managing larger teams or organizations. However, autonomy doesn’t mean the teams are not held accountable for progress and results. But instead of excessive documentation and reports, we have found a more efficient approach is to provide transparency through publicly available and highly visible charts and lists, such as product backlogs, burndown, burnup, and velocity charts, and Kanban boards.
Best practices do not support agility
So, getting back to our topic on whether agile is dead, in David’s world, there is no such thing as a best practice, at least not as promoted in the context of agile software development. In his view, agile consultants are all making this too hard. A better approach is to evaluate progress against a goal, take small bites to accomplish the goal, assess your progress against the goal, and then repeat for as long as the work continues to add value. Over time, goals change, and eventually, the product matures to a point where continued development is no longer required.
Given his reasoning, I submit a better title to David Thomas’ YouTube video and related article is not Agile is dead, but rather that Agile never existed. It was a false premise based on the errant use of an adjective – agile. Instead, what we have are a set of values and principles to guide our software development activities in an agile manner.
But isn’t his approach to software development a best practice of sorts? The same question applies to the use of product backlogs, burndown, burnup, and velocity charts, and Kanban boards. Aren’t these all forms of ‘best practices?’
If not best practices, what then?
Very gifted developers, as with specialists in any domain, don’t have to think very hard about the practices they use. They have mastered the fundamentals of their disciplines and know how to use their knowledge in new and creative ways. These learned experiences follow the same concepts guiding Shuhari, the Japanese martial art concept that describes three stages from learning to mastery.
- shu – learning and practicing fundamental knowledge or wisdom passed down from others
- ha – practice what we have learned in creative and novel ways to gain a deeper understanding of the fundamentals
- ri – transcending to a state beyond what we have learned from others and apply our knowledge and skills in new ways that further evolve the discipline and our mastery of it
Many agile advocates have adopted the concept of Shuhari to describe the process of mastering software development skills. The point is that we all have to start from the beginning, learn the fundamentals, practice hard and long, and ultimately master our craft.
David Thomas notes that he doesn’t need to test the software he develops. He has mastered the elements of software development to the point that he thinks through testing and likely results as he’s writing his code. He doesn’t need to perform the tests because he’s already performed them in his head, and he says the metrics he’s recorded demonstrate there is no degradation in his code from this process.
David has reached the state of ‘ri’ in terms of software development knowledge and mastery. But I would submit that most developers are not at his level. Those who are still at the levels of ‘shu’ and ‘ha’ could not get away without testing. They are still learning the fundamentals of software development and how to apply the practices they learn from the experts.
Start with good practices, but evolve
The knowledge the novices are learning and applying are ‘good’ practices, at least in specific applications or situations. Those situations may revolve around the tools and technologies employed by your team. Customer and management requirements can also drive the practices deemed acceptable in terms of delivery and reporting requirements.
Good practices also establish a baseline from which to start our learning experience, both for individuals and teams. Virtually all Lean and Agile methodologies preach the importance of continuous learning and improvements. As we learn, our evolved practices become our best practices, until even better practices supplant them. We may change some practices because our understanding has improved. At other times, our situations or the problems we face may drive changes to our existing practices.
This type of heuristics based learning requires trial and error to see what works and what does not work. The point being that continuous learning and continuous improvements are the real goals.
Failure is scary
But, here’s a question for you. Are you allowed to fail? Even more important, if you are not allowed to fail, how can you succeed? I’m not talking about making the same repetitive errors over and over again. After all, the objective is to learn from our experiences. Nor am I talking about placing all your bets on one option, putting the project at risk of failing. But does your management understand the need to take small incremental steps to achieve the desired goal, knowing that some of those steps will have suboptimal results? Does your management understand the value of trial and error practices?
These are essential questions. If we buy into what David Thomas is saying, that means we need to experiment with different practices and ideas while on the job. We may need to implement capabilities just to see if they are what our customer wants. The customers may need to see the implementation of certain features and functions before they can fully grasp how the product can be used to best support their needs. The whole point of experimentation is to try out different things to see what works, keep what is good, and throw out or ignore the rest. And that means you and your management, and even your customers must be willing to accept some failures.
Will your managers and customers let you do that? After all, don’t they expect you to be the experts in your domains? Don’t they expect you always to succeed, since they are paying the bills? In the real-world, aren’t we afraid to fail?
Fail, but fail small
Yet that’s exactly what we must we willing to do. The trick is to keep the failures small and tolerable by taking one small bite at a time. You see, failure is not a bad thing if done correctly. Yes, there is a correct way to fail. Take small bites out of a problem. See if the approach works in terms of satisfying your goals and objectives. Adjust as necessary and try again. When you succeed, move on to take the next bite. And always take the path forward that delivers the most value and extendibility. Now you are failing gracefully with minimal consequences while building on incremental successes.
I submit the number one reason the traditional Waterfall model fails so often is simply that the bites are too big. They are monstrous. And the negative consequences of failing on such a large scale become catastrophic to the organization making the investments. But, at the end of the day, whether using Waterfall or Agile, software developers still discover requirements, create architectures, design products, develop and test their code, and then configure and deploy the final solutions. It’s the size of the bite that matters the most.
Conclusion
Agile is not dead, but the industry misapplied the concepts behind the Agile Manifesto. The point is to keep things small, delivering new increments of functionality frequently, but also limited in size so that you can afford to fail. And, above all, stay focused on the customer and their needs, as they define what failure and success both look like.
It’s your turn
Now it’s your turn to respond. Does this concept of agility make sense to you? Are you allowed to take risks? Are you allowed to work in small iterations and increments where failures are not catastrophic and career limiting? If not, why not?
