Should Developers Abandon Agile? (ronjeffries.com)

An anonymous reader quotes InfoQ: Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto. The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto...
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...

"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.

But what do Slashdot's readers think? Should developers abandon Agile?

Comments

Re:derails because of laziness and job protection

[Junta]

Developers will write some unittests, but just enough to test some new functions here and there in different components.

Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.

As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.

The original Agile was simply:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Which has always been pretty obvious to anyone.
The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.

The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.

The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.

Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.