Question

I read a lot the past few weeks about something that calls the 90% syndrome.

Basically, the syndrome describes a project that reaches about 90% completion on schedule, then stalls, finally finishing after about twice the originally projected duration.

I found old articles about this problem which describe it and tried to understand its root cause.

But I didn't find any new articles or information sources about how this problem is dealt with in Agile methodologies. Does Agile methodologies, and specifically extreme programming and Scrum, deal with this issue in some way that is different than what is done in Waterfall projects?

I believe that short cycles can have a positive impact reducing the damage and probability of this syndrome and that in XP, in particular, there are some methods such as TDD that help avoid rework and really get to done.

No correct solution

OTHER TIPS

Agile deals with this by not doing that last 10% at all. We do the most important (valuable) work first, so by time you've worked your way through that first 90%, it's extremely likely that the last 10% is nice to have kind of stuff that isn't worth the investment to develop that last little bit. We tend to vary scope on an Agile project, not the schedule.

Alistair Cockburn has a good article here that talks about this with the analogy of packing up a home for moving.

Essentially I think the problem you are describing is when you ask the team to report "what percentage complete" they are and then use some formula to aggregate that into a overall project percent complete value.

One of the most important aspects of agile project management is the concept that a the state of completeness of a deliverable is binary. To steal a Yodaism: it's either done or not done. There's no such thing as partially done.

This leads to a couple of other important concepts and first and foremost is what done means. I am partial to the 'done like dinner' standard i.e. dinner is only considered done when it's actually ready to consume. The other important thing here is that by having small independent deliverables, you get a much better precision on what progress has been made.

Once you have this in place, it becomes possible to talk about percentage complete for a larger effort. If you have 10 deliverables that are roughly the same size (in terms of effort) and you have 5 of them done, you can say that you are roughly 50% complete. More importantly, you can take the data about how long it took to do those 5 things and what kind of variations you saw and use that in predictive models to forecast when the rest of the work will be complete.

Agile deals with it in extremely simple way : It doesn't have "schedule".

As I described in this answer; 90/90 happens when you are trying to build your schedule based on "happy path", only to find out at the last moment all other edge cases, that need to be implemented.

In proper agile environment, short iterations and small chunks of features, with focus on software being always in "releasable" state, make it possible to avoid this kind of planning. But it makes it much harder to schedule when big features will be properly finished.

Simply said, agile methodologies try to avoid this by not basic "completeness" of project based on how much of schedule is done. You base it on what features are already implemented.

Easy: Don't ever ask for progress on a task as a percentage.

Waterfall is based on the assumption that you know up front what have to be done - so you can measure how far along the way you are. In Agile you don't know everything up front. You will learn things along the way, specs will change and requirements be clarified, added or scrapped based on the cycle of feedback.

Since you don't know what journey you are going to take it is of course impossible to say how long you are on the way.

There are two possible ways to understand that question:

  1. 90 out of 100 features are done. But you did the easy features first and the remaining 10 will take just as much time as the previous 90 did.
  2. All your features are "90% done". But you did the easy parts of the features first and the remaining "10%" will take just as much time as the previous "90%" did.

In both cases you estimated the effort very poorly. At worst you have nothing functioning to show for your efforts.

Scrum solves this by:

  1. not making months long schedule and believing it to be accurate. What you have in Scrum are burn-downs which allow you to estimate how long the remainder might take. But Scrum is extremely open about this being a guess at best.
  2. taking one feature at a time and finishing it to the point where you have a deliverable version. By forcing each work item to be done, finished, tested, polished and waxed you eliminate the tendency to only estimate the happy path and procrastinate on the "yeah, before shipping we'll have to handle a few special cases but it's essentially done!" parts.
  3. prioritizing features by the value they add to the product. That way, when you run out of time/money you have the most valuable product that you could possibly have built in that time.
  4. keeping iterations short. At the end of each iteration you have the option to change course, continue developing, abandon the project with a minimal amount of wasted effort, readjust your expectations for when it is done in the traditional sense.
Licensed under: CC-BY-SA with attribution
scroll top