Distributed Agile best practices: An expert round-up

 

Bryan Jacobson

Scrum Master, Dealertrack Technologies

Accomplished leader with a track record delivering outstanding products. Strong communicator who connects stakeholders to developers and collaborates across all parts of the organization.

 

"First of all, we should be honest with ourselves and admit that a “distributed” agile team will never be as effective as a co-located team.

In fact, people see improvement seating team members within view and within a few steps of each other, versus in different rooms or on different floors of the same building. When you’re in the same place questions get answered within seconds, instead of minutes or hours. You overhear conversations you need to hear. Multiple team member can consult with each other quickly. You can tell if it is a good or bad time to interrupt another team member.

However, for many reasons, sometimes you have a distributed team or remote team members. What to do?

1. Travel

It makes a vast improvement to spend at least a day or two face to face, at least once, and ideally two or more times a year.  Communication improves. Team work improves. “Us vs them” is reduced.
If you can’t do regular travel, doing it at least once also makes a significant improvement.
I realize that some teams, due to budget constraints, cannot get travel approved. As Agile experts we should advocate that we don’t make a one sided analysis that assumes “travel costs money” and “not traveling is fine”. We should find ways to quantify the impact of missed communication, teamwork difficulties, misunderstanding, rework to correct problems, missed customer deliveries due to time spend correcting problems, etc.

(Obvious, and everyone does this): If time zones differ, make good use of the times when both teams are in the office. In extreme cases some team member may need to come in early or late.

Top recommendation: If you have a team that is largely co-located, but has one or a few remote team members, the remote team members will be at a disadvantage.

2. Remind everyone to over-communicate

• Make it the responsibility of the remote team members to make sure the communication happens. They should:

• Call on the phone (over email) as much as possible. Video call is even better.

• It is the remote person’s responsibility to ask for information.

• It is the remote person’s responsibility to ask to be included.

• It is the remote person’s responsibility to pick up the phone when they are not sure.

• Categorize email as “non-communication”. A growing percentage of people are simply not reading their email.

 

Top recommendation: Video calls are very beneficial. Seeing the other person makes the other person seem more human. You engage better. They engage better. It forces the remote person to be engaged and participate (not sit there partly listening, but partly reading their email or whatever).

3. Use a Chat based team collaborations systems like HipChat or Slack

• Require everyone to monitor it.

• Require everyone to use it for questions.

• Use team rooms for most conversations.  That way everyone sees the conversation, knows what the problem is, what the solution is, etc.

• Have special channels for critical communication if the main team room gets “too chatty” and people miss important notices.

 

Benefits: Everyone sees critical conversations. Less interruptive than the phone. If someone is out on the break or in a meeting, they see messages when they get back. Faster than email, harder to ignore than email.  There is a record of conversations that can be checked later.

Top recommendation: Have an online system of information record, such as a wiki or issue tracking system. That way everyone has the same view of information. 
Use the rule: If it’s not in the wiki, it didn’t get decided. A conversation that some people heard, and others didn’t, doesn’t qualify as a team decision"

Daniel Mezick

Agile Coach & Author

Coaching executives and teams since 2006, Daniel Mezick is an expert on extending adaptive Agile culture beyond software. A published author, his books The Culture Game (2012) and Open Space Agility Handbook (2014) talk about his Agile philosophies and help teams and enterprises work better.

"In general, distributed-Agile teams that want to be successful are subject to the very same Agile principles as co-located teams. This means (for example) that "working software is the primary measure of progress," and that "business people and developers must work together daily throughout the project," and that "the most efficient and effective method of conveying information...is face to face conversation."

Distributed-Agile teams that keep Agile Manifesto principles in mind are the teams that will win big with Agile. The actual methods or practices are far less important than the principles that power them. So for example, a team may use one of several methods to practice the following principle: "business people and developers must work together daily throughout the project." As long as the practice aligns with (and does not directly violate) Agile Manifesto principles, the team- distributed or otherwise- is going to be OK. And do great work. And deliver working software-- ourprimary measure of progress."

Suzanne Prince

Director, Product Management, ThoughtWorks

Suzie Prince works with ThoughtWorks Studios as Director of Product Management. She has ten years experience designing, building, and delivering software for large and small organisations in a variety of domains.

 

"Distributed teams require specific and purposeful management that is different than co-located teams. Clear, articulate and specific communication is deeply important. I highly recommend peer-to-peer collaboration between teams or individuals who are not located in the same place. Removing silos and exchanging information frequently is paramount to success. At the same time I recommend having full stack teams and minimizing dependencies between teams. When dependencies do occur creating clear contracts and hand offs is important. Tools that support visual representations of work in and between teams as well as tools that support synchronous and asynchronous communication are essential.

Avienaash Shiralige

Agile Coach, Srijan Technologies

Avienaash Shiralige is an agile coach and trainer, and has been working in close conjunction with Srijan. For him, agile is a way of life, and he helps business and teams understand and implement agile methodologies into the way they function. He also shares his expertise and experiences on his blog titled “Agile Buddha’

"Information sharing and communication are well known challenges when you offshore. A great aspect of Agile is the open synchronization of the team on a daily basis. But, how is the remote development team synchronized with the local team or with customer?

Here are a few distributed agile best practices that you can incorporate into your work culture:

1. Streamline offshore team communication and development infrastructure

The off shore team must be able to seamlessly communicate with the onshore team. You could use emails to video conferencing and anything in between. Go for a trial before you start on a project. If you experience any technical issues during trial, demand an upgrade and/or additional systems. Fix them before you dive into project

2. Meet face-to-face to build trust
If the offshore team is small, bring the entire team onshore for some up-front project activities such as establishing the shared project vision, requirements elicitation, initial planning and execution of initial 2-3 sprints. If the team is big and budget is limited, then have key members of the team onsite. Additionally, plan travel of onsite teams to offshore location and spending few sprints together.
Travelling onsite is a big investment, so make sure it brings tangible returns.Define collocation goals and closely track it. Teams should spend outside office time together to build informal relations.

3. Reduce work disruptions due to each other
Establishing continuous integration approach with good test coverage is a must. Good CI will ensure teams getting successful green build when they start their day. This will reduce work loss or productivity loss due to one team committing bad code and next team unable to use that code base. You could also have a common email list between teams, where you post your issues.This will get you support from other team members not just in common office hours, but also during outside of office hours too.

4. Shared project Vision
When you are starting a project and all along the project keep offshore team completely involved in all the activities. Share customer feedback, involve them in release planning, doing all scrum ceremonies together. The Product Owner (PO) has to make an extra effort in communicating product vision, road-map, his conversations with product users etc to offshore team. Product Owner spending a sprint or two together with offshore team, makes the team feel important and in the process lot of domain knowledge gets transferred.

5. Synchronize your working hours to get at least 1-2 hour overlap
Plan at least an hour of overlap between local and remote teams. Use this one hour for synchronization and information flow between teams. Plan your joint team activities like pair programming, reviews, joint meetings, distributed stand-up etc during this overlap. Even in extreme situations like 12 hour delta between teams, local and remote team can alternatively extend their day to get sufficient overlap.

Some Agile purists say that Agile is contradictory to multi-shore development because of its inherent reliance on face-to-face communication. I consider agile thinking(short sprints, working software, focus on people and collaboration and more) is a natural solution for above offshore challenges. Yes it requires new way of thinking and doing.

You can also watch our webinar by Avienaash and discover why distributed agile teams are necessary for global enterprises.

Ken Collier

Director of Data Science & Engineering, ThoughtWorks

Dr. Collier leads a team of brilliant data scientists, data engineers, and data analysts. The focus of this practice is on advanced “big data” analytics solutions that combine adaptive data pipelines, modern data engineering, rigorous data science, and data savvy business analysis to create maximum value from data.

"Cross-team communications in distributed/remote agile teams is a function of three key factors - distance (timezone difference), language difference, and cultural gaps. Each of these decreases the effectiveness of cross-team communication/coordination, but distance is perhaps the most significant.

• Timezone: When a team is separated by 6 timezone hours or more, asynchronous communication becomes the norm. At ThoughtWorks we seek to shrink this separation by using near-shore distribution whenever possible (e.g., US/Brazil, India/Australia, etc.)

• Language: Language barriers are the next most significant factor. The distributed team as well as the customers must have at least one shared language in which everyone is fluent.

• Agile Terminology: The "agile language" must be common for everyone. Does everyone have a shared understanding of what "pairing" means, the rigors of test-driven development, and the definition of "done"?

• Culture: Cultural differences, both regional and corporate, are impactful. The team should establish a shared set of cultural norms and expectations. For example, is there a cultural of hierarchical subordination (i.e., "pecking order") held by the remote team that differs from that of the host team? At ThoughtWorks we routinely rotate distributed team members from the remote location (where the delivery team is) to the host location (where the customers and stakeholders are) for a few iterations at a time. In this way everyone on the distributed team gets some face-to-face collaboration with customers, stakeholders, and other team members thereby building a shared culture of trust, familiarity, and clarity about the project."
  
  

Ben Linders

CEO, ScrumInc.

Jeff is the inventor and co-creator of Scrum. He launched the first Scrum team in 1993 and has shepherded its growth into almost every industry: finance, healthcare, higher education and telecom.

 

"Scrum Inc is totally run by Scrum - marketing, sales, finance, consulting, training, software development, everything we do. Everyone is on a single Scrum team. I am on a distributed team and it is essential for us to fly everyone into to a two day quarterly meeting face to face where we do quarterly planning, retrospectives, and build team agreements. We do one week sprints and meet on Google hangout for all other Scrum meetings. We are heavily into Legos these days and my Scrum Master ran the quarterly retrospective this week by having team members build lego structures representing the best and worst experiences they had. It was deeply insightful."

So that was seven Agile experts sharing their take on distributed agile best practices. You could also take a closer look at all the different challenges that can arise in a distributed scrum model, and how to resolve them. We hope you found this post useful, and will now be able to take an informed decision on starting to work with distributed agile teams.