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.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
145 City Rd
London
EC1V 1AZ
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.