Showing posts from May, 2018


On our mob, we have started using the “Mobodoro” technique, which I picked up from Willem Larsen at Hunter. 
The idea is based on the “Pomodoro” technique, where you do 25 minutes of solid work, then take a five minute break. And repeat. 
 But with Mobodoro, we have a couple of minutes to plan, then we do repeat mob rotations of 2 or three minutes, adding up to 25 minutes. Then we do a quick retrospective on the previous 25 minutes, have a quick break, and then repeat. 
And for the break, we have a rule that we have to leave the mobbing area. Even if we just walk a few feet and back. 
The retrospectives have been great. Often we have nothing. Because we’re only retrospecting on the previous half hour. But quite often we find something small we can change: a better way of using our whiteboard; a new chair; changing the mob rotation time; buying some Lego to keep track of our work. 
The day seems to go much more smoothly, and at a much more sustainable pace. Two or three minutes break every …

Teamwork and the Human Current podcast

I listened to a great episode of the Human Current just recently, where they interviewed Cesar Hidalgo, and it got me thinking a lot about teams, and how they are complex systems, and how teams learn. It got me thinking so much, that I've listened to the podcast several times now. The first time, I was cycling to my choir rehearsal, and couldn't stop to listen to interesting bits again, so I listened to it again while sitting down at home as soon as I could!

The first stand-out quote for me was from Warren Weaver:

Complex systems are those in which the identity of the parts involved, and their interactions, cannot be ignored.

This is a really deep idea. We have gotten so used to the reductionist approach in which you can understand something by taking it apart, and looking at the individual components. And this approach works, as long as the relationships between components is simple and obvious.

But with people, the relationships between individuals is anything but simple and …


I often hear people talk about “adding resources” to a software team or project, and I really don’t like it. 

And there’s two reasons why I don’t like it. 
Firstly, we’re talking about people. Sentient, caring, decent people. People aren’t resources. People should be treated with dignity and respect. And calling someone “a resource” is not a nice thing to do. I am not a number...
But secondly, the underlying assumption with “adding resources to a team” is that “more resources equals more productivity”. And that’s problematic. Teams are complex systems, and adding more people to a team, disrupts the team. It sends the system off on a new trajectory. And it might never make it back to where it was. So simply adding people to a team can completely change the team dynamic, and can completely change the team’s performance. 
Another problem with the assumption is the idea that new team-members just need to be “brought up to speed” in order to be productive. But the mental models that we build u…