Early on, our strategy was to organize ourselves into two teams, and have the Austin-based team work on feature A while the Bangalore-based team worked on feature B. That way, we could reduce the impact of our globe-spanning timezones. (There are no normal working hours that overlap for either group. 11.5-hours difference.) We would stay out of each others' way and hardly need to talk at all.
...Hardly need to talk at all? Yeah, that should have caught my attention right away.
But we do learn—this is why we have retrospectives. Exceeding any conference-call discomfort was the pain of not knowing what our teammates were doing, not being involved in additions to our code, not collaborating on a shared, emergent design. So we set both groups to work on the same feature, and scheduled more conversations.
We have two conference calls a week, one in the morning, one at night. Morning-aligned people take the early one; night owls attend the late one. The calls are just for developers, to talk shop. Some of our topics include:
- What we've done so far and what we're doing next;
- How we'll structure our database tables;
- The business domain;
- Suggestions for improving the code.
I've started to enjoy these calls. Not only are they useful (essential, even) for building a coherent application, they are forming the social glue that allows us to collaborate and argue about the design, pulling us together into one effective team.
No comments:
Post a Comment