No Second Chance

In every (three-week) iteration, developers implement stories that are complete within the iteration. That is, there is a tangible deliverable for everything we do, within the three-week time box.

As a general rule, we encourage a new developer to take up the continuing stories on the same topic. That is, if Bill does the first stories for Workman's Comp, we'll encourage Louise to do the next batch.

A special case arises when the stories scheduled for the iteration don't get done. The developer may feel that he has momentum and just needs a little more time to get done. The calendar says that the task is way over the estimated effort. You are tempted to give the developer another chance. Don't.

It may be that the task was in fact harder than anticipated. Or it may be that the developer has gone off into the weeds. In either case, the developer has lost sight of the objective in some way, or we wouldn't be here.

We have a new practice, called NoSecondChance. No matter what the cause, if a set of stories unexpectedly doesn't get done, we put a new developer on the task next iteration. By making this our standard practice, we avoid embarrassing the first developer, and we don't have those pathetic begging scenes, asking for just a few more days.

Invariably the task gets done very quickly in the next iteration. Almost invariably, it gets done by taking a new approach which is identified in the light cast by the first attempt. The new developer comes to the task with clear eyes and can take the good from what was done before and recreate the rest. --RonJeffries

Simply put, developers learn the hard way that if the tasks take more time than the time allocated, they will have nothing to show for their effort. If they switch tasks, all the time invested in understanding the problem is now gone. Obviously the next time, they will come up with a way to show some results for the effort. If they do not switch tasks, it is possible for them to think that they now have a better chance of making it right this time, because they invested so much time in the last iteration. The result will probably be the same: Nothing to show for the effort. The main problem is the copycat that other developers may do. Switching tasks is the best option. -- GuillermoSchwarz

Why does that work? What is it protecting against? I read the above and the hyperlink and I am not sure whether the point is to Switch Teams Around or to not give someone the chance to extend their work across iterations. I look forward to the clarification. --AlistairCockburn

It works because a big slip on a small task means that the developer went off track. New eyes, and some new ideas, get it back on track. Initial writeup enhanced, is it better? --RonJeffries

What struck me was the issue of granularity. I agreed with the final paragraph - I've found that one of biggest differences I can make to other programmers is to go round, visit them and identify when they are stuck, and bump them out of the rut. I've noticed with myself that I can be stuck and not realise it until the coffee break. A five-minute conversation can avoid a couple of hours down a dead end.

But when that happens, I don't take the stuck person off the job. It's not necessary or appropriate; it would be crazy at that fine level of granularity, just because someone didn't figure it out straight away. It would break momentum.

What you're saying here is that when someone has gone off the rails for 3 weeks it should be treated differently to when it's just for 3 hours. I think I agree with that. In a sense, they've had their second chances during the 3 weeks. Do you think the pattern repeats at higher levels? If your whole team hasn't got its act together after, say, 6 months, should the job be taken away from you and given to a new team?

On the newer draft - I got the "3 weeks" figure from somewhere but it isn't in the current version. Did it get removed, or did I imagine it? Obviously I think it's crucial; to me this pattern is about issues of scale.

As a more general point, I've found a lot of these Wiki pages are "what I do in my shop", which is useful, and it'd be even more useful if there was some explicit analysis in terms of the context and the recurring forces. In this case it seems to me that two of the forces in conflict here are "getting in a rut" versus "momentum". Maybe this kind of analysis is what AlistairCockburn was asking for? Without it, it's not clear why, if swapping staff around is so great, you don't do it all the time, willy nilly. There is balance here, but your description doesn't convey it well. A sense of forces in balance should lead to a sense of when NoSecondChance is actually the wrong thing to do because momentum is more important. -- DaveHarris

I actually tried to write up the forces but failed. I'll keep on it. We do in fact swap staff around among tasks, every (three week) iteration.

I have come to believe that in the ExtremeProgramming context, at the scale of a (three-week) iteration, momentum is never more important. If a developer (or team) can't do the task in an iteration, something is wrong and we need to start over on it. The team in question has been doing wrong things and not knowing it. They're not a good bet for another try.

As for taking everyone off the project after six months of not having the act together ... I would advise it. It actually took Chrysler longer than that to decide to scrap what they had and start over ... which is when we started doing ExtremeProgramming. --RonJeffries

We do in fact swap staff around among tasks...

I am not sure about NoSecondChance yet. It seems a bit draconian -- but a lot of the value of the XP practices are that they provide a bold, stark, easy-to-remember stroke. I am, however, absolutely convinced of the need to continually rotate people among teams, projects, and accountabilities. This has three advantages, it seems to me: 1. Keeps developers from becoming stereotyped, and thus stale and frustrated, 2. Helps with staffing flexibility, as you have more people who are familiar with more parts of the system, 3. brings fresh eyes to problems with regularity.

We don't get people moved on every (8 week) interval of the DoIt team, but we try to avoid someone working more than two or so intervals in a row on the same component/project. -- BillBarnett

I was once one of those stuck programmers. Unfortunately, our project didn't have a NoSecondChance value, so I kept spinning my wheels for literally months, trying one thing after another. -- JohnBrewer

Ditto. Consider that the programmer may thank you for taking them off the task.

Last year I got mired in a hopeless pit of despair: a "quick strike" mess of prototype that was never retired, which was shuffled to me to maintain, without any formal requirements or testing, so I had no way to know what its state was, or how it was supposed to work, etc. The team that developed it was long gone, and the current "maintainer" actually didn't know anything about it. I tried to accept it cheerfully, and then they wanted me to add a few "minor" changes (new financial codes), which I foolishly estimated I could do in a month. As I dug into it I learned it involved hideously complex calculations, was very poorly designed, with tons of duplication, dumped thousands of lines of debugging output into the logs (almost every intermediate calculation), which made the logs nearly worthless. And of course the user couldn't be bothered to spend any time with me to understand how the application domain worked, or even how he decided when it was correct. I blew deadline after deadline; frustration grew among my managers, my users, and myself. After several months of this it had become an overwhelming black cloud that I couldn't escape, a hopeless feeling of failure. I eventually just quit that job (which led to more guilt, especially that somebody else had to pick up this tar baby). Now I've largely recovered, and in fact am in a much better job now, but I'll never forget that experience...

Managers, watch for your people getting crushed between a rock and a hard place; you are the only one who can save them... -- Anonymous

EgolessProgramming