Running Efficient Distributed Teams

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.

Video: https://youtu.be/_uw0xukXiPg

Transcript

1. Running Efficient Distributed
   Teams
   Ricardo J. Méndez
   ricardo@numergent.com
   

   View Slide

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

   View Slide

3. View Slide

4. @ArgesRic
   Coordination has a cost
   

   View Slide

5. View Slide

6. View Slide

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

   View Slide

8. @ArgesRic
   Autonomy is fundamental
   

   View Slide

9. @ArgesRic
   Late-binding of tasks to owners
   Fred George, “Implementing programmer Anarchy”

   https://www.youtube.com/watch?v=tIxHmsWCd7g
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. @ArgesRic
    Conventions are important
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

19. @ArgesRic
    There’s a difference between
    urgent
    and
    important
    

    View Slide

20. @ArgesRic
    Write everything down
    

    View Slide

21. @ArgesRic
    Yes, writing things down 

    takes time.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

28. @ArgesRic
    Cross-reference and
    increase visibility
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

32. @ArgesRic
    Do small, independent commits
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

40. @ArgesRic
    Mind the human factor
    

    View Slide

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

    View Slide

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

    View Slide

43. @ArgesRic
    There are exceptions
    

    View Slide

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

    View Slide

45. @ArgesRic
    Questions?
    

    View Slide

46. @ArgesRic
    Thank you!
    Ricardo J. Méndez
    ricardo@numergent.com
    https://numergent.com/talks/
    

    View Slide