Enforcing Methods

"Recall that we release code to the config more often than daily, and all developers stay current (or I kill them)."

My current interest is creating, altering and enforcing organizational habits (a.k.a. big-M methodologies). Sooner or later it seems to come down to that quote. Other forms being, Do it our way or leave, and If you want your next pay check, do it this way.

All seems a bit draconian, but I haven't spotted another that works. This really is on my mind a lot lately, because it has to do with the foundations of our way of life.

A guy said to me today, "If we can make it work informally, that would be better than if we make it formal." I recognize what he said, but not what direction to take it.

confused as usual --AlistairCockburn

Although I do not know the original intent, let me suggest the following. The methods should be or become formal, so that it is easy to bring new people up to speed. The enforcement of the methods should be informal because we do not expect people to violate them very often and because we do not want to create a method auditing bureaucracy.

What I do (as opposed to how I talk) is that when someone is transgressing rules in some way, I'll have a talk with them. Usually something bad will have happened, which lets us begin by agreeing that something bad shouldn't happen again. I relate the rules to the bad effect in an impersonal way:

"The UnitTests weren't run before the code was released. The UnitTests would have shown the problem. That's why we insist on running them every time. We're fallible, the computer isn't."

Usually the problem won't occur again. Also I watch the person and nag them a few times in a friendly way.

Perhaps most importantly, I'd coach the other team members to watch out for the bad behavior when partnering. In other words, gang up on him.

If it does happen again, I'll have a still friendly but serious chat that says "Everyone in the group really does have to follow the rules." Since they're programmers, they can do the math on people who don't follow the rules.

If it happens a third time, I would politely but gently remove them from the group. If removing them isn't possible, I'd make it turn out that they didn't get to work on anything important.

--RonJeffries

A situation that came to the final stage was a cowboy programmer who insisted on working alone in the middle of the night. We'd come in in the morning and there would be a lot of new functionality, some of it marvelous. And there would be all kinds of unexplained things that newly didn't work. The individual's contract wasn't renewed.

--RonJeffries

One more thing (I feel like Columbo). ExtremeProgramming (and leadership in general) is a work of love. If you don't respect others, you're not doing it right. I try always to let my great respect show through for people who try hard to do the right thing. And sure enough, they do try, in almost every case. The others, who are perhaps trying in some way I don't understand ... I respect them too ... and wish them success elsewhere.

--RonJeffries

If you want a more systematic approach to getting others to follow a process, I strongly recommend "Why Employees Don't Do What They're Supposed to Do and What to Do About It" by Ferdinand F. Fournies, ISBN 0071342559

--WayneMack

Sometimes it can be hard to tell if you're doing the right thing or not, even when you know what it is, and want to do it. So we enocurage team members to come up with "rules" that have a binary outcome, and that capture the intent of the XP practices. --KeithBraithwaite