Andrew Begel
Human Interactions in Programming
Microsoft Research
CHASE Workshop 2008, Leipzig, Germany
How does coordination occur between
software teams?
What are the pain points?
How does distributed development affect
coordination?
Once coordination problems are identified,
what next?
How can you fix them?
How do you adapt solutions to fit the context?
Qualitative, interview-based study of a web
services team at Microsoft
32 interviews, 26 people
Redmond, WA, USA (20),
Boston, MA, USA (3),
Hyderabad, India (3)
Conducted study with Christopher Poile,
Nachi Naggapan and Lucas Layman
Communication
“We
miss
outanswer
on a other
lot
of priorities
those
would
appreciate
aemail…
week-before
“I
know
they
have
in
“He
doesn’t
If Iwater
have
cooler
conversations…
what
we
end
update
to now
if say…
they’ll
the
their
job…
They
I make
will
give
questions,
I’ll have
to ping
him
ayou
up
doing
sending
an
email,
and
date…
or
where
they
are.”
time
tomorrow…
So
I’m
like,
why
couple
ofis
times
to
get
an
answer.”
the
turnaround
is so15
long
for that.
don’t
you take your
minutes
right
Distribution
Capacity
now and save me an entire day?”
Cooperation
Unhelpful Behaviors
Miscommunication
Mistrust
Misunderstanding
Dysfunction
Unmet expectations
Differing priorities
Unclear ownership
Non-transparent decisionmaking
Missing information
Helpful Behaviors
Prioritizes communication
Avoids escalation
Listens
Aware of problems
Reliable, on-time delivery
Synchronizes schedules
Gives clear instructions
Gives feedback
Smart, respectful
Offers status updates
Informal meetings happen in hallways
Try not to make decisions in informal
meetings.
Send status updates electronically.
Invite non-local team members to discuss
decisions.
Distributed teams feel remote, due to
location, time, and lack of face-to-face
contact.
Get rid of distributed teams.
Arrange face-to-face visits between team
locations.
Hold meetings at times when workday
overlaps.
The lack of information makes people
anxious.
Hold frequent status meetings with
dependencies and post status electronically.
Align priorities and schedules with
dependents.
It is easy to see the problems.
The studied team appreciates your data to
'confirm' their own belief in the problems.
But, it is deceptively easy to come up with
solutions.
Practical, usable changes require buy-in
and adaptation from team management.
We need more evidence of solution
effectiveness in practice.
How do you monitor changes to software
development process? Especially in
distributed teams, far from researchers?
Not easy to adapt solution designs to field
situations. Longitudinal evaluation of
usefulness can take time and effort.
What lessons can be learned from success
of Mylyn, Jazz, CoCoMo, Wikis, Agile,
CMM?