Bringing Effectiveness and Sanity to Highly Distributed Agile Teams
3 likes1,388 views
Wojciech Seliga discusses the challenges and benefits of managing highly distributed agile teams, drawing on 27 years of programming experience. He emphasizes that while distributed agile can provide advantages like round-the-clock productivity and access to a larger talent pool, it also amplifies existing issues and requires strong communication and trust-building among team members. Seliga advises against going distributed without valid reasons, suggesting organizations should empower teams and avoid common pitfalls such as micromanagement and miscommunication.
Bringing Effectiveness and Sanity to Highly Distributed Agile Teams
- 1. Wojciech Seliga Bringing Effectiveness … and Sanity to Highly Distributed Agile Teams
- 2. 27 years of programming (started in pre-school)
- 3. 8 years with „big international corporations”
- 4. 8 years with agile
- 5. 4 years with Spartez
- 6. 4 years with Atlassian
- 7. 12 years in geographically distributed teams and/or with remote customers About me
- 8. Do NOT do it, unless ... Distributed agile is difficult Distribution is a huge burden
- 9. Valid reasons to go distributed No local talent available
- 12. Round the clock team
- 13. Great people move Photo by Linus Bohman
- 14. Questionable reasons to go distributed Cheaper workforce (hidden overhead)
- 15. No office space
- 16. Desire to be „global”
- 17. Building remote empires Photo by dan4th
- 18. Strive at executing projects using co-located teams. Divide Globally & Conquer Locally
- 19. Do's
- 20. Empower all sides Photo by epSos.de
- 21. There are people who make things happen, there are people who watch things happen, and there are people who wonder what happened James Lovell
- 22. Skilled & flexible people Agile really reveals problems, remoteness amplifies it
- 23. Linchpins
- 26. Domain knowledge
- 27. Communication
- 28. Responsibility Photo by Helmut
- 29. Build trust Deliver good stuff on time
- 31. Meet deadlines
- 32. Be honest
- 33. Be transparent
- 35. Avoid bad surprises Photo by rogiro
- 36. Face to Face Photo by AndYaDontStop
- 37. Get to know your remote peers Cultural differences
- 38. Put names to the faces
- 39. Responsibilities
- 41. Virtual Meetings Iteration planning
- 42. Release planning
- 43. Iteration summary & demo
- 44. Stand-up - once or twice a week
- 45. Daily progress available online
- 46. Keep it short Photo by Ha-Wee
- 50. Paratroopers
- 52. Bottleneck problem Photo by noticelj
- 53. Good communication tools Video conferencing
- 54. Skype
- 55. Screen-sharing
- 56. IM (chat rooms)
- 57. Issue tracker
- 58. Wiki
- 59. CI (!)
- 60. And more...
- 61. Code review Disseminate knowledge
- 62. Build trust
- 65. Post commit vs. pre-commit
- 66. DVCS and pull requests
- 67. Rotating the pain Photo by appaji
- 68. Good fences make good neighbours Projects
- 69. Subsystems
- 70. Plugins
- 72. Interfaces
- 74. Platforms Photo by Hryck
- 75. Dont's Or how to destroy your geo-distributed endeavour
- 76. Micro-management Photo by Peter Ito
- 77. Bottleneck Proxies Icons courtesy of iconka.com
- 78. Initial Proxies - Dispatchers Icons courtesy of iconka.com
- 79. They vs. us Syndrome
- 80. Managers here, subordinates there Photo by Lord Mariser
- 81. Architects here, developers there Photo by kioan
- 82. Cheaper workforce abroad Photo by wildphotons
- 83. Ignoring the fact of remoteness Photo by donata ramonaite
- 84. Meeting overdose Photo by Steve Smith
- 85. Advantages of distributed teams Someone round the clock
- 86. Less conflicts during commits and fixing tests
- 87. Taking over work started in the morning
- 88. Code reviewed by next morning
- 89. Time to cool-down before responding
- 90. Shorter and intensive communication
- 91. Fun (new places, new cultures)
- 92. Better computing resources utilisation - CI env is yours
- 93. Takeaways Avoid distributed if you can
- 94. Agile amplifies problems
- 95. Assign your best people
- 96. Let people build trust
- 98. Understand risks
- 99. Take advantage Photo by Edinburgh Blog
Editor's Notes
- #5: Better great people abroad, than average locally
- #7: Better great people abroad, than average locally
- #11: Cross-functional teams
- #15: Video over just voice – sleeping warning. 2 – 4 people work best. Avoid more than 7, unless it an announcement
- #16: Giora Morein Ambassadors and Carrier Pigeons One visitor vs many at a time Cities matter Frequency of meetings Company apartments Atlassian secondmends
- #26: No sense of responsibility. Us-them approach
- #27: Also domain knowledge here, devs there Turning developers into „coders” or „programmers” Destroys trust, hampers productivity
- #28: Communication, travel, management, etc. - overhead Poor workers – poor results Smart workers – they will know how much you earn and get frustrated pretty soon Great people are not cheap regardless of the country, cheap workforce fallacy Esher Derby – train people and they will go, but don't train and they will stay...
- #29: Remote teams are different Planning is different, dynamics is different It's easy to get disconnected Allocate extra budget for travels
- #30: Too many F2F meetings – lower efficiency, being a host to often is tiresome, costly Too many virtual meetings – frustration Our rule – max. 1 – 2 virtual meetings a week (with as few participants as possible) Max. 1 - 3 F2F meetings a year More participants => video conf
- #31: (support, questions from other teams)
- #33: (support, questions from other teams)