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.
Does the availability of online conferencing using web cams or Webex type platforms change the ability of the team to communicate and improve the project velocity?
Jerry Helms
Non Stop Portals
No, look at the colocation data in George’s bibliography. All those things help to not lose more time. They don’t improve the project velocity they way being in the same room/same floor does.
I think colocation is extremely helpful, but I believe it’s only 1 factor of developing great, successful software. Yes, it’s good when we have it, but I’ve worked on some amazing teams that have created 1st to market successful software that have been geographically distributed with several of the team members working from their homes (on one such team many of the members were in different states across the US).
On my current team, the rest of the team is in a different state and colocated with the customer while I work out of my home on the other side of the country. And I know for sure that I communicate some of them and the customer more than some of them do.
So, I don’t believe it’s all about colocation. You can be colocated and still have lousy communication. Or you can be colocated and communicate okay but still fail at other vital things like delivering the “right” thing and maintaining a sustainable pace through quality and having the right skills and experience and having people that are passionate about what they do and holding one another accountable for delivering the best and being open to new ideas and perspectives…
Sure, it’s nice to be colocated, but I don’t think that’s a reason to write off people who are remote.
Johanna, I must beg to differ!
I shared your opinion years ago. Then, the manager of my agile team (he is also the most senior developer) had to move back to India. We all had to adjust, but with good ways for voice and video chat, wikis, digital photos and the like, it was not a significant velocity reduction over the long term.
Now I’m one of two remote members of an agile team. Of course, being remote has its down side. For example, my PC is broken and I have to ship it back. But, whatever downside is, I feel, made up by having people with exceptional talent and experience on the team, who otherwise would not be on the team.
My team set up a rolling cart for each remote team member, with a laptop, webcam, Skype and mic. My webcam displays on the laptop, and my team members roll ‘me’ around to whoever I’m pairing with, or to meetings (rolling through the halls saying hi to people is fun!) I can control the webcam to look for people.
We are on IRC all day. It’s a cultural challenge – the team has to get used to accommodating the remote people. But I think it is worth the effort.
We know that people make projects and products successful. Why not broaden out the available pool of great people, by embracing remote team members?
Abby – I hear what you are saying about distributed team members and when distributed teams are having problems, it is invariably because of the poor communication brought about by the distribution. Sometimes you just have to distribute, but many times it is an artifact of the organization (Conway’s Law).
Hi, Johanna,
Excellent, perceptive to understand the nature of a team bit and I agree with the functional definition. However, I strongly disagree with this quote and the theme of this particular article: “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.”
Through over 10 years of project management in ‘waterfall’ and agile s/w projects, I have seen both large, complex projects and small ones develop and demonstrate very strong, organic trust between team bits and team cores. As a project manager who has helped teams with completely co-located culture accept and fully integrate remotely located and critically important “bits” in Israel, Ireland, Taiwan, China, India, and Japan, it’s clear to me that doing so is completely replicable and teachable. The point about core and bits being “out of time sync” is indeed one of the challenges that needs to be worked, but it isn’t one of the top challenges, in my view.
I’m happy to discuss this more with anyone who is interested.
Pingback: Tobias Fors » Blog Archive » Roll Around in a Cyber Cart
Much later, but I really agree with Pete. In my technical field, there are way more jobs than qualified people. In other words, it’s hard to find the right person and the exact person you need may be on the other side of the country, or the world. Working only with colocated team members is self-limiting and self-defeating.
That said, I’ve had scrum masters tell me that Agile simply doesn’t work with remote team members. Perhaps those scrum masters need additional training.