7

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.

Bernhard Barker
  • 548
  • 3
  • 8
Belgi
  • 567
  • 1
  • 4
  • 9
  • 2
    I think it's the 80/20 rule in action: 80% of the job takes 20% of your time and the other 20% takes 80% of your time. So basically if you're done 90% job-wise, you're only there about half-way time-wise. – Pieter B Aug 10 '17 at 18:17
  • 1
    What is the 90% completion you mention, 90% of single features or 90% of a complete project? – Kwebble Aug 10 '17 at 18:49
  • 1
    A reference to some of what you have been reading seems in order. – JimmyJames Aug 10 '17 at 20:35
  • It doesn't matter if you use agile or any other method, basic risk management requires that tasks are ranked by risk, and the riskiest tasks completed first. In addition, project managers must not be allowed to lie to management about progress -- either use no project managers, or reduce the consequences of honest communications. – Frank Hileman Aug 10 '17 at 22:24
  • If a project seemed to have reached "90% completion on schedule" after 6 months, but it turns out 100% are only reached after 12 months, there was obviously the wrong metrics used to measure the progress - the person who said "90%" was pretty wrong, since it really was "50%". Agile approaches allow to use small deliverables as a metrics for progress, and they priorize the most important deliverables first, and they allow to adapt the definition of when "what means 100%". But this is essentially all there in the existing answers, so I am not going to write my own. – Doc Brown Aug 11 '17 at 08:57

5 Answers5

13

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.

RubberDuck
  • 8,911
  • 5
  • 35
  • 44
11

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.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
7

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.

Euphoric
  • 36,735
  • 6
  • 78
  • 110
  • 1
    90/90 happens when you are trying to build your schedule based on "happy path": I normally approach this by (1) estimating the amount of time needed for the happy path, (2) doubling it to account for bug fixing and problems discovered along the way, (3) add another 10-20 % to have some extra buffer. – Giorgio Aug 11 '17 at 09:56
  • 2
    Actually, agile does not make it harder to schedule when the big features will be released. It just admits it's effectively impossible. The advance plan won't serve you any better: it will give you a date, but you're gonna miss it anyway. In fact, agile is better, because it can improve the precision over time by not pushing the parts that are impossible to estimate ahead. – Jan Hudec Aug 11 '17 at 10:17
3

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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
0

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.
Kempeth
  • 210
  • 1
  • 5