A talk I gave at Webit Expo, Sofia, in April 2016. I focused on how to run efficient, fully distributed teams, how they differ from local teams, the pitfalls to avoid, and which agile concepts should be re-evaluated.
Running Eﬃcient Distributed
Ricardo J. Méndez
• Software engineer, run Numergent.
• Work mostly with data-oriented projects, on media, health care
information management, and ﬁnancial companies.
• Run project-speciﬁc, distributed development teams.
• Six years of working exclusively with distributed teams.
• I’d rather take the right expertise where I ﬁnd it.
Coordination has a cost
When you have a question,
your answer may not arrive
even on the same day.
Autonomy is fundamental
Late-binding of tasks to owners
Fred George, “Implementing programmer Anarchy”
Having lots tasks assigned early
can overwhelm a developer.
Never force people to ask for
permission to work more.
Instead, let people continually
ask themselves “what's next?”
Assign early only very specialized
tasks, with speciﬁc deadlines.
Conventions are important
Fundamental for issues and tasks.
Come up with a clear
nomenclature from the start.
Mis-assigned or mis-interpreted
severities and priorities
will slow you down.
Conventions: Issue severity
• Enhancement: Self-explanatory.
• Minor: Deal with it as time allows.
• Major: You don’t want to launch without it, not having it requires a
• Critical: Fundamental to system’s concept and integrity.
• Blocker: Stopping at least one person from working. For bugs only.
Do not let P1 Blockers become a
There’s a diﬀerence between
Write everything down
Yes, writing things down
You should be doing it anyway.
Do not abide an oral history,
approach to project
If it’s worth answering, it’s worth
writing the answer down.
Issue-speciﬁc answers go on the
General questions go on the wiki.
Chances are people will ask the
same question twice.
You only pay the cost once.
Your team will talk less, and
This is not a bug, it’s a feature.
Tag feature branches with the task
Link to issue discussion on commit
git-ﬂow is your friend
(or something like it)
Developers own their feature
Never assume they are set in
Do small, independent commits
Push your feature branches,
even if you’re not done.
Make intermediate commits,
even if you’ll amend later.
When all you have is Scrum,
like a stand-up
Daily meetings, however short,
will be an issue.
You will need to touch base daily.
Do it asynchronously.
Keep a good idea of people’s
Agree on team member availability
It’s not about synchrony.
It’s about timing.
Mind the human factor
You won’t have the usual visual
Be extra aware of cultural ﬁt, or
There are exceptions
You may need to have a few
Plan ahead and budget.
Ricardo J. Méndez