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.

111 thoughts on “The Anti Agile Manifesto

  1. The manifesto resonates with me and I’m curious to know if the anti manifesto has an official list of supporters? Not just ad hoc supporters like myself.

  2. In my observation, agile may work well under certain circumstances.i.e., web application development, where all the architectural decisions have been made. Where it seems to go rapidly off the rails is where it is applied more broadly to solution development benefiting from structured analysis, solution architecture and/or systems integration.

    It can be on track where the user and developer are working on features at the user interface, but, if the design patters for logic, data access and data persistence are not well governed it can get a bit chaotic.

    I don’t necessarily take issue with the repackaging of SDLC, but I think the part where developers dismiss the value of strategic, structured analysis, and/or skip design/reviews/alternatives before building is risky at best.

    It is well suited for the hook-and-drag business of software development, as opposed to the practice of software engineering. The client gets hooked on the concept, and dragged along without strategic design into endless refactoring, It may serve developers and those that benefit financially from development, but it certainly does not benefit the client, in all but a narrow range of cases.

    • Agile at its best is about managing changing requirements, not eliminating them. I agree that agile needs to be confined to small, clearly defined problems, but any project should be made up of small well defined problems.

  3. Ok, so here’s where it gets sticky or circular. In order to know what those small well defined problems are, the nature of their dependencies, and where there are economy of solution, strategic/architectural analysis needs to occur. Thoughtlessly chunking up problems and solutions typically leads to kluges, technical debt, and refactoring. Whether by design or by accident, agile practitioners avoid this anti-agile aspect, in my observation.

    While we’re at it, there is also this business of confounding requirements and design. “We didn’t have the requirements” is a developer’s mantra when covering up a solution deficiency. “No, you did have the requirement, you did not bother to analyze it, design a solution, (and alternatives), before you started coding”…So then if the client steps in and embellishes the requirement/user story, then its “The requirements keep changing, that’s why its not done this sprint”. “No, you keep experimenting with solutions, rather than designing them, your design continues to change, because you didn’t interrogate the requirement”. To your point, there’s the well defined problems… that should have well-defined, economic, solutions.
    I am realizing that I am not anti-agile, I am anti incompetence, anti deflection, rhymes with full fit. Competent resources can operate in any paradigm, mediocre resources need a paradigm in which they can operate that leaves plenty of room for excuses. Agile is such a paradigm, and is promoted and utilized by those that need it for the former.

    • Agile is a philosophy, not a set of technologies. It is about involving the end users through the entire project. It is the total opposite of just sitting down and starting to code. It is also about being ready and willing to change course as the requirements evolve. That means you need good requirements and design to begin with.

      At the beginning of every new project for a new client, i state that the project is a voyage into the unknown, and there will be changes as experience with the developing project makes our vision clearer.

      Many times, the end users don’t really know what they want until they see a prototype or an early version.

      Basically, I agree with most of what you posted, but would say it differently.

      • The convergence is it coming down to the practitioner.

        It’s clear Agile not a set of technologies, but as with any philosophy, its application is dependent on the interpreter/practitioner. I am expressing what I have observed empirically, via several consulting engagements where the enterprise is moving toward agile practice, lead by other consultants…My primary objection is playing loose with structured analysis and design, and with deflecting responsibility, be it Waterfall, RUP, Agile…The Agile practitioners I have had the opportunity to interact focus on the connection with the user, while avoiding coordinated design, data governance and the like. Then, when the work starts “blooming” i.e. a user story becomes understood to be a feature/epic, there are all sorts of dependencies, unable to be delivered any time soon.. and/or part of it is built, but its not minimally viable, its deflected to the requirements changed/the user didn’t know what they wanted, while this was not the case. My point is to own it all, not just when its convenient…..Work ethics, even business ethics can make or break any philosophy/methodology.

        Reality is that requirements evolve and solutions evolve, no question. I guess my expectations of competency and integrity may be antiquated.

        Many enterprises are still looking for the “cookbook” that will make their IT shops, or vendor engagements run smoothly. It comes down to the people part of people/process/tools. Without competency, integrity, discipline, leadership, then human nature, capability immaturity and chaos devolves it into amateur hours, In my opinion.

        Enjoying the banter, thanks.

    • You are so full of bs I could not abstain for responding. If your requirements are to vague they can be interpreted many ways most that do not fit with what you want. We cannot do mind reading. Requirements keep changing is a real problem. Most clients do not have any idea about the difference between giant changes and small ones. Is like asking someone to knock down a sustaining wall and calling it an embelishment of the original design. You are clearly someone that has not passed the stage of infancy and does not understand that everything has consequences and that in a complex structure seamingly small changes can have grave consequences. But anyway I dare you to live one year in a house build with Agile. If you survive we will talk more.

      • I get the feeling that a lot of the people posting are not involved in all of the steps of projects. I develop business software, so I am writing from that perspective.

        The first step in any project is justifying the time and expense. Even at this point, the project should have quantifiable goals. The goals could be better reports for management, fewer data entry errors, faster shipping, better outreach, etc. This justification is often already done by business people before the team is contacted.

        The general form of the requirements should be based on analysis of the current business compared to a projection of what the business will look like with the application(S) and staffing changes in place. At the same time requirements are being collected from the business people, personal/professional connections should be made which will allow constant interaction with the users as the project proceeds.

        This is very basic, but I am trying to make it clear that there are always requirements, and it is up to the development team to find out what they are and be prepared for changes.

      • I would like to start out the answer with like joke that is not entirely joke. “A manager is someone that believes 9 women can deliver a baby in 1 month”. the point is that Agile makes a number of false assumptions like:
        1. all tasks can be divided into smaller tasks: this is false. dividing a task into smaller tasks is not possible without losing coherence and functionality many times.
        2. everything (or most) can be automated tested. Actually most software cannot be automated tested because it depends of human interaction which is very diverse.
        3. a person can start another sprint after finishing one. Sprints are not meant to follow one after another . they are meant to be rare things done only when is absolutely necessary. Interesting enough the most agile animals are the ones that in 90% either do nothing (big felines and other animals of prey) or move very slow (deer, bunnies and other herbivors).
        4. Meetings are more effective than a well thought mail or message. Usually this is false because verba volant scripta manent.

        And now let’s get to your exact claims:
        “I get the feeling that a lot of the people posting are not involved in all of the steps of projects. I develop business software, so I am writing from that perspective.” I developped a various number of software ; not sure what you mean by business software as most software is part of a bussiness. Most of the people are involved in the writing software part of the industry not in the managerial positions.

        The rest is mostly oratorics. Here is a fast example: if you tell me build me a house can you expect he will build what you wnat based on such vague descriptions? No you cannot! There are a variety of houses with 1,2 even 3 floors which you should know from the beginning because it affects how the foundation is build. A house can be made from wood earh, brick, rock or others again important for the foundation. Basically there are things that should be discussed first. Interestingly what customers care more and discuss first is the color of the house which can be changed with ease at any time, but the things that have to be decided first those are seen as unimportant and changeable at any time. Is the same problem with software. About requirements coming late. Let’s say you have lifted the walls and the ceiling and now the customer wants to tear down a wall because he wants more space for his living room. but maybe that wall is a sustaining wall. This means rebuilding most of the house to do this, but for the client it is seen as something extremely simple Again one of the problems with late requirements. It is one thing to change the color or position of a button which may take 5 minutes and to change some functionality that is at the bases of the software or changing something that is third party. And the business partner never listens to things like this and usually managers ignore this kind of stuff.

        From your answer it seems you only have been in managerial positions and have no idea what is happening at the factory level.

      • I’m not sure what you are trying to say. Most of your post has nothing to do with my post, and where it does, you agree with me.

        All I was saying is that nobody starts a project without a reason, and the reason should include an idea of what is needed, that need is the basis of the requirements, not the final requirements.

  4. I do not start coding until I understand the business case for the project. I plan the functionality of the application based on close communications with the end users and their management. I decompose the project into functional “modules” based on business needs. The agile development only begins once the developer(s) have a clear idea of the business needs. Things sometimes change a lot when the first version is shown to the users, but normally changes are minor.

    Interactions between modules are part of the required functionality from the beginning. There is no “build the parts now and integrate them later”.

    Works for me.

  5. Agreed, mostly. Adding to important points made by others: Agile may work for things like web development, where incremental update and enhancement is straightforward (after all, the user is really using your server, and even the client-side actions are being downloaded fresh every startup). It is harder for cases like embedded systems where the thing has to work, first time, every time, after being stored in a drawer for years with the batteries out – without updates, without connection, without communication. Agile requires the end-users and subject-expert stake-holders to be involved throughout; most things I’ve worked on don’t get revealed to the end-users until they’re shippable products, and the subject-expert stake-holders are too busy making the company money at industry conferences and pre-sales to sit down and discuss the incomplete specs they tossed over the wall.

  6. This is all so interesting… I’m writing software for over 25 years and still truly like it.
    What is happening around “Agile”-the-word recently is an interesting thing. Actually vast majority of current job openings include “Agile”-the-word as a requirement for an applicant. So people naturally are trying to satisfy those requirements and totally embrace Agile-the-word in their resume and presentations/interview. Then those who interview them are also on the same level of understanding of Agile-the-word. So this is a perfect match.
    Therefore “Agile” is a synonym for “Modern” and “Progressive”. No more then that really. Well, if you know how dauly stand up looks like6 then you are a Agile-Pro!
    This is a reality out there. You may discuss all the nuances of philosophy and such, but… That’s all nonsense is totally misunderstood by vast majority of “Agile-practitioner”.
    And now ask yourself: if this type of using the words alone works, why would anyone try to change their mindset?
    So people are just people. This is really what it is all about.
    Then there is another major problem with Agile as it is applied now: it is 90% about code creation (html and friends included). But from my experience code creation as such is no more then 30-40% of all the effort required to actually create a working product. There is design/system architecture (completely not covered by the process), there is documentation (both user and maintenance), there is acceptance testing, there is production support, there is upgrade testing, there are countless meetings both technical and non-technical. This is all NOT covered by Agile whatsoever. While meetings/docs can be covered outside of the main agile cycle (but what’s the point if you cannot ship the product without it), design and architecture cannot be avoided or worked around.
    So then people say: the main change is the change in organisation, meaning that your entire organisation should adopt the new ideology/philosophy. But guys, really, what are you hoping for? Such changes cannot be forced. There is something in the spirit of every large organisation that is very-very persistent. This is called corporate culture.
    So large organisations are concerned about their IMAGE and how they LOOK rather then improving the internals. And here we have all the consequences: mocking the agile values, mocking the agile processes etc.

    From my experience, there are the following minimal set of pieces of work that constitute the good project: 1) THE IDEA of a project 2) Clear vision how it can be implemented 3) Architecture 4) Design (both visual and software) 5) Coding 6) Integrations 7) Test-cases 8) Documentation 9) Maintenance.
    Agile only addresses a couple of these items. But there is no workaround for the rest.

    So, my opinion, there is no workaround for lack of experience. I can adapt to all the rest.

  7. The worst thing about this is that agile manifesto doesn’t even mention User Stories, Epics, Standups, etc. This sounds like severely misinformed commentary or rather effective trolling.

  8. Today, Agile is marketed with the snake oil promise of fixing all development problems – cost / schedule overrun, poor teamwork, inflexible process, unhappy users. If you are not doing it you dam well should before you get left behind. Unfortunately, the basic sound ideas defined in the Agile Principles have been hijacked by a vendor feeding frenzy, endless marketing hype and by implementations ( Scrum, Kanban etc ) that promote short term thinking, exaggerate value and minimize challenges. The narrative is now based largely on dogma, questionable rituals and puffery. Given that many companies are not happy with what they are currently doing, the promise of Agile is easy to understand and attractive to management pulling it’s hair out to fix things and looking for a short cut. My thoughts at

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