Sitting in my cube at work at 8:30pm on a Saturday it hit me. I really need to work on my delegating skills.

After catching up on a bunch of todo items, notes, and emails from the past week I delved into an existing problem with one of our projects builds. It involves cruisecontrol and maven 2 and all sorts of problems getting maven to do the checkout from cvs or using the tag to execute cvs from the command line. Anyway after about an hour of tinkering I managed to get it running again, though the build is still failing due to some issues with maven. (Did I mention I’m still not impressed with maven. It appears to handle everything seamlessly and then you end up in these nasty configuration battles over integrating it with cruisecontrol or even CVS. Ant is verbose, but straightforward and has tons better documentation, books, and examples.)

Anyway the point is I haven’t really delegated out the build box successfully. I’ve talked to at least two of my developers about it, but I haven’t really handed over the reins to anyone. I really like build tools and I don’t want to give them up. Thus I’m at work late on a Saturday trying to do too much.

James Shore posted on the idea that you should favor synchronous integration:

1. Run the build on your local workstation and make sure everything builds and passes tests. (This step is optional but helpful.)
2. Check that the integration token is available. If it isn’t, wait until it is, then get the latest changes from the repository. The revision control system should automatically integrate (or merge) most changes. If you have any merge conflicts, investigate and fix them manually.
3. Run the build. If it doesn’t succeed, you have an integration problem. Consider asking the last people who checked in for help. Start the integration process over when you solve it. (This step is also optional but helpful.)
4. Assuming the build passed, get the integration token. This will prevent anybody from getting your code before you’ve proven that your check-in worked.
5. Check your code in to the repository. At this point, the build in revision control is unproven. You have to prove that it works before releasing the integration token and letting others get your changes.
6. Walk over to the integration machine, get the changes from the repository, and run the build. If it fails, you have a configuration problem: the build only works on your machine. Roll back your changes (revert your checkin), verify that the build works again, and put the integration token back. Fix the problem on your local machine and start the integration process over when you solve it.
7. Assuming the build worked, you win! Put the integration token back and celebrate by ringing the bell. You don’t have to, but it adds a little fun and it lets others know that something has changed. I like to channel Monty Python when others do this.

A syncronous build seems to clash with Agile where you’re trying to avoid waste and a lot of waiting around for a syncronization token. Moving into serial mode while you checkin and build appears counter intuitive.

James explains the advantages as:

It is slightly wasteful, because integration is a serial operation and you have to wait for it to complete. On the other hand, with a fast build (ten_minute_build) and a policy of rolling back integrations that don’t succeed, the wait should never be too long.

In practice, synchronous integration is less wasteful than the task-switching and broken builds that tend to occur with asynchronous integration. It’s a much bigger pain to have to lose my flow and switch contexts in order to help somebody else debug a broken build.

I just can’t see the advantage based on my limited experiences on builds with Cruisecontrol. Our teams are not working on really large codebases in general. We’re probably a fairly typical medium size development shop. A larger project might have four developers on it so maybe this would show up in those cases.

Typically developers check in a few times a day and we rarely have merging issues. We do have broken builds every few days, but they’re generally resolved by the developer within a few minutes to an hour. Going to a synchronous build would be wasteful for us.

At a recent team meeting four out of eleven developers missed the meeting. None of them planned ahead of time to miss the meeting, and all of them were a little surprised when I mentioned it to them.

Three of the four who missed the meeting are not collocated anywhere near the bulk of the team. They are on other floors or in other buildings. The one developer who was located with everyone else was simply heads down coding. I’m willing to bet that if all of the developers were located together chances are all but maybe one would have made the meeting. A host of developers walking by your cube is a good reminder.

So colocation is even helpful for team meetings. After I realized we were missing quite a few people I dismissed the idea of trying to round people up and assumed things had probably come up. Running around to another building and another floor for a 30 minute meeting just isn’t worth it. The distance barrier makes it difficult to take action to resolve a simple problem.

Anyway not really that big of a deal, but another little lesson on the value of sitting near your neighbors.

Reading through Scott Ambler’s recent results of his Agile survey it stood out that one of the least used practices was colocation. Common coding conventions were almost 4 times as popular and even pair programming is more popular than colocation. Fighting the facilities battle is still a losing battle many places.

After picking up a rugby ball over the weekend to use as a prop or talking stick I sprung it on two Scrum projects today. I just explained that the ball when you held the ball you talked and when you were done you passed it on to the next person.

On the first standup which is only about 6 days into it’s first Sprint I think it helped focus the conversations around what the team was working on and kept some of the divergent conversations down. On past standups the meeting had broken down to the point that issues were discussed, but the simple what you did the last 24 hours, what you’re doing for the next 24 hours, and any impediments got lost. It also appeared to help the focus from the Scrum Master to the team members which was really part of the point.

On the second standup today with a team that’s on it’s sixth Sprint the results were more mixed. This is a team that has standups down pretty well, but occasionally focuses on the Scrum Master to keep the flow of the standup moving. I was hoping to break some of that default behavior.

First they wanted to know who thought up the idea and I gladly acknowledged that I had over the weekend upon seeing one at a local soccer shop. I explained that the idea of a talking stick had been used on many other Scrum projects. At least two developers thought it was unusual enough to just lay the ball on the table when it was their turn instead of just holding it while talking. And one developer who’s more of an observer announced he would just ‘pass’ a very simple pun, as he handled the ball to the developer on his right.

Overall I think it’s been a fun experiment, but on the more mature Scrum project we might end up dropping the idea. Definitely something to reevaluate in the retrospective if not even sooner.