Resources

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 up about our code are complex in themselves, and very difficult to describe to anyone else. And, because any new team-members will have a much lower-quality mental model of the code’s behaviour, they will make much lower-quality changes to the code. 

Adding people to the team means that existing team members have to try and convey their mental models to the new people. And they have to guide the new team members as they make what would be basic mistakes to the original team members. 

And that of course requires good conversations, trust between team members, respect and kindness. And these all take time to build up. High quality social interaction is complex and takes time to build up. Team members need to build up a shared context to allow such communication. 

Even worse, as the team grows, the number of social interactions grows rapidly, and the chances of a common understanding or context decreases rapidly. 

So, don’t assume you can disrupt a human social group and achieve any predictable results, let alone an increase in productivity. 

Comments

Post a Comment

Popular posts from this blog

We always start from where we are

Image
Earlier on in this year, I had a really interesting discussion online with Duncan Hothersall about Scottish Independence, and Brexit. I support independence, and Duncan very much doesn't. Scotland is currently about evenly split between supporters and opponents of independence, with a small number of hardcore unionists and nationalists on either side. But many people are in the middle, and weigh up the decision based on the perceived pros and cons. In itself, this disagreement between Duncan and myself is interesting. We share a similar world-view and similar hopes for the future. We agree in many ways on the kind of future we would like to see. But we disagree on how we want to get there.  This is of course a common pattern. We often share a purpose with other people, but we disagree on the tactics or maybe even the strategy for how to achieve it, and there is a wealth of literature on how to resolve such disagreements.  But what I found fascinating was how we both responded to B
Read more

Mobodoro

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 brea
Read more

Gilded Rose Katas

Image
Introduction Last Summer, I had the pleasure of bringing Amitai Schleier into my company for a few days, as part of his coding tour . One thing that really inspired me was his emphasis on a Learning Hour each day, and on using katas.  Katas are a short set-piece practices. The word “kata” comes from the Japanese martial arts tradition (形 - literally, "form") and is used to describe a regular repetitive, choreographed practice. Wikipedia gives a good description here  https://en.m.wikipedia.org/wiki/Kata . In software, there is a good collection of these set-pieces. Implementing FizzBuzz in a new language is a good example.  So, after Amitai’s visit, I started running katas every day. It took us a while to establish them, because we don’t have set starting or finishing times. But we now do half an hour of katas every day after lunch. We have used the time to look at TDD, TCR , Haskell, and we have used several well-known katas.  But the one we spent the lo
Read more