Tweet
Tweet

Slide 1

Slide 1 text

Running Efficient Distributed Teams Ricardo J. Méndez [email protected]

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

@ArgesRic Coordination has a cost

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

@ArgesRic Autonomy is fundamental

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

@ArgesRic Assign early only very specialized tasks, with specific deadlines.

Slide 14

Slide 14 text

@ArgesRic Conventions are important

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

@ArgesRic There’s a difference between urgent and important

Slide 20

Slide 20 text

@ArgesRic Write everything down

Slide 21

Slide 21 text

@ArgesRic Yes, writing things down 
 takes time.

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

@ArgesRic Issue-specific answers go on the issue. General questions go on the wiki.

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

@ArgesRic Cross-reference and increase visibility

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

@ArgesRic Do small, independent commits

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

@ArgesRic Mind the human factor

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

@ArgesRic Be extra aware of cultural fit, or personal differences.

Slide 43

Slide 43 text

@ArgesRic There are exceptions

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

@ArgesRic Questions?

Slide 46

Slide 46 text

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