When Doing Well is Better Than Doing the Best

A colleague of mine at IBM, Tim Feeney, made an excellent point about process enactment recently. Sometimes we spend a lot of time trying to perfectly enact 100% of our process. But we should be thinking about how efficiently we can make the process good, rather than spending lots of time making just one part of the process perfect.

Usually when we think of enacting a process, we imagine that team members are forced into doing some action (or prevented from doing something). for example, you can only check-in if there are no Warnings in your code. Or you can’t change the state of a work item from Implemented to Complete without first going through Verified.

But what if it’s expensive (or just really hard) to enforce something? Not only is it difficult to create the enforcement; processes change too. So we need to maintain and possibly modify our enforcement code. Process enforcement requires a cost/benefit analysis just like any other development.

For example, what if you want everyone to add a tag called “clustering” to all work items that deal with clustering? How do you even know if a work item addresses clustering? You can create an RTC extension to do a text search for “clustering”. But you might have clustering-related work items that don’t have the word “clustering” in them. And the word might appear in a field you’re not looking for. So you end up doing a lot of work but only achieve a partial benefit.

So we can probably find a better way to spend our time than hacking together an RTC extension with limited value. After all, do you want to test an extension by entering a hundred different work items, or would you rather play the just-released Assassin’s Creed III?

Forcing people to do something in a certain way, or trying to “clean up” after everyone when they don’t follow a procedure, is not the only way to get something done. There’s a lot to be said for encouraging good behavior rather than enforcing it. It may not be a 100% complete solution, but 100% may not be achievable anyway. And encouragement allows for flexibility and individual decision making.

So instead of writing a bunch of expensive RTC extensions to perfect a process, you can create a query in a dashboard widget. For example, all new work items that do not have a “clustering” tag are displayed on everyone’s dashboard. Hey look – there’s a work item related to clustering- I’m going to tag that. And it only took 2 minutes to create the query. That’s a very high cost/benefit ratio even if it’s not a perfect solution.

Or, you can display dashboard queries that find work items that are suspicious. A high priority item with a due date far in the future probably hasn’t been filled out properly. Or work items assigned to someone outside of the project are suspect and should be reviewed. Same for due dates that don’t match iteration assignments.

The point here is that there are inexpensive ways of identifying and displaying process violations. If everyone sees the errors of their ways right in their dashboards, then they will likely perform the process enforcement themselves. A little Dashboard Shaming never hurt anyone.

We software engineers try to create 100% complete solutions to our problems. But sometimes we can be very content with a good solution that costs far less then a perfect solution. Especially when a perfect solution may not even be attainable.

The lesson here is to step back and figure out the cheap and easy way of doing process enforcement first. Sometimes you should enact a process by leveraging people’s eyes and brains rather than writing a bunch of code.