Danpuckett at 20:29, 17 April 2010

2010-04-17T20:29:40Z

205.232.67.226: New page: 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 br...

2010-04-17T20:27:45Z

New page: 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 br...

New page

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 <i>self</i>-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
<i>demonstrate</i> 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.

← Older revision		Revision as of 20:29, 17 April 2010
Line 1:		Line 1:
		+	'''facilitated by Dan Puckett'''
		+
	The greatest risk when deploying CI or TDD into a team comes from		The greatest risk when deploying CI or TDD into a team comes from
	teamwork / emotional issues / "the soft stuff" rather than technical		teamwork / emotional issues / "the soft stuff" rather than technical

Fear and Rage in CI and TDD - Revision history

Danpuckett at 20:29, 17 April 2010

205.232.67.226: New page: 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 br...