running efficient distributed teams
TRANSCRIPT
@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?
