The Braidy Tester reports on how he tried to institute Agile on a team in short order. After presenting a bunch of practices including pairing, mini-milestones, and people working on fewer features at time he waited for management to respond. Management’s response:

In case you hadn’t guessed, none of my suggestions were enacted.

I can be pretty dense sometimes, but I got the message.

He explains that the great part was that by going back and arguing his points on an individual basis and just continuing to lobby, many of his suggestions did get implemented in the long term.

My experience has been that the incremental approach has worked in practice where wholesale adoption of Agile would have failed. The best part has been is that when people come to the realization on their own that a particular practice makes sense and adopt it on their own.

Whole hog, rapid adoption of Agile practices like TDD, acceptance tests, refactoring, user stories, collocation, etc is still intellectually appealing. Since it only takes three weeks to form a new habit you can possibly move a team into Agile very quickly if you can enforce everything. I just haven’t been in a position to experiment with this approach, and I do fear it may backfire in many work cultures. Still it’s an experience I’d like to have someday.

Our builds are failing today on one project. They’re failing because one of the developers asked me to turn on a Clover failure target. Now if the unit test coverage falls below 75% the build fails. The 75% number was fairly arbitrary, but you have to pick something.

The fact that we’ve made it to this point is both a good and bad sign:

• Good, because the team is insisting on a certain level of coverage.
• Bad, because they’re still adapting to TDD. Essentially on each Sprint they’re writing a few unit tests up front, then a lot of JSF code, and then catching up on the unit tests at the end.

Our eventual solution has to be to switch over to real TDD and not leave most of the unit tests for the last part of the Sprint. Hopefully forcing builds to break if things slip will help with that for the next Sprint.

Turns out my problem with getting ruby to recognize the xml-simple rubygem was solved by a simple require statement:

require 'rubygems'

Configuration issues are so often the bane of programming. Anyway the necessity for this is explained here as in RTFM.

I like Ruby gems, I can see the resemblance to Perl’s old CPAN idea. CPAN always drove me crazy since everything you pulled down then had say 8-10 more libraries that it required. Till this day I still avoid often avoid perl just because of the pain of constantly installing libraries to get simple things to work.

I ran into one of those too easy to go wrong type problems. Just two easy steps to use XmlSimple:

1. 1	sudo gem install xml-simple

2. Run a ruby script with <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

   1	require 'xmlsimple'

   </div>
   

Two hours later I still get the same useless error that doesn’t really have any google hits:

`require': no such file to load -- xmlsimple

This week I scheduled a Sprint Planning Meeting to select the backlog on a project. Our normal time box for this meeting is about 4 hours. Since this is the 4th Sprint for this project and these meetings have generally only been going 90-120 minutes in the last few planning meetings I actually scheduled the meeting for only 90 minutes.

When the meeting happened we got into some important discussions around the Sprint goal and the largest feature for Sprint #4. Unfortunately much of this discussion really got going the last 30 minutes of the meeting. We couldn’t extend the meeting since the product owner had other meetings to attend, so we came to a quick conclusion and agreed to a slightly vague goal.

The lesson here is you’re better off sticking to a half day schedule for the meeting even if you get through it in less time for most Sprints. I compounded the issue with only setting up the meeting a week in advance so I really couldn’t find a 4 hour window for the meeting at that point. Lessons learned.