Last week (22-26 June) Chet and I ran an Agile Skills Development workshop at the University of Michigan Medical School Information Services. We’ve coached them, provided CSM courses, and done a previous ASD workshop for them. I guess they sort of like us.

Of all the things we do along work lines, the Agile Skills workshop is the most fun for us, and, we think, the most fun for developers. One attendee this time referred to the session as “one of the most educational and enjoyable experiences I’ve had.” As the workshop was gong on, a couple of Twitter people asked what the workshop is about. Here’s a bit of a story about that.

The workshop is five days in its most effective and our preferred form. We generally offer the workshop using Java and C#, and have done it in Ruby as well. The workshop qualifies attendees for the Scrum Alliance Certified Scrum Developer rating if you’re into that sort of thing. If not, that’s fine, we respect you at least as much and since we have to pay to register you, we even save a few dollars. Win-win, as I see it.

The first day we usually do our famous “Small Card Game”, which is fun to play and gives a chance to think about estimates of story value and cost. We did it a bit differently this time, in that we didn’t begin with discovering the value of cost estimates, but instead went straight to value, with a cost discussion later. We did this because we’d like to avoid cost estimates if we can. See various articles here on estimation. The outcome of the game, in any case, is to show that focus on value is much more powerful than focusing on cost, although, of course, it’s usually best to do a high-value cheap thing before a high-value expensive thing. The outcome of this value-focused approach was pretty good and we’re thinking about changing the game script for future use.

Also on the first day, we talk about the Scrum-style approach we’ll be taking, and we do our “Nature” talk, where we derive the need for ATDD, TDD, refactoring, and continuous integration from the nature of iterative development. And we demonstrate pair programming and iterative development to give attendees a taste of what we’re asking them to try.

The next three or three-and-a-half days consist of iterations. The teams (one per table) select stories from our provided backlog, and try to build them using the XP practices that are the core of Agile developer skills. They work in 90 minute iterations, and at the end of each we review everyone’s performance at integration, unit test development, acceptance test development and so on. And we review each team’s code, pointing out issues in the code and inviting improvements for next iteration. Then each team does a retrospective, decides how they’re going to improve for next time. Rinse, repeat.

The MSIS team was particularly good and flexible, in part because they all knew each other, so they had a starting level of trust and ability to work together. They were bright and enthusiastic, with a wide range of knowledge and experience, like most teams. They included a few people who were very strong software designers, which led to some interesting discussions, since we’re always pushing to leave out big design elements until the code asks for them.

As always, teams run into the same problems in 90 minutes that they run into in a one- or two week iteration, only faster and more visibly. We help them think and talk about what to do about the problems. The short iterations help a team recognize time-wasting activities that would be harder to spot spread over a week or two. Sometimes a team will get everything done that they undertake. More often, they’ll fall short. Sometimes they’ll get nothing done at all and might even regress. We help them understand what happened, and help them devise things to do about it. Most often, this comes down to taking smaller bites, and to using the tests to support continuous production of those little bites.

The last day, we did a 60-minute iteration, since they had mostly not had time to finish in a 90-minute one the day before. (We always recommend shorter iterations when a team doesn’t get done.) Then we did a 30-minute one to help sharpen focus a bit more.

In the afternoon, we did some mob programming on Chet’s infamous Worst Code In History example, and then closed with questions from the group on whatever was on their minds.

As always it was great fun for us, and the teams seemed always to be having a good time and expressed often that they had had various insights. That’s why we do the class, of course. Our purpose is to expose attendees to the XP practices that we find necessary to rapid iterative development, and to give them enough experience with them to decide how to integrate those ideas into their regular work. Five or six iterations of real product development, packed into a week, gives a really good taste of the ideas, and a chance to relate those ideas back to one’s own regular work.

We had a good time, they had a good time, and we even got to go home each evening to our wives and kitties. We’ll be happy to come run a workshop for you, even if it’s not so close to home. If you’re interested, please do get in touch!