Comments on: Aim at a developer, shoot the team

by: AhtiK

Sun, 01 Oct 2006 19:46:46 +0000

I see blaming often as an inhumane and unprofessional way of trying to urge people to find the real cause.

“What went wrong, how can we improve ourselves next time?”
vs
“You have 50% of bugs still unfixed and we supposed to be live since yesterday and client is paying less than we pay you and your shirt stinks!”

Blaming is like irrogant problem statement without cause-analysis from a distance and doing this in a bossy way

by: Blanka

Tue, 26 Sep 2006 11:59:14 +0000

Blaming and punishing should really be the last option. The worst about it is that is sends this message to the team: don’t try anything new because if you fail for any reason, you will be punished. Why should someone give the very best of him, his creativity, for a fair chance to be ridiculed later?

by: Tim Williscroft

Mon, 25 Sep 2006 22:16:26 +0000

You might find solace in the works of W Edawards Deming.
(The TQM guy)
The first rule of TQM is “Drive out fear”

It works for manufacturing, why couldn’t it work for software.

by: Kristjan Kanarik

Mon, 25 Sep 2006 10:12:50 +0000

Right on point, Imre. During last 10 months I’ve been in a major client facing role (analyst/PM) and when something has gone wrong, I’ve been asked a number of times “how could that have happened? who is to blame?”. I mean, come on, does someone actually include “looking for victims and punishing them, softly” as an activity in the project plan? Not so.

Same goes for any other activity that hasn’t been planned for - even refactoring which Karel has bashed about, endless optimizing (probably Karel has bashed about that as well! etc. If it isn’t sensible (doesn’t create value for the customer), don’t do it.