
Agile is a Sham - willvarfar
http://williamedwardscoder.tumblr.com/post/20054342100/agile-is-a-sham
======
plinkplonk
I personally think Agile _is_ mostly a scam built around some very small
nuggets of common sense wisdom, which has then been propagandized by legions
of clueless methodology consultants to mediocre teams and management, and spun
into mediocre books and conferenceware. Just my personal opinion, ymmv etc.

That said, _this_ is a badly written article which doesn't convey much useful
information or convincing argument. I am surprised it is on the HN front
page,leave alone being the top ranked article (at the time of writing this
comment).

Agile and TDD have been exhaustively discussed before on HN and an HNSearch
will bring up much better arguments, both pro and con, from people who can
clearly explain their viewpoints.

~~~
equalarrow
True, the article is basically a rant, but I tend to agree. I've felt like the
agile train left my station long ago and it wasn't for trying. After being
invited to attend a free 'workshop' from one of the holiest purveyors of agile
out there, I left with the feeling that it definitely was all for those who
did not know how to actually 'do the work'.

The trends I've been seeing and trying to do are as follows:

* full stack responsibility. You own the task front (js/html) to back (db), including testing.

* no f-ing standups. Communicate normally with your colleagues, no prescribed check in with them.

* no iterations. Release whenever; it may sound crazy but kanban style release whenever you're ready to push features out, in my mind, is the way to go.

* engineers, again, run the company. This in my mind is the biggest thing - having those 'with power' also be engineers and the product being the most important product.

All the above are the opposite of what I've seen with the agile movement. Keep
teams small, keep them close and your product will reflect that.

Another huge, HUGE thing is to get the fucking mba management types out of the
office. Can't stress this enough: if you can't code, you don't belong. You're
making a tech company but you don't understand the basics of how the product
is made.. So, you own a furniture making company and you don't understand what
glue, oak, and lathes are..? Fail.

That's my real life experience and opinions regarding agile. I've tossed away
all the agile stuff for a new project I'm doing and like the poster says, it's
all based on common sense. You can run your company or project any way you
want. I have friends that have millions in revenue every year with their small
shops and they don't do any agile stuff. Yet they're one of the leaders in
their space and when my friend, the engineer ceo, told me "we have no
iterations or deadlines except when it has to be done by", that was a big
wakeup. I was thinking "THAT'S how I want to do things".

So, it _can_ be done. Good luck. :)

~~~
ArtB
> full stack responsibility. You own the task front (js/html) to back (db),
> including testing.

Unless you are 1337 with all of those you end up with silos instead of
properly defined layers and reusable code.

> Another huge, HUGE thing is to get the fucking mba management types out of
> the office. Can't stress this enough: if you can't code, you don't belong.

Awesome, I'll get around to telling my boss that, the very same one that hired
me.

------
cletus
I'm surprised no one has brought up Steve Yegge's _Good Agile, Bad Agile_ [1],
which speaks well to both Google culture and scaling (good) Agile. One of the
comments on that post mentions it. It's worth reading (and being Yegge,
that'll take awhile).

Agile is like anything else: some well-meaning (and arguably useful)
principles that get warped by bad managers and bad companies. The natural
evolution for any such idea is to turn it into an industry and there are any
number of people who are willing to sell you training, lectures, books and
programs for Agile (with a capital-A). You need to separate the industry from
the idea.

[1]: [http://steve-yegge.blogspot.com/2006/09/good-agile-bad-
agile...](http://steve-yegge.blogspot.com/2006/09/good-agile-bad-
agile_27.html)

~~~
davesims
Exactly. And note the date: 6 years ago. I think the collective wisdom has
been acquired. The IT community needs to name it in a way that makes these
lessons learned common enough that the next time someone is burned by Bad
Agile, they won't rewrite one more iteration of this same post.

------
mseebach
It's useful to distinguish big-A and small-A agile.

Big-A Agile is a management buzzword, something you can become certified in
and certainly a scam.

Small-a agile is a number of mostly common sense principles on how to approach
process. It is emphatically not the process itself. While it cannot be
meaningfully certified, it can be taught and learned.

Someone else linked to the agile manifesto. I'm just gonna go out on a limb
and paste the punchline:

 _Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan_

~~~
MrKurtHaeusler
I haven't heard that argument before. Interesting.

For me, big-A Agile refers to the Agile Manifesto for Software Development,
and is the Agile that people are talking about in posts like this. It may be a
software development buzzword, and yes there are certifications and they are
scams, but I find the values and principles in the Agile Manifesto to be
fairly sound and relevant within the context they were first produced in, as
basically a reaction to waterfall in larger companies developing business
software with average developers.

Small a agile is an English word meaning quick or flexible or something.

I am not saying I am right and you are wrong, just that is how I have usually
thought about it.

~~~
mseebach
You can't "be" big-A Agile, it's a tool set or a check-list - but you can (and
should what to) be small-a agile as a development organisation.

The reason I make the distinction is that big-A is the quantifiable bit, but
you can tick all the boxes and still essentially do waterfall. Conversely, you
can be small-a agile without ticking the boxes - agile isn't, and can't be,
prescriptive.

If the team feels they don't need daily stand-ups, or if they want to sit down
(the horror!), there is nothing about being agile that should keep them from
doing that. Same goes for tests: You can worship the test coverage number
obsessively, but if your assertions are pointless or missing, you won't reap
the benefits. Conversely, an agile team can decide to forego tests if that's
the right thing.

------
hpaavola
The problem with these "only good programmers will create good products so
stop with the Scrum already" rants is that in real life we have more than
enough mediocre engineers and we just have to come up with best possible
products with those.

I work as a quality assurance consultant. Usually companies buy my services
when everything is messed up. Now if I try to solve their problems by saying
"hire better engineers", nothing gets fixed. Nothing gets fixed because there
is only so many good engineers available and the company usually don't have
enough money to hire him/her.

But if I teach them to follow Scrum, it is really easy to add code reviews,
testing (unit and functional), planned releases, etc.

It could be argued that one does not need Scrum to get those done or that it
does not matter since team of better engineers will at some point do better
job. But have problems in our hands right now and those must be fixed
yesterday. So until some other methodology than Scrum get popular enough,
we'll use that.

So in real life Scrum makes getting the best out of normal team so much
easier. Sure there are always rockstars who don't need any process, but in
reality you, me and most of us, are all pretty dumb and just have to live with
the fact.

~~~
brazzy
The other problem is that the people who write those rants are probably not
half as good as they think they are.

------
S_A_P
In the last few companies I have worked for, Agile was not lightweight, and
became a significant hindrance to productivity. In fact, there was an "Agile
consultant" brought in to make us more agile at one company I worked for. He
ended up making our process 3-4x more convoluted and process intensive. He
also succeeded in making the work not fun anymore. In my last job, "Scrum"
meetings could take 30 minutes or more on many occasions, and our "sprints"
would regularly change scope or be canceled mid way through.

I know that isnt Agile, but the problem is that many managers(and apparently
consultants) think that _is_ the way to do it. In my opinion, work getting
done is not because you implement a process or methodology. Work gets done
when you have a good team in place and trust them to do their job. Many
companies seem to think that they can promote a non technical person to manage
a development team. The problem with this is that they have no idea how
software is built so implementing a methodology that promises consistent
results no matter what the inputs are seems reasonable to them.

I am by no means representative of anyone other than myself, but I find I am
most productive when a) I know the problem domain inside and out b) I am given
some leeway with architecture and design c) I am not bogged down in process.

As projects get larger, its not as easy to allow for those conditions, so
getting smart people on board is imperative. Agile should allow for managers
to get some transparency and a view into the process, but little more...

------
sambeau
Agile and Scrum have some good things going for them.

They teach developers that building things is always an iterative process. A
well designed product will still require incremental on-the-fly improvements
to get it right just as code does. Sometimes a design will require a refactor
just as code does. Needing a 'complete' design doc before building a product
is a fallacy.

They teach project managers that if they just let the designers and developers
get on with it they can usually self-organise and manage their time better
than if done top-down by a non-technical outsider.

They teach producers and 'product owners' that constant interference can be
detrimental to a production process. Developers should be allowed to develop.

Best of all if done right they allow everyone scope to make mistakes yet still
fix them and good mistakes that they can try out and keep.

However, there are downsides: scrum has no role for designers in the day-to-
day production. Either they are pushed to the role of product manager or they
have to work independently a sprint ahead. An ideal system would put the
designers into the heart of the scrum team.

Top-down scrum is where it all goes badly wrong: producers and managers
insisting that designs are complete before a line of code is created, managers
taking the role of scrum-master, sprints being nothing more than waterfall
milestones etc.

------
creigh
Let me say this. I have found scrum in particular to be used as a management
tool (report back tool), and not a developer tool. It doesn't matter where i
go. It starts with the greatest of intentions, and ends up where management
are sticking there fingers in the pie half way through. And by that I mean
they don't use priorities on the backlog to manage the process. They use the
standup meetings as a moan session when things don't go there way. To me scrum
in its purest form is where the developer drives the process. Most projects
will perform better if they just let them do that.

~~~
rbanffy
Agile _is_ a management tool. It helps manage developer time, feature bloat,
organizational blocks, communication overheads and user expectations. It also
helps you measure performance and identify bottlenecks in your own process.
Like other comment said, it helps getting a couple things done instead of
having a huge pile of stuff half done.

~~~
creigh
Look at what Agile is promising to fix. The development process not the
management process. Semantics aside, I like everything you said, except to say
that either the line manager is doing those things, or 'it' (scrum) is doing
those things.

~~~
rbanffy
Managing the things I mentioned fixes a lot of problems common to broken
development processes. [Insert your agile method here] provides a useful
framework upon which to build a working development process.

------
peteretep
This is a terrible, polemic and content-free post. Please stop submitting
stuff like this.

~~~
zedshaw
So is your comment, please stop making them.

------
rickmb
This kind of somewhat understandable but ultimately clueless ranting just
tells me one thing: no way in hell I'm ever going to trust a programmer who
cannot (or can not be bothered to) distinguish between marketing bullshit and
the real thing.

This kind of attitude will show up in other matters, most importantly
understanding what actually needs to be developed, what the priorities are and
why they are important.

I'm surprised how many people here seem to be ignorant of Agile. Take for
instance the certification scam accusation that is liberally thrown about:
only Scrum has certification, and even that has always been controversial. As
far as I know, no other Agile flavor tries to sell certification. But even so,
Red Hat sells certification, does that make Red Hat Linux a scam?

There are scammers and greedy consultants in every area of IT. None of that
has fuck all to do with Agile in particular. So why are people so hell bent on
using this against Agile?

------
roguecoder
How well a team works together depends on far more than how smart the
component engineers are. One clever engineer may be sufficient for a Suduku
problem, but it is a matter of scale. This fellow is basically arguing that we
don't need government because people get along just fine on their own. Which
is absolutely true on an individual scale, and not at all true as soon as two
people live next door to one another.

In my experience 90% of software problems are social problems. He seems to
care only about technical problems, and assumes those are solved by the magic
of intelligence. I believe that if you can not explain to someone else how to
do what you do, you aren't actually a master of your craft. Appeals to hire
smarter coders sound incredibly hollow unless they are accompanied by
techniques to make the average coder smarter.

There are much better critiques of Agile out there, mostly having to do with
how it has been sold. I'm not sure what he thinks he is contributing to the
discussion.

Any process can be harmful. It can also be incredibly useful, and the lack of
process is at least as harmful as process applied badly. I recommend the book
"The Checklist Manifestos" for examples. It proposes that the goal of process
is to handle routine complexity and make cooperation routine, leaving human
attention and effort free to focus on the actual hard problems.

------
bitwize
No. Process is important; it's necessary. There are at least two prongs to
this problem: one is you can't manage what you don't measure, and process
gives you a way of tracking functionality implemented, defects, defects
resolved, etc. There's nothing inherent to programming that gives your manager
or your team any sort of knowledge about how far along you are, or just as
importantly, when you will be done. You can hack all you like and -- even if
your code is visible to all -- there's no way of guessing how far along you
are, or if that needs-to-be-fixed-yesterday bug is close to resolution.

The other prong to this problem is you can't remember what you don't record.
Well, _you_ may have an eidetic memory, but unless the _company_ generates
deliverables besides code that explain what the code does or is supposed to
do, a change in team X years down the line may mean the company forgets why
Joe wrote the widget wrangler in the way that he did, and accordingly the
widget wrangling module becomes an unmaintainable black box. Generating these
deliverables is a part of the software process, whether Agile or otherwise.

And there will _always_ be a process. This arises simply as a consequence of
the fact that management needs to know how well you're doing, and if you're
performing in a cost-effective manner, to many decimal places of precision.
And if the process isn't agile, it could be something far less pleasant.

Agile Processes (big A) may sound scammy to you, like their proponents are
trying to sell back to you shit you already know. But you only know that shit
because you're a software developer. Management can't do what you do, and
they're the target audience of Agile Processes like Scrum and XP. It gives
them a ready-made Industry Best Practice that they can decide with confidence
to adopt company-wide, with little perceived risk because it's so proven and
widespread. Compare and contrast with the success of the "open source" meme in
convincing companies to adopt, and participate in, free software.

~~~
super_mario
No, it's even worse. You can't manage what you can't measure. And so far no
one has found a metric to measure creative output like painting, writing
poetry or writing software. Whatever metric you choose to measure and evaluate
your team, and esp. what ever metric you reward is going to lead your team
optimizing their performance for that metric.

You want to measure LOC, programmers WILL write more lines. Want to measure
and reward less defects, programmers WILL create less defects etc. But will
your software be sexy, appealing to users, creative, innovative, trend setting
solution to old/new problem?

~~~
SideburnsOfDoom
> And so far no one has found a metric to measure ... writing software

How about ...

* Number of new features delivered per week (and size of said features)

* Number of new users per week

* Number of page views per day

They're fuzzy metrics at best, but saying "writing software can't be measured"
is just defeatism. It's not fine art, it's not a Jackson Pollock painting,
it's a craft. It has utility. We can get a grasp on that. Even the pretty bits
are ultimately there to make it more useful to people.

~~~
super_mario
That's even more nebulous. Yes, those things are perfectly measurable, but how
do you translate x number of new users per week into code?

Isn't that what software development is all about. It's about collapsing this
cloud of uncertainty into concrete deterministic expression a.k.a code, which
only solves the problem as you understand it.

If software development were that measurable, software developers would be as
well paid as CEOs or sales people. But we are not. Because there is no way to
demonstrate almost any relationship between what we do on daily basis (stare
at screen and type on the keyboard as management often sees it) and sales and
revenue. Some places go as far as to think of their development organization
as overhead, a cost center.

------
vannevar
_Process is, actually, just tax. If you need to follow a prescribed process in
order to be in any way an effective coder then you are mediocre at best and so
is your work and your project._

Discipline is just a tax. If you need to structure and test your code, then
you're a mediocre coder at best, and so is your work and project. Just write
whatever you feel like, it'll turn out ok. You're awesome, how could you
possibly code anything less than exactly what the client wants?

Nonsense. Agile is a discipline, just like properly structuring your code and
testing it. It's discipline at a macro scale, on the team, rather than the
individual programmer. You might argue over whether its specific practices are
better or worse than other methods, but arguing against _any_ development
process at all is absurd.

------
lmkg
The problem with Agile development is the same problem that has affected many
modern revolutions: The revolution _against_ the current ruling class gets co-
opted _by_ the current ruling class[1]. The revolution then ends up changing
nothing more meaningful than the colors on the flag.

Agile was supposed to help developers escape the obstacles of poor management
and poor managers. It's really about developers owning the development of the
software, and being given more creative authority. Non-developers play a
support role, if they're present at all. That part is all fine and dandy, and
it's The Good Part® of agile. Let the guys who make software be responsible
for making software. Brilliant!

Managers, of course, don't want to get marginalized. If they see a movement
towards Agile, they would rather bring it in themselves, so that they can
control how it's implemented. And they implement it in a way that a) fits
their existing biases about software development b) doesn't marginalize
themselves[2]. Both of those goals are met by taking the agile process, and
turning into The Agile Process (engraved on stone tablets, up on a pedestal).

Agile should be _less process_ , but when the transition is implemented by
_process guys_ , it just ends up being _different process_ rather than less.
And naturally, the one role in agile that ex-managers can step into
(aforementioned support role) is more important in this set-up, because it's
about owning and managing the process. So the revolution happens, and nothing
changes. Instead of developers having more freedom, the old managers just have
a new title. That title still comes with the authority to make developers fall
in line, except that "in line" now refers to a different set-in-stone
collection of steps and rules.

tl;dr Meet the new boss, same as the old boss.

[1] I'd rather not derail this thread into history and politics so I'm
avoiding details.

[2] b) is actually a subset of a). One of management's existing biases is that
management and process is an important part of software development.

This isn't a knock of managers; everyone thinks the same about themselves.
Hell, Agile itself basically originates from developers having the same bias.
They just happen to be more correct ;).

------
benohear
"Agile is not a silver bullet" is more to the point, and applying it
dogmatically can counterproductive.

But regular communication, short, well defined sprints and a prioritized
backlog available to all can do wonders in terms of getting a small amount of
stuff done rather than a large amount half done.

~~~
crudolph
Agree with this 100%. Transparency and communication are key when you have
more than one or two people on a team.

------
PaulHoule
Well, agile and TDD (not necessarily together) are good for two kinds of
projects.

(1) If you're building simple web apps for small town clients in a framework
like RoR, you can break things into little tasks and estimate with laser-like
accuracy. This fits in great with an agile methodology

(2) If you're writing security-sensitive string parsing code or any algorithms
with tricky components, TDD is a big win. When I was in grad school I
converted a very slow program for solving a quantum system (worked for N=5)
into a very fast program (worked for N=64) by building very detailed test
scaffolding. I don't know if I could have built the fast but complicated app
without the tests.

Now, I've got another app where I almost want to use TDD but I'd wind up
building a whole Potempkin village of mock objects and I just can't bear the
line count I'd need to first write it all, find bugs in, and then maintain.

~~~
Xylakant
You're wrong on both accounts:

(1) Being able to estimate with laser-like accuracy is not part of what's
agile. Estimation is not part of the agile manifesto at all - Kanban for
example can be done without a single estimate. It just limits the number of
tasks that you have in parallel. Scrum on the other hand does deal with
estimates, but it mainly postulates that you can't estimate large chunks of
work at all and small chunks not necessarily correct. So there are all kinds
of observed correction metrics built in that help you to get a better estimate
- no one vouches for a correct one though.

(2) If you can't use TDD because you have to build a whole set of mock object
you might have a tightly coupled system. Writing a test is not dead line
count, it helps to formulate boundary conditions and expected behavior. It's
certainly not useful for all kinds of project but it's certainly not limited
to security sensitive or tricky algorithms. If the behavior is simple, then
the test is simple as well. If the behavior is complicated, then the test will
be as well - but at least you'll think about how it is supposed to be.

~~~
PaulHoule
My own "agile" process for certain kinds of development involves breaking down
all tasks to less than an hour and estimating time to 10 minute granularity
and planning on weekly releases.

For boring web apps built on the right framework I find this keeps everybody
very happy. Devs aren't chasing their tails, you can make and keep promises to
the client, etc.

Of course you've got to be building the kind of app where there aren't
surprises, but those exist.

As for the other project, the whole thing is a machine where you put a 600
million fact knowledge base in one end and it manufactures 'potempkin
villages' (little knowledge bubbles about particular domains w.r.t a point of
view) on the other end. Once it's done, I could use it to generate micro test
cases for the rest of the system, but in the short term that doesn't bring in
revenue or delight customers.

------
ilaksh
I dunno. In a way I think he is right in some ways in that most of the times
people say they are doing agile or scrum it is a sham and they are not really
doing agile and also it generally doesn't tell you much about how well they
work.

Also I think that process can very easily get in the way. I was actually
thinking maybe things would work better for small teams if you just handled
everything in a group chat room with a history like campfire.

But I still have hope that someday I'm actually going to use TDD for a project
and then have way fewer regressions to deal with. Still haven't had the
discipline I guess to really learn and apply TDD after all these years
although I have sort of done it a little a few times.

And also a few other things like short iterations and getting the simplest
useful software going which I always thought were part of agile, those things
help. Although it has always been a battle for me to get managers or even
users to stop adding features and do an initial release so I haven't been very
successful in that aspect.

I don't know if the quality the individuals on the team is everything but it
is a good point that it is probably more important than anything.

I also would really like to believe that having a real QA team as part of the
process would improve things, although I have never had that luxury either so
it may be a false hope. But that would be something in the process category.

------
elmomalmo
An agile process isn't just there to manage the developers, it's there to
engage and manage the customer as well.

In my experience, customers rarely know exactly what they want out of a
software project, large or small. Complicated documents, produced up front get
ignored because of TL;DR and projects start on faulty specifications that
describe a solution to illusory requirements. So, inevitably, there will be a
disparity between documented requirements and the desired outcome.

Iterative delivery - a key feature of agile as I have experienced it - gives
the customer multiple chances to try-out and feedback on working software
along the way. Furthermore, by making the customer part of the solution early
they are as instrumental as the implementers in ensuring the validity of the
software and - therefore - the success of the project.

Incidentally, I think this is why many customers (internal and external) are
suspicious of and hesitant to engage in a truly agile process. That is, they
would become equally liable for the success of the project because of the
decisions they are required to make. They are part of the solution and
therefore potentially party to the blame for any failures. It's much safer for
them to be more likely to fail and avoid the blame than it is to risk
complicity in a failure, however less likely that failure might be as a result
of the process.

What agile does that the author missed (or at least declined to mention) is
that it gives a name to and formalises an approach that attempts to manage the
customer as well as the implementers. It compensates for the fact that
customers can't always be expected to fully understand their own requirements
and for the inevitability that they change their minds.

------
DanielBMarkham
[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant
"Agile Ruined my Life" [http://www.whattofix.com/blog/archives/2010/09/agile-
ruined-...](http://www.whattofix.com/blog/archives/2010/09/agile-ruined-
my.php) Also I am writing some practical how-to Agile e-books trying to undo
some of the damage: <http://tiny-giant-books.com/scrummaster.htm> ]

Just differentiate between what Agile is and how people are pushing Agile on
you. Different things entirely.

Agile is best practices around iterative and incremental development. Period.
Yes, there's a manifesto and there's Scrum and all sorts of other things, but
at the end of the day Agile is a marketing term. A place to go find out what
people are trying in order to get better.

Two secrets here. One, team success is about 90% dependent on who is on the
team. Good teams do well. Bad teams do poorly. But if you're going to have
more than one team, you need some way to measure and talk about what they are
doing, so you have to have _something_.

Agile -- when done correctly -- is just the minimum amount of _something_ you
need to get your work done. It is the minimum amount of process. After all,
it's not like you can have no process at all. Whatever you're doing already is
a process.

I've seen hundreds of teams struggle with Agile, and to me the problem is that
we do a really bad job of balancing the difference between "here's a best
practice that worked awesome for about 80% of the teams that tried it" and
"These are the rules. You must do this." In many shops, Agile is just another
way of micro-managing teams, sadly.

I can't help that. I also can't help the fact that lots of folks are out to
make a buck on certifications and such. I don't think that makes Agile bad.
Heck, I'm not even against certifications, although I'd never get one. I just
think we take things too far.

I like the idea of having a marketing blurb "Agile" where I can go to find out
what kinds of new stuff is being done. It helps me pick better reading
material.

The second secret is that most teams, frankly, are not that good. So you need
some kind of way to demonstrate that as well. Making things incrementally and
in small iterations lets you see how bad teams are early on. You fail early
and often. Then at least you have a bit of a shot at trying to help.

But believe me, I feel your pain. Sounds to me like you are a lot more upset
at modern marketing and management attitudes than Agile. Remember that we
technical folks have a way of over-doing whatever we get into, as I was
writing in my blog before your post appeared! (It's still very strange to me
watching HN how the same topic comes from multiple writers at the same time)
[http://tiny-giant-books.com/blog/agile-means-stop-focusing-o...](http://tiny-
giant-books.com/blog/agile-means-stop-focusing-on-the-wrong-thing/)

~~~
wpietri
Exactly. And this shit makes me furious.

I got involved with this stuff before the term "Agile" existed. At the
beginning, it was a bunch of professionals (mostly developers) sincerely
trying to find better ways of working. Extreme Programming, for example, came
to be because the developers were really interested to experiment with how
their team got stuff done.

It breaks my heart that in the ensuing decade it has turned into exactly the
kind of bullshit, top-down, PHB-fluffing idiocy that early agilists were
trying to get away from. If you look at the Agile Manifesto, the focus is
supposed to be on a) people, b) shipping working software, c) collaboration,
and d) being adaptable. That is sure not what it has become.

In my view, we made a crucial mistake: we didn't think about money and power
enough. Now the Agile industry is 98% selling idiotic certifications and
homeopathic doses of process improvement to organizations that don't really
want to change anything at all.

Mad. It makes me mad. Sorry we screwed it up, everybody.

~~~
__abc
The only people that screwed it up are the ones that monetized it. They made
it

a) rigid based on their definition b) defined themselves as experts in making
teams agile based on their rigid definition c) charged for it

PS. These same guys, once they couldn't squeeze anymore blood out of the Agile
stone, moved onto a new marketing term, "craftsmanship". They now charge the
same clients, even more money, to teach them this "new way of doing it .....
right".

Plus, they make a mint on the books they hastily write and push out.

I eagerly anticipate that successor to Craftsmanship.

~~~
wpietri
Depends on who you're talking about here. Bob Martin one of the craftsmanship
people, is very sincere in his desire to make the field better. I'm not sure
about who's cropped up lately, though.

Also, it's very, very rare for somebody to make a mint on a software book.
I've talked with a number of authors, and their universal view is that writing
code pays much better than writing a book. You do it because you have
something to say, not because you want to get rich.

~~~
Silhouette
> Bob Martin one of the craftsmanship people, is very sincere in his desire to
> make the field better.

Unfortunately, you can be totally sincere in your good intentions, and yet
still repeatedly be wrong. When you are a high profile figure who presumes to
advise others on the best ways to do their job, that makes you a liability.

It's a shame. Some of Bob Martin's earlier work exploring OO and the SOLID
principles was quite decent stuff. But I think it's obvious at this point that
he and several of his colleagues at Object Mentor have collectively lost the
plot.

~~~
wpietri
Could be. I guess I'm not aware of the repeated wrongness on ObjectMentor's
part. Got links?

The big problems I saw, though, came from people who weren't particularly
sincere. They were happy to sell whatever large companies were buying. E.g.,
two-day "Scrum Master" courses and a splash of Agile holy water to bless
whatever top-down idiocy a company was already engaging in.

~~~
Silhouette
At this point, a comprehensive critique of Object Mentor would be more a case
of writing a book than posting a few links. However, in the interests of not
attacking them completely without justification:

\- Object Mentor are big advocates of XP. The _fundamental principle_ of XP is
that a certain practice is good, then doing more of it must be better. There
is no logic in that position at all, and it doesn't stand up to even cursory
criticism. Moreover, if XP is as superior to other processes as the typical
advocacy quotes and statistics imply, how come organisations using XP aren't
consistently reporting dramatically better measurable results and how come so
few software development groups have chosen to adopt it? Sooner or later,
people notice that the emperor has no clothes. (I suspect this is why we now
have Software Craftsmanship: it's a new positive-sounding but conveniently
meaningless marketing term to pitch to clients.)

\- Bob Martin has repeatedly stated that anyone who doesn't do TDD is
unprofessional. Safety-critical software is typically not developed using TDD;
in fact, formal methods, BUFD, and other very much not Agile processes are
often used in such fields.

\- Michael Feathers redefined the term "legacy code" in terms of unit tests.
There are decades of research studying what actually causes a project to decay
to the point that it is difficult to maintain and update. To my knowledge, a
lack of unit tests has not yet been cited as a causal factor by any paper on
the subject. (FWIW, I do think Feathers' book on the subject offered some
interesting and worthwhile ideas, I just don't accept his premise that having
unit tests is what defines whether code is legacy or not for practical
maintenance/project management purposes. I think when you try to co-opt an
ill-defined but commonly understood term and give it a formal definition that
is very different to the mainstream concept, you lose some credibility.)

\- Brett Schuchert, a man writing a book on C++, managed to make "Hello,
world" take five source files and a makefile totalling nearly 100 lines, using
TDD of course.

\- Ron Jeffries. Sudoku. Probably enough said. TDD is not an alternative to
understanding the problem and how you're going to solve it.

\- From a post on the Object Mentor blog, Brett Schuchert apparently advocates
pair programming based on a 1975 study of something involving two-person
teams, a ten-year-old study of university students, and a couple of links to
secondary sources. The original research for almost every one of the primary
sources he appeals to either directly or indirectly is no longer available at
the cited links less than 18 months later.

\- Bob Martin thinks there are no more new kinds of programming language left
to find. That's roughly on par with equating Haskell and Brainfuck because
they're both Turing complete, and shows a complete lack of awareness of the
state of the art.

\- When it comes to the amount of up-front design and formal architecture that
makes sense for a project, the amount of retconning in recent comments from
the TDD guys is laughable. There was a particular interview featuring Bob
Martin and Jim Coplien a couple of years back that was almost painful to
watch.

I could go on, but if that lot doesn't paint a clear enough picture for anyone
reading this, I don't have a powerful enough Kool-Aid antidote to help them.

I do agree with you about the insincerity. That's worse in theory, but
unfortunately it's probably no less damaging in practice.

Edit: Here are few links to support some of the points above.

<http://www.infoq.com/interviews/coplien-martin-tdd>

[http://skillsmatter.com/podcast/agile-testing/bobs-last-
lang...](http://skillsmatter.com/podcast/agile-testing/bobs-last-language)

[http://ravimohan.blogspot.co.uk/2007/04/learning-from-
sudoku...](http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-
solvers.html)

<http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp>

[http://blog.objectmentor.com/articles/2010/11/09/info-
please...](http://blog.objectmentor.com/articles/2010/11/09/info-please-tdd-
and-pair-programming)

~~~
wpietri
You start out with a giant misunderstanding, which makes it hard for me to
take the rest of your complaints seriously. Extreme Programming is not an
arbitrary desire to turn all the knobs you can find to 11. It started as a
question: what happens if we take certain practices that are good and do them
more intensely? E.g. if some testing is good, what if we test pretty much
everything?

That team found that they really liked turning particular practices way up.
But you can't turn all the knobs up, so you are implicitly turning others
down. E.g., if you turn up iteration speed, then you are turning down the sort
of heavyweight waterfall requirements process ubiquitous at the time.

So the "extreme" was a way to explore the space of possible processes, not any
sort of fundamental principle. Teams trying XP are explicitly encouraged to
experiment similarly. I sure have; the process we use is derived from XP but
departs from it in a number of areas.

I think a lot of the rest of your points are similar misunderstandings along
with some cherry picking. E.g., the OM blog post on pairing. He said that
people sometimes asked him for basic background materials, so he posted some
links. To go from that to "Brett Schuchert apparently advocates pair
programming based on.." is either very poor reading comprehension or the act
of somebody with an axe to grind.

As to not doing TDD being unprofessional, I'd generally agree. I tried TDD
first in 2001, and have worked on a number of code bases since. For any
significant code base that's meant to last and be maintainable, I think it's
irresponsible to not have a good unit test suite. I also think there's no more
efficient way to get a solid suite than TDD.

If you (or anybody) wants to discuss this further, probably better to email
me; that's easy to find from my profile.

~~~
Silhouette
_Extreme Programming is not an arbitrary desire to turn all the knobs you can
find to 11. It started as a question: what happens if we take certain
practices that are good and do them more intensely? E.g. if some testing is
good, what if we test pretty much everything? That team found that they really
liked turning particular practices way up._

Well, of course they're entitled to their opinion, but that's all it is: an
opinion. An argument that if some testing is good then test-driving everything
must be better, or that if code review is good then full-time review via pair
programming must be better, has no basis in logic. And those kinds of
arguments go right back to the original book by Kent Beck, and they have been
propagated by the XP consultancy crowd from the top right on down ever since.

IMHO, if a trainer is going to go around telling people that if they don't
program a certain way then they are _unprofessional_ , then that trainer had
better have rock solid empirical data to back up his position. Maybe as you
say, I do have a giant misunderstanding, and in fact Object Mentor do make
their case based on robust evidence rather than the sort of illogical
arguments I've mentioned. In that case, I assume you can cite plenty of
examples of this evidence-based approach in their published work, so we can
all see it for ourselves. Go ahead; I'll wait.

 _I think a lot of the rest of your points are similar misunderstandings along
with some cherry picking. E.g., the OM blog post on pairing. He said that
people sometimes asked him for basic background materials, so he posted some
links. To go from that to "Brett Schuchert apparently advocates pair
programming based on.." is either very poor reading comprehension or the act
of somebody with an axe to grind._

This is a consultant who presumes to tell others how to do their job, openly
posting asking for any source material from others to back up his
predetermined position, and then claiming in almost the very next sentence to
favour material based on research or experience. He says that the links he
gave (the ones where much of the original research is either clearly based on
flawed-at-best methodologies or simply not there at all any more) are things
he often cites. And he gives no indication, either in that post or anywhere
else that I have seen, of having any library of other links to reports of
properly conducted studies that support his position. I don't think criticism
based on this kind of post is cherry-picking at all, but of course if it is
then again you should have no difficulty citing lots of other material from
the same consultant that is of better quality and supported by more robust
evidence, to demonstrate how the post I picked on was an outlier.

The same goes for any of my other points. If you think I'm cherry-picking, all
you have to do to prove it is give a few other examples that refute my point
and show that the case I picked on was the exception and not the rule. If you
can't do that -- and whether or not you choose to continue the debate here,
_you_ know whether you can do that -- then I think you have to accept that I'm
not really cherry-picking at all.

 _As to not doing TDD being unprofessional, I'd generally agree. I tried TDD
first in 2001, and have worked on a number of code bases since. For any
significant code base that's meant to last and be maintainable, I think it's
irresponsible to not have a good unit test suite. I also think there's no more
efficient way to get a solid suite than TDD._

Please note that I'm not disputing that an automated unit test suite can be a
useful tool. On the contrary, in many contexts I think unit testing is
valuable, and I _have_ seen plenty of research that support such a conclusion
more widely than my inevitably limited personal experience.

On the other hand, I don't accept your premise about TDD. For one thing, TDD
implies a lot more than merely the creation of unit tests. Among other things,
I've worked on projects where bugs really could result in very bad things
happening. You don't build that sort of software by trial and error. You have
a very clear statement of requirements before you start, and you have a
rigorous change request process if those requirements need to be updated over
time. You might have formal models of your entire system, in which case you
analyse your requirements and determine how to meet them at that level before
you even start writing code. At the very least, you probably have your data
structures and algorithms worked out in advance, and you get them peer
reviewed, possibly by several reviewers looking from different perspectives.
Your quality processes probably do involve some sort of formal code review
and/or active walkthrough after the code is done, too.

If you came into an environment like that, and claimed that the only
"professional" thing to do was to skip all that formal specification and up-
front design and systematic modelling and structured peer review, and instead
to make up a few test cases as you went along and trust that your code was OK
as long as it passed them all, you would be laughed out of the building five
minutes later. If you suggested that working in real time with one other
developer was a substitute for independent peer review at a distance, they'd
just chuck you right out the window to save time.

TDD is not an alternative to understanding the underlying problem you're
trying to solve and knowing how to solve it. A test suite is not a substitute
for a specification. Pair programming is not a substitute for formal peer
review. They never have been, and they never can be.

I haven't gone into it here, but of course there are other areas where TDD
simply doesn't work either. Unit testing is at its best when you're working
with pure code and discrete inputs and outputs. It's much harder to TDD an
algorithm with a continuous input and/or output space. Tell me, how would you
test-drive a medical rendering system, which accepts data from a scanner and
is required to display a 3D visualisation of parts of a human body based on
the readings? Even if this particular example weren't potentially safety-
critical, how would you even start to test-drive code where the input consists
of thousands of data points, the processing consists of running complex
algorithms to compute many more pieces of data, and the observable output is a
visualisation of that computed data that varies in real time as the operator
moves their "camera" around?

 _If you (or anybody) wants to discuss this further, probably better to email
me; that's easy to find from my profile._

I appreciate the offer, but I prefer to keep debates that start on a public
forum out in the open. That way everyone reading can examine any evidence
provided for themselves and draw their own conclusions about which positions
stand up to scrutiny.

~~~
wpietri
_An argument that if some testing is good then test-driving everything must be
better, or that if code review is good then full-time review via pair
programming must be better, has no basis in logic._

That's not the argument at all. That is, as I just said, the reason they
decided to _try_ that. Their reasons for continuing to do it and further to
recommend it are entirely different.

 _[...] better have rock solid empirical data [...]_

You do realize that almost everything that goes on in the industry is not
based on rock-solid empirical evidence, right? And also, that you're
privileging an arbitrary historical accident by saying that new thing X has to
have evidence when the common practice doesn't?

 _If you came into an environment like that, and only "professional" thing to
do was to [...] make up a few test cases as you went along and trust that your
code was OK [...]_

That is not something I have ever heard any Object Mentor person say, and it's
not something I said. It's so far from what I've ever heard somebody like Bob
Martin or Kent Beck say that your misunderstanding is so dramatic that I have
a hard time believing it's not willful.

 _I prefer to keep debates that start on a public forum out in the open._

Well, I'm not trying to have a debate. If you'd like to have one, you'll have
to do it without me.

~~~
Silhouette
_Their reasons for continuing to do it and further to recommend it are
entirely different._

So you keep saying. The problem is, almost everything Object Mentor advocate
does seem to be based on some combination of their personal experience and
pure faith. I object to someone telling me that my colleagues and I are
"unprofessional" because we happen to believe differently, particularly when
we _do_ have measurable data that shows our performance is significantly
better than the industry average.

 _You do realize that almost everything that goes on in the industry is not
based on rock-solid empirical evidence, right?_

That may be so, but most people in the industry aren't telling me how to do my
job, and insulting me for not believing the same things they do.

 _That is not something I have ever heard any Object Mentor person say, and
it's not something I said._

Good for you. XP consultants have been making essentially that argument, in
public, for many years. TDD without any planning ahead is inherently a trial-
and-error approach, which fails spectacularly in the absence of understanding
as Jeffries so wonderfully demonstrated. Plenty of consultants -- including
some of those from Object Mentor -- have given various arbitrary amounts of
time they think you should spend on forward planning before you dive into TDD
and writing real code, and often those periods have been as short as half an
hour. You may choose not to believe that if you wish. I'm not sure even they
really believe it any more, as they've backpeddled and weasel-worded and
retconned that whole issue repeatedly in their recent work. But I've read the
articles and watched the videos and sat in the conference presentations and
heard them make an argument with literally no more substance than what I wrote
there.

You keep saying that I'm misunderstanding or cherry-picking evidence. Perhaps
that is so and I really am missing something important in this whole
discussion. However, as far as I can see, throughout this entire thread you
haven't actually provided a single counterexample or alternative
interpretation of the advice that consultants like those at Object Mentor
routinely and publicly give. You're just saying I'm wrong, because, and
there's not really anything I can say to answer that.

~~~
wpietri
That's because you're trying to have a debate with the Object Mentor guys
rather than a discussion with me. Your problem with them isn't my problem, and
neither are your misunderstandings. It is not my job to argue you into a
better understanding of something you clearly can't stand.

------
kevinpet
Just because something doesn't have a name and isn't written down anywhere
doesn't mean it doesn't exist. If you don't like agile, it doesn't mean you
have no process. It just means you are following another process. Assuming you
have a project that actually involves interacting with multiple programmers,
your ability to interact with them is a key part of getting the job done.

If you're a lone cowboy doing it all alone, then good for you, but please
state that upfront in your blog posts about how the software world is doing it
wrong so we know you are evaluating things from a very unusual position.

If you aren't a sole programmer, then you've got a process. Maybe it's better
than agile processes. If so, please, tell us what that process it.

This whole article reads like a racecar driver dismissing automotive
technology because the only thing that matters is the skill of the driver.

------
mattdeboard
The world is full of mediocre programmers, and in each cluster of mediocre
programmers you'll find that they're surrounding much better programmers.

Ergo, since mediocre programmers exist, agile isn't a sham, and is necessary.
QED

~~~
hack_edu
The notion that some 'good,' 'quality,' or 'talented' programmer is somehow
entirely autonomous is entirely a fallacy. I'd trust a team of 'mediocre'
programmers that follow process and get it done than place blind trust in a
couple cowboys or post-docs who have some claim to genius in a prior life.

Sure, some are better than others. But to those who somehow believe that Great
Programmers can do anything, get over yourselves. They (read: you) probably
aren't nearly as good as you think.

~~~
mattdeboard
So aggressive! I'll be the first to proudly proclaim that I know practically
nothing, and am a terrible programmer. But I'm not mediocre. Mediocrity ==
doesn't know how to ask questions, decompose problems, troubleshoot or
research. Calm down bud.

------
gnaffle
Relevant article: <http://www.joelonsoftware.com/articles/fog0000000024.html>

Of course, you need process if you really want to consistently create defect-
free software: <http://www.fastcompany.com/magazine/06/writestuff.html>

------
shadowmint
Direct quote: "Process is, actually, just tax. If you need to follow a
prescribed process in order to be in any way an effective coder then you are
mediocre at best and so is your work and your project."

No.

Read some history; you'll see the same arguments back years ago about
processes being stupid then (80's, 90's) too.

I'm willing to accept that perhaps Agile isn't a perfect process, and that
agile projects don't always work out.

However, process just means that you have a repeatable set of steps for
generating a repeatable outcome. It's an absolutely vital part of every
industry, from manufacturing to farming to, yes, programming.

Everything is a process; TDD is process, writing a plan for your code is
process, hell, even just sitting down and hacking away and keeping everything
you need in your head is a process.

When you have a team that is larger than one person, organizing that team
relies on having expectations from each group in the team, and from each
person in the group. That's _formalized_ process, and that's what agile is.

Summary: Opinion piece, unsubstantiated, no background context. Bleh.

------
talkingtab
Thinking is hard. It seems like the cycle is a) someone thinks b) people
follow without thinking c) someone realizes that unthinkingly following some
process doesn't work so they debunk the theory without thinking.

So the question you have to ask yourself before you participate in b) or c) is
do you have any idea _why_ or _how_ agile is supposed to help?

------
nefasti
Just wasted 5 minutes of my life reading this. save your time. Just a rant
with no direct point or constructive thinking.

------
marknutter
I view Agile the same way I do P90X, which if you swapped one term for the
other this post would probably be just as valid. Yet, I use P90X and get good
results. Is it dependent on my motivation and physical abilities? Yes, of
course. Will it help an unmotivated person become fit? No, of course not. But
what it does give some people is a road map to follow and a process for
following it. Much like Agile does.

My team is using Agile and it's effective. It's not a silver bullet, but it
keeps us on the same page for the most part and it gives the business team
goal posts for getting features designed and queued up. If us developers
sucked, it probably wouldn't help that. But since we're all decent, motivated
workers, it has been going pretty well.

So is Agile a sham? Sure, whatever. So is P90X. I'll keep using both, thanks.

------
fredwu
I disagree with the author's opinion on processes, and I have put some of my
thoughts in a separate entry here:
<http://news.ycombinator.com/item?id=3765693>

------
guynamedloren
_See, the thing is, the success of the coding-part of a project is dependent
on the calibre of the engineers doing that coding and not the process they
follow.

The success of the non-coding part of a project is dependent on the calibre of
your sales/management and how they interact with the customer. If you are
trying to prescribe some rigid process, however lean, in order to make that
interaction effective, then you have a customer interface problem and process
isn’t going to help it._

Couldn't agree more. The only thing I'd like to add is that there also must be
a solid interface between sales/management and engineers.

Thanks for this.

~~~
vannevar
_[T]he success of the coding-part of a project is dependent on the calibre of
the engineers doing that coding and not the process they follow._

And the success of an NFL team has nothing to do with process either. It's all
the players. That's why they never hold practices or review footage with the
coaches. Who needs set plays? Tom Brady just tells Wes Welker to go deep and
get open. You guys up front block. That's it. Super Bowl. Process is for
losers.

~~~
guynamedloren
Programming != football.

~~~
vannevar
True, but the argument in favor of process applies equally well to both.

------
Aloisius
I've been using scrum for about ten years at several companies. Each time I do
it, I explain to everyone that the process has nothing to do with getting
people to be more efficient or work harder. It has everything to do with
helping me estimate when stuff will get done so that I can let all the
dependent parts of the company know well ahead of time.

If the work being done doesn't get re-prioritized, I can pretty accurately
judge about 3 months out and very accurately judge a month out. That lets the
rest of the company plan fundraising, PR, sales, etc.

This is where I disagree with the author. You do get fairly predictable output
out of a group of engineers _regardless_ of their ability as long as they are
consistent in their estimates for how long something will take (it doesn't
matter if they over or underestimate, just that they do it consistently). You
just won't like the results if they are mediocre.

I really want to stress how important the whole self-learning and re-
adjustment part of the process is (if someone doesn't scream at least once
during a retrospective, they're probably just going through the motions.)
While I've run "scrum" for 10 years, the details of how each worked were
pretty different depending on the teams involved.

That said, I tend to hire self-managing, self-learning engineers which scrum
works beautifully for. I also am completely comfortable with delegating away
large amounts of authority especially given the type of people I hire.

------
davesims
Must be Wednesday.

TODO next week: Go collect all of the blog post cycles of "Agile Sucks" ->
"No, agile in theory is fine, it's just marketing and implementation that
sucks."

It's a full-fledged meme at this point. And I think if you distilled all of
these posts down to their essence, you'd have a really solid critique and we
could build some lessons learned, and the next time someone gets burned by a
bad implementation of s/Agile|XP|Scrum/ maybe the narrative will change a bit
from "Agile sucks" to something more productive, something closer to "there's
that Agile execution thing again, and here's what I did about it."

Everything OP says is true, Agile is misapplied, overmarketed and badly
executed, and much suffering in the name of "Agile" has happened.

But we need to change the story now. This same cycle of "sucks" -> "yeah but"
is generating more heat than light. Time to reset and redirect our
expectations to something productive.

"In time there will be a new movement which paints Agile as broken,
inefficient and bad and we’ll get a new brand. That’s the kind of iterative
development I’m looking forward to; a new target for our collective disdain
;)"

Here we've hit on something. On common refrain in anti-Agile screeds is "Meet
the new boss, same as the old boss." And it's true, but instead of cynically
setting us up for some other jaded iteration of Good Process Idea -> Marketing
Scam/Bad Implementation -> Backlash, let's distill the lessons learned into
something a little more focused and circumspect.

Let's not cycle through this again, please. Let's set Agile in its proper
place, good stuff, bad stuff, the whole thing. And let's tell the right story
that might help us stop looking to things like Agile as the One Best Way to do
software and see it as the limited tool it is, dependent on many other
concerns, such as quality of developer, product focus, political environment,
etc. Agile was a great insight in its time, and I think the time is come for a
large-scale retrospective by the community to state the lessons learned.

One iteration I would really like to see end is "Agile Sucks" -> "But Not
Really". Time to move on to the next level, one that acknowledges Agile's
failings but doesn't involve a wholesale scrapping of Agile's important
insights.

~~~
willvarfar
(blog author)

+1

~~~
davesims
Nice, thanks William.

------
darylteo
I like to say to people:

"Software Engineering is an attempt of turning an art into science".

Let's be honest. Software development is an art form. Just like people form
groups from quartets to orchestras to make music, so do people form groups of
differing skillsets to develop software.

That doesn't mean an art is shooting from the hip. There is still tons of
practice to be done, and the various skill levels of each individual
determines the possibility for success.

The problem, then, is that there are not enough Bubles, Joshua Bells,
Ashkenazys, etc. around to make all the software in the world. Most companies
have to make do with large concentrations of amateurs led by the occasional
Bieber/Gaga.

So what are all these processes then? They're essentially what companies wish
to use to artificially increase their chances of success... However,
manufacturing art leads to potential stagnation and also the possibility that
every project that follows the same process have the same flaws (like how all
pop music nowadays all sound the same).

Sadly, it'll take an extremely brave company to get artists to develop their
software nowadays. Nowadays, the artists stick to developing their own
products =)

~~~
brazzy
Let's be honest. Software development is _not_ an art form. That's pretentious
bullshit. It may have some creative aspects, but far fewer than it has aspects
of craft and, yes, engineering.

~~~
darylteo
To each his own =)

------
kevindmorgan
Maybe you should go and read this again: <http://agilemanifesto.org/>

------
drewolson
_A fun anecdote is to consider the belief the TDD crowd entertained that, by
creating tests for a problem you couldn’t solve, you could somehow evolve a
code that passed the tests and therefore solved the problem!_

I'm all for a healthy debate of TDD, but the above statement seems ridiculous
to me. For me, TDD helps with two main things:

\- I specify the behavior I'm adding/changing before I implement it. This
helps document the change I believe I'm making.

\- I feel more confident when making changes to a large codebase.

TDD works for some and not for others. There are very interesting arguments to
be had about the subject. However, can we please stop acting as though TDD
advocates view their tests as having psuedo-mystical powers to solve problems
automatically?

------
pbiggar
Well, yes and no, but mostly no.

Looking at the collection of things that people refer to as "Agile", some of
the practices work for certain teams at certain times. Saying "its all a sham"
is as much bullshit as calling Agile a silver bullet that will solve all your
woes. (Just because it's not one extreme, doesn't put it at the other).

The OP calls out two practices, Scrum and TDD. I've tried "Scrum" at 3
different places, where by "Scrum" they meant "have a stand up meeting". Never
worked. For that project!

However, TDD has actually been a silver bullet __for some tasks __. And on
other tasks it killed my productivity.

Basically, stop thinking there are silver bullets, and figure out what works
for your team and project.

------
jonstjohn
We use agile at my company w/ about 15 employees. We introduced it about two
years ago to help focus our development process. Although I know there are
some issues with agile, we've fully embraced agile by modifying our process
along the way to suit our style. It has worked really well and I wouldn't
change it for anything else right now. Does it produce high quality software?
I agree that depends on the engineers, but it does produce a predictable
process that we all are on board with. That's huge in my eyes.

------
neeleshs
To me, agile is essentially common sense. sprints, story cards,scrums are not
nonsense, but discipline. I don't care what these are called, but they have
served as a good set of tools to bring in discipline to the team. It helps a
lot, when your team is not full of self-driven, talented developers. While
that may point to an issue in hiring, we all know how difficult it is to hire
and retail such people.

------
Uchikoma
Not sure where the poster comes from.

(The poster seems to confuse Agile in "Agile is a Sham" and the Agile
"industry". I can't talk about the Agile "industry" as I'm no part of it or
have no contact to it, so I will concentrate on the "Agile is a Sham" part)

After introducing Agile/Scrum in 3 companies over the last 10 years, not as a
consultant but as a permanent employee, I'd think it has been a success three
times. Measuring success with two metrics: Predictable, ongoing results and
developer happiness.

Developer happiness in agile usually comes from calming down the fury of
requirements and wished for features. Sprints do enable developers to focus
for 2-3 weeks on one topic instead of being pushed to the most urgent topic of
the day by management. Happiness also comes from communicating and working and
feeling as a team.

I assume the poster has - if he has - a different agile experience. Perhaps
he's not a team person or uncomfortable with coordinating and working with
others. 10% of the developers I've worked with just don't feel right with
agile, it's not their thing. They should not try to adapt to agile from my
experience, as it does not work. Better to find a non agile environment that
does work for them.

From asking developers after agile introductions we had >90% approval rates on
the question "Would you like to go back before agile?" and "Would you like to
have a different development model?"

Scrum in particular is different from, e.g. XP. It focuses on process and -
deliberately - says nothing about engineering practices or craftmanship.
Coders are free to chose those for themselves. Some struggle on this or think
they don't need to have them just because Scrum doesn't prescribe those. Some
think Scrum is sh* as it does not talk about engineering practices or
developer quality. But this is intentional.

Scrum will not make development "work" with bad developers. But it will make
good developers work smoother together and make them - if they are team people
- more happy from my experience.

One final note: Some people here agree that Agile is a Sham and does not work,
then citing examples of managers/scrum masters that deliberately did not
follow Scrum. Following Aristotelian logic at least this does not make sense.

A final final note: I got a very fine and tasty chocolate cake from my current
team for birthday, so I might not be doing things that wrong ;-)

------
helmut_hed
Agile may well be a sham, but this statement:

 _the success of the coding-part of a project is dependent on the calibre of
the engineers doing that coding and not the process they follow._

seems to me obviously untrue, for >3 engineers, and the larger that count
gets, the more process you need. As an engineer I find that statement very
appealing, but experience suggests it's off base.

------
damian2000
"thats SCRUM and TDD and all the rest; it is all those new ways of managing
development projects"

TDD is a style of developing and nothing to do with management. Anyone who has
worked on something more than a trivial size app knows how useful having a
decent set of automated unit tests are. Anyone who dismisses this as a
"management scam" is fooling only themself.

~~~
willvarfar
I'm glad you parsed the first line... now please read the rest of the article
;)

------
super_mario
That should be clear to anyone that has even a little mathematical/computer
science training.

Anyone that says you can follow some process to ensure success is effectively
telling you they have implemented artificial intelligence that simulates a
production line designer and to be able to do it by using humans pushing bits
of paper around as their computer.

~~~
peteretep
> Anyone that says you can follow some process to ensure success

I'm going to argue this on both of its implications.

Firstly: Agile is not about ensuring success. It's about greatly increasing
the chances of success, and minimizing failure from fallout. No amount of
process will rescue you from truly dreadful technical team, but so what?
Plenty of processes will almost guarantee failure with the best tech team and
will in the world.

I'm going to go for the assumption that you knew that already, though, and are
attacking the idea that a management-related solution can help in the solving
of technical-related problems.

Take a look at a modern hospital, and you will see layer upon layer of
'management' solutions to support medical problems. Prescriptions are checked
by the doctor, checked by the pharmacist, and then checked by the nurse. Do
hospitals throw these rules away with sufficiently good doctors? No. Do
hospitals do this because they think their doctors are shit? No.

Agile can be a highly effective management solution for supporting technical
development. I know this because it has been for me, on many occasions, with
many different teams, in many different settings. I've also seen it badly
implemented to the point where it's an impediment to teams, but ... so what?
That's a risk with any process.

~~~
super_mario
Agile and other processes go much much further than your contrived example of
checks and balances in a typical hospital. It would be like hospital directly
interfering into the daily doctor/patient interaction or say stipulating that
no surgery can be longer than 2 hours. You want to do 9 hour heart transplant
surgery. Sorry, can't do that. Break it up into 2 hour chunks and measure
progress after each to make sure you are going in the right direction.

This is why agile is like religion. It is so vague and so thinly disguised
into general meaningless correct sounding "principles" that it can be anything
to anyone.

~~~
Xylakant
You're messing up agile and Scrum. Scrum has the restriction that every task
has to fit within a single iteration. And even with scrum, that limit is self-
proscribed. If you regularly have tasks that dont fit in a single iteration
and you can't cut those down to smaller tasks then you're free to choose
longer iterations. Scrum just says "make iterations, measure progress during
iterations to get an estimate how much you can fit in the next." It's like
doctors measuring how long they usually need for heart transplant surgery and
applying that knowledge to the operations plan for the next week. I'm sure
they do. And I'm sure they limit the time they have in the operation room and
won't schedule a non-critical long operation at the end of a packed day. (I
actually dated a doctor for 6 years and they surely did - apart from working
tons of overtime and other unsensible things)

~~~
super_mario
I'm not really confusing the two, I know perfectly well the distinction.
However, agile is usually sold exactly like that, as a solution that will
improve/solve problems.

Generally, few teams in any organization have so much autonomy to choose their
own process. If they did and they decided on their own to do some kind of
agile, so be it. But agile is usually imposed externally (because it's in
currently) but so is any other process. By the way I'm not criticizing agile
per se, I'm criticizing the idea of process as solution.

~~~
Xylakant
But then your issue is not with "agile" or "scrum", it's about how people
abuse the notion of agile or scrum. It's the same with every other tool,
programming language or process. They get abused by people pushing their
agenda.

I've seen organizations that started calling their lack of planning "scrum"
because that sounded better than saying "d'oh we just make up our mind on what
to do every couple of days." But that's not scrum or agile and it's not the
fault of people applying or promoting proper agile techniques.

------
driverdan
This quote summarizes how terrible the article is:

> If you need to follow a prescribed process in order to be in any way an
> effective coder then you are mediocre at best and so is your work and your
> project.

------
huherto
I try to emphasize the agile principles. I think there is a lot of wisdom
there. The most important: "Continuous attention to technical excellence and
good design enhances agility"

------
fredwu
This blog post offends me a little bit. The post screams hey, I am a cowboy
programmer, and it almost implies that if you employ processes then you are
stupid.

In this day and age, I would have thought finding the right tool for the right
job is common sense. Apparently not.

Agile, among many other things, is not a silver bullet - it never was and it
never will be. The key thing is to experiment and find what works for you,
your team and your company. Most software projects are done in a team
environment - putting a bunch of talented developers and designers together
actually isn’t as simple as many seem to think. One example is right out of
that original blog post:

> Given that I am not a fan of prescribed process as the solution to our
> problems, you can infer my opinion of the general quality and effectiveness
> of those programmers who teach these courses.

From that attitude, I can already see that he is an interesting developer to
manage.

A team needs to function efficiently as a team. Having one or two ace
developers aren’t going to help a lot if they can’t get along with the others.

Not to mention that people have spent time and effort proving that techniques
such as TDD work for certain projects [1].

As many things in life, there are always people who try to take advantage of
others. No doubt there are questionable ‘agile consultants’ who try to make a
fortune out of uninformed clients. Just because some people aren’t using agile
effectively or even correctly, doesn’t mean agile itself is a sham. Developers
constantly make mistakes and write shitty code - should we say all the
programming languages out there are a sham?

Keep an open mind is important, and a lot of times even necessary. To dismiss
agile all together is in my opinion childish, and offensive to others who try
to improve things and create more value.

[1] [http://research.microsoft.com/en-
us/news/features/nagappan-1...](http://research.microsoft.com/en-
us/news/features/nagappan-100609.aspx)

Originally posted at <http://fredwu.me/post/20058808238/agile-is-not-a-sham>

------
rduchnik
"buzzword-compliant" that's a good one...lol

------
mkramlich
I do think think that there's a combo of simple techniques and rules of thumb,
that, taken together, yield better results, with less ceremony, than Agile.
And certainly far better than Waterfall, in the general case.

That combo (in my judgement) includes: iterative development, risk-driven
prioritization, KISS/YAGNI, note-taking, scripted automation, CLI bias, FOSS,
backups, version control and RDD (README-driven development). And several
more, but these are among the biggest.

Because you don't necessarily need tests. You don't necessarily need pairs.
You don't necessary need cards, or standup meetings. You don't need big
upfront design. But you do need to produce working code. You should provide
enough documentation to help you remember how things work and why, and bring
new team members up to speed and/or project inheritors, and you _ought_ to be
flushing out assumptions or minimizing your biggest risks as early as you can,
when there's still the most time to fix things, workaround, or abandon an
approach entirely. These are rock solid, universal patterns I've seen over the
decades. And they apply to small projects and large. Solo rockstars, small
teams, large, etc. Independent of tech mix and software types.

And yes, ultimately the quality of people you have is the most important. They
drive everything else: the choice of technology, tools, architecture,
prioritization, morale, pace, resilience, etc.

