On at least one of our Scrum projects the daily Scrums aren’t popular with the developers on the team. My best guess is that they need to adjust their format a bit. Typically the developers just read off the spreadsheet numbers on their tasks:

They were of the opinion that maybe they only needed one or two Scrums per week. My top of the head suggestion was maybe they needed to adjust how they ran the Scrums. Perhaps trying to focus more on just finished tasks and stop worrying so much about exact hours. The point of the Scrums are to sync up the team and share information, not feel like drudgery.

I’ve finally gotten around to reading The World is Flat since I’ve had some downtime recovering from a nasty flu. It’s one of those talked about business books that you sort of need to read so you know when people are referring to it. Very simple synopsis is that everything in the world can now be outsourced and so competition is global. Then think of 500 pages of anecdotal examples.

Turns out AJAX has so much hype it even ends up in the book:

Because these tools are delivered over the Internet and written in standard Web formats, they are accessible to anyone who has an Internet connection and are easily interoperable with any business. What enables work flow at this level is AJAX, a Web development technique that allows complex Internet business applications to be embedded into a Web page, then called up with a simple browser and accessed as easily as viewing a page on Amazon.com.

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.