Agile Sucks, Agile Fails – I Hate Agile

Oh Agile, why do we hate thee so much?

If you ever did a search for the terms: “Agile sucks, I hate Agile, Agile fails, Why Agile doesn’t Work,” etc… you’ll find yourself in an internet flame war against Agile. Click a couple links and you’ll find people from all walks of life flaming Agile. From developers, project managers, and even executive level folk.

So, why the backlash? What’s the problem?

Simply put. I believe there isn’t enough writing around case studies, or white papers on how Agile has succeeded. You hear a lot about agile theory, or new ideas around agile methodology (which it isn’t, by the way).

Agile is all about helping the customer. Finding the value where it can be found. In one sense, Agile is the method or process of helping people. 

Knowing the ins-and-outs of Agile, Scrum, DSDM, Crystal, TDD, blah, blah is great and all. Hey man, let’s see those case studies where it’s actually worked! My commitment next year is to only submit talks to Agile conferences around case studies. I plan on writing more about case studies here… or on another blog… … but I think I found the answer: Agile White Papers and Case Studies. Check it out!

Maybe we’ve been agilizing everything too much. Let me see where it’s worked. Sing me a song pianoman. Tell me a story.

64 Replies to “Agile Sucks, Agile Fails – I Hate Agile”

  1. Before there was formal thing known as “Agile” people talked about how Waterfall did/did not work. So the fact that there are people saying the same about Agile (or anything else) should be no surprise.

    I’m always interested in what did or did no “work” and why people feel it did or did not “work” for them. Some things may “work” for some people even if only part of that thing gets applied very well while others may feel it does not “work” unless every aspect of it (as they see it) gets implemented and “works.”

    So people try some set of things that they believe defines Agile for them. They may or may not implement them well (surprise) and they declare that the high level term “works” or does not. I happen to think Waterfall “works” if you accept its assumptions about how to make it work and what constitutes “working.” But there is certainly a way to approach Waterfall in a most dysfunctional fashion.

    Well, some of those same dysfunctions (which people may attribute to a history of Waterfall use), will exist and be part of many Agile implementation efforts.

    I like what I first heard from Ken Schwaber about how Scrum, for example, not “fixing” anything, just making it very clear what the organization must commit to addressing if they want to be more successful. If you address and fix those things, Agile will likely “work.” If you do not, it likely won’t.

    But you could have fixed many of them under Waterfall and made Waterfall “work” (at least better), too.

  2. I don’t think we need more case studies or success stories. They are red herrings. Telling people at company Z that Agile will work for them because it worked at companies W, X and Y is misleading, and essentially, a lie—meaning that you have no better idea of whether it will work or not at company Z no matter how many case studies you can pull out of your hat.

    Being Agile means implementing a set of philosophically sound, human-centric principles in a context-sensitive way which will be different /every time/. Case studies do not help—but they may hinder, as both consultant and management try to force-fit a new team/group/division/organization into someone else’s way of doing things. It fails… and that’s when we hear the cries of “Agile doesn’t work”.

    So, no, we don’t need more proof, we need more faith, more trust, and, let’s face it, a lot more down-to-earth common sense to remind us that /doing the same broken thing over and over again/ just does not work. Y’know?

    1. Tobias! Thanks for commenting man! Oh, the contrarian 🙂

      I would think, though, that there are certain things, that you can take from case studies and say “hey, this may just work here… the environment is the same… etc etc.” not to take it full bore… but to take bits and pieces of Case Studies and try them out.

      … though to be honest, as I re-read your comment… i do heartily agree with you. sometimes… it’s more about faith and trust over ‘proof.’ …. sometimes again… it’s those that write example case studies that help us learn about what (has and possibly can) work… right?

      what would happen if no one wrote anything… at all?

  3. I like what Tobias says because I have been exposed to case study publication for at least 30 years. Many of these really are motivated by promoting a product/service more than delving into what does and does not work.

    To meet Peter’s goal of seeing what has worked and has not for others, I’d prefer reports focused more on specific practices, how they were implemented (in some detail) and what people found were the pros and cons of how they did the implementation.

    There is no question, after a decade, that the Agile Values, Principles and practices “work”; however, making them work, by understanding what they are trying to get at, is the issue.

    When Tobias says we need “more faith, more trust,” I’d agree, in spirit. I do think, though, that one can look at what an Agile approach fundamentally asks be done, and rather easily determine how it all makes sense and certainly can work. But if the willingness to make more than superficial change isn’t present Agile will not “work” any more than any other improvement idea.

    1. Always enjoy your commentary Scott. Well said.

      It will be interesting to see what all the total submissions will look like. The point… here, is to try to accumulate “examples of success.” – We can nit-pick about what made them successful… but a purview into those examples… I think that would be valuable!

  4. Firstly, let’s remember where we might be if Kent Beck and Jeff Sutherland had waited for proof 🙂 Secondly… okay, case studies can have some value, certainly to the people writing them, as a way to consolidate their learning, but also perhaps to others. As Scott says, if the focus can be on pros and cons of specific practices it may forge a better understanding of those practices. Also, a focus on failure as a learning tool in the way J. B. Rainsberger has often talked about would be beneficial.

    My objection here is believing that more case studies will lead to better Agile. It won’t. I actually believe it will lead to worse Agile as people try to fit their implementation to someone else’s model — look at the disastrous legacy of the awful Nokia Scrum Test if you want a reminder of such folly.

    Perhaps case studies can be studies of joy rather than studies of process improvement and money-making. That may drive the deeper kind of change many of us are seeking.

  5. Do you have links to what the executives hated about agile? Would be an interesting read.

    I agree with the need for success stories — of course — since I posted a request for success and failure stories on my blog as well.

    10 years out of the gate, we should have some examples of success.

    Engineering is not a faith based endeavor; what would have happened if Kent etc had waited for proof?

    For one thing the industry would have been saved from the whole XP distraction; XP was a fad, the proof of which is self evident in the job postings and google trends for XP. Only a very few postings ask for extreme programming compared to anything else. Go search you favorite jobsite or aggregator ( if you don’t believe me.

    To me scrum is no different. Surely after 10 years of hot air, people should be skeptical at the lack of success stories.

    Show me the proof Mr Pianoman!


  6. > XP was a fad…
    No, XP was the foundation for almost all good engineering practices today. That people no longer call it XP is testimony to its credibility and success —and to the integrity of its founders. I hope Scrum achieves the same anonymity—very soon. The prevalence of the Scrum brand-name is destructive to the successful application of its principles.

    1. XP was the foundation for a successful faith based marketing campaign which was copied by Scrum.

      XP is so dead, that many of the original XP Prophets have switched over to selling Scrum.

      The fact that they no longer call it XP is not a testament to it’s success; it’s a testament that out of all the XP practices, the only one with significant uptake was Unit Testing.

      XP did not invent Unit Testing. It did make it popular though. Onsite customer? Nada. Pair Programming? Nada. Merciless refactoring? Don’t see that much.

      Big Test Up Front? Yeah, that got uptake.


        1. No, I’m not angry; I’m still unimpressed by Scrum and XP, and I have no qualms in stating so.

          I’m not impressed by you and the agile crowd always trying to denigrate and belittle people with their own opinions. Give it a rest.

          Speaking of success stories, weren’t you involved in Yahoo’s agile transformation? Occurred about 2005? Looking at their stock price prior to and after that period is quite interesting; Yahoo stock is worth about 1/3 of what is was before their agile transformation.

          I guess that might lead you to not be interested in case studies?

          1. Actually, I believe a few case studies were written at Yahoo! after I left… They fired me for i) insisting that development practices should be improved (along XP lines…) and ii) for insisting that Scrum wasn’t about process improvement, but management change—culture change.

            I’m not sure their case studies benefitted them, or anyone else.

            Yahoo!, like many companies before and since, were looking to Scrum as a quick-fix. Which it isn’t, despite how it’s often sold. Seeking only process improvement, faster work, and higher profits with Scrum will not lead to success.

            If we need case studies at all, I’d prefer to see failure case studies rather than success stories. We learn from the former, we get smug and complacent with the latter. Sure, Yahoo! was a failure, and sure, I had a part in that. The important thing is to learn. And I did. I can’t speak for Yahoo!

  7. It may be important to learn, but does that need to be at the industries expense?

    That is the whole point of this case study exercise; can this or that be taught and absorbed by companies and is it effective?

    My personal opinion, is that all of this success stuff boils down to talent. Talent can not be taught. Talent may be able to be nurtured, but the two should not be conflated.

    I have more “talent” playing the guitar than some people, but I’m not a very talented guitarist. In return I have to work at it much more than people with real talent. When I work at it, I get a little better, but I’m still not talented.

    That is why I’m not a professional guitarist. What we have here is an industry of people telling third rate programmers/managers that they can be excellent through this or that method(ology).

    Well, that means the method should in fact be testable to see if it produces useful results, on a SUBSET of the population, before unleashing untested theories on the world and “certifying” people in them.

    Additionally, we as an industry need to focus on the people a lot more, that talent is not something that is trainable, that talent is valuable and should be compensated for appropriately.

    Too much of what is going on is getting cheap programmers, throwing a methodology at them, and finding out that that doesn’t work (what a surprise).

    But many of the consultants and trainers are all too happy putting ranks of also-ran programmers through more and more agile training when what they should do is create an environment where the best people will want to work there, and then they will not need any particular methodology beyond that to increase their chances of success.


  8. Back to the idea of case studies…

    Personally I’d love to see case studies paired with their theoretical underpinnings.

    For example; there were those pair programming case studies (blog posts and research papers) a while back, and several of them discussed both observed behaviour and the theory of why pairing works.

    Surely that would be a good way to learn from success.

  9. I would also like to see more case studies. In fact, I’ve often said that even something like a “documentary” would be very useful. I helped bring agile practices to a small software company. Neither myself or anyone on the team had any extensive experience with agile. Seeing some of this in action would have been very helpful. It’s one thing to read about practices, it’s another to actually see them in action. So much can be lost in words. So I don’t think it is so much about saying hey, this worked for company X so it will also work for company Z, but more about saying, hey, this worked for company Z, maybe there are some things you can take from what they did and apply at company X?

    In fact, that was the whole reason I submitted an experience report for Agile2011 about our evolution to agile. If you’re interested, you can find the paper at

  10. Our very large company (that you all know very well) that shall remain nameless has jumped the shark on Agile/Scrum and is now implementing it in all areas, Basic Algorithm development, Hardware Development, Software Development, Basic Research, you name it. We no longer have Technical Managers we are all put on scrum teams. A huge scrum of scrum will churn to coordinate all our scrum teams and coordinate everything in lock step. Our company with large groups of developers in China, India, France, Germany, Rumania, USA is now committed to this new fad and anyone voicing displeasure is sent to the Ministry of Truth to root out their doubts. We are told it is all the rage and everyone is doing it and they all love it. I learned long ago that when people say things like that to watch out. That is how I avoided destruction in the recent stock, real estate bubbles. So every one is happy.

    Our 10 min scrum is over an hour and involves Netmeeting. Our sprint planning is weekly and will take the entire morning and keep you from lunch. Everyone must stay on board and show they are enthusiastic. One team member called into the scrum from the hospital where he had just taken his wife in an emergency to make sure he attended the scrum!

    Each day we are asked for each task how many hours we worked, how many more are planned. Why isn’t this task done? This is worse that working in the military filling out time sheets. I am a self directed guy that gets things done and that might not be on a backlog list.

    Of course the exodus has begun. As much as I enjoy the luncheons for those departing they are taking their knowledge to our competition. I found time will on a bridge line to the half day agile meeting to update my resume and my linked in page as well.

    Of all the crap I have seen: TQL, TQM, ISO9000, CMMI, Six Sigma this one takes the cake.

    1. Dang friend. I am so sorry to hear this. People just don’t know how to tread softly, and implement change slowly… and effectively. Forget calling it agile or whatever.

      Hope you land where you want to!

      1. This is the company, C Unix and the recently deceased Dennis. Yes that Dennis. His office will soon be demolished with building #2 to save Property taxes. No national historic site. No tours buses. Demolished.

        In light of the need to co-locate all of the scrum teams that are now going to be the sole organizational entity replacing existing team leaders and managers it seems China and India groups are destined to grow as we are to shrink to oblivion. Co location is key. We in the USA are so yesterday.

        1. OK thanks for the information.

          Google for Steve Yegges post Good Agile, Bad Agile. I think he says that foisting unproven methodologies on people should be an HR violation.

          See where you can go with it. Has the ministry of truth supplied any evidence that it works?

          Myspace received a fatal dose of scrum a few years ago, and yahoo received a near fatal dose in 2005.

          Nokia networks I can’t find any information on their stock price but it looks like they are set to fire 17,000 people.

          I think the colocation fetish is one of the biggest disadvantages to scrum, along with just about everything else about it I suppose.

          But maybe this will wake people up; they’ll be fired from their jobs because they aren’t colocated with the team in the cheapest country they can find.

          Basically, given the history, when a company goes big on scrum, it’s a good time to consider shorting it.


          1. They are now people managers or scrum masters. Two bailed just recently, other people are shifting positions. I of course have relied on these people so I can ignore the corporate BS. Now I guess we are all on our own. All the stuff I blind eyed is not coming back to haunt me.

            China with the 51/49% joint venture is very encouraged by all this. Cracked flex-Lm licenses and huge China govt money to purchase equipment is a big plus for them. We are in demolition mode, literally, they are growing like the grass. We are in an unfortunate time zone, neither India/China or Europe. We go. Go Agile!

        2. @DaveL

          I feel your pain – I’m familiar with that org, and was in that building in Sept. Lot’s of struggles indeed, with a few precious points of light.

          It was that group for which I coined the term Millipede Organization – It has a seemingly unlimited supply of its own feet to shoot. 😉

          1. That’s why I think people should consider shorting (the stock) of once great companies that switch to scrum.

            It is often the last gasp of a once great company (Myspace, Yahoo, etc…)

            It’s like seeing an old guy with a new red sportscar….a sign that they are over the hill and headed for the dustbin

            They have run out of ideas and are clinging to what they think is hip and cool


    2. We are having agile forced upon us. It’s silly. I spend more time in meetings telling people what i am going to do than actually doing anything. I write highly complex scientific medical imaging software, usually prototyped in matlab before implementing in C++. The idea of “sprinting” through this kind of work, where it can take me weeks to months to work out a complex numerical solution or machine vision problem doesn’t make sense to me. No one ( on my team) can estimate how “big” my story is; they don’t have te experience in the domain. Agile may work for some things, but to me it crates too many meetings, too much talk, and worse, too much electronic paperwork. We are asked to put everything in JIRA- well, until JIRA has a formula editor on par with MS word, entering math formulas that look intelligible is impossible. Agile is a nice concept, but at 27 years in the programming world I’ve seen one fad after another, and this is another. The good parts of it, such as they are will survive, but a lot of this stuff is going into the dumpster and the sooner te better.

  11. Our company used the Waterfall method for quite a long time, but for the last 3 years we have been indulging in Scrum method.
    We cannot imagine how a big and productive company like ours could work in the un-efficient Waterfall method.
    We just admire Scrum here: we care to follow every step “by the book” (Ken Schwaber’s excellent book).
    Scrum method has also changed our attitude as programmers. We feel no dismay from being involved in software verification duties. On the contrary: we are more willing to doing QA than to actually go deep into the code.
    We have a lot of meetings which surely contribute to our feeling as being part of a team. We consult each other before we make even the slightest change in the code.
    And indeed, we see the benefits: the software we develop became much more immuned to faults and much less prone to shortcomings. Our customers acknowledge this and sales get higher.
    Our concept is that the software we produce is a consolidated huge lump that each modification in one area of it might affect other areas. Working in Scrum prevents these “shocks” and cross-effects. This is why Scrum fits our goals.

  12. Anyone who says that waterfall fails has no clue of what their talking about. I’ve been in the IT industry for 25 years and have been on 50+ waterfall projects and all have been successful except two, which had nothing to do with the process but company direction.

    In the last 2.5 years, I’ve been involved in scrum and it’s like being in kindergarten. As an architect, agility comes with fragility. The architecture in some scrum related projects are so bad that separations of concerns are all over the place. I’ve been hired to fix their issues of bad designs due to lack of requirements, and let me tell you it smells very bad. Their unit testing sucks, no isolation as most their unit tests are more like functional tests. I told the CEO that software is like building a house. If you forget the basement and decide its best to put it in later, guess what? You’re better off rebuilding the house as it will cost you a lot less in the long run.

    Let me tell you something: Not knowing what you want to build upfront is complete nonsense. Can you imagine building a NASA Shuttle or a 747 using agile/scrum? I don’t know about you but I won’t fly either.
    Software like any engineering project requires a foundation that is modeled first in blueprint (UML) then later developed in to a pilot. Waterfall is based on design upfront from well-defined requirements/specifications with use cases, and then later developed/QA’d with 4-6 week milestones (sprints). Requirements that come up later are reiterated where necessary. Usually they are small and normally don’t affect the main foundation. It works well and will always work well. Hence, why mission critical applications will never be built using the scrum process. Scrum is great for prototyping something quick and dirty. Prototypes are then thrown away and should never be used as the foundation moving forward. Pilots on the other-hand are different. Scrum is also good to maintain and enhance systems with very light requirements. But as soon as requirements have a major impact on architecture, watch-out!

    1. Thanks a bunch for your comments on this. I believe that both agile and waterfall have their places of application… especially with big programs like building a space shuttle! … Too bad… america won’t build any of those anymore though… … …

  13. In my opinion, agile development is the worst thing to ever happen to software development. I’m on my 3rd agile project with the federal government and it’s another mess. Agile has become a bad excuse for rigor-less software development projects. Here are a few observations to support my opinion:

    a. Agile introduces a totally new set of terms, processes and artifacts that only the development team understands (and more often than not, they don’t understand them either). As a result, valuable project time is spent explaining and re-explaining the Agile methodology over and over again.

    b. Agile is documentation averse and as a result, does not scale to large projects. Large project teams do not have the bandwidth to participate in the Agile process (e.g., scrums) and therefore rely on documentation reviews (e.g., Requirement Review, Design Reviews, etc.) which don’s seem to be a part of the agile methodolgy.

    c. Items “a” and “b” make Agile projects complicated and difficult to understand. Complicated methodologies have a higher probability of being executed incorrectly than simple ones. In addition, project stakeholders will more effectively participate in methodologies they understand as opposed to complicated ones they don’t understand.

    I think the worst thing about the agile methodology is its name. If you’re bidding on a software development proposal in today’s world and you’re not proposing the agile methodology then your methodology is automatically non-agile, slow, inflexible, etc. It’s like we’re all now trapped in this agile mess and there’s no way out!

    1. > Agile has become a bad excuse for rigor-less software development projects.

      In an earlier comment I mentioned a blog post I wrote called “Waterfall Works”. Yes, a crap-ton of software has been delivered that way, and using no process at all.

      But why is it that Agile methods gained a foothold in software development in the first place? Because traditional methods weren’t satisfying the needs of business at the rate they should have been. The rigor of which you speak was the reason the so-called lightweight methods were created. As far as businesspeople were concerned, that rigor wasn’t delivering software in either a cost-effective or timely manner.

      Of course, one could argue that people weren’t following the process correctly. On more than one occasion I saw groups attempt to use the RUP but didn’t tailor the process to their needs. The result was a bloated, burdensome process that created too much drag on the work… there was more work being done to feed the process than to deliver the software system! Heavy waterfall processes under which I had worked did the same thing. The process was supposed to be a paint-by-number guide that allowed anyone to be successful. The problem was exactly that – the process was an assembly line that didn’t take the people into account. In fact, the process was more important than the people.

      Agile methods applied to only software development in the absence of good product management practices will provide a very small improvement at best. Agile methods applied to the project management aspects of delivering software, and ignoring technical practices will grind to a halt after a relatively low number of iterations. Agile methods done poorly will exacerbate the problems you have mentioned *BECAUSE* they inherently acknowledge that people are involved.

      When Agile methods do work, it has been because the people were put first and the process served them. Blindly doing standups, sprint planning and sprint reviews won’t help if you don’t have people capable of doing the work. The organization in which those people exist must also be capable of supporting them. That’s where I’ve seen the bulk of failures – pilot projects are wonderful, but the organization as a whole isn’t interested in change, or is afraid of what the change may bring.

      In the end, it’s not that Agile sucks, per se. When I heard about XP in 2000, I understood completely where it had come from because I had been in the same morass of big-binder, follow-the-rules-to-the-letter process. If you haven’t experienced a heavy process and how it can suck the life out of software development, then I suppose it would be difficult if not impossible to understand the benefits of Agile.

      To me, that’s a really good problem to have.

      1. Software project failure (i.e., not delivering the agreed to scope on time and on budget) is more often than not due to an incorrectly executed SDLC. The probability for failure increases with SDLC complexity. That’s what the Agile community fails to understand and that’s why Agile sucks.

        1. Adrian, is it [only] the improper execution of an SDLC? I mean… there has to be more to it than that…. right? What about the [human] element? People man… people! 🙂

          1. Ofcoures, people execute the SDLC.

            Software project failure (i.e., not delivering the agreed to scope on time and on budget) is more often than not due to an incorrectly stakeholder (people) executed SDLC.

          2. Ofcoure, people execute the SDLC.

            Software project failure (i.e., not delivering the agreed to scope on time and on budget) is more often than not due to an incorrectly stakeholder (people) executed SDLC.

  14. I’m writing anonymously cause internet is not as big as everyone once thought and I do fear retaliation. I do say the same things at work but I have to sugar code it again for the fear of retaliation.
    So I’m turning the sugar-coding off now and so here is my take on Agile methodology:

    If Agile methodology was liked only by engineers it wouldn’t get very far. The fact that Agile methodology is now tried virtually everywhere in one form or the other is because managers love it.
    Because unfortunately managers including directors of engineering are typically incompetent people with MBAs, friends and family of the Boss or there because some other incompetent Boss hired them without fear of being overshadowed or overtaken.
    So what do Agile methods give to incompetent managers? Zero-Accountability! If there is no strict specification or clear direction then there is no way to pin-point the responsible party except for an engineer who did something that customer or the Boss didn’t want (if only they knew what they wanted…).

    Let’s take a simple problem:
    Customers complain that speedometer needles in their cars are jumpy and an engineer is tasked with “fixing” the problem. Let’s say you are a software engineer that was tasked with the problem. You do due diligence figure out the nature of the noise and apply a proper filter… Wait, what proper filter? Is there a specification on the allowed error, specifications for step, linear, exponential response??? So in “normal” company that has competent people in charge, such spec exists in the first place. If the customer complains about the noisy speedometer then something was overlooked and filter or system as a whole needs correction or perhaps the spec needs to change. Now the biggest question is why there is noise in the first place, is it mechanical, electrical or software problem??? In “normal” company it is easy to check all of the above, because there are specs for everything. Whatever part of the system is not meeting the spec is the problem.
    And now here is how problem is handled with Agile methods:
    (Boss/Manager/Customer): Fix the jumpy needle!
    (Engineer): How about this?
    (B/M/C): No the needle still moves around too much…
    (E): OK, how about this?
    (B/M/C): No, now the needle doesn’t follow speed fast enough…
    Simply put, it becomes trial and error process, the worse part is that now speedometers will work different on different models of the car, because there is no spec in the first place. But above works great for incompetent management, they can’t write the specification, they can’t understand the specification even there was one but they can crack the whip and act all-important.
    Agile is also adored by incompetent engineers. Again because it is easy to meet some vague specification and fix/tweak it along the way. This is how incompetent engineers work anyway, they don’t study the problem, they play with it until the customer is happy. They love their job, since they get to play with stuff (in their own words). In reality a life of a good engineer is fairly boring: gather data, study data, propose/simulate a solution that meets the spec and apply the solution.
    Agile has no measurements of success or pretty much everything is considered success since: well we produced something and customer had to buy it… What isn’t successful about that? Something that kinda works is very easy to make. Take a look at products with software in them today. Most of them I bet were developed using Agile methodologies. I know this because today’s products hang, crash, have unexplained behavior, bugs and need updates all the time. Simply put Agile is for wannabe engineers.
    After being an engineer for a while and knowing what I know now, it is pretty impressive that planes still fly, the cars stay on the road most of the time and people don’t get crushed (most of the time) by the heavy machinery. Hope Agile never makes its way into everything, or, well the planes will stop flying…

    1. Yes you are right the Ministry to Truth can get you at any time. Remember WAR IS PEACE, FREEDOM IS SLAVERY, and IGNORANCE IS STRENGTH. You can bake a cake one slice at a time and everyone loves Agile.

      1. Usually the product owner or the prjceot manager can be considered to some extent clients. Democracy isn’t that good of a system when it comes to software development, as it will quickly turn to anarchy. We all think that our ideas are the best and that everybody should listen to us, but it’s not always the case, and somebody must decide which features stay and which features go.Another thing: it’s a bad practice to allow an outside client to talk directly to your development team for obvious reasons. You only send the product owner along with some really boring business analysts to talk to the client. And perhaps a good looking blonde account manager, so they won’t look like a Star Trek geeks convoy. So, in front of the developers, the product owner acts like a spokesman for the client, and, as initially stated, to some extent, he IS the client.

  15. Every Agile project I ever worked on or around as failed. The previous one wasted $50 million, but I saw that coming and jumped ship on alpha 1. I’m in another one now with a $10 million budget and the business managers have wisely decided that the best methodology to develop this system, which will be installed into hardware that is already fully specced, which will not be delivered until 2015, which will be developed by a team of two dozen developers over five sites in three countries, is Scrum. So I’m looking to jump ship on this as well.

    In my experience Agile is chosen as an alternative to off-shoring. By keeping an Agile team in-house the business managers can use the methods to a) micro-manage everything down to the tiniest detail, and b) bring cheap inexperienced local developers up to an adequate speed. That second reasons explains while Agilists get so worked-up about any criticism – without Agile they’d be working in desktop support.

  16. Agile is a great thing for micromanagers.

    Making grown, intelligent and usually well educated adults stand up every day and pass a talking ball around the room helps to demean them and put them in there place. Threat them like the insignificant children they are. Management hates engineers totally has no respect for them. They are a necessary evil to them.

    Agile had some good ideas (mostly common sense ideas most worthy engineers already did) and put name to them. Of course there was the stupid crap like eating a cookie every time your JUnit ran and you checked in your code, but some of it was good. Like do what is needed now and don’t try to guess the future.

    Management has bastardized it to once again use it as a way to treat the complex and creative thinking discipline of software development into a way to mass produce junk on an assembly line. Hey, make everyone follow the least common denominator way of doing there job and you can easily outsource them when the time is right. Sounds good for guy in the office looking for a big bonus.

    Not to mention all the clowns out there raking in big buck with Agile consulting. Most of them haven’t ever put two lines of code together in there lives but they will waste a week of your time playing stupid games and telling you some piece of crap tool like VersionOne cures all. Notice that they always say unless you follow this “book” to the letter you will fail. That’s their disclaimer because nothing fits exactly the same everywhere. A guy who wrote a book for the main purpose of selling his book cannot and would not write a book that fits every organization, market, etc.

    Forget Agile, Waterfall or Bill and Ted’s excellent methodology or not. It doesn’t matter. Software succeeds based on the people building it. Clear headed, reasonably intelligent, engineers who are engaged in building a good product. They work directly with whoever to get a understanding of requirements and probably are key player of putting requirements together. Without that, you will not be very successful. Recognize talent and drive and make them feel important. Agile (or at least how it is practiced by no-talent managers) does the opposite. It treats everyone as problem children that they have to deal with.

    1. Bob – U da man. Completely agree with you here… especially your final paragraph. It’s the people! Good people working together can make great products. Where did we miss that part? (The human part)?

  17. Agile is crap.

    It’s a convenient cover for lack of planning and lack of preparation and it’s a license to write disjointed, garbage code that becomes increasingly harder to develop and maintain as everyone writes a small piece of crap that works on their machine and works on their local tests, but doesn’t integrate well with what everyone else wrote because there was no overall design.

    Basically, it’s software development for ADHD idiots.

    1. Bob, what’s your favorite word? Apparently “crap.” Lol.
      However, in some ways you’re correct. I would say that the majority who are ’employing’ agile… allow for such things… why? Because they don’t know (of/about) better development practices.

      It would make sense we build good dev practices in… yeah?

  18. It’s like getting more into micro management of individuals work. When I attended agile training, the instructor was giving more stress somehow companies wanted their employees to focus on office work and not on Facebook, gmail like etc. For any company, Agile is really big pain for employees. Agile requires too many people resources to do any small task.

Leave a Reply