
Demystifying agile, top 7 myths. - wtfdeveloper
http://www.makinggoodsoftware.com/2010/11/07/demystifying-agile-top-7-myth/
======
lyudmil
I don't think there's much value in articles such as this. This one in
particular uses an incredible amount of vague language (What do you mean by
"agile"?), and sets up a number of straw men (Did anyone ever claim
retrospectives fix everything?).

This kind of writing always seems to me to be trying to limit discussion in
some way. It pretends to criticize a certain approach by bringing up problems
that don't really exist (or aren't important), but implicitly accepting the
basic principles of the thing they're criticizing, thus framing the debate. On
one side we have the total religious fanatics who apply Agile to everything,
and on the other are the sensible agilists, who don't think that
"retrospectives fix everything". Okay, that's a debate you can have but it's
an extremely narrow spectrum of opinion. If you're really trying to reach
people who are "agile-averse", then you ought to argue for your approach _with
them_ and demonstrate that your way has merit.

~~~
zby
Personally I don't think he wants to limit the discussion or even make a point
- it rather looks like he writes whatever baits more people.

------
hsuresh
A lot of what people write about "agile" processes tend to be written keeping
in mind teams/people at traditional companies. Very few of these are helpful
in a "startup" environment.

So a pro tip to make sense of such articles - imagine being part of a big team
at a big company while reading. They will start making a lot more sense.;)

------
ericHosick
All very good points. And I agree there seem to be a lot of misunderstandings
even now.

How about, though:

2) Agile does have a good process for estimation. Estimating by relative size
removes all those "unknowns". This does allow for a velocity that doesn't vary
between iterations. I have three teams that have a velocity that on varies 10%
between iterations. There is more to Agile than just Estimation. There is the
commitment that a team makes to deliver. So, even if their estimates are off,
the team is more likely willing to put in the extra time to meet the
commitment. Remember, in Agile you commit to product, not points.

With regards to accurate: it isn't supposed to be accurate. It is supposed to
be reliable.

4\. With regards to documentation, no light design, etc. This stuff always
seems so mis-understood. Agile says you do enough documentation/design to make
it to the next game. But yes, not a silver bullet.

5\. Agile requires any issues brought up by a retrospective to be placed in
front of the backlog. I guess if management isn't willing to allow that, then
they aren't following Agile. In the end, it is really all about execution
which has nothing to do with Agile itself. Agile just affirms that you need to
continually reflect and improve on the process itself. It doesn't explain how
to manage that.

6\. It is true this would be silly to say. And there is Behavior Driven
Development (BDD) which requires you to test your system from end to end.
There is also continual integration (CI) which allows "heavy tests" to be run
periodically as opposed to continually during development.

Please note, I didn't make these "rules". I just follow them and it has worked
really well for me.

------
fiveo
Agile is such a generalization. There are many practices below Agile such as
Scrum, XP, Lean, Kanban, DSDM, FDD, etc.

Agile itself is just a set of principles. The actual implementation still
require some processes.

I don't think people should attack Agile as a whole, but they should focus on
which practices they chose. For example: Scrum is an agile practice for
Project Management. But in order for a shop to use Scrum, they must implement
certain practices from XP. XP more of an agile practice for Software
Developers.

There are shops which implement only SCRUM but not the XP part. That is to say
that they implement the whole Sprint, Retrospectives, Backlog, Stand-up
meeting, but they did not refactor bad code, they did not try their best to
have an automation in place. At the end of each sprint, they never test the
whole app, they only test whatever the sprint accomplished. This is even worse
than the previous practice.

I wholeheartedly agree with those who have been burned by management who
thinks that SCRUM or XP will make things better in a short time. I hate to say
this but it takes a very long time for a company to change their culture and
mindset (depending on the size of the company and what the company does:
product vs service).

If your company is switching to something new, make sure they know that
methodology inside out. Make sure they met the pre-requisite. Make sure they
are willing to sacrifice their time and money for a while.

Otherwise, get your resume ready cause the ship will sink faster than before.

On the other hand, some people might not agree with this but when you have one
of these processes in place and everything in your engineering department runs
well, that doesn't mean life is good. When the company is not doing well, your
senior engineers who receive a big-fat check every month might be a good
candidate to be let go. The reason is because your intermediate and junior
engineers have already known everything inside out (cause one of the practice
in Agile is to share knowledge, cross-functional team, or whatever).

Be aware that it could be a double-edged sword.

------
Morendil
Some relatively lucid observations there. (Disclaimer: I'm an expert. I was
into Agile before it got named that.)

There's one point that I starkly disagree with:

> “Hero developers” make most of the big differences made in software
> development.

Wait, did I say I disagree? Hero developers make a big difference all right -
for the worse. Nothing breeds bad management like the one guy who pulls
through when the team can't. Managers come to rely on them, and therefore on
sheer blind luck, when the name of the game is to _engineer_ success, by
putting together a solid team.

~~~
JoeAltmaier
Put this into context: are your experience from working at a big company? Do
you even know any super-performer software engineers?

------
caustic
I don't know, may be it is just me, but I noticed people here at HN don't have
respect about agile. Is this the case?

~~~
steveklabnik
It depends; sometimes, you'll see a huge pro-agile crowd, other times, not so
much. This is accentuated if you s/agile/tdd/g;.

I'd wager this is largely due to how one is first exposed to agile
methodologies. I'm young enough that I stumbled across agile as a way to solve
problems, and so it sounds pretty good to me. However, my slightly older
colleagues remember agile as the Newest Management Fad, with high priced
consultants, seminars, certifications, and your boss paying lip service to
change while still Not Getting It to match.

I like agile's philosophy, but I can certainly see lots of criticisms of
Agile.

~~~
DrStalker
My first experience with Agile was a housemate describing this amazing new
design system that meant he could get right into coding without any tedious
planning and sort everything out later.

He created a startup for his pet project, eventually managed to get one
customer for his product and then realised his idea was fundementally flawed
and would never be commerically viable or even supportable.

That is still my impression of Agile - full speed ahead, buzzwords to maximum
power and hope for the best.

------
wslh
He missed one important point: Agile is an agreement between the customer and
developers, it's not magic. A few years ago the customer would tell you: "I
want all the features by this day, I don't care about iteration".

Even now, many customers just want the perfect product at the end of the
contract.

~~~
famsam
Which customer would tell me that? Which of my customers have you spoken to?
None apparently. The Agile way, make stuff up and fling it at people.

