Is Agile Really a 'Developer Rebellion Against Unwanted Tasks'?

I recently wrote about an analyst firm's report on Agile software development that basically blasted the movement, calling it "a developer rebellion against unwanted tasks" and saying it's "designed to sell services."

Okay, this issue isn't strictly database development-related, but it brings up some interesting questions, so I'd like to get your opinions. Some 25 people had commented on the article as of Monday morning, and it was picked up by Slashdot, where it exploded with more than 477 comments.

As usual, the comments were all over the map. Many agreed with the analysts' premise; many vilified them. But I found a couple things especially intriguing. For one, many people still seem unclear as to what Agile actually is. The analyst firm, Voke Inc., based its definition on the Agile Manifesto and its 12 principles. But the analysts note that commonly used associated term such as Scrum and Extreme Programming aren't even included in the manifesto.

They wrote:

During the course of daily business we frequently encounter people who use the term Agile. We consistently ask for a definition of how the word is being used and defined. Frequently, the first response is a laugh followed by a lengthy response that concludes with a statement that there is no real definition for Agile.

That seemed to be borne out on Slashdot, where one reader defined it as:

Agile is a development methodoloy that radically changes the way software developers work. Instead of the typical role of "manager", "designer", "programmer" and "tester", these are split into "chief", "baker", "garbargeman", "clerk" and "monkey". You can probably imagine what each role is responsible for". Typically you work in subteams of three of these disciplines, unless ofcourse you have three "bakers", in which case a "chief" must be added to the subteam. These subteams are further divided in a "major" and "minor" roles, where the majors are responsible for all typing work and the minors documents progress. Every 2-3 hours these minors meet in a decentralized location and synchronize progress, so all subteams keep working at the same pace. At the end of the day all subteams commit their current state of development to a centralized repository and automated builds compile everything overnight. At the last day of the week, all these daily bugreports are filtered by the minors and relayed back to their majors for fixing. Iterate this for however long it takes to complete the project and you're done.

Yet another wrote:

Agile is a particular process for getting things done, which became trendy in software development in particular about a decade ago. It's main tenet is to do work on short cycles, delivering the result to the customer, and then allowing the customer to define the next priority. The hope is that this continuous delivery model avoid the primary pitfall of longer software development cycles, which is spending months/years developing something, only to discover that the requirements were poorly defined at the start (and that the product therefore doesn't meet the real needs), or that market trends have rendered the result pointless.

Not too helpful. How can we meaningfully discuss the effectiveness of Agile software development if there's so little consensus as to what it really is? There's lots of good debate as to its effectiveness, but are the debaters discussing different things? Does someone need to be in charge here? Or is Agile just a basic framework that companies are customizing for their own needs, so it means whatever each company wants it to mean? If so, aren't developers debating apples vs. oranges?

The analysts, who received more than 100 unique definitions of Agile in their survey of 200 people, eventually interpreted Agile as "doing less faster to get ongoing feedback." Does that definition work for everyone?

Also, the report seemed to take some digs at developers themselves (not just management, who are always easy targets). In a section titled "Agile as an Excuse," they wrote:

Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. One participant indicated that negative connotations of both Agile and Waterfall are affecting morale. Some aspects of the Agile movement appear to agitate developers into pushing back on essential tasks that are valued less on the whole by the Agile movement. Based on our survey, unprofessional behavior under the guise of Agile is not going unnoticed. We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.

In another section, they warned:

Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.

So who's to blame here? Management for not strictly following Agile precepts, developers making an excuse to do their own thing, or consultants and the like trying to use the movement to sell their own brand of services under the guise of Agile?

I'd love for you data developers to share your own experience with Agile. Please comment here or drop me a line.

Posted by David Ramel on 07/17/2012