ed sykes - cross shore teams aotb2012
TRANSCRIPT
Making cross-shore time-zone spanning teams work
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)
AUDIENCE
Wednesday, 5 September 12
Who is agileWho is doing incremental developmentWho is using an off-shore teamWho is thinking about using an off-shore team
Wednesday, 5 September 12
changes we made to make 1e work better with their offshore teamexplain what 1e does
Wednesday, 5 September 12
since sumir is indian that’s where it was setup
Wednesday, 5 September 12
1e is based in the uk, london, ealing
Wednesday, 5 September 12
1e india company created with a single customer, 1e uk
Wednesday, 5 September 12
started with creating QA team - available pool of resourcesworried about being able to find developers
Wednesday, 5 September 12
going to explain problems and then how we solved them
Wednesday, 5 September 12
all IT domainschallenginghave to continually learn new things
Wednesday, 5 September 12
time zone difference: 4.5 hours
Wednesday, 5 September 12
Here’s my team - pretty typicalexplain what mQA etc meanautomation crucial, NWSE had 14 platforms to support
Wednesday, 5 September 12
explain the breakdownmention uk QA lead and India QA leadonly QA roles are off-shored
Wednesday, 5 September 12
iterative processbased on scrum / xpexplain plan / dev / qaplanning done only by QA
Wednesday, 5 September 12
remember this is 2009
Wednesday, 5 September 12
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.
Wednesday, 5 September 12
day of planningplanning artefactsall ukqa deal with platform, infrstructure, think about tests (didn’t communicate to dev)
Wednesday, 5 September 12
devs come up with list of tasks
Wednesday, 5 September 12
QA discuss tools, platforms, technologies, things we haven’t thought of
Wednesday, 5 September 12
second day work startsdevelopers work on single story until no more resources fitthen they work on second user storyno pairing
Wednesday, 5 September 12
devs complete tasks uk mQA writing test caseshandover from dev to QA, devs start on another user story
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
still 2009
Wednesday, 5 September 12
All this chaos is in the UK
Wednesday, 5 September 12
Now let’s talk about handover to indiaOften batches cameIndia had to learn stories by executing test cases
Wednesday, 5 September 12
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’)
Wednesday, 5 September 12
handover was conducted over an hourcramming weeks of discussion and testing around a user story into an hour
Wednesday, 5 September 12
India logged non-bugsunsupported setupmissing functionality (just out of scope for that user story)simulating the customer doing something unusual
Wednesday, 5 September 12
daily meeting in the morning UK timeupdate from indiaupdate from UKeach team in meeting room sat around computer and speakerphonedesktop sharing
Wednesday, 5 September 12
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
Wednesday, 5 September 12
Relationship wasn’t very goodIndia liked email so as not to interrupt ukPoor communication mediumuk preferred phone but didn’t want interruptions
Wednesday, 5 September 12
Tried to solve this by adding more detail to test cases (india and uk agreed this)
Wednesday, 5 September 12
started to turn indian colleagues into robotsdeskilling effect - exact opposite of what we wanted! vicious circleuk forgot details - india frustrateduk resented ‘obvious’ questions
Wednesday, 5 September 12
technical gremlins
Wednesday, 5 September 12
hard to hear in meetings - meeting rooms echoesdidn’t know who was talkingimpossible to follow discussiondiscussion explained at end to india
Wednesday, 5 September 12
india power outagesphone lines going down
Wednesday, 5 September 12
tried video conferencingcompetition for resource across whole business
Wednesday, 5 September 12
competition for meeting rooms in the uk and indiaadhoc meetings were difficult to dosome people held noisy meetings in open plan office
Wednesday, 5 September 12
‘They’re doing this / that’discontentno joint retrospectivesno shared work
Wednesday, 5 September 12
each team had their own pain / triumphnothing sharedno collaboration
Wednesday, 5 September 12
Wednesday, 5 September 12
we start to think about how to get everyone working together betterhow can we solve underlying problemsdaunting problem, where to start?
Wednesday, 5 September 12
start with the easy stuffstarted trying to build personal relationshipsbring QA leads over
Wednesday, 5 September 12
We had a problem with regressionleave it till the end of all the user story work
Wednesday, 5 September 12
didn’t know how long it would take until the enddidn’t know what bugs would be foundwe weren’t release readymanual process
Wednesday, 5 September 12
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
Wednesday, 5 September 12
Another team started to pair testers up - one india / ukTrying collaboration for the first time
Wednesday, 5 September 12
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
Wednesday, 5 September 12
Still in iterationsPlanning still takes whole dayOverlap isn’t enoughTechnology use isn’t good enoughSharing work though!Sharing triumphs / problems
Wednesday, 5 September 12
Wednesday, 5 September 12
UK QA lead went on maternityNew lead clashes with India Lead
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
When we return relationship between UK / India leads deteriorated beyond repairBoth leads removed from positionsNew India / UK QA Lead appointed
Wednesday, 5 September 12
Start to repair the damage done with exercisesShared values exerciseTeam agrees on everything (we kept away from anything controversial)
Wednesday, 5 September 12
get to know exercisedraw what you do on the weekendfunny answersreally helped us to learn about each other
Wednesday, 5 September 12
exercises done with videolaughing and joking between everyonejokes extend into other interactionspersonal contextrapport
Wednesday, 5 September 12
Still not planning togetherbut thinking about it
Wednesday, 5 September 12
Still not doing joint retrospectivesRetrospectives still analogue
Wednesday, 5 September 12
collaboration starting to break down barriers
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
India leads head homeStronger personal relationships spur us on to solve our problems
Wednesday, 5 September 12
What about planning together?What about better dailys?
Wednesday, 5 September 12
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
Wednesday, 5 September 12
We try everyone on headsets in front of computers
Wednesday, 5 September 12
We experiment with the tech using the dailyLearn the best way to run daily
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
Team culture starts to develop from working together and having meaningful daily conversations
Wednesday, 5 September 12
Notice cultural phenomenonLearn to ask questions in the right way
Wednesday, 5 September 12
Wednesday, 5 September 12
Recap: Daily going wellTeams sharing workStill doing iterations
Wednesday, 5 September 12
Size of the work has started to come downConservative on adding stories to iterationPlan early if we finished early
Wednesday, 5 September 12
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 :)
Wednesday, 5 September 12
planning one story at a time fits in common hoursUse of technology has bedded down to allow planning attempt
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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!
Wednesday, 5 September 12
The UK devs discover that Lync / headsets better for pairingHistorical resistance due to pairing experience (hard to get round desks, far from screen)
Wednesday, 5 September 12
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
Wednesday, 5 September 12
Final hurdle is retrospectivesStart doing them online with whole teamUsing trelloFill in items as they happen - meeting starts quickerStart solving problems togetherFosters closer team
Wednesday, 5 September 12
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!
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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.
Wednesday, 5 September 12
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
Wednesday, 5 September 12
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
Wednesday, 5 September 12
http://martinfowler.com/articles/agileOffshore.html
http://www.firstlinesoftware.com/agile/offshore_agile/
Wednesday, 5 September 12