In our shop, we don’t “force” the practice, in the conventional sense, but it’s strongly encouraged and more importantly, supported. It does take a while to get used to it and we give folks a huge opportunity to ease into to and adopt it.

What I can say after many years of personal ‘exposure’ to this practice is, that it does what it promises: it produces better code, it keeps developers thinking in a way that they can’t and don’t on their own and it produces it’s own rhythm in time. It’s exactly that rhythm, or “flow” that you describe, that keeps my folks coming back to it. They would tell you that it makes development more fun and they feel more motivated to create.

I’m always sorry when I can’t figure out a way to help individual contributors in my shop get there; they eventually move on to other environments where they can experience the flow in their own way. But I understand.

There are, of course, lots of times during the day when certain tasks are so mundane, that pairing would interrupt individual flow; we also encourage that.

I would like to hear more about your IM journaling. We use IM extensively in our shop; it’s on constantly, even for folks across the room. Whenever there has been a problem of miss-communication, it is always an IM (or email) issue. I guess I come down on the verbal, face to face side every time, but I may be old-fashioned here.

I think I get what you’re saying: you are in a distributed environment, and that means distributed communication. I don’t do distributed environments, exactly for all the reasons that you’ve come up with ‘solutions’ for, but if I had to do distributed, I think I’d be using the techniques that you’ve come up with.

Every team in our shop [save 1 out of 6], is co-located. The last has a single member [he's new and hasn't shown up yet, so this is an experiment] that will be working in another location from the rest of the team, 1/2 of the week. During the 1/2 week, he will be paired as much as possible with another member of the team, just so he’ll have support.

That’s the way we roll.

Hal

I can’t help but observe that even our president got into this bind – there is a certain part of the population that thinks that a leaders job is to kick @$$ and take names when there is a problem, and they want their leader to provide a public display of the frustration they feel. I have a similar personality, and I’ve been asked more than once why I don’t get mad when things do not go to plan – my usual response is “What good would that do?”

Technical project managers often face this issue – it can seem to others that they spend more time defending the technical team for not meeting its objectives than trying to drive the team to the outcome that is needed by the business. Business people want project managers that are leaders, not accountants. One aspect of agile that I like is that the process rhythm pushes the team of its own accord – the scrummaster still needs to bring drive and energy to the team but the team pushes itself.

It is also worth mentioning the very cool Conchango task board – http://consultingblogs.emc.com/crispinparker/archive/2010/01/20/scrum-for-team-system-v3-scrum-masters-workbench-task-board.aspx

If I were a betting man, I would say that Twitter won’t be around in five years but tweets will. There will be a number of platforms supporting these social interactions. The killer app here will be to federate them. The Internet dial tone.

I would recommend taking a look at this IEEE whitepaper – http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1033025. Looks like it is mirrored here if you want to avoid the registration hassle: http://www.accurev.com/product/docs/SCMBranchingModels1.pdf

What papers like this can help you do is make sure you are going down a well-traveled path in terms of process and terminology for branching, which is helpful for the team. But within a given branching strategy, it is “up to you” to ensure that you aren’t allowing your branches to be an “enabler” for excessive work in progress.

If you’d like to continue the conversation, we’d certainly welcome it.

Scott