Distributed agile teams require commitment to collaboration from both team members and business leaders. Effective collaboration relies on strong processes like daily stand-ups and planning sessions, as well as collaborative tools like video conferencing and document sharing. While technology can help, collaboration is ultimately about people committing to work together across locations through open communication and knowledge sharing.

1. Collaboration for Distributed Teams
Tackling the problem of good communication
within agile teams spread over many locations
Kaunas Agile Tour 2014

2. Walk this way!
Millau Viaduct – Collaboration between
Norman Foster and Michel Virlogeux
Collaboration between RUN DMC
and Aerosmith

3. Introduction
• Commitment to collaborate
• Business commitment to agile
• Distributed teams
• How have we done it?
•People
•Technology
•Tools

4. Commitment to collaborate
• Agile is hard
• It is about people and their commitment to collaborate
• Team contract or working agreement
• Sprint/Time box planning
• Task sizing
• Stand-ups
• Retros

5. Business Commitment to Agile
• White boards
• Sticky notes
• Team spaces
All examples I have found are single location

7. But what about distributed teams?
• There has been development collaboration for years in the Open and
Closed Source worlds
•E.g. Apache 1.0 released on December 1st 1995
• So how is that different from our Agile projects?
•Very developer led
•Project Management Committees allowing access to commit source code
•Voting on features
•Organic entity

8. How have we done it?
The People
• A bit of background
•We have people in 4 physical locations (3 in UK and 1 in LT)
•We have 2 partners (1 in UK and 1 in Poland)
• But why don’t we just have singe location project teams?
•Our internal customers are all in one place
•We don’t have all skills in every location
• Each person on a project commits to collaborate - they know that they
can not build the system on their own
• The team decides how they are going to work - what is important to
them - working agreement (see next slide)

9. Project Working Agreement
• All follow agreed stand up etiquette – be
prepared, be concise, everyone else
silent, only give actions and blockers –
discussions left for triage, respect
location.
• Meetings will : start and finish on time,
have an agenda, only have relevant
people.
• Collaborative Discussions – Face to face
is best. Discussions not to take place via
email. Group email is to inform not
discuss.
• Keep up morale of the team – regular
get-togethers.
• Documentation – right balance, visible,
agreed in timebox planning session.
• Discussion on stories to be documented.
Start small and scale up as necessary.
• Treat team mates as you would expect
to be treated.
• Achieve a common understanding –
knowledge sharing, understand stories,
use team Wiki.
• Think business not just technical – agree
regular demos.
• Eliminate blockers as early as possible
and be pro-active thinking ahead.
• Be consistent with planning method –
story points and high level task planning
for timeboxes.
• Team commitment to quality – test early
and often and use automated tests.
• Timebox changeover – retro afternoon,
planning following morning. Alternate
locations when possible.

10. The People (continued)
Note, not much technology is outlined... as this may change
• But key points:
• No discussion on email
• Use of wiki for documentation
• Face to face is best

11. The People (continued)
• Scrum of Scrums
• Issues brought and resolved
• Pizza Friday
• Common function community get together
• any subject can be proposed
• the attendees decide on agenda during the session
• Dojos
• Community skills sharing
• focussed on a particular topic
• Lunch Bites
• Project, product or technology information share

12. How have we done it?
The Technology
• Face to face is best - the teams get together:
•at the start of projects
•at "big" points
•at deployments
•at the end to celebrate!

13. The Technology (continued)
• Video Conferencing -
•this is the corner stone of our collaboration
•all stand-ups via VC
•VC rooms in all locations
•starting to use desk to desk VC more and more as technology gets better 1to1 common
place, but many to many becoming more common
•Water Cooler Window - ad hoc window between sites
•starting to see virtual team screens - a combination of WCW and desk VC

14. The Technology (continued)
• Phones and conference calls
•this is still an important part of day to day life, but seeing less and less as all desks are
getting VC (more with people outside the project teams)
• Text based live communication (chat rooms)
•widespread, many conversations at once
•permanent record
•file sharing
• Document Collaboration
•the most important
•central location
• Email
•has it's place, but used for notification only
•don’t send a document… send a link

15. How do we do it?
The Tools
• Source Control
•We all understand the importance of good source control
•I promote the use of developers and testers having full access to
source - increasing collaboration
•Now we are seeing our system administrators, network engineers all
using source control for collaboration and DevOps activities
•TFS, GIT, CVS, SVN

16. The Tools (continued)
• Wiki/Document collaboration
•This can't be stressed enough, documents once out of first draft, must
be managed centrally
•Example of non central document management - training slots
•Example of Thursday night boys – text (bad), now the kids collaborate
with facebook (good)
•Sharepoint, Google Docs, DocuWiki

17. The Tools (continued)
• Interactive/electronic white boards
• We use SMARTTech 8070i
• these are great for collaboration
• when not in WCW mode, they are used for cross site collaboration
using interactive software SMART Ink and Lync
• Planning visualisation
• TFS, Urban Turtle, Jira

18. Some Examples
• Developer wanting access to database server
•Ticket, emails, back and forth, closed tickets, re-opened tickets
•Come and have a look, realisation, more is done
• Database developer working on database deployment
•Developing on own, DBA review at CT deployment, knocked back
•Getting DBA on board and getting advice early in dev process
• Tester testing code after development
•Defects found and ticket raised, QA type approach
•Dev and Test working together, zero defect development

19. To Summarise
• Collaboration is about people committing
• Strong processes and methods
• Tools can help, but it is about hearts and minds