
The Death of Agile [video] - StylifyYourBlog
http://www.thoughtworks.com/talks/the-death-of-agile
======
Toine
I'm really surprised by this video.

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

~~~
MetaCosm
Welcome to software development, where no one really knows what they are
doing, the methodologies don't matter and everyone is wrong! Software is still
a mix of art and science, there are a lot of ways to get to the right answer,
and it is often very arbitrary and unbounded by physical processes. It might
never settle, it might be like all the different methods authors use to write
books -- strange rituals and personal patterns... there is no "right" way to
author a novel -- might end up being the same with software. The end product
is what you will be judged by...

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

~~~
pinaceae
it is not a mix of arts and science, it is akin to middle ages styles
manufacture. re-inventing the wheel, left and right, hundreds of years away
from real engineering. even questionable if something like the freemasons
exists yet.

------
oldpond
I think I know who Dave is making fun of, and yes, there are plenty of
stakeholders who are hopelessly lost and willing to "buy agile" to make it
look like they are doing something. Just get all the useless project managers
to call themselves scrum masters and hold daily stand-ups (which in the old
days we called micro managing) and hope and prey that something works...

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.

~~~
InclinedPlane
At one of my past jobs we did "agile" or "scrums" or whatever they called
their bastardized version of an agile process. At one point this involved
standups which included over a dozen people and typically lasted between 45
minutes and an hour and a half. Everyday.

~~~
EdwardDiego
Gah. So let me guess, the "stand-up" ended up with a bunch of people sitting
down, because after all, you can't stand up for that long...?

...the number of people who miss the reason for standing up (to force brevity)
is astounding.

~~~
InclinedPlane
Nope. Everyone stayed standing the whole time.

This was at a multi-billion dollar online retailer who shall remain nameless
(though it's pretty easy to figure out).

------
slowmovintarget
Now if we can just get management to sit down and watch this...

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?"

~~~
wallflower
For management, it's not really about the process du jour per se. It is about
standardization, frameworks, and control. Read 'Seeing like a state'

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...](http://www.amazon.com/Seeing-like-State-Certain-
Condition/dp/0300078153)

~~~
UK-AL
"standardization, frameworks, and control" If management wants this than good.

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.

------
bane
If there's a truism, it's that Agile is and always will be a reactionary
process to older Waterfall style methodologies adopted from other engineering
principles. That means it suffers from some of the kinds of problems
reactionary "we'll do the opposite of that old broken stuff" ideas have.

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.

~~~
enraged_camel
>>For example, I'm afraid that in many environments, Agile ends up meaning
"directionless or micro-directioned iterative development"

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.

~~~
pinaceae
that's exactly why product managers exist. i run precisely such a team,
because there are _no_ devs out there that know enough about our vertical -
and the time learning and keeping up to date would be prohibitive.

~~~
kylequest
PMs can help only with one part (the "problem"), but, unless they are also
good architects and designers, the end result and the process end up being
pretty painful.

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

~~~
pinaceae
absolutely agreed and yes, we go deep on designs. and yes, it is uncommon,
makes hiring quite challenging.

------
placebo
Watching this, my first thought was how an aerospace engineer or a structural
engineer or any engineer/manager of any complex established engineering field
outside the software development field would react to this video. Probably
with horror, shock and disbelief :)

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

~~~
tonyedgecombe
Most software projects fail.

~~~
placebo
What do you mean by 'fail'? fail financially or fail technically? If you mean
the former then that's a no brainer, as I assume most projects fail
financially whether software or not. If you mean fail technically then I'd be
interested to see numbers. It's certainly not my experience.

------
threepipeproblm
I really enjoyed this.

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

~~~
cmdkeen
"the claim that the single metric that matters in software is how easy it is
to change"

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.

------
lifeisstillgood
For me, and I think i just worked this one out, Agile can only work in a
collaborative, open, high trust environment.

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"

~~~
tonyedgecombe
This is true, I suspect that companies that fail with agile will fail with any
and every methodology.

------
InclinedPlane
For those who aren't aware or didn't pick it up, Dave Thomas is one of the
handful of originators of the "Agile Manifesto".

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.

~~~
mattmurdog
Very well said.

------
tunesmith
For those that are allergic to snark like me, skip the first fifteen minutes -
it doesn't start getting constructive until then.

~~~
pmoriarty
I don't know what you're talking about. The first part was the best part.

~~~
imanaccount247
The part where he makes fun of the agile snake oil salesmen despite the fact
that he was one of the biggest offenders?

~~~
pmoriarty
He did seem like a hypocrite for trying to tell the audience how to "do Agile"
(or, in his terms "develop with Agility") immediately after a satire on people
who do just that. Further, I doubt he was giving the talk for charity. He's
clearly making money off Agile just like everyone else.

Nevertheless, the first part was entertaining satire, no matter its source.
The rest can be skipped.

------
pmoriarty
I'd like to show this to my company, but I'm afraid I'll offend coworkers who
make their money at the company "doing Agile" and I'll get lynched, not to
mention fired.

~~~
rebelshrug
Fired for voicing an opinion? Sounds like a company worth leaving.

~~~
calibraxis
Most corporations will fire you for voicing certain (non-oppressive) opinions,
since ideology is important. You see it in schools too, not to mention cults.
You're allowed to get to the next rung by not seeing it, already having the
right attitudes, or faking it. (Consider some meanings of "cultural fit".)

~~~
rebelshrug
>> Consider some meanings of "cultural fit"

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.

------
rebelshrug
Not everything about agile software development is bad. Planning poker is a
great team exercise if you replace the planning part with a deck of playing
cards, poker chips and beer.

------
capkutay
Not to sound lazy, but I'd like to make a humble request for a TL;DR? I can
skim long papers, but you can't do that for long videos!

~~~
rebelshrug
here's Dave Thomas' blog post on the subject:
[http://pragdave.me/blog/2014/03/04/time-to-kill-
agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

~~~
capkutay
Thanks!

------
fpp
Also read his interview on the topic in Dr Dobb's earlier this year
[http://www.drdobbs.com/architecture-and-design/dave-
thomas-i...](http://www.drdobbs.com/architecture-and-design/dave-thomas-
interview-the-corruption-of/240166688)

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/](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.

------
mathieuh
I'm in university at the moment and we're learning about Agile. Next year I've
managed to get a year long placement with a big local software company and
their interview and technical assessment mentioned Agile loads. The year after
that, I have half a module (worth 8% of that year's available marks) based
solely on Agile. I've also attended talks by big names like Citigroup and also
local startups which were almost entirely about using Agile.

So is it in fact the case that in The Real World Agile is starting to go out
of favour?

~~~
radicalbyte
> 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://en.wikipedia.org/wiki/Technology_adoption_lifecycle)

------
ItsMattyG
Agile is good in uncertain environments with frequent project changes, but not
in other situations... Simon Wardley has a good model that seems to work
reasonably well:

[http://blog.gardeviance.org/2014/11/how-we-used-to-
organise-...](http://blog.gardeviance.org/2014/11/how-we-used-to-organise-
stuff.html)

------
guiomie
I keep hearing the word "agile" from vendors, consultants and non-software
related stakeholders at my work (a telco). For me it is a buzzword, thus I
have been quite reluctant toward it.

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.

~~~
DanielBMarkham
"Agile" is a marketing term: it brands various best practices in iterative and
incremental development. You go to a bookstore and want to read a mystery?
They have a whole section labeled "Mystery" where you get all kinds of good
stuff. You want to learn how groups of people work well together in tech? Go
to the "Agile" section.

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++

~~~
pjmlp
Many developers would learn a lot if they improved their soft skills instead
of yet another programming language/framework.

~~~
DanielBMarkham
I would hire people with good aptitude and attitude over people with good
technical chops any day of the week. It's not even close. I've seen too many
teams of great people walk into a project not knowing any of the tech involved
-- and kick ass. I've also seen a tremendous number of highly-skilled teams
create a death march/miserable existence for themselves where they could get
nothing done at all.

~~~
UK-AL
What do you mean by soft skills? Soft skills for a manager might be an
agreeable developer, who agrees to unreasonable deadlines. The manager would
would say he had a good positive attitude, but the project would certainly
fail.

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.

~~~
EdwardDiego
> Soft Skills from the development teams perspective is assertiveness.

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.

------
dmux
I'll just leave this here:
[http://seir.sei.cmu.edu/sheard/Life%20Cycle%20Silver%20Bulle...](http://seir.sei.cmu.edu/sheard/Life%20Cycle%20Silver%20Bullet.pdf)

------
chriscareycode
I love this talk by Erik Meijer on the topic
[http://vimeo.com/110554082](http://vimeo.com/110554082)

------
serve_yay
He is quite a speaker, but really the first 15 minutes is a standup comedy
routine for project managers. You can skip that part.

------
pmoriarty
Anyone have a direct link to the video?

I'd like to watch it, but it requires me to run some Flash plugin, which I'd
like to avoid.

~~~
devmach
It looks like they have html5 player too, which plays the following file

[http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b...](http://embed.wistia.com/deliveries/05b7d508543a1e8f7de01e27b8db61a26e7cb5c1/file.mp4)
(900Mb, HD)

edit: Although, I don't know if they allow you to "Download" the video in
sense of the licencing...

~~~
pmoriarty
I should have said that I didn't want to run any embedded players, Flash, HTML
5, Javascript, or whatever.

Thank you for the link!

------
InclinedPlane
(As much as I hate to post twice on a thread, I've had some thoughts that I
haven't seen expressed yet.)

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.

