Archive
Pre-mortems in practice
I have recently started to use an exercise from Gary Klein’s very good book The Power of Intuition. This exercise is called a Pre-mortem, if you have lead or participated in a Post-mortem or an AAR then you can easily grasp this idea.
Essentially you and your project participants imagine that many months have passed and that your project has catastrophically failed. You have to make it clear, things have gone badly, very badly. But you say we do not know why. Gary suggests using a mythical crystal ball – I have found that this whimsy helps people relax and works to lighten the mood. However you explain the scenario just be certain to tell them a story which puts the participants in a mind set which allows them to accept that they have failed. This allow their minds to begin searching the present patterns in the project to find the sources of this horrible failure.
You then proceed as if you were performing a post-mortem, except that everyone is using their imaginations and drawing upon their past experiences to tell a story about what could happen. A real key to success here is to force the participants to describe specific scenarios – draw out the details and you can really surface your likely key challenges. However if you allow for vague platitudes like “lack of management support” or “budget cuts” you will not maximize the potential of this exercise.
Instead strive to get colorful, yet plausible scenarios like “server hardware too small due to unforeseen data on Foo server” or “competing project XYZ stole key contributor Bob McCodes aLot”. Being specific forces the participants to focus on things that can really happen which you can probably do something about, whereas vague causes of failure generally can not be fixed.
This has fantastic results and really allows people to accept the possibility of failure without getting stuck in a blame game or analysis paralysis. I have found that this exercise can allow people to prepare for the possibility of failure much more effectively than merely generically reviewing plans for risks and arriving at luke warm mitigation.
Bonus points if you review this list with your project team at least once a month to keep the possibility of failure fresh in their minds and allow those minds to keep looking for early warning signs which will show up if you are on the wrong track.
Skills Acquisition
This post is a work in progress for an article about how people develop and acquire skills and what skills are particularly important for software developers…
Before we start with the specifics it is useful to examine the higher order ideas of skill acquisition and then apply those to the skills germane to software developers. A useful framework to describe this process is called the Dreyfus Model.
This model segments up the different stages of skill acquisition into distinct levels: novice, advanced beginner, competent, proficient, and expert. As we progress through the levels of capability with a given skill we move from having our analysis and actions governed by rules, to using nuanced conditional rules, to using varying levels of pattern matching, to finally fully internalizing our experiences into invariant mental representations. Experts then match these patterns against what they observe and then intuit the correct action.
The result is that experts develop an intuitive understanding of a given skill and corresponding domain. One of the interesting consequences for domain experts is that they often have difficulty explaining why they know what will happen and why they should do what they are going to do. This difficulty is caused because experts use their intuition to both understand and solve problems. Experts are often struck by certain knowledge that what they are going to do will work, but not know why. A second notable byproduct of increased skill maturity is an increase in the practitioners sense of inborn responsibility to their craft and the job at hand. True experts can usually be recognized by both their sense of responsibility and their intuitive understanding of their craft.
It is also important to recognize that experts are often the worst teachers of novices. Both novices and experts process information in very different ways: novices need rules, experts need concepts and contexts. Techniques that work when teaching a novice are maddening to an expert, and vice-versa.
The five skills or domains used during the development of correct, quality software are: analysis, specification, design, implementation, and testing. Three additional skills crucial to working in a team are: communication, documentation and planning. Growth in each of these areas is required to mature developers from novices to experts and should be used to measure the progress of developers as they expand their responsibility and influence within their teams and broader organization.
In conclusion we must focus on specifying experiences, capabilities, and responsibilities which will implicitly cross cut against the skills we desire and which we believe will have inculcated the level of maturity needed to perform the job being proffered.
About Me
Misc
Complexity, Agility and Resilience. 