Working in distributed agile - how to collaborate a scrum team working from different geographical locations
The scrum manifesto focuses on the importance of co-location, where members sit together and work closely with each other. However, in actual practice, a good number of service providers work with scrum teams where team members are located across different states of even countries. So, quite a contradiction , huh?
How many of us has watched this movie "Up in the Air" ? I was intrigued by the use of a particular term there, which I feel very relevant to this situation we are talking about. It is "GLOCAL", which breaks downs to, "GLOBAL+LOCAL".
So here, we are slightly (or may be, to an good extent...) modifying the meaning of co-location, which we try to achieve by a "virtual" colocation.In here, we make the maximum use of collaboration tools to give a "feel" to the resources that they are virtually co-located and just by turning the head or a tap on the shoulder they can reach out to each other.Now this cannot be achieved in a day, but can be done eventually. So where do we start with?B
The first step is reducing the overuse of a very important collaboration tool , which is the e-mail. We all have this belief that once a mail is sent, we have washed off our hands and passed the buck, but that is not how agile works.
So use mails only when it is a formal notice towards other teams, internally, avoid using it. What you should use instead is a chat tool like Skype for Business/ Hipchat / Rocket chat, one where you can form a group and you can constantly post any query to the group . This mimics the situation where you just ask someone across the desk, but others can overhear as well and if they have any comments, they can surely chip in.
Next, ensure daily standups are must with attendance from all members, and you again use a Webex/rocket/skype or hundred other products in market where you can see and talk to each other over the video, and all discussions are done by sharing the screens.
Same goes with the refinements, sprint planning and any other technical huddles. Now, this also means the scrum master and the management has to ensure that the infrastructure and logistics are in place to enable it, and that is what they should focus on , if they want to get the cost-benefit from distributed agile teams.
Finally , use the Jira , to the maximum extent. Feel free to write down your thoughts in your comments and tag others . I can tell from my personal experience as a scrum master, this drastically brings down the number of communication channels , and , to a huge extent , helps avoid any major miscommunication. Plus, this helps to refer back at a later point of time. Also do not forget by Jira we mean use the Digital board, and never use a local board + Jira board in tandem, you will always be at risk to miss out in updating one of them, plus it is additional work.
So these are my tips on how to start with distributed agile. Request your suggestions and comments which will help us mature this process to further extent.
This is something we've been trying to work out in my organisation.
We have a team based both in the UK and in Australia working on the same Product.
The issue has arisen that due to legal constraints, the Australian members cannot work outside the hours of 7am-7pm, and the UK members can work between 7am-7pm too. This means there is only one hour crossover time between offices.
The team is brilliant at using tools such as Trello and G-Chat to stay in constant contact, but we're having issues when it comes to reviews and plans, as trying to get the (UK) team to come in for 7am is a hard sell!
So far, I've been conducting 2 StandUps/Day, to ensure that everyone is up to date with what's going on on the other side of the world, this seems to be working, and people do catch up outside of the Daily StandUp too.
Any advice/tips on this would be most appreciated!
Thanks
We do not have geo-distributed teams at my current employer (yet. There is talk about it but not in place today). What I have done in the past when I did have this situation is to organize each team to be independent Scrum Teams. Each one works on their own backlogs solving their own problems. This eliminates the need for cross geo coordination of the events. It also allows the co-located teams to feel more ownership of the work that is being done. The only role that would be geo distributed would be the PO and only if unavoidable. That PO role usually was based in the "middle" geo and was able to work a flexible schedule in order to be available when needed by each of the geos.
Failing that, you have to make the best arrangements you can. Use team chat tools where different groups can provide commentary in a central location where each of the geos can see and respond. Comments in the tool you use for tracking your Product/Sprint Backlog items. I have even heard where each geo would do video recordings of their Daily Scrum and then each of the other geos can view them. But again, this assumes that the work is spread across geos with no or minimal dependencies.
Is the waste that results from having a dislocated team transparent to stakeholders? It sounds like there might be an impact on value delivery which ought to be better understood and perhaps in some way quantified.
I work in distributed team Europe-Asia and it does not work well. In my opinion in order to run scrum we need to meet face-to-face in order to discuss and to exchange ideas. None remote tool can provide this.
I work for an organisation which uses geo-distributed teams working, and it can work well.
Disclaimer - we don't do Scrum by the book.
My colleague (a Scrum Master) runs 3 teams of 5 devs each out of South East Asia with Product Owners based in Australia and New Zealand. The team is working on a web-based product. Because they get through a fair bit of work in a week - Sprints are 1 week long to minimise business risk.
His team is highly dependant on my (Australia based) team delivering regular increments of functionality on a middleware/API platform they consume, so I tend to gatecrash their Standups and Reviews to keep up to date on what they are doing.
Tools they use:
1. Comms for "Face to Face" events (Standups/Planning/Reviews/Retros) - Lync for Business. Everyone has microphone headsets.
2. General day to day comms - Slack
3. Board for backlog - JIRA
4. Board for Retros - GoReflect
5. Planning poker estimation - don't know. (Some online tool)
Events.
All meetings are in team member's calendars with links to the Lync session embedded.
1. Sprint planning. Scrum Master uses JIRA (shared with everyone via Lync) and works with Team and PO to pull enough work in for the Sprint. This is timeboxed to 30 min. (Stories are already estimated - see #5)
2. Standups - all 3 teams get through the 3 questions within the 15 min time box - (see caveat below)
3. Sprint reviews. Dev Team demos new functionality to PO via Lync. Reviews tend to go very well, with very few stories rejected by the PO (see caveat below)
4. Sprint Retrospectives. Via Lync - sharing the GoReflect board.
5. Backlog Refinement and Estimation (i.e. PO + Devs). There are two sessions during the week (60 min each) to refine and estimate stories for the following Sprint. Because their stories are often dependant on my team's stories and we often need input from each other's teams in combined sessions, we decided to break this out of planning for flexibility. Teams use an online planning poker tool to estimate. (This process may not be the best, but it is working for us.)
The one caveat I have is the remote team has been engaged by my organisation for a number of years, so this level of collaboration has been in place for a while, and they are also very familiar with the product sets - so they have a good understanding of the requirements before development starts - hence they tend to fly through Sprint Reviews with the stakeholders.
We should also probably be doing some sort of scaled agile approach to manage the multiple teams and backlogs and dependencies...thoughts on that are a WIP :)
Regards
Steve