New Analyst Report Rips Agile: Says It's 'Designed To Sell Services,' a 'Developer Rebellion Against Unwanted Tasks'

"The Agile movement is designed to sell services," says analyst firm Voke Inc. in a brand-new report analyzing the movement, presenting findings about its use and providing insight to organizations considering its adoption.

In addition, the report includes data supporting what Voke calls the "Agile Dilemma," described as "the inherent risk and confusion created by the business desire for speed and flexibility misinterpreted as a mandate to participate in the developer-centric movement called Agile, which may not be appropriate for all organizations or projects."

The report contrasts the "developer-centric" Agile movement with software engineering, a more comprehensive part of Application Lifecycle Management (ALM) that incorporates cross-functional teams with responsibilities for architecture, design, testing and more beyond just software development.

"The Agile movement shifts the broad, inter-departmental process of software engineering to one that is focused on software development to the exclusion of QA and operations," says the report in an "assumption."

"In spite of the specialization of resources which limits the scope of the work of developers, the Agile movement might inspire and encourage developers to push back on processes, tools, documentation, and following plans," the report says.

The July 11 Market Snapshot Report, titled "Agile Realities," is authored by Lisa Dronzek and Theresa Lanowitz, who from June 2011 to February 2012 asked more than 200 participants about their use of Agile software development and the results of that use. It's available to the public by subscription or by an on-demand purchase of about $150 on the Voke Web site.

The survey results include the following (verbatim from the report):

  • Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
  • Out of over 200 survey participants, we received only four detailed comments describing success with Agile.
  • Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
  • The primary benefits identified were faster releases (14%) and more feedback (13%). Some participants (7%) also noted that Agile developers were happy due to less future planning and less documentation.
  • Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.
  • We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
  • 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.

The survey says participants indicated that the projects more likely to be successful with Agile included smaller projects, custom-development projects and Web applications, along with projects that used Agile only when appropriate and by experienced teams who understand objectives and requirements.

Besides Agile benefits and challenges, the report also detailed information on the use of development methodologies, Scrum, sprints, development QA, an analysis of the Agile Manifesto and advice on assessing your organization for the possible adoption of Agile. The report also contains information on the rising cost of software development and possible reasons for it. The analyst report comes with a 20-page "strategic brief" titled "Cost of Rework Models for Agile and Non-Agile Projects," which Voke says "provides economic models for evaluating project results and selecting the most appropriate methodologies."

The 44-page main report concluded with a cautionary note:

All software requires effective requirements and the management of cost, quality, and schedule; this is the classic software conundrum and will remain so. Organizations thinking that there is a quick fix to this age-old problem need to realize that today's solutions are all too frequently tomorrow's problems. Remember, look before you leap!

What's your take on this report and the agile development movement? Post your thoughts in the comments and let us know!

More articles by David Ramel on ADTmag.com:

Reader Comments:

Thu, Aug 9, 2012

This is pure shock jock, non credible marketing. Period.

Thu, Jul 26, 2012

What makes me laugh are all those comments from people that claim they know better. Factual statements like "Twenty-eight percent (28%) report success with Agile." are meaningless to these types of people - and pointing out that 72% of the respondents gained no benefit probably will make those sort deny there is an issue (i.e. we can expect comments like ... they didn't do Agile "properly")

Thu, Jul 26, 2012 Dave Portland, OR

Wow, what a link-bait of an article (and yes, I took the bait). These clowns have no idea what a good agile project looks like, the benefits, the level of satisfaction from both the customers and project team members, etc. As someone above said, they should have talked to folks who do agile right, as well as the customers/business they're delivering to. I hope they realize the complete irony of the statement that agile is designed to sell services, as they publish this link-bait report. (Never mind the statement being completely laughable on its face, if you really know agile.)

Thu, Jul 26, 2012 Bill

Having been involved in the Scrum projects, it is hard not to agree with this article. I experienced every single issue that are mentioned in this article.

Wed, Jul 25, 2012 Jordan

I found the ESJ article to be borderline hysterical and sorely lacking in justification for its questionable conclusions. It just sounds like the indignant rants of the pro-agile crowd. Some people's bubble got burst and now they got the whaaambulance going Jordan

Tue, Jul 24, 2012 Becky Nagel Editor, ADTmag.com

BTW: The editor of sister publication, ESJ.com, wrote a fairly long commentary on the results of this survey -- you can find it at: http://esj.com/articles/2012/07/23/agile-survey.aspx

Sat, Jul 21, 2012 Mark

The most interesting thing about this report is the reactions of the Agile fanbase to it: denial, counterattack, and the usual personal anecdotes and success stories as "refutation" (it worked for me, it must be right!). And most importantly: it's NEVER, EVER the methodology that's wrong, it's always the people who fail to live up to it. I see some parallels to religion, but even more to the scene of complementary and alternative medicine (CAM, or quackery as it used to be called before it was rebranded).

Fri, Jul 20, 2012

I am not an expert on surveys, but I just think 200 is still too small a sample, considering the the untold number of organizations in the whole world that do some in-house software development; 200 is not even a scratch in the surface. Otherwise, we just get to exchange opinions and personal stories, again... Anyone here an actual Voke customer? If so, have you got any value from their previous reports?

Fri, Jul 20, 2012 Experienced N. Understanding IT Leader

OK, Let me see if I get this correctly. The article states that... "The survey says participants indicated that the projects more likely to be successful with Agile included smaller projects, custom-development projects and Web applications, along with projects that used Agile only when appropriate and by experienced teams who understand objectives and requirements." ... So how many software projects that a development team works on will likely involve "custom-development and web applications"? Let's see, for my team, that would be 100% of all our work. Definitely looks like a niche methodology! Also, I love the warning label part about "...experienced teams who understand...". Would any of you want inexperienced teams who don't understand, but follow classic (archaic) structured SDLC / waterfall methodologies developing your company's technology platform? I wouldn't.

Fri, Jul 20, 2012 A Microsoft MVP NJ

Enter the dev world's newest pariahs.

Thu, Jul 19, 2012 Brett

Hey, thanks for putting the last paragraph of this trollicious article on a separate page. Unfortunately, my ad-blocker won't let me see the ad you're trying to display before the content.

Thu, Jul 19, 2012 Michelle

I think Agile and Scrum methodologies CAN be effective if 1) You have an excellent Scrum Master who understands basic principles of Project Management 2) You have a good Scrum Team with good skills that go beyond just coding (time management, communication, testing and 3) You have a product owner who is enthusiastic about the product and has time to get involved. Without that combination, I think you are setting yourself up fail and have a large amount of re-work. That combination of people would also be very difficult to find and maintain.

Thu, Jul 19, 2012 Matt

Speaking of "designed to sell services", I can't think of a more apt description for this link-bait of an article...

Thu, Jul 19, 2012 JoseB FL

My experience is quite the opposite. We adopted agile principles 6 years ago and have delivered many succesful projects. The number one agile principle that increases your chance of success is its iterative approach (doing sprints). Waterfall increases you chance of failure because mistakes are caught late. Irregardless of agile or waterfall, you always need the 4 pillars (good requirements, good design, good code, good testing). Thats all there is too it. And complex tools are not needed to achieve the 4 pillars (just common sense).

Thu, Jul 19, 2012 TLCF64 PA

I've used Agile VERY SUCCESSFULLY to crank out backlog items and wishlist items as part of a managed project. of course, we had a fabulous SCRUM master and some very energetic & smart developers. Also, we didn't pretend that our method was a replacement for the PMO -- they still wanted a plan. we just translated that plan into a better way of implementation. it's not for the faint-of-heart (a.k.a. those who are less than dedicated to the project.)

Thu, Jul 19, 2012

Where is Agile still "developer-centric"? Agile has been co-opted by project managers and managers everywhere as a tool for micro-managing via tasks and burndown charts with daily status updates.

Thu, Jul 19, 2012 Max Austin, Texas

I appreciate a different perspective [from mine] on the subject of what value add Agile provides. However this article lacks objective data to back-up such generic assumptions on Agile. If Voke is willing to post this article [for free] to be consumed by the public, please also make available [for free] the survey results so that we many collectively analyze the data. We can all learn from this interaction...

Thu, Jul 19, 2012 Paul

Agile is a software development methodology. By itself it will not run a company, hire the right people, get loans from a bank, etc. Agile does not define the Enterprise Architecture for a company. Agile fits nicely within a well defined Enterprise Architecture (consider TOGAF). When combined together in an intelligent way (by a rational organization) life is good. Don't expect Agile to do things it's not intended to do.

Wed, Jul 18, 2012 Xu Yi Beijing, China

interesting, it seems the reporter is describing the things just in the opposite way... well, Agile itself is very flexible and adjustable, this is an important advantage and a severe risk too, which means people could or tend to call whatever they believe is Agile Agile. Since Agile is promoting less documentation (as many would say), it gives some people an excuse to *not* write documentation at all. Let's image that if they knew Agile is actually saying balanced or appropriate level documentation, it will give some others an excuse to *add more* documentation coz we have too little of them!

Tue, Jul 17, 2012 mindwave

Well-well, Voke is the ultimate authority on life-cycle process... Seems that it's the Voke's report that is rather 'designed to sell [Volke's] services'.

Agile methodologies have never been positioned as 'silver bullet' - something that would magically turn late overbudget projects into timely happy releases.

So no wonder that in companies with irresponsible project mentality any methodology is doomed to fail. Management of these companies is ready to declare 'See, Agile does not work -- we tried!' simply to justify their own inability to change.

Don't blame the process -- blame those that control the game!

Tue, Jul 17, 2012 raoul mangoensentono Suriname

Is it really the fault of the development method if Project Managers/Scrum Masters cant lead theair developers. If developers can't code, can't learn code from their peers. If peers can't teach or have the time to teach their juniors. If your coustomer doesn't know what he wants, doesn't make the time for you and just as worse you as a developer or an analist don't really know how to aks the questions to get to the root of your cusotmers problems? Is it then the fault of Agile or Waterfall or any other development method?

Tue, Jul 17, 2012 Keith Norwich, UK

Another “Silver Bullet” finally shown up for the froth it is. After 40 years in this business I’ve seen ‘em come and I’ve seen ‘em go but, as the old adage says “At the end of the day, a bunch of fools with a tool is still a bunch of fools.”.

Mon, Jul 16, 2012 Bob Bryan

About time the software development world comes to its senses and we find out through some very convincing statistical evidence that agile is not all that it cracks up to be. To understand why some of the agile practices are not a good way to run a software development project, see: http://efficientsoftwaremethodology.wordpress.com/esdm-home/problems-with-agile-practices/. For a better way to run a large or small software development project that increase productivity, see: http://efficientsoftwaremethodology.wordpress.com/

Mon, Jul 16, 2012 Scrum Master Jar Jar

Meesah say, you should learn to do Scrum the Gungan way! http://softwaremaestro.wordpress.com/2007/06/30/scrum-master-jar-jar/ Jar Jar

Mon, Jul 16, 2012 Mr. Mike smoky mtns

It's interesting to read all the citations where "Agile" failed in one instance or another. Scrum tutorials point out that everyone must be committed to the methodolgy for it to succeed. Scrum can be defined around ANY project - if your team can't execute, don't blame scrum. If the scrum master can't cancel a sprint for fear of punishment, you might not be agile If the sprint is longer than two weeks, you might not be agile If the business owner does not attend stand up, you might not be agile If you have team members hiding in plain sight, you might not be agile If your business owner can't define the domain, can't get buy-in from customers, or can't move the process forward... YOU MIGHT NOT BE AGILE!

Mon, Jul 16, 2012

Really? How many executives would ever say that Waterfall worked for them - really worked for them. Agile concepts make sense in theory and practice. Like any method or culture change, working on organizational buy-in to perform Agile as an organization (not lose collection of people) is imperative to any success. Those organizations that do not learn from those who have gone before them are certainly doomed to repeat the misakes of the past and create a sub-optimal outcome.

Mon, Jul 16, 2012 Becky Nagel Editor, ADTmag.com

Hi All -- Just to address some of the comments here, the article is a news story on the report, but by writing it we are NOT indicating one way or another what we think of the content. Just reporting on what it said. As you may know we also run an Agile Architect column by Mark J. Balbes -- you can check it out at http://adtmag.com/articles/list/agile-architect.aspx. Thanks -- Becky (bnagel@1105media.com)

Mon, Jul 16, 2012

Is this for real? I am having a hard time believing that someone would write an article calling Agile a failure because found it difficult. A shift in thinking can be difficult, but that does not inherently make it bad... and many of the items on here that are touted as failures of Agile I think are actually successes. That a developer can actually call out an unrealistic timeline does not seem to justify the term "rebellion" as this article implies. Instead I think that it is helping Business understand realistically what is a possiblity and what isn't... how is that bad for anyone? And Agile is more successful with experienced teams... again, a failure? Really? Isn't that true of ANY methodology? Okay, too many things wrong with this article to continue...

Sun, Jul 15, 2012 Jordan

Brainslink et al That waterfall fails is by no means assured. See my blog about that: http://jordanbortz.wordpress.com Even if waterfall were so bad and failure prone, there are an infinite # of alternatives to it, not just Agile or Scrum or Kanban. Agilists build up a straw argument against a strawman for the purpose of selling placebo to the world at large. There isn't any evidence that agile is more effective than placebo, but there is a lot of evidence suggesting people are charging a lot of training whether or not the therapy is effective or the disease is so bad. Jordan

Sun, Jul 15, 2012

Surely some truth in it. Agile is for a team thats really experienced & has matured SW developers who are self directed. If you have a relatively inexperienced team, you would end-up having a messy direction less environment or doing waterfall under guise of Agile !!

Sun, Jul 15, 2012 Richard Brisbane

This article is just plain misinformation (or maybe disinformation).Lets try to stick to facts here.1/What does agile even mean in this context. It's a bit like saying we surveyed two hundred people learning the violin and found it hard and slow. Yeah - software development is hard and overcoming your organisational dysfunctions which is fundamentally what an agile approach recommends is damn hard. 2/ Who cares what comments were made about members of the agile movement - whatever that means. As opposed to who - project managers with Gantt charts? 3/You mean to say some crazy people in the agile movement are trying to sell services and make money. How shocking! And very unlike anyone selling a "report" on a topic they very clearly have little real knowledge of...

Sun, Jul 15, 2012 BrainsLink Boston

Companies fail at agile development for one very simple reason. They wrap waterfall around it. They claim to be doing agile development but they are really doing waterfall in disguise. Failure is assured.

Sun, Jul 15, 2012 Post Agilist

I have an entire blog covering the areas where agile is inadequate, unproven, and oversold, as well as what to do instead. Feel free to give it a read: http://jordanbortz.wordpress.com Jordan

Sun, Jul 15, 2012 J. B. Rainsberger Summerside, PE, Canada

There's no question that the not enough companies have succeeded with Lean/Agile approaches. I find many complex reasons for it. I find one fundamental underlying problem: the survey itself assumes that all companies could possibly succeed working this way, especially when only a small portion of the company (IT or some subset of it) tries to change so fundamentally. I don't think that's true: the global monetary system, the corporate system, it doesn't fit the basic ideas of Lean/Agile. Large companies especially can succeed without these kinds of changes, because they don't have enough competition to push them towards serious change. To call it "Developer-centric", however, is just plain wrong. That's the one part of this research with which I absolutely cannot agree. It's nonsense, and shows how fundamentally wrong many people are about it. I'm sure both the sellers and the buyers of Lean/Agile-related advice are both and possibly equally to blame for that.

Sun, Jul 15, 2012

Seems that there are a lot of "fan-boys" who took offence to this article. I like reading contrary opinions, it helps me in making my own decisions (more information to chew on). I have worked with a couple of 3rd party companies now that claim to use an "agile" process. Even when the requirements were clearly stated up front (we had detailed documentation describing our functionality) we observed the following: a) they had difficulty quoting a fixed-price, b) the software was late, and c) the number and type of bugs were staggering. Both of these companies claimed to have quite a few clients and have been doing agile for years. Just my experience.

Sun, Jul 15, 2012 Wayne M Tampa

Ten bucks says that these companies wanted the benefits of Agile without putting in the work. In other words, they want bug-free code and fast iterations but won't do TDD, Pair Programming, having the customer available at all times to answer questions, allow for refactoring/tools, or anything that actually EMPOWERS companies to have bug-free code and fast iterations. You aren't "agile" just because you do away with planning and mandate a two-week release schedule, and I'm willing to bet that most if not all of the companies that claimed it was "hard to use" and that it failed did just that. This report is akin to somebody saying they tried owning a house and it failed miserably so an apartment is much better, but when they owned the house they didn't do any of the maintenance and upkeep.

Sat, Jul 14, 2012 FredInIT

The information given in the article looks like someone who read How to Lie with Statistics as a recipie on, well, how to lie with statistics. The first bullet... 64% found the transition confusing and hard.... 28% reported success with using it. These two numbers aren't even talking about the same thing! For example, out of the 64% that found the transition difficult, what percentage of projects failed|succeeded? Out of the 28% that found success, what percentage found the transition easy|difficult? I have a couple 99.7% of all convicted criminals have eaten a tomato. 100% of anyone who has ever eaten a tomato has or will die. Agile, Waterfall, etc., all have their good and bad points - having done work with several different systems I have a fair idea of what's going on. Much of it has to do with the business driver for the project. If time to market is the driver.. Agile. If security, stability, reliability and survivability (think life support system code on the ISS) are paramount- you better use waterfall. I do agree, though, that if the business is not able to constrain themselves with pointless changes in UI and other frivolous requests, force them through the full scope-change request process of waterfall. Here's my final statistic - 100% of all project failures occur, at some basic, rudimentary, fundamental level, due to a lack of communication and|or understanding.

Sat, Jul 14, 2012

The fact that the article has to be purchased says it all. If agile is about selling services, what is this article about? Is it not selling the Vulcan report in most illogical manner?

Sat, Jul 14, 2012

I've seen agile work really well, and this report sounds less than objective. On the other hand I've seen, other times, the higher ups use agile's flexiblity of change as an excuse to abuse, they change everything back and forth and delight in how fast the changes take effect, but don't notice that the other stuff they had originally planned for that time didn't get done because they decided these other stupid changes were more important. Then, the deadlines loom, the programmers rightly point to their marching orders, the blame is spread from the higher ups on down, and it gets unpleasant. But this is not agile's fault. It's a tool, like any other. It has it's uses.

Sat, Jul 14, 2012 Duder

"The report contrasts the "developer-centric" Agile movement with software engineering, a more comprehensive part of Application Lifecycle Management (ALM) that incorporates cross-functional teams with responsibilities for architecture, design, testing and more beyond just software development." What? Cross-functional teams that include QA, product, design, and developers are the corner stone of Agile development, in fact it's the whole freaking point of Agile. An agile team's product owner prioritizes work, the developers design and code, and it's not considered done until QA signs off on it.

Sat, Jul 14, 2012 Depressed Gov't Worker New York

I made the mistake of attempting an agile process where I work. Here's what happened:

1) The business unit did not understand what I was asking for; instead of "business rules" I got things like "Use more yellow to punch up the UI a little". Even after I explained in painstaking detail what a business rule was, I got things like "Use Times Roman for all prompts". After a while I gave up. I finally DID get a business rules document about two to three years after I'd first asked for one, but none of the rules actually applied to the software.

2) Instead of receiving changes that actually corrected deficiencies in the software, I got a never-ending set of pointless, tiny, changes in text wording. The changes that came in one week would often contradict changes from the previous week. Fully THREE WHOLE YEARS after the software was functionally complete, I was still receiving change lists and not permitted to go to beta. Finally, the project nearly became a scandal in my organization and the business unit tried to blame my boss and me, saying we were the ones who wouldn't "release" it. We countered by going to the director with a detailed explanation of the "change request" problem. We're actually going to beta now -- SIX WHOLE YEARS after I started working on the project, and FOUR years after it was ready to go to beta.

Agile CANNOT succeed until business units are mature and professional enough to fight the temptation to turn your agile project into a job security program for themselves.

MY RECOMMENDATION:

Strict waterfall with respect to user interface, Spiral model for back-end, and ONLY within the IT department, where you're working with other professional programmers. Never EVER allow nonprogrammers to have input into a design during the engineering process. Unless, of course, you WANT the project to fail. ;)

Sat, Jul 14, 2012 Felipe

Old school methods emphasize the cost of change: how the cost of changing a requirement increases as it advances through each stage of the SDLC. New models say "change is welcome". They emphasize customer collaboration, minimizing risk by failing early in the SDLC, etc. The truth is: the old methods and the professionals that use them are considered obsolete, not because of the theory. The theory can be fine to certain extent... it is the culture built around it. The culture of ripping the customer off.

Sat, Jul 14, 2012

As an imbecile, I have a constant need to come up with new magic-bullet ways of wasting time, rather than actually turning out working, maintainable products, which is much harder. When's the next Story-Point Poker session?

Sat, Jul 14, 2012

"s this article just an advertisement for the report?" Yes.

Sat, Jul 14, 2012

He's absolutely right. All the people that says "well they just failed at implementing agile" are kidding themselves. If a methodology is so difficult that it fails 75% of the time its implemented, then its a horrible methodology.

Sat, Jul 14, 2012 Matthew Eakin Columbus, Ohio

Whenever I hear someone describe agile as a "developer-centric movement" I have to laugh. It shows me they don't understand agile and what it is about. An IT department that is truly agile includes everyone: business, analysts, testers and developers. All pulling their own weight to get things done. It also includes design, architechs, network folks; everyone in the department. I would advise Voke in the future to sample people other than developers and development shops. But if they choose not to, please include dev shops that do agile right; like Microsoft, Google, Oracle, Amazon...

Sat, Jul 14, 2012 johnathan

This article smells like the demo version of the report, which I'll never see I guess. I had been in scrum for a couple of years now and trust me, it's hard for developers and conflicts, confrontation arose sharply compared to traditional waterfall.

Sat, Jul 14, 2012

We use agile and we definitely do not document. I worked for 6 months at another extreme programming company. Pair programming daily. You name it we followed the strict line. Not a stitch of documentation. I'm so glad that "agile" now pretty well means anything you want to get away with. If you want to do documentation and QA it's okay. It's "agile" now. Maintenance? That's what the next people of people get stuck with when you the current group of people leave and realize it's going to be a mess. Best thing for micro managers is "agile". No architects. You do just what needs to be done but the micro-manager is there making decisions about stories that look suspiciously like a design. I'm so glad "agile" means nothing. You ask most managers and the ones that are forced to go do the "in" thing just do sprints and stand ups.

Sat, Jul 14, 2012 gill bates CA

Scooter Fl, you are so right! Agile and "regular" dev cycle are like parkour and running. The end result may be the same but the amount of effort is incomparable.

Sat, Jul 14, 2012 Shawn h Corey The Great White North

"'The Agile movement is designed to sell services,' says analyst firm Voke Inc." As if software engineering wasn't about selling services. Besides, most requirements are nothing more than a hodge-podge wish-list some salesman wrote on the back of an envelope. The result is that most clients do not sign-off on them until 80% of the user-acceptance testing is complete. Software engineering works no better than agile.

Sat, Jul 14, 2012 Mpopke

I use agile techniques all the time, and I also document the hell out of what I'm doing and I make detailed plans at every stage. We report, we design, we plan and we document. What you are describing is not what I would call agile.

Sat, Jul 14, 2012 Scooter Florida

Agile is not easy. Even if you are fit you can't just run parkour and not expect to fall.

Sat, Jul 14, 2012 Karl

If developers do not meet documentation requirements and the project owners accept the work anyways - good for the developers. It is lame to come out and complain after the fact. Write stuff you need in the SOW of your project for christs sake. If you as the project owner "assumed" you'd magically get what you need, you are the incompetent, not the developers. That said, yeah, Agile strikes me as a way to try to squeeze code out of coders who can't code and designs out of systems engineers who don't know the industry.

Sat, Jul 14, 2012

Is this article just an advertisement for the report?

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above


Close this Advertisement