"For over 20 years we have scaled Scrum using a Scrum of Scrums as the release team. So any delivery problems in any team are resolved at the Scrum of Scrums level. Scrum is fractal in nature so if there are many Scrum of Scrums they role up into a Scrum of Scrum of Scrums. Saab Defense has four levels to run the Saab Grippen fighter aircraft factory with the top Scrum of Scrums being the senior management team that meets every day an 8:30. We also developed other proven methods 20 years ago for virtual teams which are implement at Spotify and ING Bank as chapters. I regularly coach both of these companies. For really high performing teams we allow backlog to move across teams during a sprint to automatically level loading but that is beyond the scope of this short comment. In Scrum@Scale we also reduce dependencies and carefully manage any that remain across teams. We eliminate all bottlenecks (there are no release teams, test teams, hardening sprints, operations teams, or other waste that cripples the system) and go to a pure Scrum release every sprint or better yet, every day. For teams that can't do this, their top priority process improvement is to implement it."
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?
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"
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."
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.
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.
Ben Linders is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of "Getting Value out of Agile Retrospectives", "Waardevolle Agile Retrospectives", and "What Drives Quality and Continuous Improvement".
"If you are a new distributed Scrum team getting ready to become productive, a sail boat futurespective helps you to get to know each other and agree upon the way of working for your team. You start by stating your goal and imagine how your team should look to reach it, next you'll explore what you can do to get there. Alternatively you can play a core qualities game to learn about each team member's strengths and find ways to collaborate effectively. You can build a new team using these retrospective exercises.They can easily be done with distributed teams, all you need is an audio/video connection between the team members and an online drawing tool in the retrospective."