Stephen Freeman Rotating Header Image

June, 2005:

More from XP2005

Sheffield University Computer Science has a course in which the students get to work at a “real company”: writing real software for real customers using XP. The fourth years coach the third years, and the whole thing is self-funding. A great way to get experience of the whole lifecycle in a safe environment. _via_ “Alan Wills”:

Fred Tingey and others came up with the notion of _Reverse Waterfall_:
* Start with a working system
* Test it thoroughly
* Write the code
* Design the implementation
* Describe the requirements
Sounds a bit Agile to me.

Kent Beck described his Galactic Modelling Language (GML) — on an index card of course:


These symbols mean, um, exactly what you want them to mean when you write them on a napkin.


Now it’s my turn to write about “XP2005”:

I have to admit to spending most of my time chatting to people I hadn’t seen in a while. I know I missed some good sessions and interesting people, but I did catch up with some old faces.

Mike Hill has started something called “Surprise”: It’s to be a rolling programme to implement microprojects for good causes around the world. The idea is that people like us should spare a day or so before or after our usual conferences, to get together and implement something useful for some group that couldn’t otherwise afford it. Follow the link for more information.

I ran a panel on “Leadership in XP”: with Kent Beck, Fred Tingey, John Nolan, and Mike Hill (sorry for not getting you on the published programme, Mike). The summary seems to have been scrambled on the web site, but the idea was to get deeper advice than the books for people who are facing real dilemmas at work. (For those who listen to BBC radio, think “Gardeners’ Question Time”: ).

I’m running a similar event at “Agile2005”: but as a small workshop, with Kent, Dale Emery, and Lowell Lindstrom, so prepare your scenarios…

After a little preparation, we got some nicely tricky situations that the proposers were (fearlessly) prepared to talk about in public. We ended up discussing three cases.

In the first, the Customer stormed out of a planning meeting because the Velocity was too low to deliver everything in time. Apart from the usual discussion about communication and trust, there were some ideas about how the team lead should respond immediately. First, in the words of “The Book”: , “Don’t Panic”. It’s a bad situation, but don’t make it worse. You won’t get any more done that day, so take the team off to your regular offsite place and make sure they don’t blame themselves. As Kent likes to point out these days, the only thing you can really change is yourself, so doing the best job you can is the only available response; the rest is out of scope.

The next thing to do is to take the Customer aside, calm them down and figure out where to go next. You need to understand the pressures they face and maybe they’re just having a really bad day. Then bring the two sides back together and try to patch up the relationship and find a better way through. If you really can’t, and you’re working as well as you can, then there’s not much else to do apart from escalate the issue, which won’t be fun.

In the second case, the project team was stuck with a 2 hour build that was getting in the way but that they’d never quite been able to find the time to fix. Part of the reason for this was that they were limiting themselves to a “technical budget”, set by the business, for working on their own tools and it hadn’t been enough. The obvious first response was to suggest various techniques for making the build go faster, such as breaking the tests into different stages and not running against real servers. Kent made the observation that tests can be prioritised on those that failed most recently.

The deeper response, however, was to think about what this “technical budget” implied about the relationship between Business and Development. In particular, it suggested a lack of trust that Development could make the right decisions about how much time to spend on fixing the process. John reminded us about the “Gold Cards”: technique that they’d introduced in Connextra. The proposer went back charged with a resolve to do something about the situation and I hope to catch up with him soon to hear the end of the story.

In the third case, the team was pushed into a mad scramble to get too much work done by immovable external deadlines. They made it, but only by propping up the system by hand and at the cost of burnout and a sense of failure because they hadn’t delivered “properly”. The first realisation was that the team leader had acted as a go-between between the management and developers, breaking the direct link that would have helped the two sides to understand the issues and come up with the best solution to the crisis. The second realisation was that the project was not a failure but a resounding success. The management got just enough quality to get them through the two-week event, after which the system was no longer needed, and the end customers never saw the frantic paddling beneath the waterline. In human terms, however, they snatched a defeat from the jaws of victory, and lost goodwill and a key member of the team. (Of course, as “Diana Larsen”: pointed out, they should have done a retrospective 🙂

A word of sympathy for Keith Braithwaite who couldn’t make it because he broke his arm after coming off his motorcycle.