A twitter follower was concerned with a piece of my post, Do What’s Effective For You, when I spoke of team bits. Was I saying you could not telecommute and do agile?
First, let me explain what a team bit is. A team bit is a person or a group of people grouped by geography and functional specialty. I see this most often where testers are remote from the developers. The worst occurrence is when there is a single tester separated by many time zones and understanding from the product developers (developers, product owner, business analysts, anyone who can explain how the product is supposed to work.) A team bit is always remote from the rest of the team. A team bit has no one to talk to on-site. A team bit is out of time sync with the rest of the team. There is no way for this bit to build trust with the rest of the team.
In my experience, team bits don’t work. They don’t work well for agile, although the problem becomes transparent. Team bits don’t work well for any other lifecycle, but you might not be able to tell. George Dinwiddie is collecting data at StudiesofColocation.
So, where does that leave us for telecommuters? If the people only telecommute one or two days a week and the iteration is at least two weeks long, and if everyone telecommutes on the same day, overall velocity will likely slow down, unless the team is ultra-high performing. Of course, if it’s just one day a week, you might not be able to tell. If it’s just two days a week, you might live with a slight velocity reduction in exchange for happier people.
If that’s what you mean by telecommuting, agile and telecommuting can work. But you have to limit the the number of days per iteration. Otherwise, the reduction in velocity is palpable.
The next post in this series will be about remote feature-based teams.
