Is Agile Development a Failing Concept?


Many development teams have embraced Agile as the ideal method for software development, relying on cross-functional teams and adaptive planning to see their product through to the finish line. While other teams still stick by traditional processes such as Waterfall, Agile supporters tout their method as especially effective, with more frequent quality checks and an ability to adapt.

Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods. And now one of those developers, Andy Hunt, has taken to his blog to argue that Agile has some serious issues.

Specifically, Hunt thinks a lot of developers out there simply aren’t adaptable and curious enough to enact Agile in its ideal form. “Agile methods ask practitioners to think, and frankly, that’s a hard sell,” Hunt wrote. “It is far more comfortable to simply follow what rules are given and claim you’re ‘doing it by the book.’”

But Agile, at least in theory, is the antithesis of rigidity and formula. “What happened to the idea of inspect and adapt?” Hunt added. “What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand? The canonical agile practices of popular methods have remained essentially unchanged for over a decade.”

The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In other words, software grows and changes based on real-world feedback and actual evidence, until it reaches a state in which it actually works. Hunt advocates the use of the Dreyfus Skill Model within this framework, as a way of on-ramping less-experienced developers while allowing their veteran counterparts more flexibility.

“Whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors,” Hunt concluded. “There is no ‘us’ versus ‘them.’ There is only us.”

In broad strokes, GROWS sounds a lot like Agile in its most fundamental form; presumably Hunt’s future postings, which promise to go into more detail, will show how it differs. If Hunt wants the new model to catch on, he may face something of an uphill battle, given Agile’s popularity: Small development teams and massive enterprises have both embraced Agile as a way of working through development, and many companies are actively seeking job candidates capable of operating according to its principles.

43 Responses to “Is Agile Development a Failing Concept?”

  1. Richard L

    I’m glad to see that there is some critical evaluation of Agile going on. While nobody I know is nostalgic for the bad old days of requirements upon requirements resulting in a committee to oversee the requirements, too many shops that I have worked in have used Agile to be rudderless as to what the product actually does and how will they get there.

    Agile, in my opinion, totally falls apart when you hit the maintenance phase of the product life cycle. The client has a stable system and you’re doing daily builds? What if they need only 1 of the 30 fixes implemented? Most shops have don’t have a robust enough methodology to handle that.

    Good software takes time and planning.

  2. Elena Danielyan

    Before declaring something a “failing concept”, it has to be fully implemented and tested. Agile, either Scrum or Kanban, or Scrumban, works miracles — WHEN implemented as designed. According to latest stats, 49% of the companies proclaiming they are “went Agile” never implement real Agile models, and consequently failed in their processes. Failure is with implementation, not with Agile. Your post headline is misleading and, forgive me for saying this in total openness of Agile spirit, is opportunistic. Agile development is not a failing concept, while resistance to Agile and attempts to market various “improvements” to this resisting audience are definitely doomed to failure.

  3. Michael Long

    Too many companies use the Agile “be flexible” rule as a carte blanche, get-out-of-jail free card.

    They pick and choose what parts they’re going to do, which parts they’re going to ignore, and which parts to which they’re just going to pay lip service, and call the end result “agile”. They don’t understand how each part reinforces the other, and as such pick and choose among practices and ceremonies, and tell one another that they’re being “flexible”.

    As Elena said above, failure is with implementation, not with Agile.

  4. I’ve seen good and bad agile. Those who follow their chosen methodology succeed well. Those with scrummasters who don’t understand agile fail since they’re trying to use waterfall in something that looks like agile.

  5. Elena Danielyan

    Agree entirely with Michael and Rob. Companies pull on some formats of Agile, just so they can present themselves as “Agile shop”, but pick and choose as they please, breaking Agile process into pieces, devoid it of any meaning, and then claim that “Agile doesn’t work”. Agile does work, flawlessly, if we commit to a change of our own waterfall mindset, implement prescriptions and trust the process.

  6. Noixi

    I have been with 3 businesses that implemented Agile, Too include Agile/Scrum, and Agile/Kanban. One of the first things I ever hear about them, is the phrase “They probably didn’t implement it correctly”, in regards to other businesses having failure with it.

    For my 20+ years of software development, I’ve never heard that phrase for anything else.

    My conclusion about Agile anything, is that I agree with Eric Meijer, Agile is a CANCER and must be killed. I agree with Eric, Agile adds a “subtle control” and prevents real-world feed back, while blocking a structured chain of command to get coding coded.

    Further, while all the “Agile” advocates say it allows for “thinking/creativity”, I have experienced 3 time over, that it does the opposite. It discourages thinking/creativity. Developers are more concerned about some CFO pushing a button to ensure forecasting on expenses is applied in breaking tasks down into 4 to 8 hour intervals, than dealing with thinking/creativity.

    Eric Meijer elaborated last year in a EU conference, that Agile is preventing people from coding. In that conference, Eric asked people in the audience, “Have you checked code in this week”? For which, most people in the audience DIDN’T raise their hands.

    The bottom line of that conference, is something I’ve seen EVERY DAY, for the 3 Agile-businesses I have been with over the years. EVERY DAY. Agile prevents software developers from developing software, let alone, deal with real life feedback.

    Developers need a clear chain of command. And businesses need to let developers get code into PROD ASAP, and have feed back come back to the developers, so they can see/feel/touch the real world. Something which Eric Meijer detailed. Putting artificial subtle controls from: 4/8 hour task blocks, to voting in a committing on a tasks complexity, to moving JIRA blocks across a board in supposed 10 minute standups, that actually end up taking an hour every day, and other Agile aspects; doesn’t work as far as I have actually experienced;

    For which, some advocate of Agile would then say: “They must not have implemented it correctly”.

  7. I agree, the word needs to go away for people to take anything seriously. The only blessing now is that the sales community has found another word to wear out and thats “ioT”. If I receive an email with either ioT or Agile in it, I promptly press delete.

  8. Steve Naidamast

    I have to agree with the comments that Noixi made in his reply to this article.

    I have been a professional developer for a little over 41 years and still at it. I have done a tremendous amount of studying of software engineering principals and have successfully implemented them on various projects when I have had the latitude to do so.

    Agile in that regard is nothing new, though it is touted as such. It was also not the outgrowth of some manifesto written in the early 2000s. Instead, it was evolution of the failed concept of Extreme Programming (XP). I say failed because XP was generated during the large-scale C3 Payroll Project at Chrysler Corporation. The concepts were extensively promoted around the country in the 4th year of the project. In the 5th year of the project, the project failed as a direct result of the XP paradigm.

    Agile, is merely a re-hashed construct of the Incremental and Evolutionary software engineering lifecycles without the additional constraints that software engineering places on all its practices.

    However, to be fair, the majority of organizations who say they use Agile merely pay lip-service to it as another synonym for sloppy, get-it-done development processes.

    Nonetheless, one of the major failings of Agile is it its pressure to get consistent modifications accomplished in short periods of time. And this doesn’t play very well with as another commenter stated with ongoing maintenance of existing, stable projects.
    Senior software engineering and business\industry analysts have also derided Agile for its lack of cohesive requirements and planning stages, which without, no project can be completed successfully. Just recently a well-known and highly reputable IBM senior analyst wrote a small book in the past few years describing the failures of paradigms that do not incorporate good pre-implementation controls.

    And finally, there is no such thing as eliminating the paradigm of “Waterfall” development in software construction. It simply is not possible, as doing so, as XP and then Agile have both attempted to do, is like building a house without a design plan.

    All the “Waterfall” paradigm stipulates is that you plan out your project first and then commit to its development without the complete idiocy of ongoing requirement and code modifications once the software development phase has begun.

    Only in the Information Technology profession would know-it-all fools claiming to be professionals, derive such a ludicrous concept based on the stupidity of management requirements, who for the most part know little if anything about software engineering except that it is expected that it should bend to their whims like silly-putty. The consistent high percentages of project failures in the United States has demonstrated this…

  9. Richard Roe

    The problem with Agile, of any flavor, is that the process has become more important then the objective. There is no point in slavishly adhering to a process when that adherence means you are putting a process above the product which I have seen all too often over the last 25 plus years.

    The only ‘systems’ that work are the ones where you treat developers as adults and not overgrown children who require a play pen and kindergarten rules.

  10. I’m a process / quality consultant (I envision the developers rolling their eyes already) and I’ve worked in 3 different companies who claimed to be AGILE; they all did pieces of AGILE but 2 of them had elements of waterfall and the third one was just a small shop with lead developer who didn’t feel like writing any documentation so he called himself AGILE. Conspicuously absent from all 3 places were what I consider to be the key elements of AGILE which includes team participation (developers, testers and someone representing the voice of the customer in the sessions). I think that people like to say they’re AGILE but in reality they adopt the parts of the concept that allow them to do their jobs the way they want to – to get away from too much process or excessive documentation (understandable) but don’t exhibit the commitment and energy to keep the intensity of that committed team structure in place.

  11. Hesus

    Changing the name of your daily meetings to “scrums” does not make your company agile. Subsequent failures are not the fault of true agile development.

  12. Ron Borta

    The Agile Manifesto stated concepts that had developed over a long period of time. I’ve been using these concepts, as appropriate over the last 40+ years. With the right project, the right people and the right customer, it’s a beautiful thing to behold. Good luck finding those more than once or twice in a lifetime. They are concepts to strive for. Once institutionalized as a process, those concepts are lost. Any organization using Scrum, KanBan has crippled the concept. This can be summed up best by “If you don’t know where you’re going, you can’t get lost”. When engineers have to block off small periods of time to accurately meet prior predictions, they do not take risks. Even when blocks of development are set aside for Technology development within the Agile framework, risk and creativity are discouraged by the process. Normal engineering process encourages creativity to find new solutions within defined parameters. Adding Agile concepts to that increases participation by additional minds, including the eventual customer, but must be implemented by knowledgeable engineering staff and not by process weenies, or schedule slaves.


    Agile and the rest of these ridiculous “Methodologies” are what companies that know nothing about IT put into place because of their utter incompetence in management.

    Most people would agree that putting a person with no skills in law in charge of the legal department, and letting that person enter into legally binding decisions for a company would be very stupid.

    Most people would agree that putting a person with no skills in Accounting in charge of the accounting department and when they should and should not cut checks would be incredibly moronic.

    Most people would agree putting a person with no skills any form of construction in charge building projects and letting that person make decisions about the process of building and remodeling anything the company owned would be a plan for disaster.

    And yet most people will put someone who knows absolutely nothing about IT in any way shape or form in charge of an IT Group and have that person make poor decisions and think that they made a good choice. Because hey! If they dont? We will pay for Agile, ITIL, SCRUM etc to come along and fix the issue.

    Companies that feel they need that crap dont have a management problem. Not a Process problem.

  14. Terry Owens

    inhave witness lean methodologies “fail” due to the general human spirit that thinks a pivot is a failure. The pivot is quite frankly the most important step in any Lean methodology.

    Agile hasn’t failed. Humans not adhering to the explicit guidelines set forth within have failed, but not the methodology.

  15. Nikitas Marangos

    Agile if done right can work. But *everyone* (developers, QA, BA, product management, etc.) has to buy in. I can’t tell you how many times I would try to contact BAs and product management to get information on specifications and would get radio silence back. Then when it’s time for the demo: oh, they have plenty to say and snipe me with questions and comments!

  16. Elizabeth Atwood

    Steve Naidamast is right. Agile and its relatives, including but not limited to Scrum and XP, are far too focused on slap-it-in-hope-for-the-best. The rather substandard results I’ve frequently seen on my daily travels on the Internet prove this with actual empirical evidence. Malfunctioning code, broken or mangled English and awkward user interfaces are but a few of the symptoms of the widespread sloppiness which is passing as production code today.

    There’s a parody of The Most Interesting Man In the World which says this in a nutshell: “I don’t always test my code. But when I do, I do it in production.”

    If there isn’t enough time to do it right, there certainly isn’t enough time to do it wrong. Over-reliance upon statistics measuring how much code has been checked in, or interrupting the team for yet another ten minute rehash of what’s going on or will be soon clearly is counterproductive and a monumental waste of time and resources.

    Fads like Agile, XP, Scrum and that blessing to publishing houses and seminar holders everywhere, Six Sigma, are not doing anything to improve the quality of production code. ‘Nuff said.

  17. Bill Grindley

    The management types are always trying to cut time off the development process. So they cut time off the design part of the development process, and we now say we are “flexible” or “agile” when all we have done is cobble together a bunch of code in a frenzy. Are we then surprised that it does not meet the user needs, or that it is very “buggy”? Oh, well, we just did not implement the Agile process correctly (wink, wink).

  18. Charles Novick

    Agile has become a buzz word and a crutch. Agile is comprised of a number of valid concepts that when applied will move development forward at a reliable pace. It is favored by management because it provides a means to hold developers accountable for their performance. Sometimes it works, but in the long term it will not replace good judgement on the part of project managers and a solid QA process.

  19. Elena Danielyan

    //Sometimes it works, but in the long term it will not replace good judgement on the part of project managers and a solid QA process.// — I am am expert in ‘solid QA process’, from the inception of formal QA, through formal SDLC planning every comma on large enterprises timelines for a year ahead, and to the formal Scrum Agile. Nowhere, under no methodology and historic circumstances, QA had that much opportunity to actually implement a solid quality process and, most importantly, have a guarantee that this process is adhered to horizontally and vertically — as we do under Agile. Only in Agile formats we have team and company-wide commitment to QA processes and standards, and only in Agile environment we’re guaranteed that QA time on a project is not slashed to zero. Only in Agile QA is actually performing its role in releasing bug-free products, rather than turning into post-production bug chasers.

  20. Brandon McCullah

    Richard Roe smashed the nail firmly on its head. The last Agile shop I worked at was feverishly devoted to making sure they were doing it the “Agile way” at the expense of getting anything accomplished. It took 2 hour-long (but of course intended to be 15 minute) daily stand ups to decide if a new 5 point story should be split into a 3 point story and a 2 point story, and then which should be the 3 point story and which should be the 2 point story. The debate ultimately ended when I asked if either of the 2 stories had any business value on their own, to which the answer was “no.”

    The excuse that Agile doesn’t work because it wasn’t implemented properly is just that, an excuse. An excuse for a reckless development methodology.

    I’m starting to think that what they say about XML is also true for Agile: “Agile is like violence; if it doesn’t solve your problem, you aren’t using enough of it.”

  21. Peter

    “Many development teams have embraced Agile as the ideal method for software development” – My Opinion: there is no such thing as the “ideal method” for software development but overall I like Agile. However, here are some of the pitfalls (again my opinion).
    1. Developers are pressed to report daily status/progress. Many hard technical problems need longer than a day to be resolved/implement/designed/analyzed. Hence, the social pressure of the daily/public scrum make developers create sub-optimal solutions i.e., just hack something together so you have something to report at the daily scrum.
    2. Lack of end-to-end project planning. Doing a full/detailed end-to-end project plan is hard and time consuming. It forces you to figure-out, up front, all the project dependencies, critical path and resource requirements. The notion is, because agile is so flexible you do not need to do a full/detailed end-to-end project plan i.e., just pick some tasks off the product backlog and do your sprint. Results, project progress can be block waiting on a resource or dependency.
    3. Kick the can down the road. Since there is always another sprint it does matter if a task has to be rolled over to next sprint. This is a schedule killer.
    4. We don’t need to lock down the requirements because agile is so flexible. Yes, at the beginning of the development/implementation you can make some changes. However, if you do not lock down the requirements at some point your project will never finish. Again a schedule killer.

  22. Barry Kogan

    I think the Agile development is not a technology yet, it is set of micromanagement principals which must be adopted every time to specific product development,which some times contradicts engineering approach.
    Waterfall is a technology of the product development which covers all product lifecycle. Technology, meaning that if you follow the process you get the product you want.
    As always with principles they are open for interpretation which leads to “Agile is not implemented correctly…”.

  23. Ron Borta

    According to Scrum Masters there is no other way than Agile. All other methods fail. What a load of …………

    How do they explain all of those Agile organizations cranking out #$%^$#@ web site and app software. Oh, I forgot, it the process that counts, not the product.

  24. Sitarama C

    I agree with comments from Steve Naidamast and Noixi.
    I guess Agile and like methodologies are more suited for development of meta-Application software like frameworks, dbmss, OSs, products etc. where requirements are firmly in a product manager’s domain and there is no uncontrolled shift in the requirement stance.
    In real world business apps used by average business users, requirements fluidity as well as undefinedness stem from lack of ownership for requirements. While there is ownership for acceptance of such systems there is no ownership for requirements and more importantly there is no ownership to when or how to ‘close’ requirements. It usually ends up as some compromising point after all muck raking.
    I think this is one area Agile has brought in a little better control — Agile actually involves a/some business users to ‘close’ out requirements (or story boards) so there is a finiteness to atleast part of the development. But yes in the end, the story and the associated code may get thrown out before the ‘final’ production system turns up.

  25. Shouldn’t agile, much like a programming language, be used as a tool than as a philosophy. As an example, working on developing an rdbms is more fit with the waterfall approach than agile as working on a data model is akin to working with concrete or stone – you really don’t want to be constantly re-factoring that. Once that is made, the UI’s, applications on top the db are probably best iteratively developed as they can be more easily refactored and those are really the things that end users should be providing guidance on.

    Just my opinion.

  26. Rob S

    You are proving the point that if Agile is improperly set up it fails. One of the requirements of Agile is that the standup is about each person indicating: “what I did yesterday”, “what I’ll do today” and “where i’m stuck” then move on.
    If you debate, you are not doing stand-up. All debating should be pushed aside to a separate meeting after the standup, which typically includes a subset of the team rather than everyone.

  27. Rob S

    That was meant for Brandon’s comment.
    Apparently this message board has been changed so that replies do not get attached to the related comment…did someone use a bad Agile approach to change that?

  28. Rob S

    To Elena, I agree that QA gets more say in a properly implemented Agile process. Unfortunately, so many places are not implementing Agile properly and still ignore QA.
    It seems that TDD (Test-driven development) while a relatively new term, has a lot of potential to guarantee a successful Agile implementation. The biggest problem, again, is that everyone needs to buy into it. Developers hate it because they can’t just jump into the code; managers hate it because they actually have to think about what they want to accomplish up front before any development begins. But when applied, development goes very quickly and you know exactly when the product is working. (Of course, the testers have to do a great job at building useful tests for the use cases.)

  29. David Wozmak

    Agile didn’t just appear out of thin air, in a vaccum (so to speak!). Agile appeared amidst an industry in crisis. So many miss the point of Agile, and why it arose to address the problems in the software industry in 2000-ish. Sometimes it’s good to revisit those: 1) typical project lead times were measured in quarters, if not years; 2) system and application architectures were going through seismic changes; 3) the internet; 4) customer expectations around software cycles was changing; 5) Y2K “pulled back the curtain” and exposed the software industry’s dirty undergarments: we were clearly running around in circles, unable to find our own derrierres with two hands.

    One problem that persists: I can establish a milestone that’s six months from now, and be about 50% sure TODAY that it will fail. I can however establish a milestone that’s two weeks from now, and be pretty much 95% sure it will NOT fail.

    So today, the REAL thrust of Agile is two-fold: base development cycles on resource availability instead of feature desirability; and manage expectations against deliverables on a continuous basis.

    The real problem in software development is that expectations and projections are synched up at the start of a project, and immediately start to diverge. As in, immediately. Agile in it’s core is about re-synching on a regular basis. It doesn’t so much manage development, as it manages expectations.

  30. Perry

    I’m someone who has recently returned to the field of project management after years serving alongside developers in customer-facing roles as part of project teams.

    Lately, I’ve immersed myself in the study of methodologies and best practices (Agile being only one), so I very much appreciate this lively and provocative discussion.

    My take is that this concept of “failure” — habitually regarded as negative — is actually a good thing. I would argue that methodologies like Agile, “lean” or Scrum are informed attempts (albeit imperfect) that work best when they embrace “failure” as a means to figure out what works and what doesn’t.

    Any good methodology based on best practice would properly embrace failure as a healthy — and even necessary — outcome when it comes to understanding lessons learned and continuous improvement. Iteration works only when you know what to iterate, that what you’re repeating actually works to solve problems, not recreate them.

    Also, any methodology that really works tends to embrace issues and problems and encourages team members to raise concerns in an open culture. Cultures that tend to sweep issues under the carpet will tend to fail on projects far more than open cultures — regardless of the methodology used, be it Agile or anything else.

    Studies show high numbers of items on the issues log tend to be is a sign of a healthy culture and good project management discipline. Methods that bring problems to the forefront will outperform those that tend to emphasize all-too-familiar avoidance techniques like burying heads in the sand.

    Speaking as a non-engineer (with 20 years of experience working in and around engineers) I’ll leave it to the experts to agree whether it’s safe to say programming is simply evolving toward high degrees of efficiency; I understand it takes far fewer lines of code to get a machine to do something today than it did 10 or even 5 years ago. Agile is simply a reflection of this increasing efficiency, an invention out of necessity.

    Methodoliges need to evolve too. We should expect Agile to evolve and we should encourage new methodologies to form in the face of inevitable and ever-increasing advances in programming science and technology. Methods need to change and adapt with the changes in velocity and complexity of project work.

    Projects are becoming increasingly collaborative, interative, and less “siloed.” I think we can agree these are good things, positive signs that reveal there’s hope for those methodologies that don’t stay stagnant and monolithic, that evolve to improve and get better over time.

  31. Robert

    I think a wise comparison with the agile method is to ask if it is practical to build a building with the logic. So if someone can point me to anyone in the physical world building a structure with agile methods I definitely want to hear about it.
    Will agile work somewhere? Sure it will.
    Should a business be implementing agile so thoroughly in IT – yeahhhh I think not.

  32. mahmad

    IMO agile methods’ best contribution is in the areas of structuring design and development activities to allow for discovery and adaptation. Like in any other process or methodology where formalizing and ‘selling’ of the same has ended up over-engineering the concepts and in fact hurting creativity, formal agile methods suffer from the same. Based on my experience, I also believe that upfront planning (not necessarily generating ‘CDRLs’ to collect dust afterwards) is irreplaceable. Moreover, in terms of project cost estimates and control, agile is no magic bullet – bottom-line pressures remain the same – with possibly risk mitigation strategies applied somewhat differently (again think discovery and adaptation).

  33. Rob S

    Back to the title: “Is Agile Development a Failing Concept?”
    The clear answer is NO…at least not any more than others such as Waterfall.
    If we look at Agile, it fits certain types of projects but tends to drag out a very-well defined project that could be done in waterfall.
    If we look at Waterfall, it fits certain types of project but tends to get stuck in “what do I do next” hell until the deadline approaches at which point everything is rushed and many, many mistakes are made (unless, again, things are very well defined.)

    If you build a skyscraper using agile, you’ll clear the ground, build a level, build another level, destroy both levels and build a foundation then build again and again, then break open walls to add plumbing, then break open walls to add electricity, etc. You will get everything done but with much more expense and time than traditional construct. However, if you wanted a round building that captures rainfall and used solar power, the Waterfall process would likely fail too since these are not very well-defined processes in construction.
    However, in software, it’s easy to throw things away without expense (other than labor) and if you apply things correctly, the end product will actually get done on time and be much more solid than waterfall with ongoing changes and a long project time.

  34. John Canessa

    Yes it is. Waterfall is not a software development process / methodology. Waterfall is a meta-model for software development. It is almost impossible to get it to work without actually backtracking from different phases. Going back is frequently done during the system integration and testing phases.

    Regardless on which software development methodology or combination of them is used by a team of developers, current tools allow for testing before and after integrating modules into the main software. It is just a historical fact that tends to be associated with Waterfall by Agile promoters due to the lack of testing tools in the 1960’s. With current tools and technologies that have nothing to do with Agile or any other software development methodology for that matter, sets of tests can be conducted to make sure old and new issues / bugs have not been introduced. I believe this well known technique is called regression testing. Each software development platform seems to have several tools used to generate and automate tests.

  35. Gaurav Bhatnagar

    It all depends on project. If project is well defined, go by rule-book. If it’s research type of project, go with Agile. Companies are not flexible enough to adapt different methodologies as per project. I’ve seen the cases where less experienced developers are totally lost while following Agile process.

  36. ReVeLaTeD

    As a developer that has experienced all sides, I feel that Agile works only in specific, finite situations.

    Someone else mentioned that all of the critical roles must be engaged and involved. This is true. Where it breaks down is the “voice of the customer” role.

    Remember that old story from elementary school, where you whisper something to someone next to you, it goes around the room and by the time it gets back to you, it’s a totally different story? That’s what happens when you introduce a single, biased individual as “voice of the customer”. That, to me, is the #1 failing attribute of Agile.

    If the intent is to simply parse and funnel requirements through a single individual, they cannot add their own bias to the equation, but they all do. Which convolutes the requirements because when you present a solution to the customer, and it isn’t what they want, the “voice of the customer” claims you didn’t understand the requirements, instead of owning up to the fact that they introduced bias that broke the chain.

    If the intent is to dictate what the customer needs, I question the need for such a role. Let the user tell me what they want, I’ll build what meets that objective and nothing else. I don’t need another person translating anything because it gets lost in translation.

    Another person mentioned that Agile spends way too much time focusing on process rather than deliverable. This is totally true. The standups are a nanny process and a waste of time. The point system is fine at first, but it doesn’t need a dedicated meeting to adjust it later. Meetings to discuss other meetings having to do with the status of previous meetings and followup meetings. Agile shops have way too many meetings, then get bothered when deadlines are slipping, and angry when you choose to skip a non-critical meeting so you can meet deadlines.

    Lastly, Agile is fine when it’s code. It doesn’t work with out-of-the-box system development, such as OnBase or RightFax or some other system that doesn’t require code. This is because it’s assumed that you’ve already figured things out and you’re ready to deploy. The waterfall methodology works perfect here as does RAD, but Agile just doesn’t work. It takes time to develop a Workflow, for example, but I don’t need to have a daily meeting to discuss where I’m at with the Workflow. Tell me what the Workflow needs to do – what’s the success criteria – and I’ll build it. Show it to the user, if I missed something along the way, I add it in.

    Agile shops want everything filtered by (1) the BA, (2) the PM, (3) the development manager, (4) the manager of the user before I even get a chance to show it to the end user. By the time I get to that point the user is looking at the solution like we’re inept because the other 4 elements added their own bias and confused the development.

  37. Andy Hunt hits the target: “Agile methods ask practitioners to think, and frankly, that’s a hard sell.” But it’s far worse than that. Instead of Agile encouraging people to think, too many people use Agile as an excuse to NOT think.

    If done properly, Agile can produce great results, but it requires hard work (i.e., thinking) on the part of everyone involved — not just the coders, but the managers, end users, customers and all the other stakeholders. Too many people use Agile as an excuse to say “I don’t have to think about it too much now, because if it’s wrong, we can always fix it later.”

  38. Marek

    Thank You for this post. It led me to the original blog post from Andy Hunt and it was a real pleasure to read. We started using scrum in our company some time ago. In general it was not a bad change but it was done in an atmosphere which was anything but agile. First I’ve heard the line, which became my favorite one,: “If you do not do scrum you are not agile”. Well, maybe this is not a verbatim quote but close enough. Then there was a number of lines explaining how to do things “right” to be “agile” where it was all about scrum artifacts – like “in agile you have to do stand up meetings” (no I don’t). Finally, I would argue that some groups are doing waterfall but broken down into sprints – no inspect & adapt – just crank features which business tells you to.

    OK, in truth it is not *that* bad but this religious approach to the *one and only correct* agile process made me laugh. It is so opposite /in my opinion/ to the idea of being agile, that sometimes it is hard to stand. So when I read this article and the post from Andy it was like big relief – I did not got crazy after all :-). Scrum, as any other approach, is just a tool. It can help to become more agile, especially with retrospectives, it does not make you automatically agile by any chance. And it is not a Holy Grail. I do not think agile as concept is wrong or outdated. I firmly believe it is wildly misunderstood concept, and too often abused in order to make money on it. But who know – maybe GROWS can avoid these flows and help out – time will tell.

  39. Larry

    I just found it ridiculous that recruiters were using Agile and Scrum as the 2 magic words that could break or make an interview. In reality most Mainframe shops use a combination of Agile and Waterfall whether it makes a difference some say it does I don’t actually know or care to read about it. I have been in IT 25+ years and the software development techniques were never a measure of whether a particular software would work or not. Management and programming skills were much more important, because a programmer had no choice but to follow which ever methodology was being used at that particular shop. It wasn’t something one went to school to learn. When Scrum and Agile were rolling off recruiters tongues like there was no tomorrow I scratched my head in wonderment.

  40. First, when a methodology, as part of reason for existence needs to trash what was before, you should suspect something. There is not much “agile” about agile. Aspects of it are the most common of common sense that reflect the AVAILABLE technology of the period. Why were requirements docs so important? Because getting a 1.0 release wrong in 1990 was a great way to destroy an entire company. The technology of today enables a rapid release delivered via the web. 23 floppy disks were a lot more expensive to replace… What about tools? To compare .NET / VisualStudio with the Borland C++ compiler circa 1990 is to compare nonsense. I can’t say agile produces anything better than anything else and believe me… I keep trying to find the supposed benefits. I want to believe agile has some benefit, but time over time, I just don’t see it.

  41. Soirtemed

    The #1 rule of agile “shoot & whatever you hit call it the target”

    Being flexible, providing quick resolution to problems & good service has nothing to do with being agile.

    Agile, in it’s current form of adoption, in most places, is only beneficial to:

    – Managers that want to boost their careers/resume by being credited for implementing change (as agile)
    – Consultancies paid to implement & deliver agile courses/training
    – Consultants that get paid top$ to fill agile roles (e.g. scrum masters)
    – Service providers that want to hide their inability to deliver what the customer/business wants, but still get paid for delivering something

    for me “agile” is the worst thing that has ever happen to software development (the implementation not the theory).

    I can confidently back that statement with 30+ years of software engineering experience in 6 countries and a multitude of organizations.

  42. Matthew Wolfson

    “Agile methods ask practitioners to think, and frankly, that’s a hard sell,”

    And that’s exactly why those people don’t belong in the software engineering profession. You have to understand that part of the subtext in Agile is taking out the trash. In other words, making it clear just how completely useless the roles of project managers, middle managers, and cut-and-paste developers are. If Agile “fails” the reason is always the same: it was never implemented in the first place.