The Anti Agile Manifesto

We have suffered through countless consultants and hours of meetings. Through this we discovered that Agile is simply the obfuscation of common sense – the bewitchment of the mind through language. We have learned that

epics are really just projects
stories are really just use cases
sprints are really just work
stand-ups are really just meetings
iterations are really just versions
backlogs are really just to do lists
backlog grooming is really just planning
burn-down charts are really just earned value charts
velocity is really just output
and that tasks, in fact, are really just tasks.

That is, while the concepts on the left are often presented as groundbreaking or unique, they are merely weakly defined versions of those on the right.

86 thoughts on “The Anti Agile Manifesto

  1. The point is not what you call it; it’s how much time you spend on “process” vs how much time you spend on “productivity”. The buzzwords leave me cold, and I totally agree that the fascination with using the “right words” and doing things the “right way” is the antithesis of common sense. But that’s the thing; they are also the antithesis of Agile. What you are railing against is not Agile. It’s Agile Consultants.

    • What’s your point? They’re weakly defined because being vague leaves flexibility for consultants to make shit up as they see fit/profitable. The words on the right side are not only better defined, but also common and difficult to distort.

      Agile/Scrum is just a gathering of buzzwords and circle-jerking consultants.

      • Actually, the words on the right have a lot of baggage that don’t necessarily mean what the Agile definers wanted. The new terms were evoked to narrow down the meaning to specifics. Let’s take, for example, velocity vs. output. “Output” can mean simply the amount of work done to any end (not necessarily one that is helpful), whereas “velocity” in agile-speak means the speed you work towards a particular defined goal, as measured by past experience, using well-defined measurement criteria.
        If you use the former definition, you should expect people to ascribe whatever meaning they choose to ascribe based on their past (differing) project management experiences – not necessarily the right one – and possibly in the wrong direction. If you use the latter definition, people mostly know that you are using it in the Agile sense and can agree on how to measure it.

  2. The items on the left are a more general case of the items on the right. E.g. standups are a *type* of meeting. So is is a fire drill. But it has a different name because the format of the meeting is pretty specific. Exactly counter to your point that the things on the right are more strongly defined. They aren’t. A meeting is pretty weakly defined and can take many thousands of more strongly defined formats and still be a meeting. And if the things on the right of your list worked very well (they have a strong history of failure) then you wouldn’t find things like Agile coming along trying to fix them.
    More importantly, just because consultants are ripping you off doesn’t make a thing inherently bad. Cars aren’t worse than walking just because sleazy car salesmen exist.

    • “epics are projects? iterations are versions?”

      Yes they are. Only an deluded fool with a sunk investment would say otherwise.

      “there are also great ones.”

      This is standard consultant speak for: “what I’m saying is; whatever I’m selling is absolutely great, but I won’t say so directly or unambigously because such bold statements might make me look stupid or wrong at some later point”.

  3. I’m sorry that this has happened. I promise you that it’s not what we intended. I’m guilty of some of this. I like to think that I do better now. Unfortunately, once “Agile” became fashionable, it became susceptible to the mangling you’ve highlighted here.

    Some of it has to do with companies who want to be seen doing agile, but don’t want to change the way they work. Some of it has to do with Scrum certification and the attendant cottage industry. Some of it has to do with training companies racing to the bottom to teach the least meaningful things that they could feasibly market and sell as “agile training”.

    I have to say: I really wish it were true that “burn-down charts are really just earned value charts”. I’ve seen them mostly as translucent lies about earned value.

    Blaming “Agile” for all this is lazy thinking of the same kind that created the problem in the first place, but I understand the frustration that lies behind it. I wish you’d had better experiences. Perhaps you will, in the future.

      • I remember sitting in a tiny workshop with Kent Beck, Francesco Cirillo and the late John Goodsen. I know it was ten years ago or so. Kent brought up the question of certification, proposing an accreditation model in its place. We debate it hotly. We couldn’t come to any conclusion except “this will probably not work”. We cited the typical reasons: too expensive to accredit someone, who will give the accreditations?, the accreditations will become their own currency, the accreditation process will open itself to competition and fracturing of the market… we agreed that we wished we could do it, but that we’d better not.

        There was a time that I wished *I’d* started certifying people, because it’s a nice pyramid scheme and I’d have some money. Now I’m glad that I didn’t, because I don’t think I would ever have felt good about having done it.

        As soon as there’s an X and there’s demand for people to do X, there will be X certification, and we can only hope that it doesn’t ruin the whole game. There will always be boutique Xers and enterprise Xers. I don’t think we can solve this problem other than by (1) everyone in the world becoming competent at X or by (2) discovering Y that makes X obsolete. I’m open to suggestions.

      • @jbrains: People love certifications in the industry where I work. But when a particular methodology gets popular enough that a certification industry rises around it, organizations try to adopt that methodology without bothering to understand it. It’s as if certification replaces the need for thinking or experimenting. It becomes a check in a box: “We’re certified, therefore we know what we’re doing and you should hire us.” The primary focus becomes figuring out what you need to go to get certified; figuring out ways to actually improve productivity becomes secondary. That’s the problem I have with certification – I’ve seen it happen multiple times (and even been involved in it), but it’s particularly ironic with Agile development.

        There’s a reason behind the demand for certification – it’s human nature to want a simple way of discriminating those who know what they’re doing from those who don’t (especially if you don’t either) – so I’m not sure there’s a good solution. In any case, I don’t have a problem with scrum training, just certification.

        Oh, and by the way, I also have to say that burn-down charts are not earned-value charts. The rest of the anti-manifesto might arguably have some truth to it, but not this one.

    • If agile produces bad experience it does mean it can solve it, it’s not perfect and doesn’t solve problems agile ideologist belive it will. Agile experiment is on track, and after years we finally figure out there are problems and choosing agile framework is somekind of religion. It’s realy close to religion and far from scientific research, engineering…

  4. That is what really happens when people adopt the buzzwords without adopting the mindset. This manifest is sadly funny and true for what many people practice as being agile.

  5. Great stuff,

    Brings to mind many discussions I’ve been having lately with Simon Bennett. Is a thing it’s original intent or is it existentially what it has become? I don’t think arguing the “That’s not how agile was intended!” point has much value. If a thing repeatedly manifests in similar ways then isn’t it reasonable to say the original intent having long ago been lost, becomes less relevant than the current state of the thing?

    Again really glad to see this coming into the dialog. :)

    • Agile is conceptual and a set of principles, not a set of prescriptive practices. So, yes, Agile is always “Agile-as-intended”, not “Agile”-as-practiced.

  6. Me being no good at Ballet is not a valid argument for Ballet being any the less of an art form. Neither is the argument that because very few people are good at Ballet that Ballet is ‘defective’ or somehow deficient as an art form, or not a form of art at all.
    The argument “if enough people say Break-dancing is Ballet, then it is Ballet” is plain ignorance, and arguing that the definition of a word is what most people think it is, is a nice knock-down argument for you.

  7. If you think Agile is defined by buzzwords, it is no wonder you can’t make it work.

    Agile is a mindset that leads to: making change management central to projects, cutting projects into manageable chunks, insisting on end user ownership, etc. What is your problem with any of those goals?

  8. epics are really just big dumps
    stories are really just what I tell my teammates in a meeting
    sprints are really just what I do when I have to pee
    stand-ups are really just for comics
    iterations are really just versions,,,,yes
    backlogs are really just to do lists…yes
    backlog grooming is really what should be done to your pet
    burn-down charts are really just trash
    velocity is really just how quickly you deliver to your customer
    and that tasks, in fact, are really just tasks.

    Seriously, how long have you folks been developing s/w, two months?

  9. Great post. The part “the bewitchment of the mind through language” is so true. We engage in word battles, when the only thing that matters is improving the way we work one day at a time. There is no time left to actually do stuff, if we focus all our energy on batteling one mind against the other, fighting over words and symbols. The challange is to actually find the balance between changing the way we collaborate (which requires the exchange of symbols) and actually experiencing what it means to create something – one line of code at a time.

    • I have to agree! Every agile shop I have worked in has interpreted agile to mean “We don’t do design anymore”, and they won’t allow system iterations because “there is no customer deliverable!”. Agile generally tends to produce low level, crappy code that can not be centrally modified (has anyone doing agile not heard the phrase “I don’t have time to do it right.”. Development without architecture produces a bunch of code, not a system. I’ve seen more than one agile project completely die on the vine because they wrote themselves into a dead end by focusing only on customer deliverables.

      • You have just describes an inability to get along with your management, then blame the technology. Management gets paid the big bucks to handle this sort of thing, so they are not doing their job. Does “And it is no longer my problem.” mean you have quit?

      • You are describing bad management. Competent management would not let a project go screaming off in an unproductive direction. You need to read the Agile Manifesto, and stop blaming Agile for incompetent management and developers.

  10. Hayim; Of course software quality is important, but in my experience, when projects fail, it is usually due to poor management. Even bad code is often attributable to poorly managed resources. If you are managing a software project, quality should be a major concern. That is why we have code reviews and layers of testing.

    • I agree, but the phenomenon I observed is that the developers themselves become obsessed with Project Management, constantly trying to improve their own Velocity and Burndown charts…

      • Yes, the misconception that velocity and burndown charts matter, while a predictable one given the system that presents them, is ubiquitous. Project management has nothing to do with either one. The framework that prescribes that framework is often trying to deliver on a promise of “hyper-productive teams” by applying pressure to the development team to deliver often and quickly when the delays and problems lie not with the engineering part but with the whole system. People care about doing good work and when we sell burndowns and velocity as definitions of “doing a good job” those good people will work very hard to make it happen.

        Burndowns and velocity rarely map to actual business or customer value so hopefully we can shift focus off of “doing agile” and onto customer & business outcome-driven continuous improvement. Focus on value & respect for people is a good start. :-)

  11. Hayim and Adam; You are describing bad project management. Of course people work toward the incentives that are offered. It is up to management to provide constructive incentives. You are describing management by someone who read a book and jumped on something that looked like it could shift the responsibility off to a technique, thus allowing the manager to avoid personal responsibility.

    Good projects are created by good people, including good managers. Everything else is secondary.

    • It’s the system, not the people. People respond logically to the system they are in. Usually what drives these people you describe as bad project managers who want a book or a technique to solve their problem is excessive organizational cost focus and capacity utilization. Fixing the system and focusing on the interdependencies and cultural assumptions therein is not about finding the “good people” instead of all the “bad people” statistically most people are average. But average people in a great system can do amazing things.

      Good blog post here:

      • I am not calling anyone bad, merely not able to do their job well. By good, I mean people who are good at their job. Good managers need to be above average.

        I am sure a good manager can create a system and train average people to do a great job, but that is not easy, and the system that works well in one situation may fail in another, calling for courage and flexibility. That is why great managers are so scarce. Most people do not have those skills.

        There is another issue, though. If top management puts enough restrictions on the line managers, the line mangers may not be able to do a good job, no matter how talented and motivated they are.

      • Exactly, and placed in that situation they’re likely to start looking for tactical silver bullets to try and succeed despite their circumstances. I’m just saying that calling for courage, and “greatness” ignores the bigger picture system. Mainly I’m saying these things happen and blaming people for not being more awesome doesn’t seem very useful to me. Let’s understand the whole and optimize for value.

      • Adam; There is a story that in ancient India the world was pictured resting on the back of an elephant. When asked what the elephant stood on, the answer was “It’s elephants all the way down.”

        In the same vein, with managers, it’s managers all of the way up. If the system is not functional, the people in charge of the system are not doing a good job. Those people are managers. As for asking for courage and greatness, I don’t see the problem, especially for upper management. If they are not great, why are they getting the great big salaries?

      • “Average people in a great system can do amazing things. ” Its a big lie at lest in software development.

  12. While this post (and the domain) denotes there are broken things within how Agile has been delivered and made available to a lot of developers out there, it also shows up your lack of understanding about Agile manifesto and the values it stands for. I’d suggest to read it again, not just to tackle the way it was written but to really understand the words in it (
    However, in your defense, the ones to blame here are those countless consultants who tried to teach you Scrum (which is what you are truly complaining about) and didn’t even explained the difference between values, methods and practices, and probably sold the idea that changing names to tasks was just enough to be agile. But hey, even if somebody else’s fault, you’re the one in charge of educating yourself before you start a campaign to truly stand against something and hope to be heard seriously.
    Just as Dave Thomas pointed out in its article ( there are a lot of broken things around the way “agile mindset” is being delivered to developers and companies around the world, especially because they are not even delivering Agile Mindset!!! For a lot of people, it has become just another buzzword and a mean to create a new market of potion selling while taking companies money and not making any developer happy about it.
    This is why I would agree with a campaign against babblers calling themselves Agile (even if showing Agile certifications) and don’t really knowing or delivering true agile concepts (As an interesting fact, domain is available). But standing against Agile Manifesto because you or your company got scammed by one or many of those babblers, sounds to me like standing against Human Rights because the ones apparently standing for those (who in this strange scenario actually get paid for talking about human rights) have no idea what they mean or even truly stand for them, as long as they get paid to talk about that.

  13. Just because you’ve flown on a plane doesn’t mean you can fly it. Same thing with an agile process, too many people use the buzz words and get the quickie certifications that the industry requires in order to get the job. They did the same thing to RUP, OOAD and OOAP when it came out; everyone was doing it, yet they really didn’t. I remember when you couldn’t get a Java Programmer job at big companies unless you were a Sun Certified Java Programmer … nothing has changed. If you’re going to say you are using an agile process then really learn it, really do it, and really be it or stop saying you are agile and find something else to blame piss poor requirements, design, and software on.

  14. I’ve always said that “Agile” or “agile” is just the Iterative/Spiral model with team collaboration (RUP/MSF lite) on steroids (shortened cycle times). Half the paper work and all the possibility of chaos. I know the original intent of Agile was to allow people to be adaptable to the situation and not be stuck in a rut by process dogma, but it has come back around to it. The best development projects, regardless of method/process, I’ve seen have been those that have taken a collaborative team approach where everyone starts at the same time and has common goals. They all work together and keep the final end goal in sight, they do risk assessment and management on an active basis, and are always asking the question “are we doing the right thing”. This is true for Waterfall, Iterative/Spiral and Agile.

    • Almost nobody likes this article, but a lot of people are missing the original intent of the Agile manifesto. The original manifesto was about focusing on people and embracing change. I’ve had a relatively successful career doing just that.

      “Agile” purists wouldn’t like my spending a large portion of my budget “up-front”, but I have never built an application that the client didn’t want. Knowing what you want to accomplish is not the same thing as embracing the waterfall.

    • Robust response, huh? I guess that was meant to be funny. What is a lump of work if not a project?
      Winston W. Royce, that poor man, is turning over in his early grave. The moment someone actually develops his methodology into what he originally defined, they pollute it with buzzwords so someone can re-brand it and sell it to corporate sheeple.
      I guess I’m a bad agilest for saying that.

  15. I will suggest you start by understanding that Agile is a normal reaction to the pendulum swinging too far in the years of RUP and teams spending an inordinate amount of time preparing to write code and creating unbelievable reams of documentation. If you would like to start understanding the underpinnings of Agile, I suggest you read Robert K Greenleaf “Servant Leadership” and that will give you the foundation to start uncovering Agility. Once you get your mind around the beliefs and principles that are part of Agile, then you should be able to better frame the manifesto.

    • “Reams of documentation” was created by people who thought lines of code was a reliable measure of programmer productivity. Sometimes documentation is useful, just as sometimes code is useful. It both cases it has to be fit to purpose, not just voluminous.

  16. thank you for calling crap on crap. the agile manifesto was a whiney juvenile temper tantrum. the “agilistas” I have met are closed minded, fascist, hierarchical tyrants. maybe there are other types, but I have yet to meet them. to blame the problems on agile to “unbaptized” folks masquerading as agilists is disingenuous in the extreme.

  17. i think it is about the incremental ROI than just comparing the terminology, the real business value is missed here.

  18. The interesting point to me is that this Anti Agile Manifesto speaks about practices and process. The Agile Manifesto speaks to values and principles. So this manifesto is not actually about the document it purports to oppose.

  19. The original people that put the Agile Manifesto together were trying to say what this is implying. We like this process because it comes naturally from common sense. It is everyone after that that screwed it all up. I like this lash back at the people that don’t get it.

  20. epics are really just projects – nope, groupings of user stories within a project…bad start

    stories are really just use cases – fair enough

    sprints are really just work – completely missed the point of iterations and value therein

    stand-ups are really just meetings – not at all, they are constrained info radiators to optimize peer review, almost the
    opposite of a meeting – you are actually discouraged from discussion, what kind of meeting is that?

    iterations are really just versions – nah, you might have multiple versions per sprint – they really aren’t necessarily related, but could be

    backlogs are really just to do lists – crappy backlogs are

    backlog grooming is really just planning – yep, and you have to keep doing it, Agile forces you to

    burn-down charts are really just earned value charts – wow, really? They don’t tell you the progress of the sprint or anything? Things stuck in queue? Has this person ever used a burndown?

    velocity is really just output – over a set unit of time, thus explaining one of the reasons we sprint

    This stuff isn’t really hard, and someone who is willing to register the domain antiagilemanifesto should be willing to actually read a book on the subject.

    Furthermore, I can think of a lot of valid criticisms of Agile that none of these seem to touch on – ie: it’s difficulty to sell to clients, the difficulty of using agile processes to meet waterfall objectives, difficulty in writing user stories and UAT, difficulty in getting devs to work together on a feature, etc.

  21. Destroying things is easy; building them is 1000 times harder. Instead of destroying what someone else built, build something yourself. If Agile is no good, build something that is. THEN you’ll have something to say that is worth listening to.

  22. Funny, you call this an anti-agile manifesto, yet, none of the things you write about are actually contained in the Agile Manifesto. Maybe that is why you are not succeeding in being agile? It is apparent you never discovered what really is Agile, because you are really just ranting about Scrum/Safe/Stories and other process stuff… Please at least make some sense and learn what you are talking about before you blast the agile manifesto.

    LONG LIVE the Agile Manifesto! Maybe you should actually read it and discover it is more philosophy or way of thinking than process steps… I stand by the founders of Agile Manifesto.

  23. Our company hired Berteig Consulting in 2012 to teach us Agile and paid this gang of thieves (Mishkin Berteig and his partners) $1,000,000. Former dancer from Carnival cruise line was teaching us for 12 months how to grow “organically”. Can you believe that?

  24. Your complaints seem targeted specifically at Scrum. Scrum != Agile, although many people think it is.

    Also, Scrum was always a dumb name. It was meant to be a name for everyone working together, but anyone who has actually watched a game of rugby union will know better. It’s a bunch a great hairy gorillas heaving against each other, going nowhere, and eventually collapsing into the mud. Come to think of it, maybe that does describe a typical software development effort :-)

  25. I want to join this movement, I worked as a developer (TL) and then as a BA/SA..
    I didn’t find except chaos in every organization I joined due to agile adaptation and implementation

  26. I always thought Agile had it backwards – according to Aristotle anyways: “the end is last in execution but first in intention.” We are, after all, teleological creatures. Agile addresses accidental complexity only, yet it has been sold as a silver bullet. An anti-manifesto reaction was inevitable; let’s absorb what was useful and work toward a sensible synthesis.

  27. I am new to Agile and working to manage a Sprint. I confess, I have been seduced by some of the tools and promises, and so far, I remain hopeful. Compliments to those of you who are trying to make this a coherent discussion. Some of this reminds me of the early days of object oriented programming. People said “oh, we’re using Object Oriented Programming.. see… it’s all written in C++”. Of course, as it turns out, they weren’t doing OO at all. I think there is real value in many of the Agile ideas. Time will tell.

  28. Who is the author of this manifesto? Did I miss a signature on the page?
    You stand against the agile manifesto, which is signed and the authors take the responsibility for it. At least you could do the same, since you are addressing it directly. Unsigned, this is unprofessional.

  29. The guys who wrote this proved that they have absolutely no clue what Agile is… so sad that “countless consultants and hours of meetings” could not make them understand.

    First of all “Epics, Stories, Backlogs, Standups” are NOT even Agile terms! They are related to the Scrum framework (framework!!!), but some of them (burn down charts) are not mentioned even in that explicitly, just used as optinal part of the framework! You just do not understand what Agile/Scrum are!

  30. Criticism of Agile is often made by those already long familiar with those in the software industry. Perhaps it’s understandable that they would criticize something that is new and changing the scenery.
    I do not often hear from those new to software engineering and how helpful they have found Agile to their learning process and ongoing career progression.
    As someone who came to Agile with not as much baggage as many of those complaining here, learning it alongside other techniques in University, I can say I have found it very helpful to both my software engineering education and ongoing career progression. While I have looked very hard into the criticisms also, I cannot see what all the fuss is about (at least, I cannot see it from a valid perspective – only, as has been stated many times above, it seems that a misunderstanding of Agile is the main culprit, not Agile itself).

    • Lets be clear here. The Agile Manifesto was a statement of beliefs based on ways of developing software that had been done for a long time. This is not something new and I have seen both young and old complain about this. The problem here is not the beliefs, its the practices people are using to meet those beliefs. In stead of saying you are complaining therefore you don’t understand, maybe we should consider that if so many people are miss-implementing the various “well known” methods of implementing an Agile process, why not look for some other way of implementing the beliefs that is easier to understand and practice.

      With the way the industry moves saying you need to keep doing it and fail for a few months is really not acceptable. Doing something that succeeds quickly, but can be improved upon is required.

      If anyone says I can take a course and succeed at some Agile process right away, then you should pat yourself on the back because that is something I have never seen in 20 years of development.

      • Fair enough, Agile didn’t come out last year so it’s not “new” but it’s newer than Waterfall, Unified Process etc. As far as the industry is concerned it’s still the new kid and nothing has yet supplanted it.
        You are mixing up beliefs and practices in your statements. If the problem is with the practices, then Agile is not the problem because Agile is the concept, not the practice. The processes themselves are the practices. If that’s the problem area, you should criticize those practices specifically. If you have a problem with the concepts, the criticize those; however, so far the majority of comments here, along with the article, criticize the implementations of Agile while those defending Agile are saying you are aiming at the wrong target.
        The whole concept of Agile incorporates the idea of adapting a process to your own situation – it’s almost the prime directive. If you have a problem with a particular implementation of Agile, then adapt the process to suit (an Agile concept) or tell your boss you have a problem and tell him/her what you think needs to be done differently (also an Agile concept).
        Finally, I am not sure that the majority of people are having problems with Agile other than a vocal minority that keeps complaining while misunderstanding what “Agile” actually is. If it is the minority having these problems, then maybe there is a problem *they* need to address with their understanding or with how their organizations are practices software development, rather than the writers of the Agile manifesto.

  31. Agile is about communicating and thinking. It is about results, appropriate results. It is not about tools or procedures directly. It is about knowing what result you and your clients want, and choosing appropriate tools and procedures based on that understanding.

    Agile is an approach to development, not a specific path.

  32. Agile was ORIGINALLY a back-lash against software engineering processes such as SEI-CMM/CMMI. When it could not get any traction, they started to turn it into a bad watered down copy of real processes. Agile is still a joke.
    “Agile is about communicating and thinking.” – so is CMMI so is SPICE so is every formal process. Agile is about yapping in a room with a whiteboard and hoping that everyone “gets it” and is on the same page after they go back to their desks. Real processes (not agile) are about communication and PLANNING, so you don’t kill someone with your product and don’t get your company sued out of existence for sloppy software. Its about being put on the stand in a court room and being able to answer every question put to you and have the documentation to back it up.
    Sure, if your software as NO CONSEQUENCES other than irritating a user when your javascript errors out, then hey you can use AGILE or make up any clown process you want. Just don’t call it “engineering”. Engineering means everything that AGILE is not – mainly: responsibility. Thinking AGILE? – think Takata.

  33. John, I’m sorry you are having a bad day. I hope tomorrow is better. By the way, I use agile (sort of), and I have completed many successful projects. I define success as getting paid by happy clients.

  34. Probably more than just one bad day, if being subjected to marketed agile practices. I have had enough of the agile nonsense. It’s all just stuff to sell, and has been a part more failed projects than I have ever seen before. And I’ve seen a lot, I have been a software engineer for over 22 years. I usually stick to software engineering environments for work, but have been in a couple of IS jobs over that time and am in one now. IS tends to embrace Agile somewhat more, and also tends to exercise agile concepts (not really) in the poorest ways, scrum especially. I have finally been forced to refuse to attend the scrums, which are just frequent tortuous interruptions that benefit absolutely no-one in anyway whatsoever, and am submitting progress reports once a week to my boss only. They won’t complain. Want to, but won’t because i get the job done and done right. They nominate me for achievement awards, give me large annual raises, and hate me for ignoring them in a way that suggests contempt. Gonna need psychological help soon, they keep that up. Let it go children, you are living a lie and a marketing dream.

    • Software development requires understanding the problem, picking a direction toward a solution, picking a technology, gathering a team, and effective management. The real problem in unhealthy projects is usually incompetent management, not technology. If you can’t get along with your coworkers, your managers are not doing their jobs. Don’t blame technology for management failings.

      As I said above, I have been very successful with processes that you don’t like. I delivered my first commercial applications in 1995, so I am not a beginner.

      • Blaming technology? Nonsense. Agile is no technology. It’s repackaged old concepts. “Waterfall” is a fictitious name given to a process that never worked in the way it was described in an attempt to make something that is no different, appear different. No, I blame the peddlers of this crap who are rank amateurs that claim to be professionals and are after nothing more than an easy buck.

        I get along splendidly with my co-workers, devs, who frequently admit they want to do the same as me. The business folks who force this on us, WE have trouble getting along with them. And it is no longer my problem.

  35. One thing that I have rarely seen mentioned in any articles on Agile is the effect of the quality of the codebase that is used. By this I mean it’s design/engineering and implementation. It is rare now to start a project from scratch so most consist of modifications and/or enhancements to existing suites of software.
    If the codebase is good (don’t bother asking me to define good – just talk to the developers) then the average story estimation time will be accurate and everything should fall in to place.
    However, if this is not the case then stories/sprints/deliveries will overrun, the product backlog will not come down at the desired rate, the problem list will grow and generally be ignored, developer morale will plummet and product quality will degrade even further. Engineering is now no longer important, as after all it will be delivered anyway as Managers are under pressure to get it out the door.

    So I would suggest if you are thinking of adopting Agile as a solution to your problems first find out the true state of the codebase that will be used. If it is ‘good’ then Agile may help (but then why do you need it?) but it could result in the codebase degrading as functionality is flung in at an increased rate.
    If however it is ‘bad’ then adopting Agile will not help, you could however implement it (including adding a few people that are ‘passionate’ about it) and adopt the delusion that it is working.

    • Writing bad code can be done with any code base. Poor estimation is poor estimation. This happens with what ever process you use. In an agile process you estimate based on your specific project, not some set standard that all shall use. Another piece of the picture is to recalibrate your estimations every so often. If you are continually behind because of poor estimation and you don’t fix it, nothing will help you. With any process if you are not continually improving it, then you will continue to have the same problems. Good practices are just good practices. Agile doesn’t automatically give you good practices. No process can automatically take make a good process out of bad practises.
      When I say bad practises, I mean something that doesn’t work for you and your group. If your scrum standup meeting is taking to long and not providing value, then a continuous improvement may be to just not have it. There are other ways to gather or provide the information that a scrum is supposed to provide. One of them may just be fore the team to interact more often. I was on a team where the scrum was redundant and the manager just used it as a status report to him. The team members already knew what each other was working on and if anyone needed help (usually before the scrum meeting).
      There is no one right way and anyone that says so will eventually fail when trying to apply the “one” right way to a problem in the future.

  36. Agile sucks. I wish I had time to describe the project floundering and failures I have seen that are due to the ‘new religion’. The small business that have gone bust because of it. The arrogant consultants who are on a soap box all day preaching ‘Agile/Scrum’.
    And Agile is not the only alternative to a waterfall process.

    • Agile is a way of setting priorities, not a set of techniques. Most projects that fail, fail from bad management and lack of understanding the requirements of the project. There is no tool or technique that can overcome bad management and lack of understanding.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s