The biggest challenge of distributed teams is communication, which is essential for establishing ground rules on collaboration. The practices of shifting working hours to accommodate each other, and team liaisons, help to communicate and synchronize work. Teams based on trust, respect, and openness will encourage themselves to help people throughout the organization, and ultimately foster a culture that keeps teams in sync.
Marat Kiniabulatov, project manager at SkuVault, will give a talk about the anatomy of distributed teams at the Atlassian Summit Europe 2018. This event will be held September 3 - 5 in Barcelona, Spain:
Join our team along with other users to be inspired, hear expert advice on the best ways to use Atlassian tools, learn about the latest technology and product updates, and celebrate the teams that make the world a better place.
InfoQ will cover this event with Q&As, summaries, and articles.
InfoQ spoke with Kiniabulatov about the challenges of distributed teams, how product owners and stakeholders collaborate at SkuVault and how the workflow is managed, how distributed teams communicate effectively and synchronize their work, and how SkuVault nurtures a culture that keeps teams in sync.
InfoQ: What challenges have you faced at SkuVault when working with distributed teams?
Marat Kiniabulatov: Well, there are plenty, from language barriers, to non-overlapping hours, and to team inclusion and motivation. But the biggest one is communication, that goes hand-in-hand with figuring out workflow and processes that are to be streamlined as much as possible. Collocated teams can patch an inefficient process by face-to-face interaction. But it’s essential for the remote or distributed teams to establish ground rules on collaboration.
InfoQ: How do product owners and stakeholders collaborate to define, prioritize and approve requirements?
Kiniabulatov: A while back we had issues with requirements quality, with tasks being ping-ponged between POs / Analysts and Developers, as there was no sufficient research and data when developers started to work on a new feature. There were no standards for descriptions in some product areas, and you could sometimes get quite vague or contradicting business logic. You know, it’s a startup when everyone’s doing a lot, and quality may get a bit damaged :)
After interviewing and tracking how we process requirements, we came up with a separate project, where upcoming features are collaboratively hashed out with QA and Dev teams, signed off by stakeholders and prioritized by product owners.
The steps in the project’s workflow are:
- Preliminary Evaluation, where we get the product owners researching on the feature suggested by almost anyone
- Later on we have a bulk signing off by stakeholders (usually done once a week)
- Afterwards we hash out the details for user stories alltogether with QA, PO, and development teams, to catch as many possible pitfalls as we can on the higher level, before we start developing. If there’s a need for any wireframes - the UX / UI team helps us by providing such material
- And finally we got Ready for Development bucket, where features wait for the teams to pull them in
This way we were able to increase requirements quality significantly, and we don’t have to run back-n-forth to clarify edge cases.
InfoQ: How do you manage your workflow?
Kiniabulatov: Let me first give a bit of a context: we have got two feature teams, an on call team, and two service teams.
Feature teams work in Scrum, pulling items in their sprint backlog from our global backlog prioritized by product owners.
The on call team utilizes Kanban, since urgent bugs do not allow proper planning in advance, given their unpredictable nature. The main idea behind on call teams is to react on urgent issues and let feature teams work uninterrupted. We rotate teams to prevent burning out.
The latter teams are devops and core teams that support operations.
Excluding DevOps, most teams utilize the same development workflow: Todo, In Progress, Code review, Testing, Done - typical Kanban buckets with WIP limits.
We use Atlassian Jira task tracker to reflect this workflow virtually for our distributed teams.
InfoQ: How can a distributed team that has no overlapping hours communicate effectively and synchronize their work?
Kiniabulatov: Each team is unique, and it’s up to the members to decide what works best for them; they just need to inspect and adapt over the time. There’s no single catalogue for collaboration patterns when the team members are far from each other and that slows down the adoption of distributed teams.
Most teams don’t have the luxury to start the project onsite together, so my job is to help the team see the spectrum of collaboration techniques and understand which one’s suitable for them.
The most efficient way is to shift working hours to accommodate each other. This way they get some shared working time. Some of our teams are even blending retro and sprint planning together, to sync with members that are offshore.
There’s a team liaison concept when you need to connect two distributed team parts, or connect with other teams that are unreachable during your working hours. A team member is elected as a liaison, and represents his coworkers on daily scrums, scrum of scrums, or any company-wide discussions. This is a rotational role.
I’ve written an overview of agile communication techniques for teams that don’t overlap in working hours, have a language barrier or simply distributed in my blog.
But none of the concepts above would be effective without requirements standards, more documentation (in a sense of scribing all decisions written down and searchable throughout the knowledge base) and easy-to-use workflow.
InfoQ: How do you nurture a culture that keeps teams in sync?
Kiniabulatov: Healthy culture is spread and maintained only when employees understand and share it themselves. In a perfect world, culture reflects common goals and affects motivation, which is achieved by making employees being heard, and their ability to contribute to both the project and organization and flourish professionally.
At the end of the day people are the main asset, and motivated employees no matter distributed or not can bring biggest and boldest products to life. And just like the organization itself, culture that represents it is dynamic and can change over the time.
Teams based on trust, respect and openness will encourage themselves to help people throughout the organization, will visit other teams’ events to hear about ongoing work and tell about their troubles, post humorous blog posts on their achievements, and "kudos" each other in chats.
Funny and entertaining activities that bond people together include: searching cat pics for the release notes (and be sure that the whole team participates in finding the cat that represents a huge project released), sending small presents to each other every other christmas, working on side-projects together (whether it’s webcam-based-car-repair or game development), skype beer-drinking sessions.
So light up employees and they’ll transform the culture to be as vibrant and motivative as they are themselves.