Mar-3-2009

Guest Post: Where there’s people, there’s problems

Post written by Jurgen Appelo. Follow Jurgen on Twitter 3 comments

Guest Post by Jurgen Appelo:

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.

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?

About Jurgen Appelo

Jurgen is the Chief Information Officer at ISM eCompany, rated (a while ago) as the #1 fastest growing technology company in The Netherlands. As a manager, he leads a horde of 100 software developers, development managers, project managers, business consultants, quality managers, service managers and kangaroos, some of which he hired accidentally.  He also write a blog called NOOP.NL: A Guide to Development, Management, Things & Stuff.

Share on Facebook
Post to Google Buzz
Bookmark this on Yahoo Bookmark
Share on FriendFeed
Bookmark this on Digg
Share on reddit
Share on LinkedIn
Share on StumbleUpon
Bookmark this on Delicious

  1. Stephen F. Heffner said,

    Isn’t peer review a form of inspection?

    I believe a significant part of the answer is in automating the inspection process. As the author of a software engineering automation meta-tool, I’m deeply involved in the automation of every aspect of software engineering, including analysis, re-engineering, and translation to a different language. What’s needed, IMHO, is a powerful meta-tool, not a bunch of rigid “point solutions”. A meta-tool allows you to create your own automation tools rapidly and with low effort.

    Another advantage of automating software engineering is that it reduces bugs in the first place. Once you get the automation rules right, the meta-tool won’t introduce bugs.

  2. Vasco Duarte said,

    I think that you are missing a very important point that basically invalidates your argument altogether.

    If you could achieve Zero Defects your process would be much faster infinitely cheaper!

    Here’s my argument: http://bit.ly/15lkle

  3. Jurgen Appelo said,

    @Vasco:

    Sorry, but your arguments are flawed.

    One example: “blind spots” or “editing blindness” where people are unable to see the errors in their own work because they’ve been working on it for so long.

    The only possible solution is to have someone else inspect (or review) the work. This person will find errors 10x faster than the author himself. Which evidently makes the inspection cheaper than trying to deliver with zero defects.

    Sure, TDD can alleviate some of that problem. But I don’t see how to unit test my documents, or my book, or my blog posts.

Add A Comment

 


Creative Commons License
©2011 Edgehopper.com. Please don't copy me, it's bad karma.
Edgehopper by Chris Spagnuolo is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.