Online Work and Global Collaboration
by mpchlets on Sep 11, 2013
- 248 views
Michael Chletsos lives in Hawaii, that is in the States and Titas Norkūnas lives in Vilnius, Lithuania. These locations are 12.000 km and 13 hours apart. Despite these facts, we work together every ...
Michael Chletsos lives in Hawaii, that is in the States and Titas Norkūnas lives in Vilnius, Lithuania. These locations are 12.000 km and 13 hours apart. Despite these facts, we work together every day. We do a lot of our work in a pair. And yes, there is a silver bullet for that. One person has to enjoy waking up very early (maybe 4am) and the other has to enjoy working very late (start at maybe 2pm).
We also manage a remote team of ~20 devs and ops together. There won’t be a silver bullet for that. However, we have some tips and tricks for you that helped us work better remotely.
The Remote nature of the team magnified the poor communication, due to the fact that people were communicating solely through email, chat and the issue management system. No one was talking nor working together. It is rather difficult to have empathy about someone else’s problem if you don’t ever see their face or hear their voice.
Quitting iterations and starting to release everything when ready did wonders for us. This manner of releasing works very well for web applications. It would be extremely difficult for us to go back to any iterative process without seeing it as a big problem. A common pitfall of releasing more frequently is that managers love the idea since they think they are getting features faster, which is true (but mostly a side effect). In reality releasing more frequently is developer oriented and the key is that you are allowing the appropriate amount of time for each piece of work, instead of forcing work out at the end of an iteration. You do not have to hit the release date, since releases occur as necessary and you as the developer set the release date.
At one point, we were trying to do everything in a very continuous manner, which turned out not to work in some occasions, because people do what they like first, not what the business needs.
People should work on what they find meaningful. When a team member is working on solely bug fixes or drone work, they have no passion for their work and produce results that mirror this feeling.
Involve Devs in the Ops side. One of my favorite quotes is “Reward Firefighing and You’ll Create a Culture of Arsonists” (http://www.forbes.com/sites/johnkotter/2013/07/29/reward-firefighting-and-youll-create-a-culture-of-arsonists/). We had Ops fighting fires everyday and more requests kept piling on them. Find the highest priority work and get on them first, ignore all other work otherwise. In the meanwhile, turn over the tasks that developers were previously asking of operations over to the developer team until you can get some breathing room.
The DevOps notion of CAMS (Culture, Automation, Monitoring, Sharing) is essential to a functional team. We tried to do it in a different order, starting with Automation, continuing with Monitoring, Sharing and lastly, Culture. While the Automation part worked (with moderate success in Monitoring and Sharing), we learned you must start with Culture.
- Total Views
- Views on SlideShare
- Embed Views