The Death of Agile [video]
thoughtworks.com
thoughtworks.com
I'm a junior developer who just got out of college. I knew the software industry isn't as mature as some other industries, but I kinda thought as a whole we were moving towards a more professionnal, more robust, less amateur industry.
This guy, if I heard correctly, participated in writing the Agile manifesto, which is basically software's 10 commandements written by the Agile gods. In this talk, he basically says : "Yea actually we were kinda wrong, you shouldn't listen to anyone telling you to do anything, just run free in the jungle and you'll be fine."
So after all those years of trying to find a solution to how to do software correctly, this is his answer? Why would you say something like that?
How do you teach people then? Where can i learn how to do my job correctly? The 4 steps he give cannot be taken seriously...can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."
> How do you teach people then?
You can't really, teach to the best of your ability and try to send students out with an ability to learn. It is MORE harmful to PRETEND you know what is going on than to openly admit you don't and are attempting to learn. False knowledge is worse than real confusion.
> Where can i learn how to do my job correctly?
In this field, it is a young and crazy field, maybe you will be the one who pioneers a way to actually do things more consistently... maybe you will just serve up another nonsense silver bullet.
> can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."
Doctors kill patients all the time via mistakes, it is actually one of the leading causes of death in the western world... the half-life of medical knowledge tends to be less than a decade, so a decade out of school, a lot of what they know is wrong, or worse... actively harmful. We turn doctors into gods because it COMFORTS US, not because it has any connection to reality.
Which is to say: just like everything else, including both art and science.
> Where can i learn how to do my job correctly?
That is a really heavy question to answer. I could try give an opinion but I've only been developing software for 10 years. Maybe in another 20 or 30 years I'll have something good to tell you. The fact is you just need to build things for many years and see what succeeds, what fails, and what you can learn from each success and failure.
I have been developing software for almost 30 years now.
Not everything was bad about waterfall, RUP, UML, Booch and related methods.
As not everything is good about every agile variant out there.
The secret, if any, is trying to find a good mix.
Which is very difficult given the constraints in team member skills, what the sales team promises to the customer, what the customer is willing to pay for, and what the managers what to ear and sell to the customers.
Specially when most companies treat developers as replaceable cogs.
Software is creative work, treat your team like a band. Maybe if you're lucky you can find a replacement for the bass player if he quits, but realistically when your team changes the way you get work done and the kind of work you'll get done will change too.
Developers are treated like robots. Mentally taxing labor like software development is not viewed in the same professional light as lawyers or doctors. The lowest cost seems to prevail and managers and business owners are always on the look out for reducing their overhead cost. Even the most generous and good hearted ex-engineer turned CEO has to view the engineers as a cost overhead. This is why unless a business has monopoly, it cannot invest in engineers, it is constantly looking for a turnover to maintain the low overhead.
The last part really sickens me and especially when people cry why is it so hard to find developers? It's hard when you aren't willing to pay the true cost.
Now, that said, Agile is fairly new as software engineering goes. It isn't that young of a field.. waterfall put man on the moon, after all. Agile particularly speaks to how one can remain somewhat stable while optimizing for velocity, and is particularly well suited for the type of businesses that have dominated the last 10-15 years: self hosted consumer applications or SaaS. The key to choosing a process is to understand what you are trying to optimize for and what sort of release process your project requires. Agile, for example, might not be the best solution for gamma knife firmware or embedded systems in cars. To give him the benefit of the doubt, perhaps he's reached the age of reflection and trying to emphasize that everyone should step back and consider their goals, and reevaluate their strategies in light of those goals. [edit: and understand a lot of people are lazy and/or risk-averse, and would prefer to think that there is a magic best practice, that if applied hard enough, will work for everything]
I watched the whole video, and I'm not impressed. Same old 'no true Scotsmen' crap that is epidemic to Agile. Yes, in almost 15 years, we are all still failing Agile instead of the other way around. Only now, it's gotten so bad it needs a new name. What he should realize that he doesn't like is complexity. If you have more than a thousand developers working together across multiple related product lines with various marketing, sales, and development dependencies then the 12 original principles and $2 will get you a bottle of soda. He shouldn't be mocking Agile in the Enterprise, he should be trying to figure out what is wrong/missing in Agile that causes it to become so pathological at scale.
As we learned with the Apollo Guidance Computer [0] and Shuttle computer systems development [1], the methodologies were not strictly waterfall. I'd like to do some more research in historical engineering techniques. I am not convinced that waterfall has had a much sway as the industry makes out.
[0] http://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist)
[1] http://en.m.wikipedia.org/wiki/Iterative_and_incremental_dev...
That's generalization for you, though. It says more, less clearly.
Regarding the Agile Manifesto, he's not said they were wrong, Dave's saying that the main principles of the manifesto are being ignored.
From his blog post:
[quote]
Let’s look again at the four values:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation, and
- Responding to Change over Following a Plan
The phrases on the left represent an ideal—given the choice between left and right, those who develop software with agility will favor the left.
Now look at the consultants and vendors who say they’ll get you started with “Agile.” Ask yourself where they are positioned on the left-right axis. My guess is that you’ll find them process and tool heavy, with many suggested work products (consultant-speak for documents to keep managers happy) and considerably more planning than the contents of a whiteboard and some sticky notes.
[/quote]
Dave then goes on to give his heuristic as a replacement for all the consultant BS that emphasizes the very things that are supposed to be less important.
He's really saying pay attention to the requirements, check your progress toward them frequently, and every-so-often, check that they're really still the requirements. As for code structure, technology selection and so on, he as much as came out and said to work with an architect or a master developer to help make those choices correctly.
He was again correct when he said that all of software development practice boiled down to making things that were easier to change over the long run. So when other factors don't rule it out, choose in favor of flexibility.
there are a lot of shops out there that develop and deliver great, working software on a rapid schedule. succesful saas shops come to mind - and even Microsoft has picked up massive steam in that regard.
the really awesome, productive dev teams are too busy to publish talks and whitepapers about their methods - they're 100% tasked with shipping. think about that anytime you see talks and conferences, etc. the best engineers in any industry work in silence.
it's the blow hards and wannabees that end up on stage or writing manifestos :)
Because of this, I believe 'doing your job correctly' varies considerably from place to place, depending on the different people you happen to be doing your job with. Learning a specific development methodology is much less important than communicating and working with others to come up with a development methodology well-tailored to the context.
I believe the best place is to work your job, and have the right amount of introspection :)
But what helped me the most with this "how to do software corectly" question, was to realize, that there is many different kinds of software.
If I would attempt an analogy, our industry reminds me of carpentry.
And as a carpenter you might approach differently if working alone, or with coleagues, if renovating or building a house on a green field, if building a garden bike-shed, or working on a river-dam :-)
Meaning there will never be specific 10 commandments applicable for everything.
Sometimes agile will fit your team (heck, my most productive week was spent PAIR PROGRAMMING :P )
Sometimes it won't.
One of the things that I believe is incredibly important is a feedback cycle. Do a thing. See if it worked. Reflect on what you learned doing that thing.
And most importantly, ignore any feedback that starts with "You're doing it wrong." But listen carefully to anyone who says "Here's how I'd do it."
This is how I learned software development. I wrote crappy things and placed them before people I respected. And these people gave me exactly what I just explained..
You're a junior developer - there are so many people willing to help you out and learn, if you ask.
Enjoy software development!
But you're asking about learning, and from my perspective anyone who is willing to ask incisive questions has the wherewithal to continuously improve and ultimately succeed in his/her field.
Fads and fashion...
Let the master programmers (with substantial backing proof) lead the way and everything will fall into place.
Welcome to life. You will find that the world doesn't work the way it's described in books or from the mouths of someone with grey hair.
I've been in this business since the 80's and a consultant since '98, and I can say that although I love the agile approach, busted organizations and "enterprise" consultants are killing the ideas. Agile is a software development approach, not an organization development methodology. The last gig I was on the customer tried to "go agile". All the departments started holding daily stand-ups which quickly became silly repetitions and micro management kill-zones. Picture this, the daily help desk standup: "Yesterday I answered phones, and today I plan to answer phones again." Everyone was doing 'agile' except the software development teams. Maybe Dave is right, all you can do is laugh about it. And then put it all on the cloud.
The incredible thing was how much upper management treated Agile as a panacea. It made me realize that they had no idea how to actually run a company, which is why I ultimately quit. I can't work for people I don't respect.
...the number of people who miss the reason for standing up (to force brevity) is astounding.
This was at a multi-billion dollar online retailer who shall remain nameless (though it's pretty easy to figure out).
I keep watching Cargo Cult "Agile" turn every project into a galley, developers at the oars with the scrum master merely manning the drum and shouting "row!" Two lashes for failing to update your task in the system, no matter that the work got done...
We really need to get back to the real measure of working software instead of "are we going to have a demo or not?"
From Ruby Rogues 184 RR
"JESSICA: Alright. So, I am going to echo one of Greg’s picks because it was on my list but for a different reason. ‘Seeing like a State’ is an amazing book. And I think it’s drastically changed the way I look at software, not for the same reason as Greg talked about but because it shows why what we do is hard. ‘Seeing like a State’ talks about all the subtleties of human systems and human interactions at the local context level. It talks about all the improvisation that everyone does on a day-to-day basis and how in real human communities, we’re constantly changing the system to adjust to a slightly different reality, to corner cases we hadn’t seen before but now we have. It’s shifting and it’s not well-defined. And suddenly it makes complete sense that the hardest part of software is figuring out what we want to do. That’s it. It’s a great book."
http://www.amazon.com/Seeing-like-State-Certain-Condition/dp...
In my experience its the constant change(I don't mind controlled change, but hidden change), constant scope creep, constant increasing of tasks, without increasing estimates. The constant being asked to "do things faster" without caring about quality, then being blamed about quality at a later date that makes things fail. Trying to implement every single feature, rather than focusing on a small set of useful features.
In a word its management that makes projects fail. You need a system to set constraints on managament so they have to make proper trade offs and don't expect everything in a small amount of time.
It's easy to manage if you expect everything can be done. What makes management hard is making the trade offs because you have limited resources.
If you implement a standard way of doing things, you can stop management wrecking projects.
Boss comes in and asks to change something? Well it has to go through the normal estimation process and the estimate increased etc
They can't ask you to cut corners, because it must go through the same quality procedures
etc
A lot of developers are complicit in this, because they have a super hero complex. They want to show off, and have unrealistic expectations of themselves. Management think they getting a great deal, but in the end the developer can't deliver. One of the parts of becoming a senior developer is to start to really know yourself. Then adjusting your systems to compensate.
One thing i like about SCRUM is the velocity technique, because uses past history to estimate rather than ego driven estimates.
Frameworks and standard techniques are there to protect developers much more than to protect managers.
my back is still hurting ( our BigCo had methodically tried to implement Scrum/Agile/Lean during 2012/13 which happened to be such a great failure. It seems that management is so shell-shocked by it that they haven't tried to push any new methodology during the whole last year. Well, and the management lost all credibility here too - any attempt at pushing any new methodology today would make everybody laughing in their face :)
>"are we going to have a demo or not?"
almost two first weeks of a sprint almost whole organization is working on a demo for the previous sprint - that was beyond insane.
Wow. You're right, that's beyond crazy.
What frustrates me is that demos can be very useful, if done right, but if you're doing them because "We do Scrum, here look at this certificate I got from Scrum Alliance saying that I'm a 'Certified ScrumMaster®', see?!" like the artefacts of Scrum are magical ceremonies that will cleanse you of your software sin...
For example, we create a small video demo of a feature story as part of the story development, and we make it available for our business team (who are on the opposite side of the world) immediately. This gives them a chance to flag the occasional oversight on our part sooner, and we can fix it sooner. It works really well for us in terms of ensuring quality, but also for keeping the business team aware of what we're doing.
But if it didn't, then we should iterate on our process (like bloody Scrum says to do) and stop doing them.
so far there is nothing in that paragraph specific to Scrum :) Doing demo sooner in order to get feedback and chance to fix sooner is more toward Agile. Doing demo just because it is end of sprint is Scrum. Agile and Scrum are two pretty opposite things :)
I'm not saying everybody should switch to Kanban, but in our case it is just enough process to keep track of our progress while not getting in the way of getting stuff done.
__Individuals and Interactions__ over Processes and Tools
For example, I'm afraid that in many environments, Agile ends up meaning "directionless or micro-directioned iterative development"
e.g. just start building stuff, nobody has any real idea what the ends state is supposed to look like or work, but we'll iterate into something at some point. Probably when we get close to running out of money.
Old fashioned honest engineering is tossed out while the framework/technology of the month gets absorbed into this or that sprint cycle and when problems preventing what feels like forward motion are discovered, crap just gets thrown against the wall until something moves forward a step.
Things ship late, nobody can schedule anything, budgeting and hiring plans are a mess.
One of the defining aspects of being human is that we're capable of thinking a few steps ahead and formulating a plan. The way Agile works in most shops returns us to being mere beasts of coding.
Of the places I've seen, the difference between success and endless-iteration-failure-followed-by-multiple-rewrites-from-scratch-before-delivery-because-look-at-all-the-lessons-we-learned-along-the-way is that somebody sat down before any work started and defined the goal, timing, budget and expectations.
There's some planning, some mockups, some interaction prototypes, etc. at the start that's hard work to do, but defines the goals and vision the work effort should be going towards...the "shape" of the work.
Goal driven development is something that seems to be missing in too many shops. It's hard though, because you don't want to end up in the waterfall trap again, but you don't want to end up in an directionless iteration morass either.
It takes experience and lots of road miles to understand that balance and succeed.
Directionless. Absolutely.
Before he retired, my uncle was the VP of Technology for a very well-known financial firm. He managed a large department of developers and IT folks across multiple countries.
We were talking about Agile vs. Waterfall once, and he said something that stuck with me: Agile works if and only if your developers have significant amounts of industry expertise. Because only then can they look at a set of vague requirements, make sense of them and translate them into solid product features using their experience and knowledge in that specific problem domain.
Whereas if you look at the software industry today, most developers specialize along languages and frameworks, rather than industry lines and problem domains. Resumes almost never say, "X years of experience in [industry]" because most companies say they want to hire developers with "X years of [insert language/framework here] experience."
So then they end up hiring developers who are really, really good at Rails/Angular/Java/C# or whatever, but have never solved problems in the company's industry because their last job was something totally unrelated. They know how to use the tools and they may be able to iterate quickly, but if they implemented the feature correctly in the first place they wouldn't need to iterate in the first place and the product would ship on time and be on budget.
Edit. I have often thought that a good way to pair program would be to pair up a strong domain knowledge / weak dev with a weak domain / strong dev. I have had the opportunity to do this on occasion and the pace at which you churn out great working code is phenomenal.
The devs still need to learn about the domain and they need to understand it enough to build a good solution. Having to learn a new domain on your own can be tough. Having external SMEs (subject matter experts) reducing the ramp up time and answering detailed questions is a big help.
It's pretty common for PMs not to be SMEs though...
Waterfall had big upfront design, which meant every time a manager asked for a change it screwed up the design and had to modified which took a lot of time. So people didn't ask for changes and the resulting software didn't do what they really wanted.
Iterative development tries to embrace change, it's an attempt at controlled change.
Though I haven't given this too much thought, I think it boils down to the fact that the software engineering process is not like (and who knows if it will ever be like) older well established engineering fields, and this could be due to a combination of:
a) The unbelievably vast number of degrees of freedom and therefore infinite ways an engineer has to achieve a working model. Aside from the requirements and the hardware limits, the only limiting factor is the engineer's imagination and creativity.
b) The mind blowing complexity of a large software project. The space shuttle, definitely one of the more complex machines built by mankind, is built from about 2.5 million separate parts. The Linux kernel (from 2012, according to wikipedia) has 15.9 million lines of code, and it is by no means the largest software project.
c) The relatively young age of the field vs. the exponential rate at which new technologies are devised and introduced in it
All this I feel currently puts software development somewhere between an engineering and a form of art. However, I'm sure many people would find it unsettling to think they have to trust a form of art when flying in a commercial jet at 30,000 feet, launching a $500M space mission, or endless other modern operations that depend on software to succeed. The fact is though, that it does succeed. I doubt the same methodologies are used in every large software project around the globe, but the bottom line is that whatever methodologies are used (not taking into account different levels of effectivity or cost) most apparently appear to succeed getting the job done without a established "standard".
One detail that stuck out at me is that after Thomas makes the claim that the single metric that matters in software is how easy it is to change, he moves on to show a balancing robot.
Now he doesn't directly connect those concepts, instead he talks about the PID algorithm. But what struck me is that Moshe Feldenkrais defined good posture almost exactly in the same way that Thomas defines good software, although he is talking about humans rather than robots. Specifically, Feldenkrais says that good posture in a given context is that which makes it easiest to move into the next desired position (or a spectrum of potentially desirable next positions).
Not if you have actual business people that you work for, then you're delivery ratio (things achieved per person/unit of time) is key. Because that delivers predictability and enabled planning. It lets you have discussions about what level of quality to deliver, staffing requirements, manage delivery expectations and plan releases.
The key thing is that it demonstrates the cost of change to them, so after being burned they come to appreciate the benefits of building in flexibility, but it also affects how they interact with the business. Delivery, and the burnup/down it allows, is the way we as developers can train product owners to predict the risk in what is coming and use their expertise to reduce it.
I've seen far more time saved, and lost, due to the business learning to ask the right questions, and raise the right stories, than due to building flexible software to handle changes. No matter how flexible your software is the really huge changes always bring massive pain - and as developers we don't have the domain knowledge to necessary to identify those whereas business people can.
If you have that, pretty much anything you do will be agile. If you don't there is bugger all you can do to get to agile without fixing it.
Personality conflicts, leaders who shut down discussions, developers who just want to do what they are told and collect a pay check, this and more will screw you up.
So go for slow development, constant learning, some humility, and a company that won't fire you for looking like you are just "thinking about it"
Other than the obvious (profit motive in selling snake oil) there are some common problems that make evaluating and applying process difficult. One of the biggest problems is actually the effect of highly talented teams. If you have a team of skilled folks then they will often succeed independent of process. If they are burdened with unworkable processes they will quite often work around them, bend them, or ignore them and get shit done regardless. Which makes it difficult to tell when you've got a good process in place as well.
Another major problem, alluded to in the video, is the desire for brain death in management. People want silver bullets, they want universal advice, they want policies that don't require effort or thought to achieve results. You see something similar in tech security, everyone wants to hire a unicorn/jesus who swoops in and fixes everything, like a landscaper who comes in on the weekends to do yard work or something. The reality is that development, and security, requires effort at every level. It requires conscientious application of skill and judgment to get good work done, and that's true at every level. You can't simply apply one or another process and then switch your brain off and hope for the best.
4:00 - Middle-aged white guys at a conference to figure out how to sell fear by turning agile into a "noun"
5:00 - Make agile more difficult-sounding with lots of terms so you can manipulate companies out of time and money
6:00 - Sell unnecessary roles like "scrum-master" to further manipulate companies out of time and money
8:00 - Agile plot to mock developers who don’t “fall” for the previous manipulations.
But again, the tone changes after the first fifteen minutes, so I intended that comment for those who would watch the first few minutes and think that it's just someone invested in making fun of "Agile" the whole time.
Nevertheless, the first part was entertaining satire, no matter its source. The rest can be skipped.
Well, yes, poking a scared cow would not be nice.
I think you meant sacred? :)
Not to mention the fact that various job titles (scrum master?) are tied to the existence of such process within the company and are not useful outside of the context.
Good point, and I can see how showing a video like this to your coworkers could be construed as a subversive act - particularly if the company has invested significant resources towards their agile implementation.
I hope this means the death of scrum.
The diagram he shows in the presentation around 5min is from Scaled Agile that is trying to formalise the use of agile development approaches within the enterprise context (online at http://scaledagileframework.com/ )
I believe some the key messages from Dave are:
* Use common sense and focus on the goals and what you're planning to deliver - the approaches provide you with the agility to more likely arrive there.
* People and working solutions before processes and approach
* Collaborate, explore and adjust to change vs follow a predefined fixed plan
Some negative examples I've seen:
"Funny and ridiculously expensive certifications" - Job adverts making it a key requirement to have a "scrum master" certification instead of looking for people who successfully delivered solutions (within change / complex environments) Note: It takes 1-2 days from absolute beginner to being a "certified scrum master" and it costs a stunning £1,200 in London.
"Process over common sense" - Within a company of some of my friends when they asked me to help to turnaround a critical situation with their key development team - besides 2 developers all others had left because of conflicts with their line managers, one of them now standing in as "scrum master" and prescribing to continue and do daily stand-ups like before with two 6 people teams - sometimes only one developer together with the manager.
Deleted comment
Agile is all about autonomy of the team over what you're describing, which is a mish-mash of a lot of different strategies.
So is it in fact the case that in The Real World Agile is starting to go out of favour?
Nope, it has finally crossed the line into being "main stream". On the technology adoption lifecycle* it has hit the late majority.
It has been taken up by the "software development as career"-types who're only in it for the money; it's now a "requirement", just another box to be ticked.
Sad, but on the plus side it's better than the "waterfall" processes which preceded it.
* http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
http://blog.gardeviance.org/2014/11/how-we-used-to-organise-...
Seeing also one of the original authors thinking so, means I'll stay even more away, and perhaps take people using the word with skepticism.
I like this, but it's tough for many people to grok, because it's not a detailed instruction book, like some other methodologies.
If you want to stay current in how people are doing cool stuff, consume Agile material on a regular basis. But take it all with a grain of salt: you learn stuff and then try it. What works in one situation won't work in another. One of the things practitioners learned early on is that tech is 95%+ about people, not bits and bytes. People tend to be a few orders of magnitude more difficult than, say, C++
Soft Skills from the development teams perspective is assertiveness. The ability to say no(in a nice way) to an unreasonable request, without some kind of compromise on timeline or scope. A manager might say that guy is unreasonable, stubborn or manipulative(if you say no diplomatically). However the project has a higher chance of succeeding towards realistic goals.
Point being soft skills means different things to different people.
It's also "not being a dick to your fellow team members". One asshole can poison an entire team's culture. Besides, if you're doing Scrum remotely close to how it was intended, the only person who needs to be able to tell the product owner to fuck off nicely is the scrum master.
Have you not watched the video? Agile is a scam. Even one of the signers of The Agile Manifesto himself just admitted it on camera.
That some people will continue to give credence to an outright scam after it's been exposed and admitted to by one of its foremost practitioners is just a sad statement on humanity.
I'd like to watch it, but it requires me to run some Flash plugin, which I'd like to avoid.
http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b... (900Mb, HD)
edit: Although, I don't know if they allow you to "Download" the video in sense of the licencing...
Thank you for the link!
I think a lot of folks are missing some important perspective on the origin and rise of "agile" and the current state of process in the software industry. So let's take a quick trip back to the bad old days before agile to get a sense of what software development was often like back then.
First off, a lot of software was developed "out of house" so to speak, as works for hire by consultancy type companies. There would be extensive negotiations between the customer and representatives of the development company, the end goal of this process was typically a specification and a timetable that was then mutually agreed upon, through a legally binding contract, as to what would be built.
Next, the development company would take that specification and come up with a design that would be able to match the specs. Then that design would be sliced up and handed out to various teams and eventually down to individual devs. After the individual coding was done it'd be integrated together and compiled into a working product. The product would then be passed off to QA to test in order to make sure it didn't have any bugs and that it matched the spec. After that the product would then be passed on to the customer to use.
And everyone lived happily ever after.
Of course, there are a few problematic aspects to this process. Namely: everything. Usually what would happen is that the spec and/or the design would be unrealistic or impossible to implement, and wouldn't be what the customer actually wanted regardless. Often this was handled by acrimonious bouts of negotiation, often involving lawyers. Meanwhile, attempting to build anything that worked at all using this sort of process was a nightmare. When the software was integrated only at the last minute there were always a million new problems discovered. With such "big-bang" integrations a lot of effort is spent spinning away just getting the software to build and work at all. Meanwhile, when QA is the last step before handing the product off to the customer that means that defects, especially design defects, have had the greatest amount of opportunity to fester and take the most effort to remove. And, of course, the chance that the project would chew up many staff-years of effort without actually producing anything of use whatsoever was quite high with this model, since actually building software was a fairly late step.
In the face of all these very fundamental problems with the venerable "waterfall" process model a lot of new process ideas started to gain traction, more or less culminating in the "agile manifesto". The core idea of agility is to use iterative development, continuous integration, and open lines of communication to keep on track. The "customer" (or "stake holders") can see the direction of the product mid-stream and have many chances to correct communication errors or even errors in their original conception of what they wanted. The software is always being built and always being tested so integration overhead costs are much less severe and defects are spotted much closer to where they are introduced, making them easier to fix. The software is routinely in a "shipable" state with a continually evolving subset of the "final" featureset, this lets the customer see how close the developers are to the schedule and also dramatically reduces the risk of not shipping anything at all. The developers can always time box the release and ship something of value, even if it wasn't what was originally intended.
And so on.
The thing is, today we live in a fundamentally agile world of development. Waterfall is so far from the norm it's essentially extinct. The very idea of futzing around with nothing but requirements and specs for months or years before bothering to write a line of code is so anathema to the current standards of software development it seems ridiculous. Everyone knows you start with a skeleton and you flesh it out iteratively. The idea that you'd have your code base in an unbuildable state, let alone an unusable product state, for more than a few hours or days at most is similarly seemingly preposterous.
The fact that the basic principles of agility are now so ubiquitous that they are like a mold infecting every nook and cranny of the software industry is still unsatisfactory for a lot of folks. Management wants a process they can sink their teeth into. They want something that requires no effort on their part but seems like a silver bullet that can solve any problem. They want gadgets and tools. They want a process that they can leverage to justify all of their bad behaviors while removing accountability from themselves. And that's what agile-the-noun has become. Not agility, but rather an excuse for micro-management. A way to plan without planning. A justification for short-sightedness and disengagement. A convenient rolodex of excuses for why everyone but management is at fault for being late or building something bad or broken or that no one wants.
You either die a hero or you live long enough to see yourself become the villain.