Sunday, March 7, 2010

Discover Your M&M Early Warning System

Dan and Chip Heath, the authors of the best selling "Made to Stick" and "Switch", wrote a clever article in this month's Fast Company titled: "Business Advice From Van Halen." The famous rock band developed their very own early warning system for detecting problems (especially big ones). As the article states it "was the canery in the coal mine." How did they did do it?... by requesting a "brownout" of M&Ms. The article is definitely worth the read. The ingenuinity of Van Halen, and the Heath brothers' point, was determining problems early on with your projects can be simple and effective.

In keeping with my theme of my last two posting regarding agile approaches to technology development, I have my own set of tools that detect early warning signs of tactical or strategic problems with the project(s) and/or the organization. Tactical warning signs detect a team's trouble with their immediate deliverables. Solutions for addressing these issues can usually be easily solved. Strategic warning signs reveal more serious organizational problems with either the team or the overall larger company and are more difficult to address. These issue can stem from cultural differences, management weakness, and lack of focus. Here are some examples of tactical and strategic warning signs:

Tactical Warning Signs for Projects:
  • Decreasing scope/committments during iterations, or worse under-delivering to your customers/sponsors.
  • Tasks that span longer than the planned effort, especially those that were estimated to be relatively simple.
  • Impediments to the iteration's committments revealed during daily stand-ups and retrospectives.
Strategic Warning Signs for Projects and the Organization:
  • Missing vision/goals for the project and it's iterations.
  • Velocity for the highly prioritized features of the project are considerably low (regardless of the overall velocity for all work completed by the team, which may include effort spent on items outside of the focus of the particiular iteration).
  • Large spikes of scope increases over the course of several iterations during the project.
  • Lack of consistency in following/practicing the agreed to agile practices.
  • Morale, team dynamics, organizational changes, and other soft management issues discovered during team retrospectives and/or one-on-ones with individual team members.
Tools such as leveraging velocity tracking, release goals, and prioritization are great ways to quickly assess the state of your projects. More importantly though is maintaining the pulse of your teams. At the end of the day, the two most effective ways to measure a team's strategic success is through your retrospectives and individual one-on-ones. Nothing replaces the human aspect of building rapport with your team members. I've personally witnessed managers lose entire teams through a domino-effective of voluntary attrition for lacking this crucial element to their management approach. All your hard reporting and tracking methods in the world will never provide you with the health status and morale of your teams without relationships built through conversations.

Israel Gat, The Agile Executive, shares his own thoughts on early warning signs for agile projects. Definitely a recommended read.

1 comment:

  1. (Re-produced from


    I'm in complete agreement with the emphasis your article gives to team dynamics. All the tracking tools available to project managers, PMOs and sponsors tell of trouble that has already happened, rather than warning of trouble to come. Of course a project which has started tracking behind schedule or over budget is likely to keep heading in that direction, but point is that the trouble has already started by the time it is reported.

    To truly predict trouble, I agree with you that the key lies in people. Only people can deliver a project. All the methodologies, tools, facilities and techniques in the world will not produce a single deliverable. If the people whose performance you rely on are not confident of delivering, then trouble is ahead.

    Similarly, if external confidence in the project is shaky, the 'safe' environment for the project will erode, resources and engagement will evaporate, and it will become impossible to deliver.

    I guess I'm saying that confidence is my special sauce for predicting trouble. Confidence is not something that can be measured with a tool, tracked in a risk register or reported at every steering committee meeting. Which is not to say a good project manager can't make a valid assessment of the confidence in the project - perhaps by asking themselves a few questiions:

    Does everyone in the project team understand what the project is trying to achieve, and how?

    Does the steering committee/project board understand what the project is trying to achieve, and how?

    Do the team and the steering committee/project board have the same understanding?

    Does the team have a plan for delivering the project, and does it make sense?

    Is the team passive, waiting to be told what to do, or is the team passionate and capable of driving themselves forward?

    Is the steering committee/project board allowing the project manager to manage and involving itself in decision making, or is it tending toward micro-management and disempowering the project team?

    If the answers to any of these questions (I'm sure you could think of more) come out badly, then trouble is likely to be around the corner.

    David Gibbons