
Agile Ruined My Life - DanielBMarkham
http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php
======
Raphael_Amiard
As a young software developper, what really bores me with Agile, is the name,
the shiny box you put things into, where it should just be named "Good
practices for software developement". It's the mentality of selling things as
products, with some kind of prebuilt ideology and aesthetic built along with
the core, that really makes me run far far away.

I don't want to be sold a product. The fact that it led people to try new ways
of developping software, be it TDD or pair programming or whatever, is good,
but heck, just give me the core idea, remove the gift wrap, and go away. I
don't want nor need some kind of new age manager coach.

Anyway, the article seems to be making this very point in some way, but then,
why the name agile ? Well for marketing of course. So, while i sort of agree
with the article, well i'll just be far away looking, thanks.

~~~
bitwize
Eric S. Raymond accurately characterized Agile when he described it as
repackaging the things hackers do anyway, in a way that can be sold to non-
hackers.

Maybe you don't want to be sold a product. You're not the target audience for
Agile Methodology(tm). The MBA and Tim Robbins crowd are.

~~~
joe_the_user
The problem is it is _packaging_ some of the things hackers do anyway.

When it's just something you do, it's fairly easy to see when it is or isn't
appropriate to do.

When it's a package, it's invitation/excuse or requirement to always do it
that way. And as the gp says, that's a problem.

------
lionhearted
Hey Daniel,

Some of your advertising is running a little haywire on you.

> My cousin called me up and was telling me about all the weight he's lost on
> this strange new diet. He was really excited. So I dug around and found the
> link to share: Dr. Siegal's Cookie Diet - More than 500,000 people have used
> his cookies to lose weight. Now it's your turn! This page contains a single
> entry by DanielBMarkham published on September 7, 2010 9:42 AM.

You might want to block that ad manually or change providers. Don't know how
much cash that's bringing in, but would you be eligible for something classier
like TheDeck ads? Seems you've got the right market.

Took a screenshot for you, can be seen here:

<http://awesomescreenshot.com/09113hrc2>

~~~
DanielBMarkham
Thanks. I'll fix that.

Geesh.

------
dkarl
Scrum consultants stay way past their usefulness, turning into self-
aggrandizing organizational vampires.

I think there's something to be said for Scrum, and I think the shock therapy
of a period of wholesale dogmatic adoption is the best way to start, with
gradual backoff from Scrum dogma only after you appreciate the Scrum way, but
goddammit you need to KICK THE CONSULTANTS OUT a few months after adoption and
not let them set up camp inside your organization, playing politics to extend
their gig as long as possible. The Scrum consultants in my company have been
here almost a year. We know Scrum now. They still don't understand much about
our business or our systems. Why are they here? Why do I keep hearing
"<vampire redacted> says I can't do that," when <vampire redacted> is just a
freaking process consultant who reports to a peer of your boss's boss? Why do
we let them have that kind of power, when they only exercise it to pretend
they still have something to teach us so we will keep paying them?

Also, the ScrumMaster role attracts the wrong kind of people. It attracts
people who want power and want to be important. The desire for power conflicts
VERY BADLY with being a good ScrumMaster, much worse than being a developer or
manager or any other job I can think of. ScrumMaster is a simple role
requiring only a little more process expertise than the chicken or pig roles.
A ScrumMaster is a meeting facilitator. A ScrumMaster has no authority and no
ninja skills. Being a ScrumMaster is like being the guy who can fix the
printer. Having good ScrumMasters is very, very important, but they are not
Important People. Does that make sense? They are not managers. People outside
a Scrum team should not treat the ScrumMaster as a decision-maker or the
proper conduit of information into the team. Bad ScrumMasters exploit those
habits to aggrandize themselves and try to boss around their teams. Then they
have power without responsibility.

~~~
api
_"Scrum consultants stay way past their usefulness, turning into self-
aggrandizing organizational vampires."_

s/Scrum/Management

FTFY.

~~~
SoftwareMaven
Do you _really_ believe an organization could function with no management? Can
you really not see the wholes that would create?

The programmer attitude of "All management is bad. I'm better than everybody
else in the company. I'm the only invaluable person in this organization."
gets really old.

EDIT: OK, as pointed out below, I'm an idiot (much nicer than my grouchy
post...). I do feel strongly about the anti-management stance, but that was
necessarily not what this reply was talking about. My apologies.

~~~
dkarl
If you do the substitution, you get "management consultants," not
"management." I think it's a valid statement. Business always needs
management, but management consultants are only good for helping a business
solve a particular problem or get through a particular change. Then they
should get out of the way. Instead, they work their way up somebody's butt and
sit there pulling checks, wielding unaccountable power that is inappropriate
for their place in the reporting structure.

It goes like this:

1\. People do what the consultants say because hey, you're supposed to be
learning from them. It makes sense.

2\. Some recalcitrant people refuse to go along with any changes, and upper
management puts out the word: "We're paying good money for these consultants.
On my authority, do what they say." This still makes sense.

3\. The consultants start meddling in things outside their original brief,
just because they think they're smart and want to prove it. People have to
live with it, so the consultants are gradually accepted as a generic part of
the power landscape. This is the beginning of the pathology.

4\. The consultants continue wielding power in a disruptive way as long as
they can, because if the organization doesn't need their constant correction,
somebody might realize it's time to get rid of them. This is the full-blown
pathology: consultants actively disrupting productive work because it's the
best way for them to stay employed.

~~~
SoftwareMaven
Ahh, you are absolutely correct. I jumped to my pre-existing stereotypes. Bad
me.

I actually have a negative opinion of most consultants (generally defined as
people who tell you what you should do). I feel much better about contractors
(defined as people who do what you tell them to do), but only in cases where
it isn't your primary business competency being contracted.

------
api
I'm not really anti-Agile, but I like seeing people question the crazy hype
around it.

Agile is really just a collection of mostly decent project management and
coding advice. It is absolutely not a silver bullet, and it's also not best
suited for every project.

There is no substitute for actual coding skill, and there is no substitute for
thinking about the specific demands of your specific project when deciding how
to manage it, how to prioritize things, etc. Every project is different.

To put it even more simply: you cannot substitute a "McMethodology" for
actually thinking.

------
seldo
The idea that "being agile" is a fixed process that you can write down and
teach to people seems to me to be a contradiction in terms. If you have to
train people how to do it, and have meetings about it, and read books about
it, how can you possibly be agile?

Actual agility is the ability to quickly adapt to changing circumstances. To
do that as a team you need trust, and great communication. No process can give
you either of those things if you've not got them, but a bad process can
certainly take them away.

------
maxawaytoolong
I'm convinced the main point of scrum is simply so that everyone has to be in
the office at 9 or 10 everyday.

~~~
ww520
Yes. There used to be a manager who would schedule a meeting at 10am everyday
with me to force me to come in. I was like fuck this, if I have to work until
11pm/midnight the previous night, I should have a little leeway in coming a
bit late the next morning. I don't want someone to babysit my time.

~~~
tjpick
> have to work until 11pm/midnight the previous night

?

Just don't do that then. In at 9, out at 5. No problem, life goes on.

~~~
ww520
Never work in a startup?

~~~
tjpick
What difference does that make to the price of cheese?

------
j_baker
You know, I'm really beginning to regard the "Agile is led by consultants who
don't know what they're doing" and "TDD is a crutch for beginners" crowds as
being like the Rush Limbaughs of programming. There's a grain of truth to
their points of view, but that's it: just a grain. They get their strength
just from being loud enough to make people notice.

To be fair though, I think of the Bob Martins out there as being like the
Keith Olbermanns of programming. Again, just a grain of truth but loud.

Die hard Haskell programmers get the distinction of being the Ron Pauls: hip,
opinionated, and doomed to an existence of never being taken seriously.

Can't we all just accept that different people work different ways rather than
being constantly at each others' throats?

(For the record, I'm not in any of these camps. In fact, I try to avoid
joining _any_ camps.)

~~~
tieTYT
"Can't we all just accept that different people work different ways rather
than being constantly at each others' throats?"

We could if we all worked on one-man projects where you are the only one that
reads the code that you write. The reality of the situation is, one day
someone else will need to understand and modify your code. If you're
inconsiderate about your coding style, then I would say, "No, I can't accept
that you work in a different way".

Furthermore, given the choice and all things being equal, I'd rather work on
the project that has a huge test suite than the one without it. From my
perspective, I'd say the programmer who wrote that test suite is the more
considerate programmer.

~~~
j_baker
"We could if we all worked on one-man projects where you are the only one that
reads the code that you write. The reality of the situation is, one day
someone else will need to understand and modify your code."

Please don't patronize me. I'm fully aware of the fact that I'm working on a
team of developers. They even work in the same room as I do.

Secondly, my argument is about 5 miles away from the argument you are arguing
against. I'm arguing about organizational issues. I'm not saying that any
developer needs to be able to be "incosiderate" all he wants (whatever that
means). Guess what? Some shops do well by being agile. Some shops do well by
not being agile. Some shops (if you can find them) do well by using Haskell.
And there are a ton of shops out there that don't. What I'm getting at is that
just because something didn't work for you in your particular situation
doesn't mean it's bad.

------
mikeryan
Here's how "Agile" has worked for me.

Start with a big list of features you wan to implement. Product Owner/Manager
keeps list in proper order of importance.

Every 2 weeks team gets in a room for 1 hour and marks off what they have done
and picks off what needs to be done for the next iteration - generally you try
to pick off less work then you think you can do. We'd let you pull in
additional work as the "iteration" went on - any extra work completed was a
bonus for the PM. Unlike traditional agile - we found that having QA and
bugfixes trailing dev by an iteration worked best.

repeat.

Now with this, and it really depends what you're working on, you can still do
"releases" every iteration if you want - but you don't have to (but to release
a feature it would take generally 2 iterations one for dev, one for
test/bugfixes). Generally we would only do daily standups if we're 1. Relying
heavily on an outside team. 2. Getting close to a release. Standups always had
to occur before 11am (usually at 10) as close to the start of the day as
possible.

I found this method worked great. It left the managers with the ability to do
some scheduling - w/o those effing "points" or "cupcakes" level of work
meetings - which created metrics that _no one used_. You still get
transparency and can release quickly as features get implemented.

~~~
bmelton
My experience is similar, but based more on Sprints and more frequent, shorter
meetings. We also utilized "Post-It Driven Development", meaning that all our
tasks were written on post-its, with an estimated time-to-completion (rough,
like 2 hours, 8 hours, 2 days, etc.)

We would meet for 10 minutes or less each morning, and each person would move
their post-its as necessary -- we had 4 columns, not started, started,
finished or roadblocked. Each day the post-its got moved over to where they
needed to go, and anybody who looked at the board could see exactly who was
working on what, how much work was remaining, how much work was completed, and
who was or wasn't doing a good job of time estimations.

New feature requests would be queued by the product manager until all of the
previous sprint's features were implemented (or delayed, or resolved in some
other way), and then we'd start over.

~~~
squidsoup
I've been doing "post-it driven development" on my own, using my monitor
bezel. It seems to work until the stickiness wears off and the task becomes
lost forever. Oh well.

------
autarch
I think there's a few key points to take away from Agile ...

1\. Involve end users (aka customers) in the process as much as possible,
since if they don't like the end result your work was wasted.

2\. Do work in small chunks. Releasing every 1-3 weeks gets changes out in
front of real users quickly. The shorter your cycle the less likely you are to
spend lots of time on something useless.

3\. Write tests!

The _specific_ details of any agile methodology are, IMO, less important. If
pair programming or TDD or stand-up meetings help you with those three points,
great. If not, don't do them.

------
rbranson
All of the "heavy" agiles like Scrum have confused me: isn't agile about
fundamentally less process and more flexibility? One can't serve two masters.
Teams have to pick a point along the completely structured - completely
flexible line. As far as I'm concerned, these flavors of agile are just wolves
in sheep's clothing that allow existing waterfall autocrats to continue their
reign under the guise of adopting "agile."

~~~
tieTYT
It's all relative. For example, the reason you have daily 15 minute meetings
is because lots of companies had daily 1+ hour meetings. I believe scrum
originated from trying to fix companies that were doing things unbelievably
bad. From that perspective, it's a lot less process than before.

------
hello_moto
I'm getting confused by most of you guys. Some of you said that there are
Agile consultants that would blame a failure because "you don't follow it by
the book".

First, follow what by the book?

Second, what book?

Third, don't confuse Process with Principles.

Organization failed implementing Agile because the people behind it are still
stubborn and still clinging to the old ways of doing things. Yes... this is
the reality in our field. We often say things like "IT, Computer, Internet
change the way we do things", please allow me to finish that sentence: "...
but just don't tell us to change how we build software".

Agile never talks about making software faster. They talk about delivering
business value and high-quality software. Even then, quality is defined by the
Client, not by the developers/engineers. Some clients were okay with small UI
glitches.

Scrum is a Project Management technique that uses a set of Agile techniques
behind it. In Scrum, after each Sprint, you should have a potential shippable
product. How can you have such situation without a good test-automation?
Manual test would work fine early on when the list of features are minimum,
but it doesn't scale. Remember, a Sprint is usually either a week or two. How
can you re-test the whole product every 2 weeks? Hire more QAs?

Developers these days pay lip-service when it comes to writing test-
automation. They'll dodge any tasks related to test. This happens because of
our university/education doesn't teach us that test is important. Testing is
usually a footnote in "Software Development" courses.

The reason why TDD is important is simple: people lie all the time. People are
lazy. That's a matter of fact. They would say "sure, my code is testable, we
don't have to write unit-tests now". By the time someone tried to write a
unit-test, you'll hear tons of excuses. Can't do.

Now, let's get to everybody's favorite part: Superstar Developer. Yes, they do
exist. No, they're not perfect, they'll make mistakes, they'll get sloppy,
their estimate went south, etc. Superstar developers write unit-tests. I don't
care if they do TDD or not, but at the end of the day, their code should be
testable from all angles.

Please understand that we are trying to get better in this industry. Developer
testing their own stuff is something quite relatively new. There are _plenty_
developers out there that allergic to testing.

------
extension
The lifecycle of software development fads:

phase 1: a few brilliant people come up with a brilliant idea and use it to do
brilliant work

phase 2: idea propogates as dogma, commercialized and exploited by hucksters,
causes mass cargo culting and holy wars

phase 3: everyone gets fed up, idea is nomitavely stigmatized while its most
useful aspects are quietly assimilated into the status quo

As it was with AI and OOP, so it shall be with Agile

------
efsavage
Agile/Scrum/whatever consultant engagements should be measured in hours, not
days or weeks. Do a workshop on TDD or optimizing your standups, but if a team
is being so badly mismanaged that full-time babysitting is neeeded, they need
to replace their management, not add to it.

------
jasona
Amen.

The greatest success I've had is using a hybrid approach of agile and
waterfall. But, let's face it, Agile is anything but agile when it comes to
the process. The Agilists out there will be the first to beat you over the
head when you don't follow the process by the book.

~~~
btilly
_Agile is anything but agile when it comes to the process. The Agilists out
there will be the first to beat you over the head when you don't follow the
process by the book._

There is a delicious irony here. The first bullet point of the Agile Manifesto
is that individuals and interactions matter more than processes and tools.
(See <http://agilemanifesto.org/> if don't know what I'm talking about.)

The heart of the Agile movement at the start was that no one process fit all
situations. So they tried to come up with whole families of methodologies
exactly so that teams could choose the one that best fit their situation. Some
of those methodologies proved popular. (eg Scrum.) Some people made a living
out of pushing those. And voila! The message became, "Here is a magic
methodology that is right for all situations, which we'll be glad to teach you
about in our next expensive seminar!"

And so it happens. It seems that all revolutions are destined to become what
they were revolting against.

~~~
chromatic
* The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!" *

Would you hire someone to manage your software development process who's only
qualification is sitting through an expensive three-day seminar?

Would you trust an organization which does so?

If not, why the surprise that such projects struggle?

~~~
btilly
There is no surprise. But many people's only exposure to agile is this, and
the result is that people wind up with an unfairly bad impression of what
agile means.

That said, I've used a variety of agile methods for years, but I'm quite sure
in ways that would make many of the presenters of those seminars object very
strongly to my calling it agile.

------
credo
Here is another good post on agile [http://steve-
yegge.blogspot.com/2006/09/good-agile-bad-agile...](http://steve-
yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html)

------
d5ve
One thing I've noticed with Agile projects at $work is that the processes
better suit a "contractor" mindset, than a "fulltime employee" one. NOTE: I'm
a fulltime employee, so view things from that mindset.

As a contractor (in theory), you're bought in to do a specific job, and then
you leave - get done, get paid, get gone. This works well with Agile, where
you can devote your entire attention to the project, and not get caught up in
other things.

However, fulltime developers will find it more difficult to devote all their
time to a project, as they're likely to still be maintaining some of their
previous projects as well. In smaller organisations, you often end up being
the go-to person for part of the system, and the rest of the business may
struggle with these people being out of reach for weeks or months.

Another factor is that contractors have less reason to care about existing
code and its design principles when designing and implementing a new project,
and well as less reason to care about the maintainability of it. This leads to
the software platform having a melange of different styles, further
complicating the lives of those who have to support it later on.

To me, Agile just seems like contractor culture converted to religion.

------
joe_the_user
_"An agile coach should be able to code, perform analysis, manage the project,
test -- anything that needs doing on a project."_

This kind of statement seems to typify guru-ism. I suppose there are geniuses
what can do everything, write your whole project for you in weekend and be
done. But eventually these methodology camps will wind-up turning a bunch of
fairly average people into consultants, these methodologies need to have these
consultants focus on some _particular things_ they are good at and leave the
rest to the others.

The best managers I've had didn't try to be programmers. A large project
requires coordination and the manager should be there to do that - see what's
on and off track, etc.

I don't know if these consultants are supposed to be managers or architects or
what. But whatever they are, they're "goodness" needs to be in doing that
well, NOT pretending to be so smart they can tell everyone else exactly how to
do their job... And, of course, when a given consultant fails, the head guru
can excuse the basic by saying "see, he didn't everything about everything so
of course things didn't work..."

------
gojomo
My sense is that the 'agile' label is not for a specific process or place-in-
the-solution-space but for a _direction_.

It's a direction that's the opposite of many big company dynamics that can
impede software productivity. It's also a direction that's opposite some
proclivities of otherwise strong and well-meaning programmers, who nonetheless
try to achieve certainty too soon in an ongoing, exploratory project.

------
lazyant
"Real life doesn't have a theme. Or if it does, it would be amazingly
incredible and preposterously improbable if your book matched up with what was
going on with my organization." - what a gem.

Regardless of the Agile theme (that I know little of to comment) this sentence
applies to almost all the business books (specially the biography type).

I've read a lot of them and they are basically a collection of feel-good
stories with some themes. Selection bias. A typical book will have a chapter
like "Never give up" describing some story where the author insisted upon
something far-fetched and finally got it (never mind the time he spent on
other objectives he didn't get and never mentioned). Same with a lot of other
typical themes.

A more objective book like "Founders at work" shows that all of them (from
what I remember) got lucky not once but at least twice to have their break. Of
course insert here the usual disclaimers that you cannot rely on luck only,
you have to work hard etc to be ready when opportunity strikes.

------
jbooth
Whole article is worth reading just for the phrase "Cargo Cult Agile".

~~~
BrandonM
I disagree. I've been seeing "Cargo Cult X" comments all over Hacker News
recently, usually with several upvotes, and it just annoys me.

------
dan00
The idea of Scrum terrifies me, especially the Daily Scrum, because I've a
very cycling productivity. In averaging the days, I get enough done. But if I
would have to justify my less productive days, it would be very stressful for
me, and it would be quite hard to explain why I couldn't get done more today.

~~~
ehendrickson
The daily scrum is supposed to be about coordination, not reporting status to
management or evaluating progress of individuals. It's just an opportunity to
say "I'm working on XYZ" so someone else can say "Oh, I need to touch that
area later today. We should chat offline."

That doesn't mean every team handles the daily scrum well or that the purpose
is never hijacked. But it does mean that if the scrum starts to feel like a
tribunal, it's probably a process smell that should be raised in the sprint
retrospective.

------
BenoitEssiambre
When I was an early teenager, I took violin playing lessons. Whenever I asked
my teacher about violin playing technique, he would always give me a quote
which he attributed to famous violin teacher D.C. Dounis:

"There is no technique, only a bunch of tricks that help you play better."

He didn't want me to get stuck in the 'technique' mindset. I think he was
trying to tell me that applying a predefined technique instead of
experimenting with different things meant you were not adapting to the current
song, style, your, body or cognitive abilities. Different 'tricks-from-the-
masters' worked differently with different people in different situations and
a smart player would try different things until they found the combination
that made playing easier and better sounding in his current context.

I always thought that quote applied very well to programming.

------
erikstarck
In the 90s CMM and Cleanroom Engineering were popular.

Believe me. That wasn't better.

Then came this thing called RAD (Rapid Application Development) driven by a
new set of tools such as Visual Basic.

That wasn't better either.

Extreme Programming was a breath of fresh air but Fred Brooks was right.
There's no silver bullet.

------
InclinedPlane
I still stand by my comments here:
[http://stackoverflow.com/questions/343162/is-scrum-
evil/3433...](http://stackoverflow.com/questions/343162/is-scrum-
evil/343349#343349)

------
VladRussian
Scrum is a child play compare to what happens when organization gets Six Sigma
like stuff introduced through. Scrum Master as scamster !? Big deal! How about
whole management tree getting additional clones - green, brown, black belts -
who put their extremely empowered, yet clumsy and arrogant, hands and noses
into and messing with everything? After having lived through such thing, a
mild degree scrum feels just like a fly spec, a minimally necessary sacrifice
to blood thirsty Gods of Office Space.

------
motters
In general I think it's wise to beware of gurus peddling software development
methodologies. This doesn't mean that there aren't good practices which can
improve the process, but all too often the gurus are not applying a proper
quantitative analysis to their methodology to judge its relative efficacy, and
instead rely very unscientifically on feelgood anecdotes and difficult to
falsify assertions.

------
madhancr
I think Scrum helps product management more than developers. Good programmers
always get stuff done quickly and iteratively. Thats how they become 'good
programmers' and thats how most of them naturally work.

To me, making the product owner think about backlogs and stories from an end
user perspective is the real benefit of Scrum.

------
aminuit
Just wanted to apologize again for sniping at you yesterday. It was uncalled
for. Glad to see you've been able to incorporate it into a proper discussion.

------
itsalive
Daniel, join the club. <http://news.ycombinator.org/item?id=1616000>

------
icfantv
i read the comments here and wonder if the problems people are expressing here
about agile are actually caused by agile, or rather, the people implementing
agile?

my money's on the latter. agile, like any process, can be abused by those who
don't understand or are too process-oriented.

~~~
narag
_...if the problems people are expressing here about agile are actually caused
by agile, or rather, the people implementing agile_

If there is no way to tell, does it matter?

I mean, if Agile requires a perfect implementation, support from everybody,
very smart people and luck, is it any good? If I have all that, I can do
whatever with any methodology.

~~~
chromatic
_If there is no way to tell, does it matter?_

It's easy to see the flaw in many failed implementations: they don't manage
their schedules, they don't have successful iterations, they don't manage
their technical investments, and the only thing they don't do that agile
suggests isn't usually worth doing is writing lots of specifications and
documentation beforehand.

~~~
narag
_It's easy to see the flaw in many failed implementations_

Is it also also easy to correct the flaw? I don't mean to blame Agile
practices. It could be the case that Agile is a bad fit to some "corporate
cultures" or certain project type and the result of someone pushing hard its
adoption is to have some practices really used and other only in appearance.
This could be what people hates.

OK. that would not be "True Agile", but what difference makes for the poor guy
that's forced to play a part?

Edit: I've had Scrum in mind all the time when writting "Agile". Sorry.

~~~
chromatic
_Is it also also easy to correct the flaw?_

Not at all. If everyone involved in the project (everyone with a stake in the
success of the project) agrees to give an agile process an honest chance,
great. If not, you'll have trouble. A similar rule applies for coding
standards, for test coverage, for security and logging, for transactional
safety, for dieting, and for getting out of debt.

------
lzw
Implementing scrum turned our team from productive and mostly free of overhead
to overbearing, involving a lot of long ass meetings (all meetings are long if
you have to stand) and produced a lot of additional confusion. The interesting
thing is that previously, with our specs and our so-called waterfall approach
were were more agile. It happened naturally as we naturally did incremental
development and we naturally talked to each other when we needed to, with no
annoying scrum meetings and asinine bs from managers. People say managers have
no voice at scrums, but what is a scrum master anyway? Everyone who doesn't
write code is a manager and their opinion can interfere with progress. And of
course the idiot child product manager would constantly lecture people about
talking too much, except she would never shut up herself.

Even if a meeting is 15 minutes, if it is irritating, insulting, distracting
and undermining, then it negatively impacts productivity for at least an hour
after. I took to. Having breakfast afterwards, where I normally wouldn't eat
breakfast, just to get centered so I could get some work done for the rest of
the day.

I left that company soon after. If I had stayed i would have gone postal, or
had to hire a lawyer to sue them under the ADA for torturing me by making me
stand and listen to sanctimonious bullshit from idiots.

People say, when a bad experience is described that it wasn't being done
right. Well i see no difference between what i experienced and what is being
advocated.

Yes, there is a lot of anger towards the agile movement because it was sold as
a tool to pointy haired bosses to impose, rather than a grassroots movement
among engineers that embraced flexibility.

That said, on my own we've adopted a number of so-called agile methodologies
like incremental and iterative development.

But the whole movement I'd oriented around imposing ideology on people. This
is wrong.

For instance, whenever unit tests or test driven development comes up the
proponents act like anyone not doing things this way is incompetent. I think
the reverse is true, but I would never say there is ONE TRUE WAY. Agile
proponents often seem to say there is only ONE TRUE WAY.

Also, don't mod me down just because I work differently to you. This is the
ideology of the ONE TRUE WAY that is just wrong.

Programmers come in all shapes and sizes. They actually can be productive and
work in a different than I do or you do.

~~~
api
The biggest determinant of success that I've seen is the skill of the
programmers on the team.

No McMethodology can make crappy programmers write good code. Period.

(However, really bad management can make good programmers write crappy code
too...)

~~~
cageface
_Exactly!_

Factors contributing to the success of a development project, in decreasing
order of importance:

1\. the skill of the team

2\. the determination of the team to succeed

3\. appropriate choice of technologies

4\. process

In my experience management agendas are much more likely to interfere with 1-4
than to help. There needs to be some kind of hippocratic oath for development
managers and process enthusiasts. Everybody pays lip service to Fred Brooks
but people somehow seem to keep forgetting his message.

~~~
api
They're forgetting it because they want to forget it.

Businessmen want (for reasons that are somewhat rational) to commoditize
everything, including labor. Programming labor has been stubbornly difficult
to commoditize. Programmers differ in skill in very deep and complex ways, and
can't just be swapped out like assembly line workers.

This is immensely frustrating to the bean counters. Anything that comes along
and promises to allow programmers to become commodities is going to catch on
like wildfire. The desire is too strong from a management perspective. It
doesn't matter how many times such efforts have failed in the past. What's old
will become new again.

~~~
ww520
Exactly. Agile becomes popular because it gives managers wetdream to impose a
factory-like process into software development.

~~~
hello_moto
I met a ScrumMaster that sees things otherwise.

The point of Agile (and Scrum) is to give responsibility back to the
clients/managers: pick one -> time or money, you can't have both; we'll show
you why from our user-stories, cards, task-boards, poker-game, scrum planning,
etc.

------
c00p3r
When people start selling Agile methods and trying to replace ideas with
routines, meetings and paperwork - it is became a scam, of course.

But the ideas, on which Agile was built upon - like interviewing experts of
the problem domain, extracting and preserving slang and vocabulary from the
stories and keeping that terminology through data, code and even a markup by
naming the same thing the same name everywhere. Design for changes, code for
reuse, start early and iterate, adapt and evolve - all those ideas are working
ones.

So, the problem is just with pre-packaged methods and forced techniques. Each
group, each project should realize usefulness of some of those ideas by
changing their habits and by practicing, not because some "guru" told you that
something is such and such. It is the only way.

It is a common situation when some ideas replaced by routines and propaganda
and authority of "teachers". Buddhism is the best example. The essence of
Buddha's teaching is several simple ideas and conclusions from them. But in
many places people have transformed them into sets of rituals, rules and
endless empty talks.

~~~
joe_the_user
Indeed, it seems rather tragic to see initially good ideas worked into a
dogma.

------
aneth
Interesting to see the present backlash against agile and TDD. As an
independent developer, I can pick and choose what works.

I can say honestly they are both really useful concepts filled with great
tools, but I am not an expert on either. TDD has saved my life a number of
times. I have seen lots of tragedies averted and productive discussions
because of "scrums."

When process takes over function in any environment, innovation and motivation
will be squashed.

