Knowledge Sharing on Steroids

One of the challenges I’ve had to face a few times in my career was how to ramp-up a software development team, specially in what relates to knowledge sharing.

Why is it hard?

I still remember watching an old presentation from Dan North where he kept hiting on the same point, which was that there is always a story behind any decision made on a project. And that is the main problem I see when joining a new team: there is always story, and you probably don’t know it.

Working in a new codebase for me feels much like moving to a house in a new neighborhood. It takes some time until you know where all the shops are, what’s the best way to get anywhere and where can you buy stuff in the middle of the night. In a software project you don’t know exactly where things are in the codebase, it takes time to understand the rationale behind the design and you are afraid of making big changes, even when they should be made!

So when ramping up a team with a considerable amount of new developers, there is a risk they won’t be able to be effective for quite some time, or that in the urge to be effective they will end up changing what doesn’t need to be changed, being counter productive after all.

So here we go again

This challenge came up again in my last project, where we were starting to work in our second release and wanted to include a team of developers in China in what would turn into our new distributed team.

Gladly enough we were able to spend 2 weeks together as a colocated team in Xi’an, but still we needed to use this 10 working days to ramp up 5 new developers who had little or no experience in the codebase we had been working on.

This time we decided to try something out of the ordinary with some inspiration coming from my period at Thoughtworks University  (what Sumeet would call workscaping), in what could be described as a mixed of promiscuous pairing and very frequent showcases.

What does that mean ?

The idea was:

  • We rotate pairs every 2 hours
  • After each 2 hour block the team would stop and every pair would do a 5 min presentation on what they had done
  • We have a 30 min slot available at the end of the day for having a more in-depth discussion about topics that the new developers had doubts about.

Some of the benefits we expected to achieve were:

  • Everyone would work together quite a few times, improving the relationship between team members
  • The new developers would have an opportunity to touch different parts of the codebase quite soon, hearing the stories from the old ones about what was there and why
  • By presenting it back to the team, everyone would have a chance to raise questions and understand a little bit more about a specific topic
  • The constant sharing of information would enable newcomers to get more questions answered and deliver functionality quicker, which always helps with confidence

So the day would start with a normal standup, and after 2 hours the team would swarm and go around the room, hearing what had been happening. Pairs would then rotate and start again. Repeat that 4 times and the day is over.

How did it go ?

Overall the result was quite good in my opinion. Most of the results we expected to obtain actually happened, specially the communication within the team, which was great after a few days.

After one week of doing it most people started feeling the need of working more hours without interruption, so we changed our pace to 2 rounds of 4 hours and then eventually rotating pairs once a day, where we ended up stabilizing. Despite being earlier than expected, it felt like a natural point where people had enough knowledge to deliver and wanted to focus on that, which can probably be considered as a success.

%d bloggers like this: