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:
- Shame --> Quit
- Lay blame
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.