Wojciech Seliga Bringing Effectiveness  …  and Sanity  to Highly Distributed Agile Teams
<ul><li>27 years of programming (started in pre-school)
8 years with „big international corporations”
8 years with agile
4 years with Spartez
4 years with Atlassian
12 years in geographically distributed teams and/or with remote customers </li></ul>About me
Do NOT do it, unless ... Distributed agile is difficult Distribution is a huge burden
Valid reasons to go distributed <ul><li>No local talent available
Specific skills elsewhere
Customers elsewhere
Round the clock team
Great people move </li></ul>Photo by  Linus Bohman
Questionable reasons to go distributed <ul><li>Cheaper workforce (hidden overhead)
No office space
Desire to be „global”
Building remote empires </li></ul>Photo by  dan4th
Strive at executing projects using co-located teams. Divide Globally & Conquer Locally
Do's
Empower  all  sides Photo by  epSos.de
There are people who make things happen, there are people who watch things happen, and there are people who wonder what ha...
Skilled & flexible people <ul><li>Agile really  reveals  problems, remoteness amplifies it
Linchpins
Self-organisation
Passion (wild hours)
Domain knowledge
Communication
Responsibility </li></ul>Photo by  Helmut
Build trust <ul><li>Deliver good stuff on time
Do not overcommit
Meet deadlines
Be honest
Upcoming SlideShare
Loading in...5
×

Bringing Effectiveness and Sanity to Highly Distributed Agile Teams

1,242

Published on

Virtual teams get a bad press - especially in agile world. Anyone who has ever worked in geo-distributed teams know how difficult and ineffective such teams usually are. However due to various good reasons most of the global companies still distribute their teams across geographies. And some of them do it with very good results...

Wojciech has been working in geographically distributed teams and/or for remote customers in Germany, Switzerland, Singapore, Israel, United States, Australia and Canada for 12 years. Some of these teams were far from perfect, whereas the others were very effective and really successful. Despite changing tools or technologies and evolving agile practices, the most important factor in an agile geo-distributed team has remained the same for years - the human.

This presentation covers these values, principles and practices which have proven to be the most important in creating highly productive agile software development culture in geographically distributed environment - including such extreme situations were team members live on the opposite side of the globe (like Australia, Europe and the North America). It also describes how proper tooling not only enables effective remote collaboration, but also provides several advantages over collocated teams.

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,242
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Better great people abroad, than average locally
  • Better great people abroad, than average locally
  • Cross-functional teams
  • Video over just voice – sleeping warning. 2 – 4 people work best. Avoid more than 7, unless it an announcement
  • Giora Morein Ambassadors and Carrier Pigeons One visitor vs many at a time Cities matter Frequency of meetings Company apartments Atlassian secondmends
  • No sense of responsibility. Us-them approach
  • Also domain knowledge here, devs there Turning developers into „coders” or „programmers” Destroys trust, hampers productivity
  • 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&apos;t train and they will stay...
  • Remote teams are different Planning is different, dynamics is different It&apos;s easy to get disconnected Allocate extra budget for travels
  • 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 =&gt; video conf
  • (support, questions from other teams)
  • (support, questions from other teams)
  • Transcript of "Bringing Effectiveness and Sanity to Highly Distributed Agile Teams"

    1. 1. Wojciech Seliga Bringing Effectiveness … and Sanity to Highly Distributed Agile Teams
    2. 2. <ul><li>27 years of programming (started in pre-school)
    3. 3. 8 years with „big international corporations”
    4. 4. 8 years with agile
    5. 5. 4 years with Spartez
    6. 6. 4 years with Atlassian
    7. 7. 12 years in geographically distributed teams and/or with remote customers </li></ul>About me
    8. 8. Do NOT do it, unless ... Distributed agile is difficult Distribution is a huge burden
    9. 9. Valid reasons to go distributed <ul><li>No local talent available
    10. 10. Specific skills elsewhere
    11. 11. Customers elsewhere
    12. 12. Round the clock team
    13. 13. Great people move </li></ul>Photo by Linus Bohman
    14. 14. Questionable reasons to go distributed <ul><li>Cheaper workforce (hidden overhead)
    15. 15. No office space
    16. 16. Desire to be „global”
    17. 17. Building remote empires </li></ul>Photo by dan4th
    18. 18. Strive at executing projects using co-located teams. Divide Globally & Conquer Locally
    19. 19. Do's
    20. 20. Empower all sides Photo by epSos.de
    21. 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. 22. Skilled & flexible people <ul><li>Agile really reveals problems, remoteness amplifies it
    23. 23. Linchpins
    24. 24. Self-organisation
    25. 25. Passion (wild hours)
    26. 26. Domain knowledge
    27. 27. Communication
    28. 28. Responsibility </li></ul>Photo by Helmut
    29. 29. Build trust <ul><li>Deliver good stuff on time
    30. 30. Do not overcommit
    31. 31. Meet deadlines
    32. 32. Be honest
    33. 33. Be transparent
    34. 34. Respect each other
    35. 35. Avoid bad surprises </li></ul>Photo by rogiro
    36. 36. Face to Face Photo by AndYaDontStop
    37. 37. Get to know your remote peers <ul><li>Cultural differences
    38. 38. Put names to the faces
    39. 39. Responsibilities
    40. 40. Strengths and weaknesses </li></ul>
    41. 41. Virtual Meetings <ul><li>Iteration planning
    42. 42. Release planning
    43. 43. Iteration summary & demo
    44. 44. Stand-up - once or twice a week
    45. 45. Daily progress available online
    46. 46. Keep it short </li></ul>Photo by Ha-Wee
    47. 47. Human bridges <ul><li>Ambassadors
    48. 48. Touring rock stars
    49. 49. Visiting professors
    50. 50. Paratroopers
    51. 51. Foreign exchange worker
    52. 52. Bottleneck problem </li></ul>Photo by noticelj
    53. 53. Good communication tools <ul><li>Video conferencing
    54. 54. Skype
    55. 55. Screen-sharing
    56. 56. IM (chat rooms)
    57. 57. Issue tracker
    58. 58. Wiki
    59. 59. CI (!)
    60. 60. And more... </li></ul>
    61. 61. Code review <ul><li>Disseminate knowledge
    62. 62. Build trust
    63. 63. Alleviate anxiety
    64. 64. Guest programming
    65. 65. Post commit vs. pre-commit
    66. 66. DVCS and pull requests </li></ul>
    67. 67. Rotating the pain Photo by appaji
    68. 68. Good fences make good neighbours <ul><li>Projects
    69. 69. Subsystems
    70. 70. Plugins
    71. 71. Vertical components
    72. 72. Interfaces
    73. 73. Clients / Servers
    74. 74. Platforms </li></ul>Photo by Hryck
    75. 75. Dont's Or how to destroy your geo-distributed endeavour
    76. 76. Micro-management Photo by Peter Ito
    77. 77. Bottleneck Proxies Icons courtesy of iconka.com
    78. 78. Initial Proxies - Dispatchers Icons courtesy of iconka.com
    79. 79. They vs. us Syndrome
    80. 80. Managers here, subordinates there Photo by Lord Mariser
    81. 81. Architects here, developers there Photo by kioan
    82. 82. Cheaper workforce abroad Photo by wildphotons
    83. 83. Ignoring the fact of remoteness Photo by donata ramonaite
    84. 84. Meeting overdose Photo by Steve Smith
    85. 85. Advantages of distributed teams <ul><li>Someone round the clock
    86. 86. Less conflicts during commits and fixing tests
    87. 87. Taking over work started in the morning
    88. 88. Code reviewed by next morning
    89. 89. Time to cool-down before responding
    90. 90. Shorter and intensive communication
    91. 91. Fun (new places, new cultures)
    92. 92. Better computing resources utilisation - CI env is yours </li></ul>
    93. 93. Takeaways <ul><li>Avoid distributed if you can
    94. 94. Agile amplifies problems
    95. 95. Assign your best people
    96. 96. Let people build trust
    97. 97. Empower all locations
    98. 98. Understand risks
    99. 99. Take advantage </li></ul>Photo by Edinburgh Blog
    100. 100. Questions? e-mail: wojciech.seliga@spartez.com

    ×