Where There's People, There's Problems

This article was first published as a guest post on Chris Spagnuolo's EdgeHopper. I re-publish it here for your convenience, and to keep my own archive complete. Oh, and I added some pictures...

I once read that "managing is harder than programming, because making people do what is needed is far more difficult than making computers do what is needed". (Don't flame me if you don't agree. I'm quoting from an unknown source here.)

This quote kept running through my mind when I recently encountered a number of, well... let's call them disciplinary challenges, like...

• Not being at a meeting, without notice, despite having accepted the request,
• Not keeping systems or task boards up-to-date with latest task/story statuses,
• Not linking code or time registration to issues or user story numbers,
• Not actively checking if there's overrun on a budget,
• Not responding to a show stopper problem within promised response time,
• Not storing project documents in the shared repository,
• Etc...

Is this a case of hanging out the dirty laundry? Not really. We're all people, employees and managers alike. We're not computers, we all make mistakes. If you don't have similar problems in your organization then I will assume you're working with robots, not with human beings.

Still, they are problems nonetheless. If my computers were this unreliable I would throw them out the window. No, actually I would carry them all the way up to the tea room in our office building, and then throw them out the window. But we don't do that with employees anymore these days. That's because managers have discovered how to be humans themselves, and they can understand the reasons for people's non-disciplined behavior, with excuses like: I-Didn't-Know-This-Was-A-Rule, Sorry-I-Forgot, There-Was-Too-Much-On-My-Mind, I-Was-Kept-Busy-With-Some-Major-Problem, I-Was-Sick, My-Dog-Was-Sick, My-Dog-Ate-My-Agenda, My-Dog-Ran-Away, and of course My-Dog-Died.

So, we all understand being human. But what to do about the problems?

One solution that people often come up with is that some supervisor should be made responsible to inspect everything. This is of course step 1 on The Road To Bureaucracy, and it is a direction that agile and lean people fervently argue against. However, other people argue that some of those steps are nevertheless very useful.

For example: Mary and Tom Poppendieck, famous for their books on Lean Software Development, argue that inspection to find defects is waste, and they call for zero-inspection. They claim that resources should be spent on preventing problems instead of fixing them, because it's cheaper.

On the other hand: Tom and Kai Gilb, famous for their work on Software Inspection (among other things), teach people how to inspect documents to find and measure defects. They even have certificates for inspection, like Inspection Leaders and Inspection Process Owners!

What's going on here?

Can these different viewpoints be aligned? Can I earn myself a certificate for doing zero inspections? Or do we have a chance of witnessing a clash between the two most celebrated family duos in software development? An epic battle between father and son Gilb against husband and wife Poppendieck?

Well, I admit that would be a sight to see...

But my guess is that their viewpoints are simply two sides of one and the same coin. Yes, preventing problems is cheaper than fixing problems, but only for 95% of the problems. In fact, it has been noted before that zero defects is the wrong approach, because preventing those last few problems is far too expensive. Which means that we have to allow some problems to flow to the next phase in the process, where detecting and fixing them can be cheaper. I discussed the staged approach to discipline in one of my earlier articles:

1. People have to show a high level of self-discipline;
2. They have a coach to help them in becoming more disciplined;
3. Their discipline must be subjected to peer pressure;
4. There should be tools to assist in mistake-proofing the process;
5. Last of all, there might be some supervisor doing regular inspections;
6. And if everything fails, the dirt will land on the manager's desk.

It is almost always cheaper to solve problems higher up in this stack. Supervising and inspecting is the final gate where problems can be detected and prevented from ending up at the manager's desk, or worse... the customer's desk. Fewer inspections are better. But zero-inspection is like full code coverage. It is a lofty goal that, in practice, is unattainable because of its exponential costs. There will always be some work left for some supervisor to inspect, certified or not.

(Oh, and if you don't agree with that... then please explain how to write a book and deliver it to the publisher with zero errors, so that the editor doesn't have to inspect it.)

So, in solving the problems I mentioned earlier, before giving work to a supervisor, I will try and make sure that I have done all I can to prevent needing him in the first place!

And of course, the principles of discipline apply to my own work as a blog writer as well... juicy title: check... teasing opening paragraph: check... re-reading ten times: check... silly jokes: check... spell-checking: check... hyperlinks and mark-up: check... great pictures: check... making fun of celebrities: check... conclusion: check... OK, ready for the next phase... Chris, will you inspect this post please?

(pictures by makelessnoise and Okko Pyykkö)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
The Complex Manifesto for Software Development
Good Tools Are Not Agile, Not Customizable, but Adaptable
The Definitive List of Software Development Methodologies