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

5. Business are distributed 5

6. Power Centers 6

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. Conﬁguration Management 13

15. Coordination is difﬁcult 14

16. Coordination is difﬁcult 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

39. Over-reliance on documentation 37

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 ofﬁce 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 ﬁrst 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 Conﬁg 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 conﬁdence 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 speciﬁcations 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-deﬁned process across all locations. Instead let people deﬁne 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 difﬁcult 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/ﬁle 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