distributed agile

Licensed Under Creative Commons by Naresh Jain

Distributed AgileIssues & Challenges

Patterns and Anti-Patterns

Naresh JainTwitter: @nashjain

http://blogs.agilefaqs.com 1

http://creativecommons.org/licenses/by-nc-sa/3.0/


http://agilefaqs.com/nareshjain.html


http://exortech.com/blog

http://exortech.com/blog


Why Distributed Development?

2





“right” people are distributed

3

Global Economy

4

Business are distributed

5

Power Centers

6

Decrease in Communication Bandwidth

8

Lack of visibility into project status

9

Lack of “remote” Control

10

Cultural Differences

12

Configuration Management

13

Coordination is difficult

14

Me

15

Mumbai17

Tech Talks!

18

FitNesse ProTest

PatangLa"u

FitDecoratorDBFit

QWick

ProFIT

19


Root CauseMy Observations

27





Lack of Trust

28

Loss of Context (biz & tech)

29

Delayed Feedback (distance & time)

30

Duplication of Effort

31

Change is Inevitable

32


What does this lead to?

33





Heavyweight Process

34

More and more Upfront

35

Strict Change Control

36

Over-reliance on documentation

37

Inability to React

38

Communication Gaps

39

Frustration

40

Erosion of Trust

41


Distributed Agile?

42





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


Case Studies

44





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

1 Account Manager1 PM1 BA

2 Tester1DBA

1 Manager1 BA3 Dev

1Tester

46


We Faced Typical Maintenance Project

Challenges

47





Lack of Documentation

48

Lack of System Expert

49

Inexperienced Team Members

50

Lack of Test Safety Net

51

Legacy Code

52

Fluctuating Workload

53

Lack of Trust

54

Fear

55

Uncertainty

56

Frustration

57

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

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

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

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

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

1 PM1 Tester

2 Dev1 Tester

63


Case Study 2

64





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

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

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

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

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

Soon...Program Organization

Tech Lead Scrum of Scrums

App 1

M3

Scrum Master

Scrum of Scrums

M2M1

M7M6

M4

M5

Tech Lead Scrum of Scrums

App 2

M3

Scrum Master

Scrum of Scrums

M2M1

M6

M4

Tech Lead Scrum of Scrum of Scrums

Shared Services/Arch/Infrastructure

S4

S2S1

S5

S3Frameworks

Scrum Master Scrum of Scrum of Scrums

Program Management Scrum

M8

70

Architecture Team3 Enterprise Products

18 Module Teams1 DB Team

1 IQA Team

4 Module Teams

4 Module Teams1 Config Mgmt Team

1 IQA Team

4 Module Teams1 IQA Team

71


Key Challenges We Faced

72





Tools got in the Way

73

Death by Cross-Team Integration

74

End-to-End Delivery came to Grinding Halt

75

Confusion & Rework

76

Frustration

77


SummaryHow Agile can help?

78





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.

Empowered Small Teams

79

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

Small Frequent Releases

80

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.

Puts the customer in the driving seat

Customer == Product Owner

81

Adaptive Planning

Inspect and Adapt

Help responding to change

Teams communicate often, share information frequently

82

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.

Feedback Driven

83


Practices that make a Difference

84





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”

Continuous Integration

85

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

Test Driven Development

86

Cross Functional Pairing and Pair Programming

Single shared code repository per project

Mutually agreed coding standards and guidelines (Automated Check)

Code Walk-through

Collective Ownership

87

Other Practices

Stand Up Meetings/Daily Scrum

Dev Hurdles

Retrospectives

Planning Game

88


Distributed AgilePatterns

89





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

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

Single Virtual Team

91

Cross Pollination

92

Seeding Visits

Start the project with a collocated team

Knowledge Transfer – People as carriers of knowledge

Build inter-personal relationships

Cross Pollination

92

Seeding Visits




“Maintenance” Visits

Ongoing

Bi-directional and multifunctional

Cultural Ambassadors

Cross Pollination

92

Seeding Visits




“Maintenance” Visits

Ongoing

Bi-directional and multifunctional

Cultural Ambassadors

Establish a Travel budget. Often it is a very small percentage of total project cost.

Cross Pollination

92

Cross Pollination - Offshore ModelTime

OnSite

Offshore

- Offshore Team Member

- Client-side Team Member - Swap Members

93


OnSite

Offshore



i 0 & i1

93


OnSite

Offshore



i 0 & i1 i 2

93


OnSite

Offshore



i 0 & i1 i 2 i 3

93


OnSite

Offshore



i 0 & i1 i 2 i 3 i 4

93

Cross Pollination - Distributed ModelTime

OnSite

Offshore



94


OnSite

Offshore



i 0 & i1

94


OnSite

Offshore



i 0 & i1 i 2

94


OnSite

Offshore



i 0 & i1 i 2 i 3

94


OnSite

Offshore



i 0 & i1 i 2 i 3 i 4

94

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

Source : ThoughtWorks

96

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

Massive over-communication

97

Local Standup meetings

Source : ThoughtWorks

98


Anti-Patterns

99





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

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

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

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

Conclusion

Distributed Development is difficult in general!

Agile can help.

Strong Development practices very important!

104

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

References

105





Questions?

Thank youDistributed Agile

Naresh [email protected]

106

mailto:[email protected]

mailto:[email protected]

distributed agile

Economy & Finance