People vs. Process

Software pundits debate whether it is more beneficial to focus available time and effort on improving software process or on hiring great people. Which is really better?


“Hey,” I said to a colleague. This was at a point in time when he and I had been working with some people in common, and those people had led me to consider Kanban for our team.

After looking into it more, I had bought in to Kanban’s possibilities. It specifically addressed the main problem we were having: bottlenecks. It organized work, not people, leaving the team free to experiment with their own solutions and work toward process improvement without any artificial constraints. Besides Kanban’s rapid board, I was hoping our team could leverage some of the other philosophies of Kanban to improve how quickly and how well we responded to customers.

“I’m pretty excited about this Kanban thing,” I told my colleague. “It should put some visibility on key problems.”

“Really?” he said, with a somewhat sour look on his face. “I don’t know. There’s no silver bullet process.”

I nodded, waiting for some follow-up statement. I didn’t expect Kanban to be a “silver bullet.” I was looking forward to the problem-solving we would do after everyone got on the same page around Kanban. At the same time, that wasn’t the response I expected. Where was he going with this? Did he think Kanban was a bad idea?

“I always look for the people,” he finally continued, no doubt noticing the quizzical look on my face. “I worked twenty years at ______…” (A very large software company that everyone recognizes.) I continued nodding, listening. “If you bring good people in, that’s when you get results. Hire right and it doesn’t matter what process they use.”

By then, I’m sure I had a raised eyebrow. Was this really what this guy thought? People were all that mattered? Everything? Wasn’t that a “silver bullet” in itself? What a tragedy. He continued to talk about how he interviewed people and what he looked for in candidates. He stressed over and over that he didn’t think or care much about process. Apparently, he was okay with our move to Kanban, but just barely. He wanted the opportunity to tell me, essentially, that moving to Kanban wasn’t going to change anything about our quality or our ability to respond to customers.

The sad part about this was that there had been a small exodus of our top talent recently. Come to think of it, that may be why he was thinking so much about the hiring process. Yet surely he couldn’t have missed the contradiction in his rant? Here he was saying that if we just hire the right people, it doesn’t matter what process we use, and meanwhile the right people were getting bogged down by the process and eventually leaving.

The truth is people are not the enemy of process, or vice versa. Where does simplistic, binary thinking like this come from? Either, or both, can be factors in a bigger picture, but quite frankly when your team desires to improve the processes they are working in, especially with something like Kanban which is focused on process improvement, it is not time to lament that you don’t have good enough people working for you. Or to brag that the way you are hiring is what is going to make the difference instead. There should be no conflict here at all. It’s an imaginary dichotomy. You should embrace both better people and better processes with enthusiasm!

In Professional Software Development by Steve McConnell, he addresses the issue head on:

Software pundits often spend time debating whether process is good or individual empowerment . . . might be better. This is a false dichotomy. Process is good, and so is individual empowerment. The two can exist side by side. [p. 26]

An example Kanban board in JIRA, from the JIRA blog.
An example Kanban board in JIRA, from the JIRA blog.

Can process make a difference in a software business, though? Of course it can. Actually, Kanban specifically has been known to transform not only businesses in the software industry, but many industries beyond, including, most famously, the auto industry where it seems to have gained the most popularity. In Lean Software Development by Mary Poppendieck and Tom Poppendieck, they recount a particularly convincing case study:

In 1982, General Motors closed its Fremont, California, plant. No one was surprised; the place was a disaster. Productivity was among the lowest of any GM plant, quality was abysmal, and drug and alcohol abuse were rampant both on and off the job. Absenteeism was so high that the plant employed 20 percent more workers than it needed just to ensure an adequate labor force on any given day. The United Auto Workers local earned a national reputation for militancy; from 1963 to 1982, wildcat strikes and sickouts closed the plant four times. The backlog of unresolved grievances often exceeded 5,000.

Two years later, the same plant was reopened by New United Motor Manufacturing, Inc., or NUMMI, a joint venture between Toyota and GM. Toyota managed the plant but was required to rehire the former GM employees. Eighty-five percent of the hourly workers were from the former GM plant, including the entire union leadership.

Within two years, NUMMI’s productivity was higher than any GM plant–double that of the original plant. Quality was much higher than any GM plant and nearly matched Toyota’s Japanese plants. Absenteeism was down to about 3 percent, and substance abuse was a minimal problem. In 1991, after 8 years of operation, a total of only 700 grievances had been filed, and 90 percent of the employees described themselves as “satisfied” or “very satisfied.”

Clearly, the process that workers have to follow can be bad, and sometimes bad enough that they want to leave a company or file over 5,000 grievances. They spend further time explaining why there was such a remarkable turnaround:

The first thing the managers at the NUMMI plant did was get stopwatches for everyone, and they taught workers how to design their own jobs. All work at NUMMI is done in teams of six to eight people, one of whom is the team leader. The team designs its own work procedures, coordinating work standards with teams doing the same work on alternate shifts. Management’s role is to coach, train, and assist the teams. Engineers are available if the team wants to call on them, but fundamentally, each team is responsible for its own procedures, its own quality, for job rotation within the team, and for smooth flow of parts from upstream and to downstream teams.

As you can see, the other side of the story is when the process aids the people involved in being the good hires that they actually are. What a difference that can make!

So should you try to find good people? Or should you work for process improvement?

Can’t you do both?

Leave a Reply

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