Agile Offsharing: Using Pair Work to OvercomeNearshoring Difficulties

Prof. Dr. Lutz PrecheltInstitut für Informatik Mobile Solutions Day

Freie Universität Berlin 2014-06-24

Outline

• Pair Programming: What and why?

• Agile Offsharing: Why, what, how?

• "But we are not using offshoring!"

2Lutz Prechelt, Freie Universität Berlin

Pair Programming

• Claimed advantages:• Faster than solo• Fewer defects• Better software design• More concentrated work• 2 people familiar with code• Can employ joint knowledge• Faster learning• Enjoyable

• Disadvantages/Issues:• May require more resources• Some programmers do not

like it

• Use it for:• Shorter time-to-market

• Higher quality

• Reducing code knowledge bottlenecks

• Knowledge transfer

3Lutz Prechelt, Freie Universität Berlin

Domain, Users &

Requirements

Team ATeam B

can underst

and

will write will write

Agile Offsharing:Assumed situation/problem

Joint system

Geographic & cultural distribution

4Lutz Prechelt, Freie Universität Berlin

Is distribution common?

5Lutz Prechelt, Freie Universität Berlin

Domain, Users &

Requirements

Home Team ARemote Team B

Subsystem BSubsystem A

Subsystem B Spec

understands

writes misunderstands

writeswrite

s

Waterfall model thinking

?

Belief: "Modularization helps!"

6Lutz Prechelt, Freie Universität Berlin

1

3a 3b

2a2b

Why misunderstandings happen

Lutz Prechelt, Freie Universität Berlin

1. Up-front requirements specification is difficult.2. We tend to under-estimate what needs explanation:

Domain, Users &

Requirements

Team ATeam B

Subsystem BSubsystem A

can understand

writeswrite

s

some talking (email, chat, skype, phone)

Daily video standup

The Agile process illusion

Belief: "Modularization plus talking helps"

8Lutz Prechelt, Freie Universität Berlin

Domain, Users &

Requirements

Team A Team A'

can understand

Distributed pair programming (DPP)

Daily video standup etc.

Radical idea: Agile Offsharing

Belief: "Only close collaboration works"

Joint system

9Lutz Prechelt, Freie Universität Berlin

Agile Offsharing:The radical step

Again: The new idea of Agile Offsharing is the following

• If cross-site communication is difficult

• do not avoid it• i.e. don't go for technical work locality

• rather, maximize it• i.e. voluntarily introduce

cross-site technical work• in order to transfer knowledge

10Lutz Prechelt, Freie Universität Berlin

standup

it always is!

Questions so far?

11Lutz Prechelt, Freie Universität Berlin

Preconditions for usingAgile Offsharing

Technical/organizational:• Small time zone difference• Technical communication

infrastructure• Strong network connection• Joint repositories• Distributed-IDE tools• Audio, perhaps video

equipment• Pair-work-ready workplace

Social:• Collaboration readiness:

• One-team thinking• Non-competitive attitude• Transparency & trust• Team stability

• Willingness for pair work• Compatible development

processes• Collaboration skills:

• Strong skills in a joint natural language

• Recognizing gaps in requirements understanding

• Requirements explanation skills

12Lutz Prechelt, Freie Universität Berlin

Not id

eal!

Establishing Agile Offsharing (1/4):People

• Find pairing volunteers• at least two on each side• strong language and

communication skills• preferably strong technical

skills

• Do not push anybody

Photograph: Corbis RF / Alamy/Alamy

13Lutz Prechelt, Freie Universität Berlin

Establishing Agile Offsharing (2/4):Technical infrastructure

• Establish distributed editing:• Eclipse: Saros• Visual Studio: VS anywhere• IntelliJ IDEA: soon: Saros• Mac OS X: SubEthaEdit • Browser: Cloud9, Codenvy

• Start with local trials at both sites

• then set up an official server, firewall rules, etc.

• Invest in comfortable, high-quality headsets

• Find handy, reliable audio software, e.g.:• SIP VoIP, Skype, Lync• Phone conferencing systems• Jitsi, mumble

14AG Software Engineering, Institut für Informatik, Freie Universität Berlin

Saros

Cloud9

A schematic view of Saros

Establishing Agile Offsharing (3/4):Tasks & Getting Going

• Create list K:Reqirements knowledge to be transfered• identify an expert• estimate explanation time

• should be 0.2 to 2 hours each

• note closest-match volunteer

• Somewhat like story cards

• Create list T:Development task• list eligible developers• list required knowledge

pieces• estimate required time

• should be 1 to 5 hours each

• Find K-T matches• that have suitable volunteer

pairs• Arrange and execute

sessions• Consciously perform them

for knowledge transport

16AG Software Engineering, Institut für Informatik, Freie Universität Berlin

Establishing Agile Offsharing (4/4):Refine

• Learn how to arrange sessions with little effort

• Learn how to cope with conflict• e.g. detect and repair power

imbalances

• Learn how to cope with language skill limitations

• Learn how to optimize knowledge transport• Reflection session after

DPP session• Better task selection• Draw in more volunteers

17AG Software Engineering, Institut für Informatik, Freie Universität Berlin

"But we are not using offshoring!"

• Are your relevant colleagues always available locally?

• The pairing idea also applies if the knowledge is not about requirements:• remote technology expert• remote usability expert• remote expert for existing

code• remote partner for

• design discussion• debugging

• etc.

Furthermore:1. Saros sessions can have up

to 5 participants

2. Side-by-side programming:• "Hanging around" in the

same Saros session • short bursts of pairing as

needed

We call the resulting behaviors"Distributed Party Programming"

(DPP)

18Lutz Prechelt, Freie Universität Berlin

Some questions of mine

• Who has done distributed pair programming:• via screen sharing?• via Saros (or similar)?

• Who wants to try out Distributed Party Programming?

• Who wants to try out Agile Offsharing?

• We are available for consulting or research cooperation

19Lutz Prechelt, Freie Universität Berlin

20Lutz Prechelt, Freie Universität Berlin

Questions of yours?

Agile Offsharing:Current research status

• Pair Programming:• There are roles related to

knowledge transfer• e.g. task expert/mentee

• There are learnable knowledge transfer behavior patterns

• e.g. Clarification Cascade

• Distributed Pair Programming (DPP):• Competent pairs can work

fully fluently• Awareness limitations

bridged e.g. by verbalization• Limited use of concurrent

editing does not break PP• Looks as good as local PP

• Agile Offsharing idea:• Various experts all found

Agile Offsharing plausible• We have just won the

Ready-Set-Transfer technology transfer contest

• Int'l. Conf. on Software Engineering

• We work with Lithuanian offshore company NFQ to evaluate Agile Offsharing

21AG Software Engineering, Institut für Informatik, Freie Universität Berlin

Thank you!

22Lutz Prechelt, Freie Universität Berlin

Agile Offsharing:Make a radically new assumption

Context: • Distributed software development, but with agile methods• Only the "home" team builds the requirements knowledge

• Traditional assumption:Transfer reqs knowledge explicitly, butmaximize locality for technical work

• Agile Offsharing assumption:Must transfer reqs during technical workor else bandwith is too low• therefore, introduce cross-site technical work

23Lutz Prechelt, Freie Universität Berlin

standup