Ed Sykes - Cross Shore Teams AOTB2012

Making cross-shore time-zone spanning teams work
@edsykes ed.sykes@gmail.com edsykes.blogspot.co.uk
Wednesday, 5 September 12
Tell a story about what we did give context - off-shoring is entangled with the way we worked. Need to understand where i am coming from to gure out whether what we did is useful for you... observations advice (some overlap)
AUDIENCE
Who Who Who Who
is is is is
agile doing incremental development using an off-shore team thinking about using an off-shore team
changes we made to make 1e work better with their offshore team explain what 1e does
since sumir is indian thats 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 resources worried about being able to nd developers
going to explain problems and then how we solved them
all IT domains challenging have to continually learn new things
time zone difference: 4.5 hours
Heres my team - pretty typical explain what mQA etc mean automation crucial, NWSE had 14 platforms to support
explain the breakdown mention uk QA lead and India QA lead only QA roles are off-shored
iterative process based on scrum / xp explain plan / dev / qa planning done only by QA
remember this is 2009
2-3 user stories plan for a day execute (dev / QA) for 9 days Decide at the end of planning day what will t in 2 weeks planning starts with high level from PM. Then discuss solution. Then break.
day of planning planning artefacts all uk qa deal with platform, infrstructure, think about tests (didnt communicate to dev)
devs come up with list of tasks
QA discuss tools, platforms, technologies, things we havent thought of
second day work starts developers work on single story until no more resources t then they work on second user story no pairing
devs complete tasks uk mQA writing test cases handover from dev to QA, devs start on another user story
when bugs were found developers switch back to earlier story some bugs from lack of agreement about scope of user story Devs didnt understand QA process QA tested things developers didnt consider important
stories moved between dev and QA some stories lasted for more than one iteration some stories laster even longer, 3 or 4 iterations sometimes 6 user stories were active
once a story had been completed in manual handed over to automation automation would choose most important test cases to automate automation was always at least one step behind, sometimes more. Out of sync difficult to automate due to lack of hooks and not wanting to make code changes since devs are on something else sometimes stories came in batches bugs revealed through repeated running purpose of automation is to reduce regression
still 2009
All this chaos is in the UK
Now lets talk about handover to india Often batches came India had to learn stories by executing test cases
india had to execute lower priority platforms what message is this sending?! why isnt automation helping (lagging way behind, job of automation is not to help get stories done)
handover was conducted over an hour cramming weeks of discussion and testing around a user story into an hour
India logged non-bugs unsupported setup missing functionality (just out of scope for that user story) simulating the customer doing something unusual
daily meeting in the morning UK time update from india update from UK each team in meeting room sat around computer and speakerphone desktop sharing
two teams would be working on different user stories couldnt understand each others update india would hear snippets from future work Outside of meetings UK reluctant to spend time talking to india due to iteration deadline
Relationship wasnt very good India liked email so as not to interrupt uk Poor communication medium uk preferred phone but didnt want interruptions
Tried to solve this by adding more detail to test cases (india and uk agreed this)
started to turn indian colleagues into robots deskilling effect - exact opposite of what we wanted! vicious circle uk forgot details - india frustrated uk resented obvious questions
technical gremlins
hard to hear in meetings - meeting rooms echoes didnt know who was talking impossible to follow discussion discussion explained at end to india
india power outages phone lines going down
tried video conferencing competition for resource across whole business
competition for meeting rooms in the uk and india adhoc meetings were difficult to do some people held noisy meetings in open plan office
Theyre doing this / that discontent no joint retrospectives no shared work
each team had their own pain / triumph nothing shared no collaboration
we start to think about how to get everyone working together better how can we solve underlying problems daunting problem, where to start?
start with the easy stuff started trying to build personal relationships bring QA leads over
We had a problem with regression leave it till the end of all the user story work
didnt know how long it would take until the end didnt know what bugs would be found we werent release ready manual process
India took on regression Often struggled due to lack of product knowledge Found it hard to do risk based regression Automation was catching up Regression time came down Working better with team Still not working on same things
Another team started to pair testers up - one india / uk Trying collaboration for the rst time
QAs share Acceptance tests (wed moved to ATDD), regression Regression testing part of done Planning still UK only UK QAs explain stories to India QAs after planning and while waiting for user story work
Still in iterations Planning still takes whole day Overlap isnt enough Technology use isnt good enough Sharing work though! Sharing triumphs / problems
UK QA lead went on maternity New lead clashes with India Lead
New QA lead sees bugs are mostly found by the UK India still coming up to speed, from a long way back New QA lead decides that India QAs cant do the job Im convinced its the system
Lead Architect and I go to India to see problems from their point of view India having trouble understanding incremental development We 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 UK India and really excited about this Raj and I decide to get them involved in planning - still dont know how
When we return relationship between UK / India leads deteriorated beyond repair Both leads removed from positions New India / UK QA Lead appointed
Start to repair the damage done with exercises Shared values exercise Team agrees on everything (we kept away from anything controversial)
get to know exercise draw what you do on the weekend funny answers really helped us to learn about each other
exercises done with video laughing and joking between everyone jokes extend into other interactions personal context rapport
Still not planning together but thinking about it
Still not doing joint retrospectives Retrospectives still analogue
collaboration starting to break down barriers
bring the mQA and aQA lead over to the UK goal to allow them to live the incremental agile development experience goal to mend personal relationships and to get to know team
Spend a lot of time with them Get the know them well on a personal level We complete a feature together Very successful piece of work Attitude of UK testers
India leads head home Stronger personal relationships spur us on to solve our problems
What about planning together? What about better dailys?
Tried video conferencing We try using MS Lync - explain what it is India on headsets in front of computers UK on speakerphone in meeting room India 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 daily Learn the best way to run daily
Use rst name alphabetical order to speak Learn to mute everyone in lync when not talking, keeps background down Two people close to each other talking causes volume pumping Use icons to know who is speaking Bring up everyones photos to see what people look like Try video, disrupts the audio channel, revert to audio + screen sharing
Notice new phenomena People surng web / checking emails Decide to do nothing about it, in an analogue standup cant tell when they are daydreaming Some 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 phenomenon Learn to ask questions in the right way
Recap: Daily going well Teams sharing work Still doing iterations
Size of the work has started to come down Conservative on adding stories to iteration Plan early if we nished early
Moving towards a ow based system (lean / kanban) Plan single story, execute mQA testing as we develop aQA write automated tests with developers Developers check in code, tests go green, move onto next story This is theory, still learning :)
planning one story at a time ts in common hours Use of technology has bedded down to allow planning attempt
At rst its hard going India has a lot to learn We persevere (get back on the bike!) Get better with each story planned Planning must happen in mornings
We discover record feature in lync Start recording all meetings for people on holiday etc Realise that we can plan when India have gone home - they watch recording
Curious inversion of who discovers bugs UK devs tend to handover late in day India mQAs are rst one to try user stories out The system governs performance!
The UK devs discover that Lync / headsets better for pairing Historical resistance due to pairing experience (hard to get round desks, far from screen)
Team starts to go beyond pairing to posse programming Team programming style starts to develop Spreads to developers and automation QAs pairing tyo write automated acceptance tests Collaboration through the roof! Everyone working through everything together
Final hurdle is retrospectives Start doing them online with whole team Using trello Fill in items as they happen - meeting starts quicker Start solving problems together Fosters closer team
BIG OBSERVATIONS
1. 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: STRUCTURE
1. 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: COLLABORATION
1. 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: CULTURE
1. 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 locations
OBSERVATIONS: RELATIONSHIPS
1. 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: STRUCTURE
1. 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 offshore team
ADVICE: TECHNOLOGY
1. 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: COLLABORATION
1. 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: CULTURE
1. 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: RELATIONSHIPS
1. 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://www.rstlinesoftware.com/agile/offshore_agile/ http://martinfowler.com/articles/agileOffshore.html

Ed Sykes - Cross Shore Teams AOTB2012

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ed Sykes - Cross Shore Teams AOTB2012

Uploaded by

Copyright:

Available Formats

Making cross-shore time-zone spanning teams work

@edsykes ed.sykes@gmail.com edsykes.blogspot.co.uk

Who Who Who Who

since sumir is indian thats where it was setup

1e is based in the uk, london, ealing

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

going to explain problems and then how we solved them

all IT domains challenging have to continually learn new things

time zone difference: 4.5 hours

remember this is 2009

devs come up with list of tasks

QA discuss tools, platforms, technologies, things we havent thought of

All this chaos is in the UK

india power outages phone lines going down

tried video conferencing competition for resource across whole business

Theyre doing this / that discontent no joint retrospectives no shared work

UK QA lead went on maternity New lead clashes with India Lead

Still not planning together but thinking about it

Still not doing joint retrospectives Retrospectives still analogue

collaboration starting to break down barriers

What about planning together? What about better dailys?

We try everyone on headsets in front of computers

Notice cultural phenomenon Learn to ask questions in the right way

You might also like