Friday, July 4, 2008

From the ashes of failure

Previously, I wrote on fearing failure for lack of trust. Failure is a seemingly endless and interesting topic but since I've been diagnosed with NADD (thanks Rands), I doubt I'll write about it beyond this post. To wrap this topic up with a nice little bow, it seems useful to discuss how to leverage failure into success.

A strong team will self organize, Agile development is generally founded on this concept. So why then does a highly skilled and motivated team fail? Well, that is complex but a few common reasons for failure include:
  • Fear of saying no to customers or executives. Nobody wants to appear unskilled, slow or inadequate.
  • Unrealistic goals. Tight time lines from hard milestones, many known risks, incomplete planning and undefined issues are all indicators of unrealistic goals.
  • Poorly defined goals. When project goals are unclear and requirements are subjective, your running full speed at a brick wall.
  • Poor estimation skills. Software is more art than science at times and even the best, brightest and most experienced developers commonly fail to estimate task level of effort. It is always a good idea to remember the definition of an estimate.
  • Lack of cohesion in the team.
  • Wrong skills on the team.
  • ...
Once failure has occurred, the only way to improve is to own it, dissect the situation and share it with others. Seriously, developers have to get over themselves for this one. This is one time ego's can't be allowed to win. So, how do we ensure failures are not repeated in organizations? The steps are relatively easy but execution of them is progressively challenging:
  • Identify. Do a full autopsy of the successes and failures as a team. Get your team in a room and walk through the project from inception to post release. Some companies call these meetings recaps or postmortems. It doesn't matter what you want to call them as long as you do it. Michael Greer has a good set of primer questions every team should ask themselves.
  • Document. Spell important issues out in painful detail. This is the pitfall feed back to use to avoid problems and the successes you must actively try to recreate in your future projects.
  • Share. Broadcast what you learn so others uninvolved can learn by proxy.
  • Support. This is the most important step, it is where the rubber meets the road. If you learned that some of your basic process is misinformed, you need support from other teams and management. If you can't get support for change, you will have to become super creative or you will be doomed to repetition. In my experience, this is where organizations fail to learn the most. We make mistakes, identify, document, share and then fail to get actionable support. Lots of lip service for change but not real change. So we lather, rinse and repeat while frustrations across the organization mount.
I've found that there are ancillary actions that help organizations avoid serious failures as well. First, retain your employees. Employee turn over will condemn the organization to repeat mistakes. I'm not suggesting you retain everyone, just the people that matter. From where I am sitting, I don't know who that is in your company but you do. Second, protect historical knowledge through documentation. I don't mean 100 page MS-Word documents, I have yet to see that work. Tailor something to work for your organization. I have always found faq-o-matics and wiki's encourage frequent updates and collect useful data. Finally, cross-pollinate by mixing up your team members between projects. This allows people with recent knowledge to seed new teams and supports the idea of sharing project learning.