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.

105 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.

  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.

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