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.
Post Revisions:
This post has not been revised since publication.
Posts
I think the problem with the clinic/hospital approach is that it pathologizes problems, and the structure keeps people from showing off work that might not appear to have any problems but is in fact rife with them.
I like the way we approach problems in architectural studio settings: you have your design team that works away at a problem, and on a regular basis a larger collection of designers get together to see your work and critique it.
A recent example is when my design lead presented a fairly simple set of solutions to the fenestration of a facade (the pattern of windows and solid wall, basically). We started off discussing that problem, but suddenly the conversation shifted and we were talking about how the tower rising above that wall looked really out of proportion. Nobody had considered that a problem, but once we started talking about it, the issue was not the awkwardness of the fenestration, but the fact that the tower itself was too wide.
Thinking back on my years of coding, regular crits like that would have made a huge difference in the quality of work we produced. Not only do you find a lot of problems in simply preparing your work for critique, but in the light of the critique you see problems you didn’t realize were there. It would have been a hard sell, though. People hate being put on the spot like that. Since I started architecture school I’ve been wondering how to take the format and repurpose it in a coding environment, and it would take some serious management commitment.
11/16/2008 @ 11:09 pm
Yeah. That’s one of the things that I miss at my current job compared to my open source experience: regular discussion of code isn’t the norm, and it’s hurt us.
Done well, I think the clinic method could help here – a good clinic team wouldn’t just look at the manifestation of the problem, they’d look at underlying causes and help guide the people reporting the problem (and others in the organization) to improve the underlying causes. Hard to do, though.
And, in a proper lean organization, they’re always reporting problems and working on ways to fix them in both the short term and the long term. (Where by “always” I mean “once a minute on average, a cord gets pulled somewhere in the factory that has the potential to stop a production line”.)
So I guess that’s a long-winded way of saying that I agree with your first sentence: pathologizing problems is the wrong way to go, it’s much better to have a deeply ingrained problem-solving (including problem-discussing) mentality.
Though something about the clinic idea still appeals to me – the basic analogy doesn’t strike me as inherently flawed. But that doesn’t mean that it’s a good idea in practice: probably our current state of affairs is such that what we need isn’t hospitals but widespread washing of hands….
11/17/2008 @ 3:39 pm
You’re all right. It’s important to note that the clinic isn’t for every problem. We use teams as the basic production team. We use technical and architectural reviews and project reviews which gather reviewers from outside the teams. And, of course, there’s lots of informal problem solving going on all the time.
The clinic is for problems that have hung around for a week or so, escaping the solution by all these other methods and is holding up the project. Often, this type of problem turns out to be a systems problem that couldn’t be solved because the people working on it did not represent a wide enough scope. If the people who are part of the problem and not in the room, the chance of solving a problem goes way down.
Moral: Use every tool you have. This business is too hard to do otherwise.
1/6/2009 @ 4:19 pm