Running Efficient Distributed Teams

Running Eﬃcient Distributed Teams Ricardo J. Méndez [email protected]

@ArgesRic About me • Software engineer, run Numergent. • Work
mostly with data-oriented projects, on media, health care information management, and financial companies. • Run project-specific, distributed development teams. • Six years of working exclusively with distributed teams. • I’d rather take the right expertise where I find it.

@ArgesRic Coordination has a cost

@ArgesRic When you have a question, your answer may not
arrive even on the same day.

@ArgesRic Autonomy is fundamental

@ArgesRic Late-binding of tasks to owners Fred George, “Implementing programmer
Anarchy”  https://www.youtube.com/watch?v=tIxHmsWCd7g

@ArgesRic Having lots tasks assigned early can overwhelm a developer.

@ArgesRic Never force people to ask for permission to work
more.

@ArgesRic Instead, let people continually ask themselves “what's next?”

@ArgesRic Assign early only very specialized tasks, with speciﬁc deadlines.

@ArgesRic Conventions are important

@ArgesRic Fundamental for issues and tasks. Come up with a
clear nomenclature from the start.

@ArgesRic Mis-assigned or mis-interpreted severities and priorities will slow you
down.

@ArgesRic 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 scope negotiation. • Critical: Fundamental to system’s concept and integrity. • Blocker: Stopping at least one person from working. For bugs only.

@ArgesRic Do not let P1 Blockers become a prioritization hack.

@ArgesRic There’s a diﬀerence between urgent and important

@ArgesRic Write everything down

@ArgesRic Yes, writing things down   takes time.

@ArgesRic Guess what? You should be doing it anyway.

@ArgesRic Do not abide an oral history, Chinese whispers approach
to project management.

@ArgesRic If it’s worth answering, it’s worth writing the answer
down.

@ArgesRic Issue-speciﬁc answers go on the issue. General questions go
on the wiki.

@ArgesRic Chances are people will ask the same question twice.
You only pay the cost once.

@ArgesRic Your team will talk less, and write more. This
is not a bug, it’s a feature.

@ArgesRic Cross-reference and increase visibility

@ArgesRic Tag feature branches with the task code. Link to
issue discussion on commit logs.

@ArgesRic git-ﬂow is your friend (or something like it) http://nvie.com/posts/a-successful-git-branching-model/

@ArgesRic Developers own their feature branches. Never assume they are
set in stone.

@ArgesRic Do small, independent commits

@ArgesRic Push your feature branches, even if you’re not done.

@ArgesRic Make intermediate commits, even if you’ll amend later.

@ArgesRic When all you have is Scrum, everything looks like
a stand-up

@ArgesRic Daily meetings, however short, will be an issue.

@ArgesRic Assumptions change. You will need to touch base daily.
Do it asynchronously.

@ArgesRic Keep a good idea of people’s availability.

@ArgesRic Agree on team member availability beforehand. It’s not about
synchrony. It’s about timing.

@ArgesRic Mind the human factor

@ArgesRic You won’t have the usual visual cues.

@ArgesRic Be extra aware of cultural ﬁt, or personal diﬀerences.

@ArgesRic There are exceptions

@ArgesRic You may need to have a few people meet.
Plan ahead and budget.

@ArgesRic Questions?

@ArgesRic Thank you! Ricardo J. Méndez [email protected] https://numergent.com/talks/

Running Efficient Distributed Teams

Running Efficient Distributed Teams

More Decks by Ricardo J. Méndez

Other Decks in Programming

Featured

Transcript