

Agile Won't Fix Your Products - ca98am79
http://firstround.com/review/im-sorry-but-agile-wont-fix-your-products/

======
gopalv
"Agile" is a transition point.

A better idea would be for the entire team to be motivated, for them to be
aware of the customer, to be able to drop something half-way and pick up a
priority as a customer scenario unfolds.

In nearly every effective team, I've been part of, the most important detail
was that anyone of us could be swapped out for someone else - it's not that we
were fungible, but that the UI guy could write backend, the backend guy could
write the deploy code. All coming to one point - the specialist could do it
faster and neater, except they could do a hack-job in someone else's module
anytime.

And if you can get yourself five people who are like that, manage some
conflict then you can get a lot more done than any other method I've seen.

Take away the pride, the motivation, point them at misdirected goals, then you
end up with nearly nothing.

Agile is the middle ground here - you're demotivated? Go pick something off
the burn down chart. You need to leave early? Tell us at the standup. Can I
borrow two developers for a week? No, the sprint plan has them accounted for,
can I drop features?

Not as a bad as that, but it's not a substitute for a tiny cross-functional
team which isn't pulled about by external forces.

~~~
mattress
I agree that Agile can be the middle ground, but it can also can be dangerous.

When my previous employer implemented "Agile" they payed what I imagine was
tens, if not hundreds of thousands of dollars for an "agile framework's"
consultants to come in and teach us how to agile correctly.

1.5 years after that I saw that our time was more micromanaged than before. We
were told regularly we were "empowered" and to speak up when we had any doubts
or anxiety or saw a problem with our plan, but when we did it we were either
chastised or disregarded or in some cases convinced it wasn't an issue.

That and the entire development organization treating estimates as infallible.
That was the worst. Being told to estimate as best you could because agile was
about adapting to change. Then getting reamed for being wrong. I gave up
pointing out all the double-speak (release dates are flexible! as long as it
is done by the release date) going on in the "agile ceremonies" (2 day 4-hour
Release planning meetings with all 30 dev teams in one room.)

I know it's just one org I'm speaking about, but after almost 3 years I don't
know if their dev organization is any better off than when they were
waterfall. Now I'm curious just how wide spread this particular issue is.

------
mattmurdog
Agile won't fix your products because you can't fix clueless, bumbling,
incompetent engineers. I've done the whole agile thing in small teams of 5 and
gotten more done than working with 100 offshore developers who find excuse to
complain about everything every chance they get. Agile doesn't fix the pride
you have in the work that you do. That's the primary motivation for good work.
Knowing that your work matters and you're not just there to collect a pay
check and check out as soon as possible.

