The problem compounds when part of your team is in a different timezone. Staying in the US with as much as a three hour gap is detrimental to an eight hour work day, but what if your company has paired you up with an off shore team in India? Sure, it seems great to have people working on a project nearly 24 hours a day, but the reality is that there's no reason four people can't do the same work in an eight hour window as two can in one window and another two in a second window. The detriment is when you need a question answered. For instance, let's say it's Friday morning, and you just checked out the latest code from source control (you do have source control, don't you?). You were all set to finish up a user story today before going home for the weekend, when you realize that your counterparts in India decided to refactor three classes. Nothing is where it was before, and they didn't send you any kind of help on how to use the new set up. You could:
- Call them. The company is more than willing to foot the international phone bill.
- Send an email. You can be a little more clear and concise to help the communication barrier.
- or you can spend the time yourself to figure out what the hell is going on.
You best option is surprisingly the third option (or you could work on something else). Because of the time change, team India has already gone home for the weekend. You'll get your response sometime on Sunday. It'll be Monday before you can get anything done.
So the question you have to ask yourself is this: If it takes that long for a team member to get work-related information, how in the world can I expect the team to develop the comaradarie and trust it needs to be highly effective? You simply can't.
Occasionally, I was brought on to help interview candidates. I knew someone else had an interest in seeing if the candidate could write code, so I never asked many technical questions. I was always after the team fit. "Can I talk to this person?" "Does this person speak in a way that is constructive?" "Will this person be able to learn from and teach me?"This often showed itself with a much simpler question: "Does this person laugh at my jokes?" If she didn't laugh, I knew right away that we'd have trouble communicating. It might have been a language barrier, or a subculture barrier? Sometimes my humor is lowbrow, but that's the way the team works on a daily basis. It happened more than once that I said a person was not a good match, "a 'No Hire' situation" as I now say in the hiring market, but I was told that culture fit isn't as important as I made it to be. In each case, the person hired was not successful in his/her job (and was usually let go or repositioned shortly after). I'd take someone eager to learn with a good team fit over a brainiac-thorn-in-my-side any day.
I've gotten slightly off topic but the point is that the team has to work together. In an Agile software environment, a team is not a group of people who meet once a week. It's a group of people who share the same work. We all own the same code, the same successes, the same failures. This isn't true in other departments where victories are the result of an individual's efforts. This is also why it's tough for management to understand why you need a big room with all of the team together all of the time. I'm not saying there can't be a side room for personal phone calls, but when you're working, you need instant access to the knowledge of the team. You need to be able to collaborate at any point in the day. You need to know these people, and know that you can trust them to do their job, and ask for help when they need it, and ask early.
The key is to have a physical presence in the same area as the rest of the team. The barrier to pop your head up and ask the guy on the other side of the table is insignificant to looking up a number, picking up the phone, dialing the number, waiting for the off-site guy to answer, and so on. A man in Waterloo worked around this disparity by getting a robot with a monitor, speakers, and web cam to drive around the office. He may not have been in the office himself, but all the components for people to interact with him quickly were there. If a time change is an obstacle, then consider shifting your office hours to match, devs love to sleep in, but families can throw a wrench in this work around. If all else fails, just split the team. The people that can work in the same space at the same time are one team, the people on a different schedule/location form a different team, or work solo. In the end, your teams need to be with their team mates, and they need to be able to leverage those team mates at the drop of a hat.
2 comments:
I'd like to stress a point that Will grazed over right at the end. Although the overseas team member issue has obvious implications, a team member that shows up a half an hour later than the others can have the same effect. Even though I'm not a morning person, that doesn't mean that Will didn't have a great solution to the previous day's problems that he needed to talk about before he logged into his workstation. If I wasn't there, a decision that I may have had important input on is already in the works by time I roll in the door (if I were the late one, that is). This can have a large impact on team dynamic over a long period of time.
I might even argue that leaving for lunch at different hours can have that effect. However, the solution to that problem may cause even worse problems. Then again, I don't think it's that uncommon.
Good catch Matt! It's true, when developers are given too much flexibility in their schedules, they can create time zones of their own, right in the same office. At our work, one guy liked to come in at seven and leave by four. I was coming in around nine and out around five or six. Matt was in closer to ten. So our max team window was already constrained to 10am to 4pm (six hours). Now toss in that people took lunch anywhere from 11 to 1pm, and we created a situation where we only had three to four hours of team time - and we were all in the same office on the same team. It was frustrating on the days where we did design, and we constantly had to pick between bringing people up to speed, or only designing during those limited hours.
Post a Comment