Acknowledge (and Learn from) Failures

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve.
+
As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve. The sooner everyone knows the true state of things, the sooner you can correct and be sure that the customers get the software that they really wanted.
-
Telling people what they expect to hear just defers the inevitable.
+
Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest.
-
This applies to large things like iteration reviews as well as small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought.
+
Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example.
 +
 
 +
Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.
 +
 
 +
Not being honest about your failures also denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.
 +
 
 +
Agile methods are based on this sort of frequent, honest, feedback, but you need not just apply this idea to daily standup meetings and iteration reviews. It also applies to small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought, or admitting that you don't know the answer when someone asks yo a question.
 +
 
 +
By [[Steve Berczuk]]

Revision as of 22:19, 28 November 2008

As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve. The sooner everyone knows the true state of things, the sooner you can correct and be sure that the customers get the software that they really wanted.

Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest.

Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example.

Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.

Not being honest about your failures also denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.

Agile methods are based on this sort of frequent, honest, feedback, but you need not just apply this idea to daily standup meetings and iteration reviews. It also applies to small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought, or admitting that you don't know the answer when someone asks yo a question.

By Steve Berczuk

Personal tools