Distributed Agile
25 likes8,531 views
The document discusses the challenges and patterns in distributed agile development, highlighting issues such as communication gaps, lack of trust, and the importance of adaptive practices. It presents case studies illustrating how agile methodologies can improve project outcomes by empowering teams, enhancing customer collaboration, and fostering effective communication. The author concludes that while distributed development poses significant difficulties, adopting strong agile practices can lead to successful project execution.
Distributed Agile
- 1. Distributed Agile Issues & Challenges Patterns and Anti-Patterns Naresh Jain Twitter: @nashjain http://blogs.agilefaqs.com Licensed Under Creative Commons by Naresh Jain 1
- 2. Why Distributed Development? Licensed Under Creative Commons by Naresh Jain 2
- 3. “right” people are distributed 3
- 4. Global Economy 4
- 6. Power Centers 6
- 7. 7
- 8. Decrease in Communication Bandwidth 8
- 9. Lack of visibility into project status 9
- 10. Lack of visibility into project status 9
- 11. Lack of “remote” Control 10
- 12. 11
- 13. Cultural Differences 12
- 14. Configuration Management 13
- 15. Coordination is difficult 14
- 16. Coordination is difficult 14
- 17. Me 15
- 18. 16
- 19. Mumbai 17
- 20. Tech Talks! 18
- 21. FitNesse ProTest DBFit FitDecorator ProFIT La"u Patang QWick 19
- 22. 20
- 23. 21
- 24. 22
- 25. 23
- 26. 24
- 27. 25
- 28. 26
- 29. Root Cause My Observations Licensed Under Creative Commons by Naresh Jain 27
- 30. Lack of Trust 28
- 31. Loss of Context (biz & tech) 29
- 32. Delayed Feedback (distance & time) 30
- 33. Duplication of Effort 31
- 34. Change is Inevitable 32
- 35. What does this lead to? Licensed Under Creative Commons by Naresh Jain 33
- 36. Heavyweight Process 34
- 37. More and more Upfront 35
- 38. Strict Change Control 36
- 40. Inability to React 38
- 41. Communication Gaps 39
- 42. Frustration 40
- 43. Erosion of Trust 41
- 44. Distributed Agile? Licensed Under Creative Commons by Naresh Jain 42
- 45. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and Interactions OVER Processes and Tools. Working Software OVER Comprehensive Documentation. Customer Collaboration OVER Contract Negotiation. Responding to Change OVER following a Plan. That is, while there is value in the items on the right, we value the items on the left more.” 43
- 46. Case Studies Licensed Under Creative Commons by Naresh Jain 44
- 47. Offshore Agile Maintenance Project Background EAI project for back office data validation and billing system for a pay-per- view cable company in New York 2 years later, lack of funds to maintain the app Decision to offshore the project Ended up with one year maintenance contract. 45
- 48. 1 Account Manager 1 PM 1 BA 2 Tester 1DBA 1 Manager 1 BA 3 Dev 1Tester 46
- 49. We Faced Typical Maintenance Project Challenges Licensed Under Creative Commons by Naresh Jain 47
- 50. Lack of Documentation 48
- 51. Lack of System Expert 49
- 52. Inexperienced Team Members 50
- 53. Lack of Test Safety Net 51
- 54. Legacy Code 52
- 55. Fluctuating Workload 53
- 56. Lack of Trust 54
- 57. Fear 55
- 58. Uncertainty 56
- 59. Frustration 57
- 60. XP Practices we started of with Planning game – 2 week iterations, story cards, Iteration Planning Meetings Small releases – 2 to 3 months Collective code ownership Continuous integration & Automated Release Standup meetings Coding standards 58
- 61. What we did not have/could not do? Onsite Client System Metaphor Simple Design Automated Testing User Stories (instead we had CR or Bugs) 40 hour week / sustainable pace 59
- 62. Evolved Agile Practices Kanban - Priority Log Micro releases – 2 to 3 days Refactoring (completely changed the Architecture) Pair Programming Collective code ownership Continuous integration & One click Release Test Driven Development 60
- 63. Evolved Agile Practices... Retrospectives Daily client driven demo on Dev env EOD Status mail Cross functional Pairing Demos and functional walk thru by Client Automated Acceptance Test 61
- 64. Results Product performs 3 times faster than before Huge increase in customer satisfaction More interesting work with increase per hour rate Great relationship and happy team Great platform to experiment with new process ideas Massive reduction in operating cost of the project 62
- 65. 1 PM 1 Tester 2 Dev 1 Tester 63
- 66. Case Study 2 Licensed Under Creative Commons by Naresh Jain 64
- 67. Large Healthcare Enterprise System SAP like Healthcare suite for medium to large-scale hospitals and institutes Large Re-architecture effort (Across 3 different Product Lines) 400+ team size across 3 different continents Multiple Organizations involved for Training and Coaching Teams 65
- 68. Started Off with... Pilot Project (1 Module of the entire application) 1 PM, 1 Scrum Master, 1 Architect/TL, 6 Dev, 1 BA and 1 Tester 100% Collocated Team Offshore members were onsite for 3 months (3 Sprints) 66
- 69. Started off with Scrum/XP Practice 2 Week Project Inception Prioritized Backlog with WAGs 1 Month Sprints User Stories Stand-up Meetings Sprint Review and Retrospectives Automated Builds 67
- 70. In the first 2 months 1 Month Sprint User Stories Automated Acceptance Tests Test First Development Collective Code Ownership Continuous Integration Sprint Review and Retrospectives 68
- 71. End of 3 Months 2 Week Sprints Distributed Teams Evolutionary Design TDD Build Promotion and Single Click Release Automated UI Tests Brand Ambassadors/Cross Pollination 69
- 72. Soon...Program Organization Program Management Scrum Scrum Master Scrum of Scrum Tech Lead Scrum of of Scrums Scrum of Scrums App 1 App 2 Shared Services/ M1 M2 Arch/Infrastructure Scrum M1 M2 Master Scrum of Scrum Scrums Master Scrum of S1 S2 M4 Scrums M5 M6 Tech Lead M8 Frameworks S3 Scrum of Scrums Tech Lead Scrum of Scrums M4 S4 S5 M3 M7 M3 M6 70
- 73. 4 Module Teams Architecture Team 1 Config Mgmt Team 3 Enterprise Products 1 IQA Team 18 Module Teams 1 DB Team 1 IQA Team 4 Module Teams 1 IQA Team 4 Module Teams 71
- 74. Key Challenges We Faced Licensed Under Creative Commons by Naresh Jain 72
- 75. Tools got in the Way 73
- 76. Death by Cross-Team Integration 74
- 77. End-to-End Delivery came to Grinding Halt 75
- 78. Confusion & Rework 76
- 79. Frustration 77
- 80. Summary How Agile can help? Licensed Under Creative Commons by Naresh Jain 78
- 81. Empowered Small Teams Its the people Duh! Build teams around motivated and passionate individuals Build a team environment where people are not afraid to try new things and fail (fail fast) Make work a fun place. 79
- 82. Small Frequent Releases Increase visibility and enable early feedback. A weekly software showcase gives more confidence than a weekly status report. Fail fast, recover quickly and at lower cost 80
- 83. Puts the customer in the driving seat Customer does Feature prioritization Customer uses early feedback to elaborate on and develop the requirements. Eliminates the need to articulate requirements in detailed documentation Customer makes business decision and development team makes technical decisions in collaboration with each other. Customer == Product Owner 81
- 84. Adaptive Planning Inspect and Adapt Help responding to change Teams communicate often, share information frequently 82
- 85. Feedback Driven Testing centric Test early, Test often and Test continuously Continuous integration Integrate with every checkin and avoid Integration Nightmares Automated Acceptance Tests Let acceptance criteria drive your development Team tastes success every time an iteration successfully passes customer’s test. 83
- 86. Practices that make a Difference Licensed Under Creative Commons by Naresh Jain 84
- 87. Continuous Integration Constant integration, building & testing of system with each change Set up a build promotion process and reduces on-site deployment risk. “The last person doesn’t go home until the build is clean” 85
- 88. Test Driven Development Reduces ambiguity around requirements by having executable specifications Acceptance Criteria per story Acceptance Tests are written before coding starts Use Unit Tests to drive your design Build a safety net to prevent regression bugs 86
- 89. Collective Ownership Cross Functional Pairing and Pair Programming Single shared code repository per project Mutually agreed coding standards and guidelines (Automated Check) Code Walk-through 87
- 90. Other Practices Stand Up Meetings/Daily Scrum Dev Hurdles Retrospectives Planning Game 88
- 91. Other Practices Stand Up Meetings/Daily Scrum Dev Hurdles Retrospectives Planning Game 88
- 92. Distributed Agile Patterns Licensed Under Creative Commons by Naresh Jain 89
- 93. Shared Workload Work split Divide work by functionality (stories), not by technical layers (horizontally). Otherwise, you create an interdependence that makes the dependent sub-team less productive Collective Ownership Each team is capable of demonstrating end-to-end functionality Capacity surpluses/shortages can be balanced through active management of work load distribution 90
- 94. Single Virtual Team Everyone works on the same release/iteration cycle drumbeats Shared code base fosters collective ownership of the source code Shared build environments allow teams to collaborate and integrate continuously Developing in “End-to-end” functional slices rather than layers allows teams to build upon each other’s work and reduces dependencies between locations 91
- 95. Cross Pollination 92
- 96. Cross Pollination Seeding Visits Start the project with a collocated team Knowledge Transfer – People as carriers of knowledge Build inter-personal relationships 92
- 97. Cross Pollination Seeding Visits Start the project with a collocated team Knowledge Transfer – People as carriers of knowledge Build inter-personal relationships “Maintenance” Visits Ongoing Bi-directional and multifunctional Cultural Ambassadors 92
- 98. Cross Pollination Seeding Visits Start the project with a collocated team Knowledge Transfer – People as carriers of knowledge Build inter-personal relationships “Maintenance” Visits Ongoing Bi-directional and multifunctional Cultural Ambassadors Establish a Travel budget. Often it is a very small percentage of total project cost. 92
- 99. Cross Pollination - Offshore Model Time OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
- 100. Cross Pollination - Offshore Model Time i 0 & i1 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
- 101. Cross Pollination - Offshore Model Time i 0 & i1 i2 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
- 102. Cross Pollination - Offshore Model Time i 0 & i1 i2 i3 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
- 103. Cross Pollination - Offshore Model Time i 0 & i1 i2 i3 i4 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
- 104. Cross Pollination - Distributed Model Time OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
- 105. Cross Pollination - Distributed Model Time i 0 & i1 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
- 106. Cross Pollination - Distributed Model Time i 0 & i1 i2 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
- 107. Cross Pollination - Distributed Model Time i 0 & i1 i2 i3 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
- 108. Cross Pollination - Distributed Model Time i 0 & i1 i2 i3 i4 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
- 109. Simple Tools take you a long way Physical Story walls with pictures on Wikis can be quite powerful Good version control system like SVN Online collaboration tools like Google Docs, Card Meeting, Forums, etc 5-10 min video recording using simple cameras 95
- 110. Source : ThoughtWorks 96
- 111. Massive over-communication Infrastructure High availability, high speed networks High-quality speakerphones, webcams Informative Workspaces and Information Radiators Communications Plans Standing calls Overlapping hours Instant Messaging,VoIP, NetMeeting, Webex etc. Wikis Team member photos on the wall 97
- 112. Local Standup meetings Source : ThoughtWorks 98
- 113. Anti-Patterns Licensed Under Creative Commons by Naresh Jain 99
- 114. Communication Anti-Patterns Single Point of Failure - Resist single person communicating with the on-site team. Unless the team has language barriers Hide real issues - Embrace transparency, honesty and openness One liner emails - You need to set context in each mail. Using Wikis to Dump information and not collaborate 100
- 115. Expectations Anti-Patterns 50% cost saving - Don’t sell Distributed Development purely as a cost saving scheme Unrealistic expectations about productivity - there will be communication overhead, there will be rework and there will be misunderstandings Wrongly try to please the customer/onsite team - Learn to say “No” 101
- 116. Focus related Anti-patterns Tool Driven - Don’t be a tool slave. Choose the right tool for the right job. Process OVER People - Don’t focus too much on a consistent, well-defined process across all locations. Instead let people define what works for them in their location. 102
- 117. Work Allocation Anti-Patterns Slice work such that the two teams have to interact very little - They will drift away. Occasional involvement - You don’t swing a huge requirement document and expect things to come back the way you wanted them Change Control Boards - Collaborate with the customer to provide them competitive advantage 103
- 118. Conclusion Distributed Development is difficult in general! Agile can help. Strong Development practices very important! 104
- 119. References Most of this is based on my 5 years of experience at ThoughtWorks Distributed Agile Development and the Death of Distance http://www.thoughtworks.com/press-releases/Distributed-Agile-Development- and-the-Death-of-Distance.html Case Study: Distributed Agile Development http://www.pivolis.com/pdf/Distributed_Agile_V1.0.pdf Distributed Agile http://www.agilealliance.com/articles/steindlchristophdistr/file Using an Agile Software Process with Offshore Development http://www.martinfowler.com/articles/agileOffshore.html 105
- 120. Questions? Thank you Distributed Agile Naresh Jain naresh@agilefaqs.com 106