Monthly Archives: February 2013

One interesting phenomena we’ve noticed on long running projects and teams (> 1 year), is that when we take the same people and make new mini teams to attack certain problems the results are suddenly better. The results seem to last as the team is disbanded and the individuals return to their previous roles, they suddenly have different ideas and a better overall view of the problems faced by their peers.

This has obviously been done for ages with “tiger” teams and secret task forces. However, it got me thinking about a different way to manage agile software development at large scale. Instead of creating 5 or 10 small teams with 6 or 8 people and managing a backlog over the course of years, you could take the same set of people and continually reconfigure teams to address a set of stories or defined epics. Thus, the teams would always be changing and no one could fall back into a comfort zone of a known set of people and interactions. I envision it as an extension to the idea of constantly switching pairs, only this time constantly switching up entire teams.

This likely sounds like hell to a certain set of people that value stability and the pride of working for long periods of time and knowing a certain area of software extremely well. There is also another set of engineers that would jump at the chance to continually be building new things with new people. Trying to find the healthy balance is the key.

Some new potential benefits would be that engineers are forced to build as simply as possible, knowing that new people would be picking up their code within weeks rather than years. It would also force more communication and a better understanding of the entire system on all participants.

I’m afraid to try this as I can also see it devolving into a giant mess where everyone is unhappy. It is also difficult to change up teams that have been together for a year and are hitting a serious stride in productivity. Studies on teams show that those teams that are together longer get more productive so this may be a terrible idea.

Still, the focus and discipline that comes from a small team knowing they only have two or three weeks/months to get a fixed set of work done has tremendous value. We’ll have to experiment with this a little more before taking it further.