Agile NightmaresScary 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