http://citconf.com/wiki/api.php?action=feedcontributions&user=Danpuckett&feedformat=atomCitconWiki - User contributions [en]2024-03-29T14:44:14ZUser contributionsMediaWiki 1.35.11http://citconf.com/wiki/index.php?title=CITCONUS2010Registrants&diff=7764CITCONUS2010Registrants2010-04-17T22:48:22Z<p>Danpuckett: New page: [http://www.danpuckett.org/ Dan Puckett] - Agile Coach</p>
<hr />
<div>[http://www.danpuckett.org/ Dan Puckett] - Agile Coach</div>Danpucketthttp://citconf.com/wiki/index.php?title=CITCONUS2010Sessions&diff=7739CITCONUS2010Sessions2010-04-17T20:30:27Z<p>Danpuckett: </p>
<hr />
<div>The notes from sessions go here. Please create one page per session.<br><br />
<br />
[[Value of Automated Acceptance testing]]<br />
<br />
[[Is Scrum Evil]]<br />
<br />
[[Continuous Deployment]]<br />
<br />
[[Backyard Beekeeping]]<br />
<br />
[[Fear and Rage in CI and TDD]]<br />
<br />
[[Automated Workspace Setup]]<br />
<br />
[[Metrics on and generated by CI]]<br />
<br />
[[How to do without a CI Server]]</div>Danpucketthttp://citconf.com/wiki/index.php?title=Fear_and_Rage_in_CI_and_TDD&diff=7738Fear and Rage in CI and TDD2010-04-17T20:29:40Z<p>Danpuckett: </p>
<hr />
<div>'''facilitated by Dan Puckett'''<br />
<br />
The greatest risk when deploying CI or TDD into a team comes from<br />
teamwork / emotional issues / "the soft stuff" rather than technical<br />
problems.<br />
<br />
For example, a team that mostly ignores broken builds has wasted the<br />
investment they made in setting up continuous integration. You can<br />
have the sexiest test framework in the world, but it becomes useless<br />
the moment the team says, "We're too busy to write tests."<br />
<br />
If the human factors are the greatest risk, we need to find ways of<br />
mitigating this risk if we want to succeed.<br />
<br />
Christopher Avery's "Responsibility Model" gives us a framework for<br />
understanding how people on teams react to trouble:<br />
<br />
The model looks like this:<br />
<br />
* Responsibility<br />
<br />
* Obligation<br />
<br />
* Shame --> Quit<br />
<br />
* Justify<br />
<br />
* Lay blame<br />
<br />
* Denial<br />
<br />
People tend to start at the bottom with Denial and move upwards<br />
towards Responsibility. All of us spend some time in all of these<br />
states every day, though the proportion of time we spend in any<br />
particular state is highly individual.<br />
<br />
The potential for learning increases as you move upwards, with the<br />
biggest jump in potential, by far, happening between Obligation and<br />
Responsibility.<br />
<br />
This model only works for <i>self</i>-improvement. It's not going to work<br />
if you go to the team and say, "Ok, all of you need to be Responsible<br />
now."<br />
<br />
That said, we can change the environment to promote and support people<br />
who happen to find themselves in a Responsible state, particularly<br />
with practices that require team support to succeed, like fixing<br />
broken builds for CI, or writing tests for TDD.<br />
<br />
Here's some things that might help:<br />
<br />
Give positive reinforcement to those who demonstrate<br />
Responsibility. Note that the best reinforcement comes not from<br />
saying "thanks," but by pointing out the positive effects that<br />
occurred as a result of the Responsible behavior.<br />
<br />
Help the team see the value in CI and TDD. If you can<br />
<i>demonstrate</i> the value.<br />
<br />
Appeal to the developers' sense of professionalism. If they can<br />
make a connection between, for example, writing test cases and<br />
"being a professional," that may help.<br />
<br />
Teach the Responsibility Model to the team, and teach them how to<br />
increase their level of responsibility using the three tools:<br />
Intention, Awareness, and Confrontation. (See Avery for details.)<br />
<br />
Model the attribute of Responsibility yourself. At the very least,<br />
it's not fair to ask others to do something that you aren't doing<br />
yourself. Also, once you get a critical mass of team members who<br />
spend most of their time in Responsible state, it will be much<br />
easier to promote within the team.<br />
<br />
Provide the designers with feedback, in their terms whenever possible:<br />
This includes the monetary costs of lack of CI and TDD. Also, show<br />
the team the effects their work is having on real-world customers by<br />
meeting the customers face-to-face.<br />
<br />
Tell management how much time and money they will need to allocate<br />
for successful CI and TDD implementation and maintenance, and get<br />
their buy-in ahead of time.<br />
<br />
Tell management that CI and TDD will be occasionally painful. Give<br />
concrete examples of painful things that might happen. Ask for<br />
support for the practices in advance, to discourage going back to<br />
the old way of doing things in emergencies.</div>Danpucketthttp://citconf.com/wiki/index.php?title=CITCONUS2010Sessions&diff=7722CITCONUS2010Sessions2010-04-17T17:18:16Z<p>Danpuckett: </p>
<hr />
<div>The notes from sessions go here. Please create one page per session.<br><br />
[[Value of Automated Acceptance testing]]<br><br />
[[Is scrum Evil]]<br><br />
[[Continuous Deployment]]<br><br />
[[Backyard Beekeeping]]<br><br />
[[Fear and Rage in CI and TDD]]<br></div>Danpuckett