Process Standards

This content is syndicated from George Dinwiddie's blog by George Dinwiddie. To view the original post in full, click here.

There’s been a long discussion on one of the mailing lists about software development process standards. Someone quoted Robert Glass from his essay “A New Way of Looking at Software Productivity” in Software Conflict 2.0: The Art and Science of Software Engineering
Data show that good people do various software tasks 7 to 28 times better than others… Could we, for example, find out what the good people do? And once we found out, could we transfer that technology to others?
Now, I haven’t read this paper, so it’s quite possible that it’s taken out of context.  But it was introduced to me with the question
This sounds like the goal we are trying to do, to discover the most effective way to do something and then enable others to work the same way.  Does anybody disagree with this as the goal?
That sounds so logical, doesn’t it. We find that person who’s most productive, and have everyone else work the same way. All we have to do is write down what they do and make it the standard. Oh, dear. I’m afraid that’s not the way people work. Fortunately, it also doesn’t be quite what this person intended, either. But this point of view, or some parts of it, pop up often enough in the software development field that it’s worth taking a closer look at it. There’s no doubt that some people are more effective at some tasks than others.  Such observations are common.  Less common are observations that group effectiveness is often highly dependent on the little-noticed behavior of someone who is not considered highly productive, but who acts as a catalyst to others.  I’ve heard tales where the catalyst was eliminated as non-productive, and the group’s productivity, including that of the stars who were put on a pedestal to be emulated, plummeted.  It’s clear to me that we should not look to “good people” but to “effective teams.” The most effective teams take a mix of people and approaches, not a bunch of clones. This is but one of the ways that a process definition approach tends to miss the mark.  What is an effective process for one group might not work so well in the group next door.  Yet there are ways for each group to collaborate and excel.  Effective teams are not created by telling them how to work, but by facilitating their finding their own way to work. Most “standards programs” attempt to make all units work the same way. I suppose that it seems easier to manage that way. You wouldn’t have to know the capabilities of the individuals. Or the teams. You could treat them all interchangeably, right?  Of course, it’s pretty obvious that people are not fungible. In operation, even identical machines turn out to need individual care. Back in 1998, a consortium led by Motorola started a satellite phone business, named Iridium, with low-earth satellites. A short nine months later, Iridium was bankrupt. There was much discussion about what to do with these satellites, which if abandoned would be a significant hazard. Fortunately, the backers were able to find a buyer for the company, at less than a half-cent per dollar of the original investment. How did such a venture go so very wrong? There are many things, but one significant problem was the assumption that flying a fleet of identical satellites would be little harder than flying one. That turned out to not be the case. Each individual satellite, once launched, was subject to unique conditions and required individual trajectory calculations and control. This drove up the ground control costs by a couple orders of magnitude, which made the service too expensive to profitably sell. So much for economy of scale by standardization. With people, there’s even less reason to expect such economy of scale. Remember that the Agile Manifesto points out that individuals and interactions trump process and tools. It doesn’t say that just to protect people. It says it because it’s the experience of the signers that it’s more effective to put your trust in people than in processes. That’s not to say we shouldn’t share what works with our processes and learn from each other.  But it does say that each group has to adopt their own process, not have it imposed on them because some “scientific approach” has found it to be superior.  That’s just a return to Taylorism. Many standards programs assume that there is a most effective way to do something.  They assume that this effective way is transferable from one person to another.  And they assume that the benefit of this magical way of working will pay off all of the deleterious effects of trying to enforce that transfer. In my experience, there are many effective ways to do most things. What’s most effective for one person might not be so for the next. What’s most effective in one situation might not be for the next. Transferring beneficial practices from one person to another cannot be accomplished by a third person decreeing it. The person picking up these new practices must want them. This means that there must be something desirable about these practices for them, not just for the company. Pushing hard for standardization from the outside can have the opposite effect, that the practices are never given a reasonable trial before being rejected. Instead, we’re better off building an environment that makes it easy to share information. We need to foster a culture that values learning. We need to facilitate, not force. It’s my understanding that the “standardized work” of the Toyota Production System is not a standard imposed from outside the workers following that standard. It’s their recording of the way they currently work to the best of their ability. And it’s intended to be modified and improved on a continual basis. That’s the kind of process standard that produces benefit.

Leave a Reply

What is 4 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA