Channels ▼
RSS

.NET

Addressing the Corruption of Agile


My recent editorial on the corruption of Agile lamented the religious aspects of Agile and assailed the view held by some developers today that without Agile practices, it's not possible to write good software. These points clearly touched a sore point, for within hours of posting the editorial, I'd received several letters thanking me for writing a long overdue piece. The comments both on our site and on the popular programming aggregators were thoughtful and generally refined points I made. Among the responses that disagreed in part or in whole, two noteworthy ones were an open letter from Rob Myers at the Agile Institute and a lengthy blog post by "Uncle Bob" Martin, one of the leading exponents of Agile practices, who more directly took me to task.

Myers agreed with my overarching points about Agile, but disagreed with my use of TDD as an example of the wayward religious aspects. He felt that the enthusiasm for TDD is due to the benefits people derive from its use. Specifically, the ability to try out code and, from the tests, tell whether it works correctly with the larger code base. And, as he insightfully points out, given the ascending complexity of today's apps, not many practices enable such quick feedback. He also likes tests' ability to be "comprehensive, executable engineering documentation describing all the discrete behaviors of the system in a non-combinatorial fashion," plus "the ability to change the code rapidly and confidently." I have no difficulty with any of Myers' points, save the implication that you need TDD to do this. All the benefits he lists could be attained equally by writing tests after the code, rather than before. And nothing requires that code be written in the smallest testable increments — a foundational tenet of TDD. Fundamentally, he's praising the benefits of writing many unit tests. I agree with the perspective. But TDD is definitely not required to do this.

Bob Martin took on my contention that Agile is a set of values, not a set of practices. He repeatedly explained how all cultures, including Agile, are known through their practices ("If you see a bride and groom breaking glass under a canopy, you can guess the culture.") He extended this analogy to other religions and to martial arts, each time expressing how the practices define the culture. I don't find this argument persuasive.

Many, many practices are so disassociated from the values they originally expressed that they have become hollow, empty, ritualistic behaviors. Religions, corporations, and Agile shops are just some of the institutions that engage in practices despite having long ago lost the understanding of the values they were intended to instantiate.

As I pointed out in the original article, organizations that don't use the defined Agile practices can still be Agile if they welcome change and exhibit the values expressed in the manifesto. I thought Martin might run with this and talk about the need to remind organizations of those values, to make them living once again. But instead, Martin argues that Agile should have more practices: "The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don't recognize as Agile anymore."

I find this view untenable. The reason many of these practices have been abandoned is because they did not generate sufficient lift for the cost they imposed. Pair programming being perhaps the defining example of this perceived lack of ROI.  In response to Martin's post, this comment was posted on Reddit: "I work at Google. Most teams don't use Agile. A very few do, and the team members complain about all the time wasted in 6-hour planning sessions. Google has great software engineering discipline, with a huge focus on design reviews, code reviews, and strong unit testing and integration testing. Most people there recognize that Agile is just a religion." It was one of many comments on Reddit to express similar dissatisfaction with Agile "religion."

Martin concludes his essay saying, "If you've got better practices, I'd love to see them. If I believe they are better, I'll adopt them in a heartbeat." However, he does not appear to see the link between the two points he's made. He cannot both state that he's willing to abandon Agile practices for better ones, and then begrudge the many organizations that have done just that.

It may well be that Agile has reached its high-water mark and the appreciation of its benefits has begun to recede. If so, Agile itself will need agility to adapt to changes. I believe those changes will mean that a few core practices will remain and new ones will be adopted as the needs of software development dictate. For this to occur productively, the values of Agile will need to be retained, while the practices change. If you look at Agile being a set of values, this is entirely possible, and likely the only way it can move forward.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy
Google+


Update: The original version of this article omitted the last paragraph.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video