Recent events on a project brought this snippet of dialogue from the Peter Cook and Dudley Moore "Frog and Peach" sketch to mind:
Interviewer: So, Mr. Grebe-Strebling, would you say you have learned from your mistakes?
Mr. Grebe-Strebling: Oh yes, very much so, and if called upon we could repeat them almost perfectly.
We all make mistakes; there isn't a project in the world that couldn't have been improved in some way or other, although identifying exactly what could have been done to improve them is always a matter of conjecture; similar to time-travel paradoxes - you can't go back and change one thing only as it may have unexpected ramifications elsewhere. If you had caught that hidden bug that only presented itself after deployment, who's to say it wouldn't have been at the expense of missing something else instead, or that raising it might have distracted the development team and derailed the delivery timeline? What's most important is recognising where decisions that were made seemed to lead to a particular problem; that gives an opportunity to try something different the next time to see if improvements can be made.
My son's school has a nice way of putting this: a FAIL is a First Attempt In Learning. Yes, we are getting things wrong; but the self-awareness of understanding this means we are able to take steps to sort it out. A naive belief that everything we do is correct is far more detrimental than a healthy dose of realism. Nobody's perfect - least of all those who think they are.
Retrospectives are a great way to diagnose failures, especially when they are entered into in the correct spirit - not as a finger-pointing one-upmanship exercise, but a way to identify weak points in the overall process that everyone can help to try and resolve. In my experience it's rare that an error is made maliciously (either through laziness or lack of ability); the cause is more likely to be time pressure, inadequate specification, miscommunication/misunderstanding or just plain oversight. Taking time to dig deeper into issues with all the affected parties present can give some surprising insights into the pressures and problems your co-workers from other disciplines have to face; it's often only when processes are examined closely that interdependencies become apparent. For example, a developer may think that the naming of components in a CMS is not important as long as the required elements are present; but if they are shown how the name is the only thing the tester has to match CMS to specifications/designs they are more likely to use the designated terms (or at least supply a table of cross-references).
Mistakes are part and parcel of everyday life, it's how we handle them that makes the difference. As the proverb says, "To err is human; to forgive divine". Burying your head in the sand and pointing the finger at everyone else will just lead to more failures. And that's the biggest mistake of them all.
Interviewer: So, Mr. Grebe-Strebling, would you say you have learned from your mistakes?
Mr. Grebe-Strebling: Oh yes, very much so, and if called upon we could repeat them almost perfectly.
We all make mistakes; there isn't a project in the world that couldn't have been improved in some way or other, although identifying exactly what could have been done to improve them is always a matter of conjecture; similar to time-travel paradoxes - you can't go back and change one thing only as it may have unexpected ramifications elsewhere. If you had caught that hidden bug that only presented itself after deployment, who's to say it wouldn't have been at the expense of missing something else instead, or that raising it might have distracted the development team and derailed the delivery timeline? What's most important is recognising where decisions that were made seemed to lead to a particular problem; that gives an opportunity to try something different the next time to see if improvements can be made.
My son's school has a nice way of putting this: a FAIL is a First Attempt In Learning. Yes, we are getting things wrong; but the self-awareness of understanding this means we are able to take steps to sort it out. A naive belief that everything we do is correct is far more detrimental than a healthy dose of realism. Nobody's perfect - least of all those who think they are.
Retrospectives are a great way to diagnose failures, especially when they are entered into in the correct spirit - not as a finger-pointing one-upmanship exercise, but a way to identify weak points in the overall process that everyone can help to try and resolve. In my experience it's rare that an error is made maliciously (either through laziness or lack of ability); the cause is more likely to be time pressure, inadequate specification, miscommunication/misunderstanding or just plain oversight. Taking time to dig deeper into issues with all the affected parties present can give some surprising insights into the pressures and problems your co-workers from other disciplines have to face; it's often only when processes are examined closely that interdependencies become apparent. For example, a developer may think that the naming of components in a CMS is not important as long as the required elements are present; but if they are shown how the name is the only thing the tester has to match CMS to specifications/designs they are more likely to use the designated terms (or at least supply a table of cross-references).
Mistakes are part and parcel of everyday life, it's how we handle them that makes the difference. As the proverb says, "To err is human; to forgive divine". Burying your head in the sand and pointing the finger at everyone else will just lead to more failures. And that's the biggest mistake of them all.
Comments
Post a Comment