Agile Nightmares

42 %
58 %
Information about Agile Nightmares

Published on December 8, 2007

Author: unbrand



Agile nightmares presentation from the recent agile barcamp held in Wellington, New Zealand 7 December 2007. Presentation given by Brian Calhoun who works at . Here's the wiki page for the barcamp:

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

Add a comment

Related pages

Hier sollte eine Beschreibung angezeigt werden, diese Seite lässt dies jedoch nicht zu.
Read more

The Art of War Applied To Software Development | Agile ...

Agile methodologies applied in Enterprise Transformation. A Hierarchical Management Nightmare - A Leadership Dream
Read more

Hier sollte eine Beschreibung angezeigt werden, diese Seite lässt dies jedoch nicht zu.
Read more

Agile Nightmare | Facebook

Agile Nightmare. 106 likes · 2 talking about this. Sharing practical implementations of Agile transformation methods in enterprise. Mindset adaptation: A...
Read more

December 2015 Agile Scrum Leadership Team Management Agile ...

Agile Methodology applied in Enterprise Transformation, Scrum adaptation for agile project management and team dynamics, Traditional management nightmare
Read more

Agile Nightmare - Google+ -

Agile Nightmare - Leadership Dream, Management Nightmare - Agile transformation methodology applied in big companies
Read more

Agile Nightmare ( ) | LinkedIn

See who you know at Agile Nightmare ( ), leverage your professional network, and get hired. LinkedIn Home What is LinkedIn?
Read more

The Project Manager’s Nightmare «

The Project Manager’s Nightmare is a game intended to demonstrate the benefits of limiting Work in Progress ... Agile Games Group . Join Agile Games Group!
Read more

The Pragmatic Bookshelf | The Dream Team Nightmare

title: The Dream Team Nightmare: Boost Team Productivity Using Agile Techniques, by: Portia Tung, isbn: 9781937785710, date: 2013-11-15
Read more