running efficient distributed teams

Running Efficient Distributed TeamsRicardo J. Méndez

ricardo@numergent.com

@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 specific

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 difference 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-specific 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-flow 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 fit, or personal differences.

@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

ricardo@numergent.com