Ed Sykes - Cross Shore Teams AOTB2012

Making cross-shore time-zone spanning teams work

@[email protected]

Wednesday, 5 September 12

Tell a story about what we didgive context - off-shoring is entangled with the way we worked. Need to understand where i am coming from to figure out whether what we did is useful for you...observationsadvice (some overlap)

mailto:[email protected]

mailto:[email protected]

AUDIENCE


Who is agileWho is doing incremental developmentWho is using an off-shore teamWho is thinking about using an off-shore team


changes we made to make 1e work better with their offshore teamexplain what 1e does


since sumir is indian that’s where it was setup


1e is based in the uk, london, ealing


1e india company created with a single customer, 1e uk


started with creating QA team - available pool of resourcesworried about being able to find developers


going to explain problems and then how we solved them


all IT domainschallenginghave to continually learn new things


time zone difference: 4.5 hours


Here’s my team - pretty typicalexplain what mQA etc meanautomation crucial, NWSE had 14 platforms to support


explain the breakdownmention uk QA lead and India QA leadonly QA roles are off-shored


iterative processbased on scrum / xpexplain plan / dev / qaplanning done only by QA


remember this is 2009


2-3 user storiesplan for a dayexecute (dev / QA) for 9 daysDecide at the end of planning day what will fit in 2 weeksplanning starts with high level from PM. Then discuss solution. Then break.


day of planningplanning artefactsall ukqa deal with platform, infrstructure, think about tests (didn’t communicate to dev)


devs come up with list of tasks


QA discuss tools, platforms, technologies, things we haven’t thought of


second day work startsdevelopers work on single story until no more resources fitthen they work on second user storyno pairing


devs complete tasks uk mQA writing test caseshandover from dev to QA, devs start on another user story


when bugs were found developers switch back to earlier storysome bugs from lack of agreement about scope of user storyDevs didn’t understand QA processQA tested things developers didn’t consider important


stories moved between dev and QAsome stories lasted for more than one iterationsome stories laster even longer, 3 or 4 iterationssometimes 6 user stories were active


once a story had been completed in manual handed over to automationautomation would choose most important test cases to automateautomation was always at least one step behind, sometimes more. Out of syncdifficult to automate due to lack of hooks and not wanting to make code changes since devs are on something elsesometimes stories came in batchesbugs revealed through repeated runningpurpose of automation is to reduce regression


still 2009


All this chaos is in the UK


Now let’s talk about handover to indiaOften batches cameIndia had to learn stories by executing test cases


india had to execute lower priority platformswhat message is this sending?!why isn’t automation helping (lagging way behind, job of automation is not to help get stories ‘done’)


handover was conducted over an hourcramming weeks of discussion and testing around a user story into an hour


India logged non-bugsunsupported setupmissing functionality (just out of scope for that user story)simulating the customer doing something unusual


daily meeting in the morning UK timeupdate from indiaupdate from UKeach team in meeting room sat around computer and speakerphonedesktop sharing


two teams would be working on different user storiescouldn’t understand each others updateindia would hear snippets from ‘future work’Outside of meetings UK reluctant to spend time talking to india due to iteration deadline


Relationship wasn’t very goodIndia liked email so as not to interrupt ukPoor communication mediumuk preferred phone but didn’t want interruptions


Tried to solve this by adding more detail to test cases (india and uk agreed this)


started to turn indian colleagues into robotsdeskilling effect - exact opposite of what we wanted! vicious circleuk forgot details - india frustrateduk resented ‘obvious’ questions


technical gremlins


hard to hear in meetings - meeting rooms echoesdidn’t know who was talkingimpossible to follow discussiondiscussion explained at end to india


india power outagesphone lines going down


tried video conferencingcompetition for resource across whole business


competition for meeting rooms in the uk and indiaadhoc meetings were difficult to dosome people held noisy meetings in open plan office


‘They’re doing this / that’discontentno joint retrospectivesno shared work


each team had their own pain / triumphnothing sharedno collaboration



we start to think about how to get everyone working together betterhow can we solve underlying problemsdaunting problem, where to start?


start with the easy stuffstarted trying to build personal relationshipsbring QA leads over


We had a problem with regressionleave it till the end of all the user story work


didn’t know how long it would take until the enddidn’t know what bugs would be foundwe weren’t release readymanual process


India took on regressionOften struggled due to lack of product knowledgeFound it hard to do risk based regressionAutomation was catching upRegression time came downWorking better with teamStill not working on same things


Another team started to pair testers up - one india / ukTrying collaboration for the first time


QAs share Acceptance tests (we’d moved to ATDD), regression Regression testing part of donePlanning still UK onlyUK QAs explain stories to India QAs after planning and while waiting for user story work


Still in iterationsPlanning still takes whole dayOverlap isn’t enoughTechnology use isn’t good enoughSharing work though!Sharing triumphs / problems



UK QA lead went on maternityNew lead clashes with India Lead


New QA lead sees bugs are mostly found by the UKIndia still coming up to speed, from a long way backNew QA lead decides that India QAs can’t do the jobI’m convinced it’s the system


Lead Architect and I go to India to see problems from their point of viewIndia having trouble understanding incremental developmentWe see how little information they receive compared to UK (from planning)We see how smart and energetic India is


We tell India that we want them to be equal to the UKIndia and really excited about thisRaj and I decide to get them involved in planning - still don’t know how


When we return relationship between UK / India leads deteriorated beyond repairBoth leads removed from positionsNew India / UK QA Lead appointed


Start to repair the damage done with exercisesShared values exerciseTeam agrees on everything (we kept away from anything controversial)


get to know exercisedraw what you do on the weekendfunny answersreally helped us to learn about each other


exercises done with videolaughing and joking between everyonejokes extend into other interactionspersonal contextrapport


Still not planning togetherbut thinking about it


Still not doing joint retrospectivesRetrospectives still analogue


collaboration starting to break down barriers


bring the mQA and aQA lead over to the UKgoal to allow them to live the incremental agile development experiencegoal to mend personal relationships and to get to know team


Spend a lot of time with themGet the know them well on a personal levelWe complete a feature togetherVery successful piece of workAttitude of UK testers


India leads head homeStronger personal relationships spur us on to solve our problems


What about planning together?What about better dailys?


Tried video conferencingWe try using MS Lync - explain what it isIndia on headsets in front of computersUK on speakerphone in meeting roomIndia can hear us better, we struggle to hear them


We try everyone on headsets in front of computers


We experiment with the tech using the dailyLearn the best way to run daily


Use first name alphabetical order to speakLearn to mute everyone in lync when not talking, keeps background downTwo people close to each other talking causes volume pumpingUse icons to know who is speakingBring up everyone’s photos to see what people look likeTry video, disrupts the audio channel, revert to audio + screen sharing


Notice new phenomenaPeople surfing web / checking emailsDecide to do nothing about it, in an analogue standup can’t tell when they are daydreamingSome non-crucial chit chat happens (sometimes in IM). Decided to be more relaxed than analogue co-located meeting


Team culture starts to develop from working together and having meaningful daily conversations


Notice cultural phenomenonLearn to ask questions in the right way



Recap: Daily going wellTeams sharing workStill doing iterations


Size of the work has started to come downConservative on adding stories to iterationPlan early if we finished early


Moving towards a flow based system (lean / kanban)Plan single story, executemQA testing as we developaQA write automated tests with developersDevelopers check in code, tests go green, move onto next storyThis is theory, still learning :)


planning one story at a time fits in common hoursUse of technology has bedded down to allow planning attempt


At first it’s hard goingIndia has a lot to learnWe persevere (get back on the bike!)Get better with each story plannedPlanning must happen in mornings


We discover record feature in lyncStart recording all meetings for people on holiday etcRealise that we can plan when India have gone home - they watch recording


Curious inversion of who discovers bugsUK devs tend to handover late in dayIndia mQAs are first one to try user stories outThe system governs performance!


The UK devs discover that Lync / headsets better for pairingHistorical resistance due to pairing experience (hard to get round desks, far from screen)


Team starts to go beyond pairing to posse programmingTeam programming style starts to developSpreads to developers and automation QAs pairing tyo write automated acceptance testsCollaboration through the roof!Everyone working through everything together


Final hurdle is retrospectivesStart doing them online with whole teamUsing trelloFill in items as they happen - meeting starts quickerStart solving problems togetherFosters closer team


BIG OBSERVATIONS1. There is a limit to how much change people can absorb. When starting expect it to take 3 years to adapt off-shoring to your context.

2. Don't give up with technology. Just like you didn't give up when learning to ride a bike!


OBSERVATIONS: STRUCTURE1. Having a company dedicated entirely to servicing 1e allowed focus

2. Offshoring QA meant that local talent matched function and available resource in network of people involved

3. Treating the offshore team as equals generates better results

4. The fewer hours your on and off site share the harder it is

5. Keeping off-shore teams together working on the same product was crucial in continually improving on all fronts


OBSERVATIONS: COLLABORATION1. If you don't have the same problems and successes you're not collaborating enough

2. If your offshore team member hold a different retrospective to your onshore members you're not operating as one team

3. Lowering the quality of interaction between on-site team members allows greater effectiveness overall with on-site and off-site team members.

4. If you start to leave behind off-site team members it's very hard to catch up understanding later on

5. Adding lots of detail to test cases, giving the precise steps to follow prevented india from learning the product. The detail de-humanised them and turned them into human executors.

6. Working a a fully distributed team is easier than working as 2 co-located sub-teams.

7. When you increase collaboration you'll find new things that the offsite team needs to learn

8. You don't really understand how to do something until you do it yourself. e.g. writing test cases during planning

9. Much more than co-located teams, the structure of your work governs your ability to perform

10. Whether you do a retrospective together is a good gauge of whether the work is structured correctly


OBSERVATIONS: CULTURE1. Having a company dedicated entirely to servicing 1e allowed focus

2. Offshoring QA meant that local talent matched function and available resource in network of people involved

3. Treating offshore team as equals generates better results

4. The fewer hours your on and off site share the harder it is

5. Keeping off-shore teams together allowed continuous improvement

6. Infrastructure is not always reliable in off-shore locationsWednesday, 5 September 12

OBSERVATIONS: RELATIONSHIPS1. A voice on the other end of a phone doesn't feel like a real person until you see or meet them

2. Strong relationship the CEOs of 1e and 1e Inc was a benefit

3. Personal relationships can paper over the cracks of process problems

4. A strong relationship between the leaders in each location is crucial

5. Sometimes the damage to relationships is so bad that it can't be repaired

6. Personal relationships are like the wind in the sails of your boat, they power your movement in the direction you face


ADVICE: STRUCTURE1. Match the off shored function to accessible talent pool

2. Choose the closest time-zone you can for the off-site

3. Bring at least the leaders of the offsite team to the onsite location

4. Send at least the leaders of the onsite team to the offsite location

5. Consider infrastructure when deciding where to locate off-shore team


ADVICE: TECHNOLOGY1. Choose a technology that allows video

2. Choose technology that allows you to easily record meetings

3. Use recorded meetings as a way to allow meetings outside of common time to happen immediately: share the recordings to bring india in.

4. Experiment with technology

5. Use your most frequent and low impact meeting to drive the adoption and mastery of technology

6. Only start using technology in high impact meetings when you're mastered it

7. Find a collaborative whiteboard technology, mspaint and screen sharing is not good enough


ADVICE: COLLABORATION1. Structure the way you do the work to allow collaboration

2. In planning rotate the leadership role amongst on-site and off-site team members to allow them to learn how to plan

3. Working together on the same thing allowed us to immediately understand the gaps in knowledge of the offsite team

4. Collaborating taught the off-site team our culture and how to work self-directed

5. Have the whole team share the same goal, e.g. to get UserStory x done

6. Avoid turning people into human executors.

7. During planning, rotate leadership of the planning around the on and off site team members. For example have everyone take turns to write the given when then.


ADVICE: CULTURE1. Allow unfocussed time in daily meetings for bonding.

2. Have shared retrospectives

3. Early on use games to help everyone get to know each other

4. Send your leaders to the offshore team to teach them your ways of working and philosophies


ADVICE: RELATIONSHIPS1. Send Uk team members to remote location and bring remote location team members to the UK

2. If leaders on the on and off site can't develop a working relationship, change the leadership

3. Use games and structured meetings to create a personal context


http://martinfowler.com/articles/agileOffshore.html

http://www.firstlinesoftware.com/agile/offshore_agile/






Documents

Ed Sykes - Cross Shore Teams AOTB2012