The Signing Up practice is a double-edged sword. It offers tremendous motivational potential, but it also offers as many hazards as any other practice described in this book.
I think of that statistic that the best programmers are 25 times as productive as the worst programmers, and it seems that I am both of those guys. | ||
| --Al Corwin | ||
Increased inefficiency. Teams that are signed up have a tendency to work hard rather than to work smart. Although it's theoretically possible to work hard and work smart, most people seem to be able to do one or the other, but not both. A focus on working hard almost guarantees that they'll make mistakes that they'll live to regret, mistakes that will take more project time rather than less. Some experts have even argued that people who work more than 40 hours per week don't get any more done than people who work about 40 hours (Metzger 1981, Mills in Metzger 1981, DeMarco and Lister 1987, Brady and DeMarco 1994, Maguire 1995).
If you're working on a project in which people are signed up, watch for an increase in the number of time-consuming mistakes and other signs that people are not working as smart as they should.
Decreased status visibility. People who sign up make a personal commitment to deliver a product in the shortest possible time. In some cases, that can-do mentality makes it hard to assess the real status of the project.
CROSS-REFERENCE
All the problems discussed here are characteristic of this kind of scheduling. For details, see Commitment-Based Scheduling in Schedule Estimation.
Monday: | "Will you be done by Friday?" "You bet!" |
Wednesday: | "Will you be done by Friday?" "You bet!" |
Friday: | "Are you done?" "Um, no, but I will be really soon. I'll be done by Monday." |
Monday: | "Are you done?" "Um, no. I should be done in a few hours." |
Friday: | "Are you done?" "I'm getting really close. I'll be done any time now." |
Monday: | "Are you done?" "No. I ran into some setbacks, but I'm on top of them. I should be done by Friday." |
Multiply this phenomenon across an entire project and you have a project whose status is virtually impossible to determine. Some organizations are willing to trade this kind of loss of management visibility for higher morale, and some aren't. Be aware of the trade-off your project is making.
Loss of control. The signed-up team takes on a life of its own, and the life it takes on is sometimes not the life that the company wants it to have. The team (and the product) might be headed in a different direction than management wants them to go. Forcing the team to change direction can give the team the impression that they aren't as empowered as they thought they were, and that can be fatal to morale.
Addressing this risk requires that you make a judgment about the trade-off between morale and efficiency as well as between morale and control. Are you getting enough of a morale boost from having a signed-up team to justify letting them go their own direction?
Smaller available talent pool for the project. Enthusiasm can work wonders, but it has its limits too. Some older, more-experienced developers who have signed up before simply won't sign up for Windows NT-like projects. The result can be an averaging down of the experience level on a project in which Signing Up is used. Such projects can be characterized more by their exceptional energy levels than by their exceptional results.
Burnout. Even when developers work overtime voluntarily, long hours can take a heavy toll. The anecdotal reports of developers who sign up for projects and work lots of overtime also include lengthy lists of developers who leave their companies at the ends of their projects (Kidder 1981; Zachary 1994).