Recommended
Recommended
More Related Content
Similar to Running efficient distributed teams
Similar to Running efficient distributed teams (20)
Recently uploaded
Recently uploaded (20)
Running efficient distributed teams
- 1. Running Efficient Distributed Teams Ricardo J. Méndez ricardo@numergent.com
- 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.
- 4. @ArgesRic Coordination has a cost
- 7. @ArgesRic When you have a question, your answer may not arrive even on the same day.
- 9. @ArgesRic Late-binding of tasks to owners Fred George, “Implementing programmer Anarchy” https://www.youtube.com/watch?v=tIxHmsWCd7g
- 10. @ArgesRic Having lots tasks assigned early can overwhelm a developer.
- 11. @ArgesRic Never force people to ask for permission to work more.
- 12. @ArgesRic Instead, let people continually ask themselves “what's next?”
- 13. @ArgesRic Assign early only very specialized tasks, with specific deadlines.
- 15. @ArgesRic Fundamental for issues and tasks. Come up with a clear nomenclature from the start.
- 16. @ArgesRic Mis-assigned or mis-interpreted severities and priorities will slow you down.
- 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.
- 18. @ArgesRic Do not let P1 Blockers become a prioritization hack.
- 19. @ArgesRic There’s a difference between urgent and important
- 21. @ArgesRic Yes, writing things down takes time.
- 22. @ArgesRic Guess what? You should be doing it anyway.
- 23. @ArgesRic Do not abide an oral history, Chinese whispers approach to project management.
- 24. @ArgesRic If it’s worth answering, it’s worth writing the answer down.
- 25. @ArgesRic Issue-specific answers go on the issue. General questions go on the wiki.
- 26. @ArgesRic Chances are people will ask the same question twice. You only pay the cost once.
- 27. @ArgesRic Your team will talk less, and write more. This is not a bug, it’s a feature.
- 29. @ArgesRic Tag feature branches with the task code. Link to issue discussion on commit logs.
- 30. @ArgesRic git-flow is your friend (or something like it) http://nvie.com/posts/a-successful-git-branching-model/
- 31. @ArgesRic Developers own their feature branches. Never assume they are set in stone.
- 32. @ArgesRic Do small, independent commits
- 33. @ArgesRic Push your feature branches, even if you’re not done.
- 34. @ArgesRic Make intermediate commits, even if you’ll amend later.
- 35. @ArgesRic When all you have is Scrum, everything looks like a stand-up
- 36. @ArgesRic Daily meetings, however short, will be an issue.
- 37. @ArgesRic Assumptions change. You will need to touch base daily. Do it asynchronously.
- 38. @ArgesRic Keep a good idea of people’s availability.
- 39. @ArgesRic Agree on team member availability beforehand. It’s not about synchrony. It’s about timing.
- 40. @ArgesRic Mind the human factor
- 41. @ArgesRic You won’t have the usual visual cues.
- 42. @ArgesRic Be extra aware of cultural fit, or personal differences.
- 44. @ArgesRic You may need to have a few people meet. Plan ahead and budget.
- 46. @ArgesRic Thank you! Ricardo J. Méndez ricardo@numergent.com
Editor's Notes
- Worked with partially distributed teams before. This includes Fortune 100 companies that I can't even name on camera. The more specialized the project, the harder it is to find the right expertise.
- QA and client management in New York. Some creative people in Amsterdam Development in Hamburg, Germany. Development in Cluj-Napoca, Romania. A modeling and animation team in... I'm not actually sure where I was coordinating the technical aspects from Bucharest, Romania Specs for: Team building a mock up store and installation in a warehouse that, IIRC, was in New Jersey, and A team building the actual physical store in Minnesota. Like, people drilling holes into a ceiling and putting nice marks on the floor at certain distances. These instructions cannot be wrong, and after this team has started working, you don’t get to change your mind.
- This is true of local teams as well
- … but since distributed teams may be spread across timezones,
- … and work under different people … who have different priorities, the coordination cost will go up
- So reducing the types of questions people need to ask is paramount.
- This coordination cost has a good side, which is that it discourages you from micro-managing. Most of what we will discuss is focused on enhancing this autonomy.
- Shamelessly stolen term. Early binding might look good when everything is going according to schedule, but chances are, things won’t.
- If you start falling behind, and you see a piling mountain of task, you get stressed, which clouds your judgement.
- On the other hand, early binding forces a developer who’s ahead to ask if they should take a task that has an owner.
- In case this sounds familiar, it’s very similar to what Kanban suggests
- Those? Sure, assign them as early as possible. But in general, I suggest leaving any non-critical non-specialized task un-assigned, and just have people grab them as needed.
- Because coordination has a cost, the fewer questions you have to ask, the better.
- Particularly important when someone’s filing tasks or issues. Come up with a clear nomenclature from the start, since you're not going to be able to wander into Joe Bob's office and ask him to elaborate.
- Issue severity the convention was “if this was launched this week, and we never worked on it ever again, how big a problem would it be?"
- Issue severity the convention was “if this was launched this week, and we never worked on it ever again, how big a problem would it be?" One rule I established is that the only person who gets to assign a task as a blocker, is the one being blocked.
- Users will tend to want whatever they want you to work on next to be a P1 Blocker, but you need to explain to them that there's a difference between urgent and important.
- And blockers are the very rare case that’s both. Emphasis on very rare.
- It doesn’t matter if the team is distributed or not. It doesn’t matter if you can just walk into Joe Bob’s office and ask him a question. If you do that, now only you and Joe Bob know.
- I don’t care how specific a question is.
- Even if you discussed it over Slack, or Skype, or IRC or Matter. Just paste the relevant chat log lines where they belong. You have a Wiki, right?
- Next time someone asks the same question, you can just send them the link.
- Developers own their feature branches, so they’re allowed to amend them unless otherwise agreed.
- It’s easier for other to cherry-pick things they need, even if you’re not done with your feature branch.
- This _also_ lets other see if you’re working on an issue related to their task, maybe cherry-pick.
- When for whatever reason you can’t make small commits… This helps other see what you’re doing, and potentially comment on your rationale.
- Maybe useful when everyone starts at the same hour, but not when people keep their own schedule. Much less across timezones. When working across multiple timezones, any way you try to set them up, you’re going to break someone’s flow.
- You *will* need everyone to touch base when they start working every day, just to make sure whatever assumption they held when they went to bed the previous day still holds. Whether you do that by Slack, or Jira's status reports, or a ping on Skype, is up to you. If you have external clients, you may need to designate someone to coordinate.
- Just because you're at your desk, you can't expect others will as well. I never really used a tool for this - nobody checked in or out. I err on the side of keeping the process light. But I can tell you that the projects in which I've had the most coordination grief, is when I had a team member whose availability was irregular. Remember: coordination is expensive.
- To solve, have previously agreed-upon availability. If anyone needs to deviate from what they said, they should let the team know. This is not about synchronous communication, is about being able to know when you're likely to get an answer.
- A few million years have optimized us for visual cues on behavior. If anyone steps on someone else’s toes, and this person is the “quiet brooding type”, the fact that not everyone is in a room will make it more difficult to tell. If you’re running a distributed team, you’ll need to give this extra care.
- A topic in and of itself, find me if you want to discuss further.