Collaboration for Distributed TeamsTackling the problem of good communication within agile teams spread over many locations

Kaunas Agile Tour 2014

Walk this way!

Millau Viaduct – Collaboration between Norman Foster and Michel Virlogeux

Collaboration between RUN DMC and Aerosmith

Introduction

• Commitment to collaborate• Business commitment to agile• Distributed teams• How have we done it?

•People•Technology•Tools

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

Business Commitment to Agile

• White boards• Sticky notes• Team spaces

All examples I have found are single location

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

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)

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.

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

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

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!

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

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

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

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

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

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

To Summarise

• Collaboration is about people committing

• Strong processes and methods

• Tools can help, but it is about hearts and minds