Fear and Rage in CI and TDD

facilitated by Dan Puckett

The greatest risk when deploying CI or TDD into a team comes from teamwork / emotional issues / "the soft stuff" rather than technical problems.

For example, a team that mostly ignores broken builds has wasted the investment they made in setting up continuous integration. You can have the sexiest test framework in the world, but it becomes useless the moment the team says, "We're too busy to write tests."

If the human factors are the greatest risk, we need to find ways of mitigating this risk if we want to succeed.

Christopher Avery's "Responsibility Model" gives us a framework for understanding how people on teams react to trouble:

The model looks like this:

• Responsibility

• Obligation

• Shame --> Quit

• Justify

• Lay blame

• Denial

People tend to start at the bottom with Denial and move upwards towards Responsibility. All of us spend some time in all of these states every day, though the proportion of time we spend in any particular state is highly individual.

The potential for learning increases as you move upwards, with the biggest jump in potential, by far, happening between Obligation and Responsibility.

This model only works for self-improvement. It's not going to work if you go to the team and say, "Ok, all of you need to be Responsible now."

That said, we can change the environment to promote and support people who happen to find themselves in a Responsible state, particularly with practices that require team support to succeed, like fixing broken builds for CI, or writing tests for TDD.

Here's some things that might help:

  Give positive reinforcement to those who demonstrate
  Responsibility.  Note that the best reinforcement comes not from
  saying "thanks," but by pointing out the positive effects that
  occurred as a result of the Responsible behavior.

  Help the team see the value in CI and TDD.  If you can
  demonstrate the value.

  Appeal to the developers' sense of professionalism.  If they can
  make a connection between, for example, writing test cases and
  "being a professional," that may help.

  Teach the Responsibility Model to the team, and teach them how to
  increase their level of responsibility using the three tools:
  Intention, Awareness, and Confrontation.  (See Avery for details.)

  Model the attribute of Responsibility yourself.  At the very least,
  it's not fair to ask others to do something that you aren't doing
  yourself.  Also, once you get a critical mass of team members who
  spend most of their time in Responsible state, it will be much
  easier to promote within the team.

  Provide the designers with feedback, in their terms whenever possible:
  This includes the monetary costs of lack of CI and TDD.  Also, show
  the team the effects their work is having on real-world customers by
  meeting the customers face-to-face.

  Tell management how much time and money they will need to allocate
  for successful CI and TDD implementation and maintenance, and get
  their buy-in ahead of time.

  Tell management that CI and TDD will be occasionally painful.  Give
  concrete examples of painful things that might happen.  Ask for
  support for the practices in advance, to discourage going back to
  the old way of doing things in emergencies.