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 9 + 7 ?
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 revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“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.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”