On Tuesday afternoon of AYE, I attended a session on the clinic method that Jerry ran. The idea: surprises always happen on projects, and they’re generally bad. In cities, we have institutions (e.g. hospitals) to go to for help when we run into trouble; maybe our development organizations should have the same?
One way to do this: pick five of your most effective performers to form a clinic team. Try to seek out diversity: you don’t want everybody to have the same kind of problem-solving approach, and it’s also useful to have people with different technical backgrounds. (You might want to rotate people into the team periodically, instead of having a static membership, too.) Then, one morning a week, the team holds an open clinic, where everybody can bring their problems. (The rest of the time, the clinic members work on their regular jobs.)
Jerry recommended coming up with the first action step for any problem within three minutes: that will prevent the clinic session from getting bogged down trying to solve one problem, and will have the clinic team serve as catalysts rather than people whose job it is to solve the problem.
I really like the clinic analogy, but I’m not entirely comfortable with some details of the recommended implementation. For one thing, emergencies happen more often than once a week. For another thing, a clinic team would be in a unique position to be able to have a broader view of the organization’s underlying problems and to work on those. Also, I like slack, and I imagine that having a bit of excess capacity available at times could be really useful. (Though I also imagine that it could lead to people inappropriately refusing to make tough choices, where the slack gets treated as full-time excess capacity.) I believe that lean suggests using team leads in this sort of role, as excess capacity / emergency problem solvers when the demand warrants while having them work on improvement measures when they’re free?
Of course, as Jerry points out, it’s hard to get approval for a full-time team of this sort, and even if you manage that, you run the danger of having them be successful, of having the number of problems go down, and then of having the team declared to be no longer necessary because they don’t have enough to do.
This post has not been revised since publication.