Successfully reported this slideshow.
Your SlideShare is downloading. ×

Distributed Agile

Ad

Distributed Agile
   Issues & Challenges
Patterns and Anti-Patterns
          Naresh Jain
       Twitter: @nashjain
   htt...

Ad

Why Distributed
 Development?

 Licensed Under Creative Commons by Naresh Jain
                                           ...

Ad

“right” people are distributed




                                 3

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

1 of 120 Ad
1 of 120 Ad

Distributed Agile

Download to read offline

This is based on my 5 years of experience with Distributed Agile. Talks about some patterns and Anti Patterns.

This is based on my 5 years of experience with Distributed Agile. Talks about some patterns and Anti Patterns.

Advertisement
Advertisement

More Related Content

Advertisement
Advertisement

Distributed Agile

  1. 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. 2. Why Distributed Development? Licensed Under Creative Commons by Naresh Jain 2
  3. 3. “right” people are distributed 3
  4. 4. Global Economy 4
  5. 5. Business are distributed 5
  6. 6. Power Centers 6
  7. 7. 7
  8. 8. Decrease in Communication Bandwidth 8
  9. 9. Lack of visibility into project status 9
  10. 10. Lack of visibility into project status 9
  11. 11. Lack of “remote” Control 10
  12. 12. 11
  13. 13. Cultural Differences 12
  14. 14. Configuration Management 13
  15. 15. Coordination is difficult 14
  16. 16. Coordination is difficult 14
  17. 17. Me 15
  18. 18. 16
  19. 19. Mumbai 17
  20. 20. Tech Talks! 18
  21. 21. FitNesse ProTest DBFit FitDecorator ProFIT La"u Patang QWick 19
  22. 22. 20
  23. 23. 21
  24. 24. 22
  25. 25. 23
  26. 26. 24
  27. 27. 25
  28. 28. 26
  29. 29. Root Cause My Observations Licensed Under Creative Commons by Naresh Jain 27
  30. 30. Lack of Trust 28
  31. 31. Loss of Context (biz & tech) 29
  32. 32. Delayed Feedback (distance & time) 30
  33. 33. Duplication of Effort 31
  34. 34. Change is Inevitable 32
  35. 35. What does this lead to? Licensed Under Creative Commons by Naresh Jain 33
  36. 36. Heavyweight Process 34
  37. 37. More and more Upfront 35
  38. 38. Strict Change Control 36
  39. 39. Over-reliance on documentation 37
  40. 40. Inability to React 38
  41. 41. Communication Gaps 39
  42. 42. Frustration 40
  43. 43. Erosion of Trust 41
  44. 44. Distributed Agile? Licensed Under Creative Commons by Naresh Jain 42
  45. 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. 46. Case Studies Licensed Under Creative Commons by Naresh Jain 44
  47. 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. 48. 1 Account Manager 1 PM 1 BA 2 Tester 1DBA 1 Manager 1 BA 3 Dev 1Tester 46
  49. 49. We Faced Typical Maintenance Project Challenges Licensed Under Creative Commons by Naresh Jain 47
  50. 50. Lack of Documentation 48
  51. 51. Lack of System Expert 49
  52. 52. Inexperienced Team Members 50
  53. 53. Lack of Test Safety Net 51
  54. 54. Legacy Code 52
  55. 55. Fluctuating Workload 53
  56. 56. Lack of Trust 54
  57. 57. Fear 55
  58. 58. Uncertainty 56
  59. 59. Frustration 57
  60. 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. 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. 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. 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. 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. 65. 1 PM 1 Tester 2 Dev 1 Tester 63
  66. 66. Case Study 2 Licensed Under Creative Commons by Naresh Jain 64
  67. 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. 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. 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. 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. 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. 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. 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. 74. Key Challenges We Faced Licensed Under Creative Commons by Naresh Jain 72
  75. 75. Tools got in the Way 73
  76. 76. Death by Cross-Team Integration 74
  77. 77. End-to-End Delivery came to Grinding Halt 75
  78. 78. Confusion & Rework 76
  79. 79. Frustration 77
  80. 80. Summary How Agile can help? Licensed Under Creative Commons by Naresh Jain 78
  81. 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. 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. 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. 84. Adaptive Planning Inspect and Adapt Help responding to change Teams communicate often, share information frequently 82
  85. 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. 86. Practices that make a Difference Licensed Under Creative Commons by Naresh Jain 84
  87. 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. 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. 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. 90. Other Practices Stand Up Meetings/Daily Scrum Dev Hurdles Retrospectives Planning Game 88
  91. 91. Other Practices Stand Up Meetings/Daily Scrum Dev Hurdles Retrospectives Planning Game 88
  92. 92. Distributed Agile Patterns Licensed Under Creative Commons by Naresh Jain 89
  93. 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. 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. 95. Cross Pollination 92
  96. 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. 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. 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. 99. Cross Pollination - Offshore Model Time OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
  100. 100. Cross Pollination - Offshore Model Time i 0 & i1 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
  101. 101. Cross Pollination - Offshore Model Time i 0 & i1 i2 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
  102. 102. Cross Pollination - Offshore Model Time i 0 & i1 i2 i3 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 93
  103. 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. 104. Cross Pollination - Distributed Model Time OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
  105. 105. Cross Pollination - Distributed Model Time i 0 & i1 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
  106. 106. Cross Pollination - Distributed Model Time i 0 & i1 i2 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
  107. 107. Cross Pollination - Distributed Model Time i 0 & i1 i2 i3 OnSite Offshore - Offshore Team Member - Client-side Team Member - Swap Members 94
  108. 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. 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. 110. Source : ThoughtWorks 96
  111. 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. 112. Local Standup meetings Source : ThoughtWorks 98
  113. 113. Anti-Patterns Licensed Under Creative Commons by Naresh Jain 99
  114. 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. 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. 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. 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. 118. Conclusion Distributed Development is difficult in general! Agile can help. Strong Development practices very important! 104
  119. 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. 120. Questions? Thank you Distributed Agile Naresh Jain naresh@agilefaqs.com 106

×