Thursday, May 03, 2007

More Agile failure modes

A couple of weeks ago I raised the topic of How Agile Teams fail.  Well in recent conversations and observations I’ve been reminded of two more modes of Agile failure.  (Maybe reminded is the wrong word, maybe I could say I’ve spotted patterns, having one or two cases logged in my mind some more examples have focused my thoughts.)

One mode is where the developers simply state they are doing Agile.  We can call this Fake-Agile.  By simply stating they are Agile the team can then ignore documentation, avoid project management, and generally hack.

Frankly this isn’t Agile and it gives Agile a bad name.  I’m sure some examples of this are genuine attempts to become Agile but without real understanding or experience it is difficult.

The lesson here is: Simply stating you are Agile does not make you Agile.

I’ve also been reminded of this by recent TDD experiences.  A team I am working with has decided they want to start doing Test First Development.  However nobody has done it before and three weeks after voting to do this there is little sign of it being done.  This isn’t necessarily the team’s fault, although they want to do it they don’t really know how.

Think about it.  When I decided I wanted to drive a car I hard to learn to do it.  The same with skiing, wine tasting, and lots of academic subjects.  Sure I can pick some of it up by just doing it, and if I’m really clever, lucky or something else I might just succeed – like the way I first learned to programme. 

But generally, wanting to do something isn’t enough to actually do it.  You need help and advice.

My solution is to arrange some training and coaching for the team to help them start doing TDD.  Once we have that in place I expect things will change.

The second Agile failure mode is a bit more complicated.  I’ve seen it a couple of times now and I suspect its behind many Agile failure.  It happens like this…

A team are trying to adopt Agile, but they are also working with new technology.  The new technology could be technology new to the team, it could be technology new on the market (perhaps a beta release from a vendor) or it could be newly introduced technology.  Whatever, the team need to learn the technology.

So we have New Process and New Technology.

The first sign is exploding cards.  Teams write cards to represent the work they are doing to do at the start of the iteration but when the iteration gets underway it turns out the cards were vast understatements, both in terms of the time required and the work required.

(By the way, you need a card and board system to spot exploding cards, a software tool will simply hide the problem.)

In some cases progress is slow and few, if any cards are complete.  Perhaps people say things like “the card is 80% complete.”  In Agile iterations 80% counts as zero.  It is either done or it is not done.

In other cases, where teams recognise the extra work involved they may write more cards – hence the expression exploding cards.  Here developers start work on a card and realise/find there is far more work than they anticipated.  They break this down into several smaller tasks and the number of cards multiply.  In one case I saw developers took to folding the cards in half to fit them on the white board.

There are techniques for dealing with this situation.  Writing cards to represent the extra work is one, and you may need to add more frequent re-prioritisation.

Another technique is time-boxing: where developers have to guillotine their activities at some point and just go with the best they know so far.

And another is investigation: where an investigation task (probably time-boxed) is conducted before the actual work itself.  This can help split tasks down.

But, all these extra techniques for dealing with this situation are relatively advanced.  An advanced Agile team may simply take these problems in their stride.  For a team new to Agile this situation can be off putting, some people may take it as evidence that Agile does not work and it may even lead to project collapse.

Such projects were probably going to end up in a mess whether they are run Agile or not.  Because of the new technology the project is uncharted waters and the amount of learning and investigation needed is very high.  Therefore, even with traditional project management techniques the project will probably hit problems. 

Here the advantage of Agile is that you know the problems are happening much earlier and not just at the end.  But, if they team is new to Agile then you may loose the project and the Agile practices too.

The solution here...  Not sure I know one.  Some projects will always slip and even fail no matter how well you try to manage them. 

If there is a solution it lies in seeking help, involving people who have done these things before – either Agile or the technology.  Training and coaching can help too, whether in the new technology or new process.

What is the lesson from all of this?  Well if there is one it is simply that Agile Software Development may look easy but it isn’t.  Getting to be Agile is not simply a case of reading one book, it is a case of reading many books, talking to many people, working with experienced practitioners, having training, coaching and trying again when things don’t work out.

It isn’t easy being Agile.


  1. I translated this article into Japanese language. You can find it on

    日本語にした記事を にて公開してます。

  2. Allan,

    You point out a genuine issue for new agile teams. Some projects will have more than others of these impossible-to-estimate tasks, and they can derail agile progress if they are not handled appropriately.

    I work a lot with engineering teams that have to cope with unknowns during development (I coach agile teams and managers). Ideally those unknowns are investigated & understood before development begins - at least that is the aim in traditional processes. But that is getting more difficult to achieve as projects become more complex. So we need to handle this kind of uncertainty within the development period, without allowing it to blow our commitment to stakeholders.

    What I have advised teams to do is first, recognize when your estimate is really just a guess. That's a sure sign that you have an R&D task, not an estimatable task. (You could call it an investigation task or a discovery task - there isn't an agreed term.) For R&D tasks set a time box, and schedule that task a couple iterations before you need the knowledge it'll yield.

    If an R&D task has been given a time box of 8 hours, then you'll devote up to 8 hours to it in the iteration, and no more. That may or may not complete the task's goal, but it will yield information - you'll have a better idea of what is really needed to do the job. Then you might be able to carve out some estimatable tasks for next iteration. Or you might still have more mysteries - if so, write up those R&D tasks and schedule them.

    In this way you stay in control of how the team's time is being used. True, you cannot force discovery of new knowledge to occur at a specific time, but if it is really important, you can choose to devote a big part of the team's effort to the time-boxed R&D work in a given iteration. This isn't a guarantee but it increases your odds. Best of all this is explainable to business stakeholders. If other agile tasks are proceeding as promised, those stakeholders are much more understanding of the situation with R&D tasks.

    I've had even brand new agile teams use this technique successfully, and stay in control as they safely dug up new knowledge while delivering on the work they understand well enough to estimate.

    - Nancy Van Schooenderwoert
    nancyv at leanagilepartners dot com

    Agile coach for embedded and safety-critical systems


Note: only a member of this blog may post a comment.