35.tex

Warning, problems in mirror may be larger than they appear

I’ve worked on hundreds of software projects. Every one had issues that caused more problems than the team expected. Often, a small part of the team identified the issue early on and the majority dismissed or ignored it because they didn’t understand how important it really was until it was too late.

The forces at work include:
    * Issues that seemed trivial early in the project become critical after it is too late to fix them. While the boiling frog experiment may be folk-lore, it’s a useful analogy for what happens in many projects.
    * Individuals often face resistance when the rest of the team does not share their experience or knowledge. Overcoming this resistance requires unusual courage, confidence and persuasiveness. It rarely happens, even with highly paid, experienced consultants specifically hired to help avoid such problems.
    * Most software developers are optimists. Painful experience teaches us to temper our optimism, but without specific experience we tend toward optimism. Natural pessimists on development teams are often unpopular, even if they are consistently right. Few people will risk this reputation and take a stand against the majority without a very solid case. Most of us have had the "This makes me uncomfortable, but I can't explain why" feeling, but sharing it rarely wins any arguments.
    * Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
    * We all have blind spots; short-comings that are difficult for us to recognize or to accept.

Some possible strategies to counter-act these forces could include:
    * Establish an organized approach to managing risks. One simple approach is to track risks the same way you track bugs. Any one can identify a risk and each risk is tracked until it is no longer a risk. Risks are prioritized and reviewed when their status changes or when there is new information. This helps remove emotion from the discussion and makes it easier to remember to re-evaluate them periodically.
    * When going against the majority, look for ways to help the rest of the team understand more easily. Encourage any team you’re on to recognize the value in dissenting opinions and look for neutral ways to discuss them.
    * "Bad smells" are worth recognizing. If the facts aren't there yet, look for the simplest tests that would provide the facts.
    * Constantly test your understanding against the team and the customer. Tools such as a prioritized list of user stories can help but are no substitute for regular communications with the customer and an open mind.
    * Blind spots are, by definition, hard to recognize. People you trust to tell you the hard truth when you need it are a precious resource.

by Dave Quick