In my 3P Vantage Point ezine and free events I often
share advice on making Agile work. This time I offer my
best tips on how to mess up an Agile initiative.
1. Have a dev manager, senior developer, or architect
provide high-level estimates and break down stories.
The team has so much development work in the backlog,
why have them all participate in planning work when one
qualified person can do it instead? Besides, if you did
get them in a meeting, they'd be quiet most of the time
and agree with the senior person anyway, so why waste
2. Make sure the database schema is ready before the
team starts coding.
The database team have their own way of working, and
“incremental” or “evolutionary” ain't it. Luckily, they
answer to a different manager so trying to include them
in your Agile team is hopeless anyway. Besides, the
Agile team members are no DB experts so you can't let
them muck around in the database. Who knows what they
might do there.
3. The same five unit tests broke the build again
last night. Enough is enough! Just comment them out.
Your tech lead looked into the failing tests and said
he'd need several hours to fix them. Again. And what
for? You know that the code works. Those unit tests
never find any real bugs anyway. Spending all this
effort on the unit tests feels like Y2K: The entire
world poured man-centuries into the problem, which
never materialized, right?
4. If the code ain't broken, leave it alone.
Product owner likes it? Manager likes it? Good. It's
all held up with duct tape inside, but who's gonna
know? Those refactoring tasks don't get you brownie
points with anyone, and the developers are scared of
them anyway (see point #3). Management really likes to
see your velocity inch up over time — being overly
critical of your code won't get that number up.
5. Log bugs in the bug tracking system and triage
them for some later iteration planning.
You used to show progress every few months, right?
Those days are gone. Management needs you to show
significant progress every iteration (which is why
two-week iterations are an awful idea.) Luckily, they
can't attend your bi-weekly demo for more than a few
minutes. If you're able to show the new screen and
there are no obvious showstoppers, that's progress;
don't nitpick about those silly things QA finds.
6. Find your appointed ScrumMaster or coach better
things to do.
Your Waterfall process didn't have a “nanny” or a
chaperone, so why should the Agile one? Seriously, you
don't need someone to just parrot the 3 questions every
day at the standup meeting, right? And they spent an
hour(!) on that last retrospective, costing you
valuable coding time. If your ScrumMaster just did his
day job (or your coach resource went back to coding),
man, that would boost velocity!
I hope you realize the above implementation of Agile
is totally tongue-in-cheek. Nothing about it is true.
Except that it's real: It's all based on cases I've
Even in organizations where everybody really wants
Agile to work, the process often bounces back. It's
usually a matter of 6-24 months from adoption until
they find themselves using a messy, unproductive
combination of iterative and Waterfall.
The reality is that Agile development is not as
simple as people like to think it is. Agile requires
changes in beliefs and habits, not just in meeting
frequency and requirements format. Even well-meaning
people can mess it up, unaware of what makes it tick.
Even if your team spends two days learning Agile, you'll
need to frequently review your implementation and
direction. Get a coach you can trust to visit your
team(s) even one day a month. For the waste you'll
remove and the team performance you'll improve, that
investment is a pittance.
Copyright © 2011-2016, 3P Vantage, Inc. All rights reserved.