In a recent Agile Toolkit podcast interview with Alistair Cockburn he mentions a time where he was helping a team through a retrospective and he brought up a provocative idea:

There weren’t any more details on how that played out, but the team apparently did just try removing the standup. I’ve had this conversation with several developers about standups. On some teams they seem like far too much of a chore and too stuck around reporting hours on tasks on a spreadsheet.

I did have one team where we took out the standup on Mondays and people were going to email their statuses around. That turned out to work pretty poorly as for the most part no one remembered to send the emails. Still if a team really wanted to experiment with no standups it’s their call. My guess is the better thing is to fix the reasons behind the dysfunctional standup. Jason Yip has a good recent post on standup patterns and ways to adjust standups that have the wrong vibe.

I made a little headway on Haskell today.

Downloaded the GHCI environment to start running/compiling in Haskell. Had to find the Mac Intel port. Went looking for at least a TextMate bundle, turns out there is a pretty basic one available. Then started one of the basic Haskell tutorials.

After just an hour or so I feel like I’m on another planet, but that was the desired effect. Next up getting HUnit up and running.

One thing’s for sure (for 2007) I’m learning Haskell. Yeah, that’s right Haskell. Why? I don’t know.

— Charles Lowell of the Drunk and Retired Podcast, Episode 78.

I knew I chose wisely when choosing Haskell.

Many of the practices I’ve introduced to my team have largely stayed within my team. There’s no moat around our section of cubicle land, and all the other teams knew about the majority of our practices, but we didn’t see any uptake. I hoped about a year ago when I ran a TDD seminar with JUnit for the bulk of java developers outside my team that we’d see a change there. About a year later I think the only evidence that they’d been through a seminar on TDD was a few tests scattered across one project.

Osmosis wasn’t going to be enough to convince people. It went the same way with my team. A few of them have really run with everything from code reviews to TDD, but many of them take a great deal of convincing.

The next push was to talk to my peer manager about how we spread the adoption across our groups. I’ve put that discussion off for at least 4 months now largely due to fear. I heavily lean towards consensus building and I don’t like show up preaching like a convert. We’ve had a pretty good relationship though and for some reason I finally stopped mulling over my notes and approaches and just dropped in on him in his office.

Turns out he’s pretty open to the ideas, and it really didn’t take a whole lot of convincing. We’re going to start out introducing some of the easiest stuff like automated builds and continuous integration and then progress to TDD, code reviews, static analyzers and the like. Just one practice at a time so we don’t overwhelm anyone with change. At the end of the process our entire development organization should be performing all the same practices to a lesser or greater extent. By this time next year our basic practices should be shared throughout the development organization.

Definitely should have broached the subject much sooner.

Turns out IBM recently snuck out a way to integrate ruby with Websphere Process Server using SCA (Service Component Architecture). It’s incredibly enterprisey and a bit surprising to see out of IBM. And the whole thing is made possible via JRuby.