Process Standards
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.
Fantastic post George – sharing it with my management…
George, I accept everything you are saying, and it is coming at just the right time for me. My organization is working on standardizing our approach, not so much so that everyone has to work the same way, but that we can rally around “our way” to get things done.
In that, the only things are that important to me are:
1. That we can bring new people onto our teams quickly and productively
2. That when teams shift around we can maximize learning from each other without re-learning our core language
3. That team members can “locate” themselves in the process and not feel like everything is chaotic
Your post helps me to keep in mind that we can go too far if we don’t allow people to work to their individual strengths.
Kind regards,
–Ken
It’s not the process, it’s the system in Deming’s sense see Russ Ackoff on” Beyond Continuous Improvement”
https://www.youtube.com/watch?v=OqEeIG8aPPk
Great post, George!
I think it is important to remember that there are a lot of different things we call “standards.” In the best case there are things that work quite well, like when the whole team agrees that we should be doing TDD on all production code. In the worst case there are things that impose process without having any real effect on outcomes, like having to hand off documentation to some process cop before you start coding. Most things, I believe, are in the gray area between these extremes and require judgment. I think it is fair to expect that the judgment comes from people who know the work.
Remember also that being a “senior engineer” at Toyota is different from being a methodologist. They are actually required to know how to do the job themselves. If we have people who understand the work trying to improve the work that is different from having some management consultant tell us how to do it.
Nice article, George. I’m gonna share with some clients. thanks!
A note on the Iridium project, although the LLC launched to operate it in 1998, the project had been under development for many years prior. I worked on that very failed ground control software from 1994-1998. It’s a classic anti-lean-startup story.
Thanks for the details, John. I did an internet search to check details, but it’s quite hard to find them for the original project. Like doctors, we tend to bury our failures.
Very good post George. John G is right Iridium was started in 1993. In 1987, Dr Brooks, Prof. NCSU published this article under name “No silver Bullet” http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
Hi George,
I agree with everything here accept the last sentence. In manufacturing the management authority closest to the work is responsible for defining the “standard work”. In most instances this is the Supervisor not the team.
In manufacturing this works well simply because the best known way to do the work (job method) is knowable. Cause and effect can be linked, which is the fundamental assumption that lies behind PDCA.
I’ve never seen a software team get better at doing software by simply making small incremental changes to their process. Some do change their process and get better, some just get better and some change their process and get worst. The causality between process and results is difficult to prove and as we all know mere correlation is not proof.
So why are we deciding to misappropriate language from manufacturing? Especially given that it is based on a naive understanding on how manufacturing processes actually work (time and motion studies, work break down structures etc.)?
I’ve heard a phrase recently that sums it up well I think:
Premature Maturity
We seem to find it difficult to accept that we are a young industry and many of the mechanism that lead to reliable success are just unknown. And those that we think we know are unproven. So what do we do? Well just like a teenager who wants the world to think that she is all grown up and mature, we pretend. We borrow language from other professions which are much more mature then ours, and claim the same maturity for ourselves.
Personally, I tink we would be better off saying that “we don’t know”. That way we could honestly learn from our experiences and our mistakes (yes we’ve made the “standard work” mistake before, its called CMM) and eventually grow up, rather then being stuck in a perennial state of adolescence.
Cheers,
Paul.
As you say standardization is meant to be a system to produce results that is modified and improved on a continual basis.
Standards are not meant to stifle innovation. Without the other aspects of the Toyota Production System (or Deming’s thinking) being in place the result can be to hold people to what used to be done. But that is not how it is meant to be used, it is meant to be a living document that evolves and improvements are discovered. The process will put an added burden on change, as it after tests (PDSA) of the improvement then the standard should be updated (and even just keeping the standard updated is something people may not want to do).
http://management.curiouscat.net/articles/1014-Standardized-Confusion
http://curiouscat.com/management/standardization.cfm
John, let me offer the observation that standardization often impedes innovation in knowledge work. I’ve seen it repeatedly.
If you have an example of a knowledge work standardization approach that does not, please share it.