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.
The Anti Agile Manifesto 
This is really stupid joke 🙂
Seems far from stupid to me. Precisely the point. Besides it is we developers that have to deliver a working product, despite whatever process is imposed on us by fanatical imbeciles that could not write a working 10-line shell script.
You are a stupid joke. 🙂
Agreed.
The IT Skeptic salutes your skepticism.
But you are of course missing the point of Agile.
The point of Agile is as elusive as any other void
Coding is not the hard part of software development.
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.
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.
Any system is not just a sum of its elements. If you collect all the parts of the motor in one bucket and then shake it, uttering a spell, the parts will not become a motor.
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.
Many Agile developers believe they are successfully doing Emergent Design, but in reality they are only doing Framework-Based Design:
http://effectivesoftwaredesign.com/2014/09/01/on-agile-architecture-emergent-design-and-framework-based-design/
Good article.
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.
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.
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.
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.
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.
Did you read it? It most certainly did mention those things:
epics are really just projects
stories are really just use cases
stand-ups are really just meetings
It’s not trolling. I think you miss the point here. I interpret this as saying, “Agile sounds like a panacea for all of our software challenges. But, when you really look at it, it’s just a repackaging of the same concepts that we already employ in competent software design and development.” There are a lot of consultants out there making a lot of money selling people something that they may already have. Papa’s got a brand new bag, and the Emperor has new clothes.
The things he rails against are not in the Agile Manifesto. They are part of Scrum which is one common interpretation of Agile, but like all things some people get the interpretation wrong.
Dan
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 http://www.actlikeastartup.com/agile-enough-already/
Beautifully-said. There will always be old and new programmers. Every few years the newest batch of programmers must somehow try to convince everyone else that they bring some great benefit to the programming team and they’re the likeliest to buy into these methodology shifts *du jour*. And if you–the older programmer–don’t fall along with the new paradigm then you get replaced by someone who will go along. Maybe it’s just a natural culling mechanism so that companies don’t have to retain their higher-paid assets; there has to be some level of nonsense that an older programmer won’t embrace. We could come up with a “new, new thing” in which programming is best done while wearing a beanie-with-a-propeller-on-top. And sure, enough, this new methodology would cull out the older, more expensive programmers since they’re old enough and confident enough to realize how stupid it looks. Management then gets a fresh batch of kids who will work salaried/exempt at 50+ hours per week at a fraction of the cost and the geezers leave. Agile is simply a crypto-ageist strategy working at the core to adjust down the salaries of the industry as a whole.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I do not understand how this can be controversial, or why it would be beyond the capabilities of old programmers like me.
Hi Guys!
If twist of tongues is what traditional management needs to wake up and realize that it’s the programmer who is DOING things then let it be twist of tongue…
On another hand, nobody claims Agile is the ONLY solution of developing software. Most likely in the future there will appear something else to earn mainstream attention by replacing Agile and something else will replace that else etc.
At the end of the day, it is only normal to evolve and evolution means change and change is taking us out of our comfort zone…
So, stop bitching about one being absolutely wrong and the other being absolutely right!
And to those unhappy with how the current employer is organizing work: open your own companies and do it better…
All the best,
Raul
This anti agile manifesto only suggests that Agile is bad, but doesn’t say what is good. Everyone using Agile frameworks INSTEAD of common sense has naturally failed and missed the point completely. So even if this manifesto is fun as a joke is completely useless and reveals an attitude of being sceptical without being constructive
What a ridiculous statement. Washed up devs looking for career opportunities as Agile Managers, along with other snake oil salesman, have no business in software development. Software development was doing just fine until Agile came along, it will do just fine when Agile goes away.
Software development was not doing fine. Check the statistics for failed projects. The percentage of successful projects is increasing, even though the projects have gotten more complex. I use “agile” myself, but I am not claiming it is magic.
Can we be sure that the percentage of successful projects is increasing? My perception is that Agile projects pin down time (the sprint) and cost (the effort of the team) – but they often don’t promise to deliver the full value that was expected when the sprint backlog was agreed. Then comes the end of the sprint and the customer is bamboozled into believing that value delivered is enough. And the project is declared a success. De-scoping seems to be the magic key to creating the impression of success in the face of regular failure.
Recent reports confirm that the percentage of successful projects is increasing, but I don’t think it’s because of Agile, I believe it’s because of the extremely powerful frameworks and platforms we have today:
https://effectivesoftwaredesign.com/2014/09/01/on-agile-architecture-emergent-design-and-framework-based-design/
Original “Agile Manifesto” consist of incorrectly-phrased statements, in which oppose the incomparable things – a known trick for the mind.
Another trick is to avoid concretisation in the author’s attitude to what is written (more/less, over/under), so that the responsibility for the interpretation was put to the reader.
One more trick of Agile is to say “we found the way” and never disclose how exactly: saying “by doing software development” is like saying nothing.
More tricks come out of the “Principles behind the Agile manifesto”: every principle describes a picture of happening, but not the mechanics of how it is achieved – this protects authors from critics of their method. In addition: the end result isn’t described in the manifest or in the principals, which factually bring the authors out of any responsibility for the practical results.
Speaking beyond the manifesto and principals, trainings on Agile are often rich with generalised and banal phrasings, like “if you have bad results – than you do something wrong” – they’re applied to any case and it is impossible to raise any objection. It can be referenced to the Agile evangelists lack of competence, but really the official literature also doesn’t contain the details on the software development – it only contain the details on Agile. It appears, that a set of non-concretised statements supposed to influence the software development process doesn’t contain any technical knowledge – this is very strange and dangerous thing, which infiltrated irrational delusions and incompetency into the whole software development business.
Agile is always relying on teams of self-organised highly-qualified professionals. When being widely spread in IT companies, Agile just takes professionals out of natural labour devision system and wastes their time to satisfy constantly changing wishes of rich people far from software development.
This results in serious disproportions in the engineering market: there’s a resource hunger on experienced engineers everywhere, but there’s less and less work for the less-experienced people. There is no natural way to learn things – there’s only woodpecker-like hand stuffing in Agile teams, which obviously is not the same as learning from simple to complex and as deep understanding. We have so many ‘professionals’, whose qualification is formally high, but practically – they’re stupid and can’t really handle non-standard cases.
In addition, Agile projects are never well-documented. It means, the replacement of any team member is always a great headache: there’s no way to onboard fast and all benefit from the Agile’s fast production is neutralised by the absence of good documentation. And guess what Agile books say: Agile is not concerned on human resource questions, those things are out of our scope!
That’s it folks.