Agile Nightmares
Scary things that can keep you up at night
Agile barcamp 07.12.07

Ground rules
Not all of these are unique to Agile.
Many of these problems are worse because of Agile.
These problems do come up a lot in Agile projects and
can derail efforts.
These are my experiences.

Re-living the pain
Walk through an Agile project & spot the pain
Can we wake up from the nightmare?

The plane stalls on liftoff
Before even starting the project, many clients don’t
want to use Agile.
Maybe they can be convinced? Maybe not? And at
what time cost to do so?
Can wake up? Yes, sooner or later. Be sure to weigh
worthiness of overall effort.

Fixed price, features, time.
Web projects particularly hard to do this as time is
usually very short.
Typical “big project” RFP process makes situation
worse.
Practically zero room for negotiation
Can wake up? Yes, but need to work Agile bits in,
around the rigidity.

Need more “transparency”
Often clients will demand specification documents.
Can wake up? Difficult. Usually hard to eliminate needs.

“But it looks like it’s done...”
In Agile, showing the clients works-in-progress often
gives the impression you’re farther along than you really
are.
Especially: browser compat., security, stubbed
features, error handling, 3rd-party integrations.
Can wake up? Yes, easily. Be persistent in setting
correct expectations.

Old habits die hard.
Repeated desire to over-specify can occur especially
with people who have lots of waterfall experience.
Can wake up? Yes. The price of freedom is eternal
vigilance.

Always late to the party.
Most projects wait until the very end to put in content.
New content: real > semi-real > Lorem Ipsum > nothing
Migrated content: who’s responsible, and how much?
Can wake up? Yes, but only if you diligently get content
in early.

Yellow is warm. No, it’s bad.
Easy to get into disagreements about the meaning of a
feature or how deep an implementation should be.
example: keeping the page from refreshing for an
online calculator -- easily veer into Ajax-land
Can wake up? Must wake up! Everyone needs to agree
on what can be delivered in budget: talk early & often.

Dependency hell
While implementing a feature, developer discovers
tricky dependencies with other story cards.
Can wake up? Yes. Inform PM, client if need be.
Timebox couple of solutions, weigh outcomes.

3rd party is late
Often, the developers are waiting on a third party such
as a design firm to deliver.
If the design firm is late, it squeezes developers.
Can wake up? Yes. PM should foresee this possibility
and tell the client and others at earliest possible
moment, even in proposal.
Can work really well to say “day for day slip”

“If you’re so Agile, can’t you
just add this one thing...”
This happens a lot. And is completely understandable.
Generally, yes, we can add it in. But something else
may have to give (usually another feature or a deadline)
At some point late in project, no, you can’t add
anything as it will decrease stability.
Can wake up? Yes, by letting everyone know early
what the parameters are for new feature inclusion.

“That’s not what I wanted.”
When you show something to the client, it’s wrong.
Client hasn’t changed their mind: you misunderstood.
Can wake up? Yes. Quickly change tack and deliver
what’s absolutely needed if it’s in line with what’s been
agreed.
Really try to avoid getting into this situation by
showing the client early releases.

Project closure
Client may repeatedly demand “just some small fixes”
before signoff of project.
Closure stretches out, and budget is gone.
Can wake up? Yes, but will be difficult at the time. May
need to suck it up.
Better to anticipate this and create acceptance
criteria that will trigger signoff.

In sum
Don’t blame the client for your not understanding.
Show client your progress early and often.
Work on the riskiest (most difficult, most unclear) stuff
first. This helps ensure no big nasties under the bed.

Thank you.
Questions?

Nightmares courtesy of...
Brian Calhoun
brian@silverstripe.com