10h time-difference-creating-effective-highly-distributed-teams
0 likes533 views
This document discusses strategies for creating effective distributed agile teams across multiple time zones and continents. It notes that while distributed agile can be difficult, there are valid reasons to set up distributed teams such as accessing talent in other locations, serving global customers, or maintaining round-the-clock coverage. The document provides recommendations for building trust, using communication tools, conducting code reviews and meetings, and establishing processes to help distributed teams function effectively despite physical separation.
10h time-difference-creating-effective-highly-distributed-teams
- 1. 19h time difference 3 continents C reating effective highly distributed agile teams Wojciech S eliga
- 2. About me ● 26 years of programming ● 8 years with „big international corporations” ● 7 years with agile ● 3 years with Atlassian ● 11 years in geographically distributed teams and/or with remote customers 2
- 3. Distributed agile is difficult Do NOT do it, unless ...
- 4. Valid reasons to go distributed ● No local talent available ● S pecific skills elsewhere ● C ustomers elsewhere ● R ound the clock team ● Great people move Photo by Linus Bohman 4
- 5. Invalid reasons to go distributed ● C heaper workforce (hidden overhead) ● No office space ● Desire to be „global” Photo by dan4th 5
- 6. Do's 6
- 7. Skilled & flexible people ● Agile really reveals problems, remoteness amplifies it ● Linchpins ● S elf-organisation ● P assion (wild hours) ● Domain knowledge ● C ommunication Photo by Helmut ● R esponsibility 7
- 8. Build trust ● Deliver good stuff on time ● Do not overcommit ● Meet deadlines ● Be honest ● Be transparent ● R espect each other ● Avoid bad surprises Photo by rogiro 8
- 9. Face to Face Photo by AndYaDontStop 9
- 10. Get to know your remote peers ● C ultural differences ● P ut names to the faces ● R esponsibilities ● S trengths and weaknesses 10
- 11. Virtual Meetings ● Iteration planning ● R elease planning ● Iteration summary & demo ● S tand-up - once or twice a week ● Daily progress Photo by Ha-Wee available online 11
- 12. Human bridges ● Ambassadors ● Touring rock stars ● Visiting professors ● P aratroopers ● F oreign exchange worker Photo by noticelj 12
- 13. Good communication tools ● Video conferencing ● S kype ● IM (chat rooms) ● Issue tracker ● Wiki ● And more... 13
- 14. Code review ● Disseminate knowledge ● Build trust ● Guest programming ● P ost commit vs. pre- commit 14
- 15. Rotating the pain Photo by appaji 15
- 16. Good fences make good neighbours ● P rojects ● S ubsystems ● P lugins ● Vertical components ● Interfaces ● C lients / S ervers ● P latforms Photo by Hryck 16
- 17. Dont's 17
- 18. Micro-management Photo by Peter Ito 18
- 19. Managers here, subordinates there Photo by Lord Mariser 19
- 20. Architects here, developers there Photo by kioan 20
- 21. Ignoring the fact of remoteness Photo by donata ramonaite 21
- 22. Cheaper workforce abroad Photo by wildphotons 22
- 23. Meeting overdose Photo by Steve Smith 23
- 24. Advantages of distributed teams ● S omeone round the clock ● Less conflicts during commits and fixing tests ● Taking over work started in the morning ● C ode reviewed by next morning ● Time to cool-down before responding ● S horter and intensive communication ● F un (new places, new cultures) ● Better computing resources utilisation - C I env is yours 24
- 25. Takeaways ● Avoid distributed if you can ● Agile amplifies problems ● Assign your best people ● Understand risks Photo by Edinburgh Blog ● Take advantage 25
- 26. Questions? wseliga@atlassian.com 26