malvasia bianca

I spent this morning hanging out in open space. The first discussion was a followup to last year’s talk by Arlo Belshee on promiscuous pairing. It turns out that a couple of experience reports were presented here on teams’ experiments with the practice. The good news: both teams saw similar productivity/quality/etc. boosts to the team from the original experiment. The bad news: both teams gave up the practice in spite of those boosts, one after about a month and the other after about three months. (The original team had been doing it for 18 months, with no plans to stop, by the way.)

I don’t remember the details of why one team stopped after one month; something about thinking that it’s too hard, or not enjoying it. So it would seem that the practice can, for some groups, bump up against Sustainable Pace. (I got the impression that the original team had a higher tolerance on that front than the norm.)

The story behind the team that gave up after three months is apparently that they’d run into a few team issues after a month or so, which they’d solved, and some bigger team issues after three months, which they might have been able to resolve but were hindered from doing so by management shuffles. Arlo said that his team had also seen big issues surface at around that time, as well; they’d managed to deal with them successfully, and doing so improved their performance.

This is a phenomenon that shows up more generally in lean discussions: once you reduce buffers / cycle times in various ways, problems start to turn up that you hadn’t seen before. It’s not that the problems weren’t there before: they were always there, hindering your progress, but you just hadn’t been forced to deal with them. Which manifests itself in other ways in agile processes, of course – e.g. continuous integration makes breaking the build a much more serious problem than it would be in other environments, but that’s not a problem with continuous integration, it’s a problem with breaking the build! This particular manifestation of the problem does seem scarier, though: in particular, it suggests that a team that wants to try it should probably be comfortable with introspection and retrospection.

After that, I participated in a discussion on what agile might have to learn from open source. About which I don’t have much to report.

I spent the afternoon at a tutorial on retrospectives, run by Esther Derby and Diana Larsen. Retrospectives are one of my current sore spots: I’m bad at running them, but I hear over and over again how important they are. And I believe that, too – I very much want my team to continue improving, and to do so in a collective fashion.

And I’m glad I attended the tutorial: we got some hands-on practice, we got some ideas of other things we could try, and I picked up a copy of their book to get more ideas. So I’m rather more confident now that I can get this to work – if nothing else, I can try format after format and topic after topic to shuffle things around, and I’m pretty sure that something will click with us. (And will then get stale after a few months, after which we’ll be able to shuffle again.)

On the other hand, I still don’t feel that it’s an area where I’m particularly skilled. So now I’m thinking that I should ask my team members if any of them wants to volunteer to design and run retrospectives. If none of them do, fine, I’ll do it myself; if one of them does, that will move more decisions down and there’s a good chance that one of them is more talented in this area than I am. And I’ve got a book full of suggestions for whoever volunteers for that.

Back to work tomorrow. I’m glad I came; certainly useful for me, and I hope it will prove useful for my employer. No revelations, nothing that’s going to have a huge concrete effect on my work, but I learned about and got practice with some useful techniques, and learned a few things about myself. And if, for example, higher-quality retrospectives can cause my team to gain just one extra week’s worth of work over the next year, then that will pay for the conference a couple of times over. Also, being at a conference made it much easier for me to concentrate on the subject: I left the hotel a grand total of twice during the conference, and spent the vast majority of time during the five days thinking about what I wanted to learn, going to talks, thinking about what I’d learned at those talks, and blogging here to get some of those thoughts out. I’ve spent some time keeping up with other tasks or doing reading on other topics, but it has allowed me to be much more focused than I normally am. I wouldn’t want to spend all my time doing this sort of thing (Sustainable Pace again), but doing it occasionally is refreshing.