I have been tasked to manage multiple agile teams in different business areas and geographical regions (time zone problems). Has anyone got any experience with this? It seems like the job will be more of a traditional project management over seer position.
I've had 2 experiences in the same company with distributed teams:
- In the first experience, I was Scrum master and I had 2 members abroad (with 8hrs difference). We just couldn't control how much time they were exactly working on the project and they were constantly pulled onto other projects of the remote location. It didn't work smoothly.
- In the second experience, I was a developer among a 20-people local team and 6-people remote team (4hrs offset). They had their own component and Product Manager. We sent 2 people over and changed them every month until they mastered the art. It worked great. We had a very defined trust for them and they had their autonomy.
For example, Agile explicitly says team should be colocated. If you have to distribute teams remotely, do attempt to give them as much autonomy as possible.
I would recommend reading the "How We Do It" of StackOverflow's blog, since StackOverflow is well known for being a remote-workers company. Zappier is also communicative about managing remote teams. I recommend Atlassian tools. Common traits are:
- A persistent video chat
- RapidBoards / Trello / any visual ticketing system
- A team collaboration tools to write and talk: Google Docs, Confluence, CampFire...
- I would add a good code management system: Stash + Bamboo (or any good code review + git + continuous build system).
Disclaimer: I used to work at Atlassian.
On the cultural side:
- Hire people you trust,
- Hire people who can write,
- Arrange real-life gatherings from time to time,
- Develop a strong culture about delivery and expectations.
The two linked blogposts are really interesting about culture.
Communication is key
I was the Scrum Master for 2 teams in Hyderabad, India (contractor), one in Montevideo, Uruguay (contractor) and one in Washington DC for a previous company. The time difference with Hyderabad is 9.5/10.5 hours. Here are some best practices that we developed over a period. You may not be able to implement all these. Strive to get there or mitigate them where possible:
- Face-to-face contact: Arrange for the overseas team members to travel to your location and vice versa. It is harder to develop good communication, collaboration and team spirit between people who have never met.
Overseas team should be able to operate fairly independently: To be effective the overseas team should have all the skills/roles to be able to operate fairly independently.
Initially we had developers and testers in Hyderabad and the designers in DC. Web front-end development requires close coordination between the dev team and designers. We could see the improvement when we hired a local designer.
We trained a local Scrum Master in Hyderabad and arranged for local Scrum stand ups. This improved team coordination overall.
We could see the limitations of not having a local Product Owner.
Arrange for more time overlap: Some of our architects used to log in at night to answer questions from Hyderabad. The Hyderabad dev team members used to come in late and leave late to have better overlap with DC.
Virtual work-spaces: Use web based tools to make story/task status, shared calendars, holiday schedules, contact info... visible to the entire team. Ideally the tool should allow threaded discussion in the story/task. If you try to do this using email, people will be buried in emails and things will fall through the cracks causing much frustration.
Get communication channels as close to face-to-face as possible: Group video calls for the daily Scrum stand ups, ability to share screens/whiteboards, team members logging into chat when at work are some things you can try.
A few things I learned about working with a remote development team by being part of one:
- Transparency is the best policy For every new mobile app project we take up, we work up a document containing all of the info we have on the client’s product and business. This way, all of the requirements are clear to both us and the client, while we can always get back to this document to clarify things in the future.
A product specifications document consists of, but is not limited to:
- Project overview
- Project objectives
- Technology used for the project
- Project architecture
- User flows
- User stories (which include acceptance criteria for every user story)
We work within the scrum framework
Some of the tools we use:
and BitBucket and GitHub as code repositories (we're a mobile app development agency)
- The Lean Canvas of the client's business can come in handy. The Lean Canvas, proposed by Ash Maurya in his book Running Lean, is a business model hypothesis testing and validation tool. It’s also a simple, yet powerful tool, which can be used by the remote team to get a lot of valuable info about your product and your business, at a single glance. A user persona sheet can also be of use.
Leading a remote development team doesn’t mean micro-managing the hell out of those people. Your collaboration with a remote team will be a lot more successful if you lead those people by inspiring them. Be there to answer their questions, be it product or business wise, be open about the strengths and weaknesses of the project; be clear about the expectations and the vision. Be like an open book, but also give your remote co-workers space to come up with solutions.