Fingerpointing

Scot Witt, Friday, January 11, 2008 @ 10:13 am

My index finger is about to explode.

Some clients  cling to the 'us versus them' mentality of old school
development. You know:

Them: "It says here in your very own document that when I click <Massage> the back panel of my chair would start vibrating, and it doesn't! Fix it!"

Us: "But the master document clearly states you need to install a Yamahoochi 45697 Vibrating Chair Back for this to operation correctly"

Them: "Where?"

Us: "Master Document 123, Section 56, Hardware Requirements, Sub 876, Chair Backs, sentence two."

Them: "What page was that again?"

Hoisted by his own petard indeed.

I was reminded of this recently when I asked a client why
his team was doing the fourth review of a specification about which we
just ended an hour long conversation. Her comment was, the
specification didn't accurately represent field which
they wanted set to read only. Originally they wanted to be able to change it.

My fault. The specification was written 9 weeks before, the client never reviewed it (nor did the development team). The changes were minor and the conversation had nothing to do with the field.

So the client initiated another full blown review of the specification, four days before we're supposed to start prototyping it.

I missed two areas I should have changed. The other four, I changed.

I am reminded getting everyone on the same team with the same dedication to assisting
everyone else appears to be an never ending
goal.

In a former life, I was a Senior Technical Writer on the Cause Team for a chemical gases company that had some fabulous tools for determining root causes.

Very good idea.

Very kewl explosions.

It turns out that checking to see if an LP cylinder is empty with your cigarette lighter is not a really smart thing to do.

And it's a really bad idea to lay blame and be done with it.

On an Agile Team, when fault occurs, no one's happy. The better idea is to ignore the person and deal with the fault.

1. Find the fault (what happened?)
2. Figure out the cause (why did it happen?)
3. Repair the fault (repair how it happened)
4. Make sure the fault cannot occur again.

My Six Sigma Green Belt is pulsating contentedly. Not so strange. The idea behind Six Sigma was Motorola's desire to reduce manufacturing faults to three per one million units produced. The mathematician/Speakers of Greek tell me that's what Six Sigma means. I just took a seminar, filled out a 34 page application and took a test- I dread the thought of getting a Black Belt.

When a team is developing something brand new, we're in a creative thinking space, Much of the time, some of the holes of the new pieces don't match up on the machine. Or the client remembers or sees something else that absolutely positively has to be included. Or we can make the end user's job easier and make them more productive in user testing .

So the Development Team rarely points fingers. In fact, most of the time I've seen the developer whose work is brought into question turn bright red and pressures him or herself to get a fix as quickly as possible. Everyone on the team looks for answers. And everybody learns as well. That's one of the reasons Agile Methodology for medium and small projects works best with highly motivated and senior level folks.

Which means I'm gonna keep my mouth shut, fix the specification and get back to the other stuff I have to do.

You'll have to excuse me for a little while, though.

I'm gonna go find an Ace bandage, soak it with water and apply it to my index finger so it doesn't explode.

Technorati Tags: fault finding six sigma team

Powered by ScribeFire.

tech development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment