Many Software Development teams claim to be “Agile” when in reality their practices are more “Agile-ish” or (even worse) just a very rapid Waterfall. In the case of Agile Scrum this is sometimes referred to as “Scrum-but.” Thankfully, the dev team here at gap intelligence are committed to respecting best practices for Agile Scrum.
“Scrum-but”
One of our biggest challenges to avoiding “Scrum-but” has been the structure of our team. While our main office is based in San Diego, we also have developers in Tashkent, Uzebekistan and Vancouver, Canada. While San Diego and Vancouver are both on the West Coast of North America, Uzbekistan is almost literally on the opposite side of the planet.
As with most distributed teams, Communication has been the core issue we have to work through as we strive for an efficient, self-organizing team. In one way or another, it’s a topic of discussion in almost all of our Retrospectives. Many of the solutions we’ve tried have come from blogs we’ve found online and others have been home-grown. Here are some of the tools and processes that are helping us overcome the obstacles of different time zones (12 hours apart), language barriers and cultural differences:
Slack
Photo Credit: mspoweruser.com
It would be difficult to overstate how much our team loves Slack. We originally started using it just within the dev team, quickly expanded to include Product Owners, and then eventually to the entire company. I don't even like remembering our work lives without things like:
- integrations with Pivotal Tracker, GitHub, AppSignal and Meekan
- channels set up for each of our products to facilitate communication between dev team members, product owners and stakeholders
- channels for each of our two Scrum teams to use for discussion, story handoffs, pull requests and issues
- a #coding channel for coding questions/discussions and sharing snippets and links to resources from around the web
- a dedicated #scrum channel for all members to post their updates after sharing them verbally in the Daily Standup … regardless of their time zone
- the hilarious Giphy integration that lets us share some personality and emotion in our online conversations
Adjusted Work Schedules
All of the best-written Slack messages and emails in the world can’t take the place of the non-verbal, real-time interactions that are inherent with face-to-face conversations. In order to facilitate collaboration our team members on both sides of the planet have adjusted their work schedules. We’ve experimented with a couple of options and are currently trying out the Tashkent gappers working “second shift” 3 days a week and the North America gappers signing on an hour earlier than they used to on those days. These 9+ hours a week of predictable overlap have solved many of our issues with sprint ceremonies, story handoffs and stakeholder communication for Production Support. The obvious downside to this approach is the impact to life outside of work, but so far the improved outcomes have been worth the inconvenience.
Google Hangout
All of our meetings are conducted via Google Hangouts which gives us the benefits of both Video Calls and Screen Sharing. Backlog Grooming, Retrospectives and Sprint Planning are all significantly easier when the Tashkent and Vancouver gappers can see what is being typed as well as hear what’s being said in the room in San Diego. This visual component helps soften the language barrier. We do our best to follow the “one person speaking at a time” and “mute unless you’re talking” rules to further improve understanding. In the past, remote team members were sometimes hesitant to interrupt when they couldn’t understand (and would sit quietly instead) so we have also recently recommitted to the best practice of “never assume silence means consent.”
Team Composition
Each of our Scrum teams is made up of developers based in North America and Uzbekistan. We've also adopted a policy that developers can do production support for products that belong to either Scrum team which maximizes our ability to support our internal and external customers with minimal lag time. It might seem unorthodox but it works because we regularly rotate team members and we have the knowledge base within the entire team to support any of our products. As a self-organizing team, our developers coordinate to ensure that no one is taking on more than their share of support vs. sprint commitments. Our blended team structure also helps us tackle and avoid the dreaded “us-versus-them” attitude that can drag distributed teams down.
PlanIT Poker
The practice of verbally sharing estimates has a tendency to favor the louder, more confident voices. We use PlanIt Poker to ensure that every developer’s initial estimates are given equal weight then the team discusses any discrepancies until consensus is reached.
Team Hackathon
Just as in sports, sometimes it helps to drill skills that need improvement. We recently held a round-the-clock multi-day (internal) hackathon for our dev team. Each Uzbek developer was randomly paired with a North America developer and challenged to build something in 2.5 days that “extends, enhances or integrates with one or more of our existing products.” 20% of the total scores were based on a live Demo that smoothly involved both team members. The hacks themselves were impressive, but the focus on teamwork across time zones and clear communication/handoffs have been just as valuable.
Responding to Change
We certainly aren’t perfect in our communication, but one of the beautiful things about Agile is the commitment to inspection and continuous improvement. Our Retrospectives shine a light on friction points and drive us to constantly adapt and evolve. We also love hearing about new ideas that might help us grow. What’s working well for your distributed teams?
