Title: Distributed Agile Teams
1Distributed Agile Teams
- SENG 615 Agile Software Engineering
- Mark Dochstader
- 04 December 2007
2Distributed Agile Teams Outline
- Definition
- Challenges
- Introduce Exercise
- Complete Scenario
- Review Results
- Related Work
- Conclusions
- Final Thoughts and Questions
3Distributed Agile Teams Introduction
- When you hear Distributed what comes to mind?
Can a distributed team be agile?
4Distributed Agile Teams Definition
- The use of agile methods when members are not
collocated - Geographic
- Temporal
- Different Types
- Remote customers
- Dispersed team
- Distributed team
- Why an agile approach?
- Distributed or not, traditional approaches lack
adaptability - Distributed teams need even more sensitivity to
changing customer needs than collocated teams
5Distributed Agile Teams Challenges
- What does this mean?
- Pair programming is hard or impossible
- On-site customer is not available for some or all
developers - Can we even use agile methods with distributed
teams? - No The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. - Yes The importance is adhering to the
principles not the explicit implementations it
may be harder but can still be done
6Distributed Agile Teams Scenario 1
- A New Idea (version 0.0)
- You decide to start an individual development
project for personal use. - Personal Information Management (PIM) tool
- Unique features
- Unknown technologies
Complete Scenario 1 of the handout
7Distributed Agile Teams Matrix
C / P
C / P-
Communication Focused?
C- / P-
C- / P
-
Process Oriented?
8Distributed Agile Teams Common Issues
Communication
Strategic Assets
Technology
Security
Process Synchronization
Culture
9Distributed Agile Teams I AM A Team of 1
- Most effective team size for communication
- Simplest All at once model is the single
programmer - Internal architecture is centrally stored
- Consistent vision
- Tool Set
- Minimal/Incomplete
- Tailored to the individual
- On-Demand
10Distributed Agile Teams Scenario 2
- Early Days (V 0.1)
- 2.5 Developers
- Same location
- Different schedules
- Interest from potential users via Internet
Complete Scenario 2 of the handout
11Distributed Agile Teams Distributed Agile
Development (DAD)
Submit Code Meta
- Asynchronous distributed pair programming
- The first programmer works on a task for a period
of time - To end their session the programmer composes a
brief description of what is complete and tested
and what remains to be completed - The second (partner) programmer starts their
session by reviewing the notes and produced code - The partner then modifies and expands the code as
required to complete the task
Repository
Developer 1
Get Code Meta
Add Code Update Meta information
Developer 2
Customer
Monitors
Guides
12Distributed Agile Teams Reviewing DAD
- Validation
- Undergrad programming assignments with 4 sets of
programmers collocation/distributed and
pairing/non-pairing - Distributed pairs were synchronous
- Both paired teams performed superior vs.
non-paired - Collocated vs. distributed showed little
difference - Concerns with the approach
- Added requirement to produce supporting
documentation vs. verbal communication or
concurrent completion - Implicit assumption that both programmers in the
pair are experts - Customer guides development by monitoring written
descriptions - Focuses on the process changes inflicted by a
distributed team and not the communication hurdles
13Distributed Agile Teams Scenario 3
- Diamond in the Rough (version 1.0)
- Added remote teammate
- 2 P/T grad students
- Early Adopter customers
- Located worldwide
- Suggestions growing
Complete Scenario 3 of the handout
14Distributed Agile Teams Tools
- Agile Manifesto individuals and interactions
over processes and tools - PRO
- Tools are needed to help synchronize larger teams
- whiteboards and index cards don't scale. - CON
- Most tools inhibit communication they're a weak
reporting mechanism replacing rich discussion. - Tool Adoption Test Is the tool aiding or
replacing the intended practice?
15Distributed Agile Teams Tool Coverage
- Acceptance Testing
- Unit Testing
- Pair Programming Supplements
- SubEthaEdit / TightVNC
- Modeling Tools
- Whiteboard and colored markers
- Metrics
- Clover / NCover
- Build Source Control
- Ant/Nant
- CVS/Subversion/VSTeam
- Collaboration Planning
- Project Management
- Wikis
- Rally Lifecycle Management
16Distributed Agile Teams Design Principles of
Collaboration Tables
- Interpersonal Interaction
- Fluid Transitions between Activities
- Mitigate focusing on a single type of activity
- Transitions between Personal and Group Work
- Multiple views (personal / shared)
- Task Collaboration vs. External Work
- Use of Physical Objects
- task-related (notebook, camera)
- non-task-related (beverage)
- Simultaneous User Actions
We can use these design principles to assess
potential tools.
17Distributed Agile Teams Scenario 4
- Solid product with growing customer base
- Divergent focus
- Integrate
- 3 development teams
- New developers
- New customer group
Complete Scenario 4 of the handout
18Distributed Agile Teams Distributed Extreme
Programming (DXP)
- The key problems in DXP are to maintain
sufficiently rich communication, and a sufficient
level of respect, between colleagues separated
widely in time and space. - Three general cases for cross-site agile
- Agile Outsourcing (AO)
- Agile Dispersed Development (ADD)
- Distributed Agile Development (DAD)
19Distributed Agile Teams DXP Prescription
- Maintain a commitment to the value judgments that
characterize the core of all agile methods. - Use XP practice as-is when possible
- Adopt agile-esque substitutes when you cant
use the existing agile practice - Use process to guide development when distributed
aspects violate principles of agile
20Distributed Agile Teams DXP Results
- Validation
- Experience-based
- Commercial projects
- XP-based with Scrum influences
- One Team
- Balanced Sites
- Onsite Visit / Ambassador
- Communication Channels
- Distributed Standup
- One Team, One Codebase
- Unapologetically influenced by personal beliefs
- No empirical evidence
- Limited literature review
21Distributed Agile Teams DXP Matrix
Balanced Sites
One Team
One Team One Codebase
Visits
Distributed Standup
Communication Tools
Communication Focused?
-
Process Oriented?
22Distributed Agile Teams The Scalability Problem
- Single Super Hacker
- Surgical Team
- Extension of the single programmer
- Rare resource
- Pair Programming
- Capture advantages with gt 2 people
- Scrum
- Scale small, cross-functional teams
- Applied to a multi-site distributed team
23Distributed Agile Teams A Scrum Experience
- Easel Corporation (Early 1990s)
- Scrum teams of distributed developers
- Any developer, Any Site, Any Task
- 50 developers in US, Canada Russia
- Large Library System (gt 200 Million Users)
- Focuses On
- Daily Scrum meetings
- Daily meetings of Product Owner team
- Hourly automated builds from one central
repository - Developers at different sites on the same team
- XP practices
24Distributed Agile Teams Easel Scrum Matrix
XP Practices
Diff Sites One Team
Auto build One Repo
Daily Product
Daily Scrum
Communication Focused?
-
Process Oriented?
25Distributed Agile Teams Easel Scrum Concerns
- Identify Three Approaches
- Isolated Scrums (Typical Offshore)
- Distributed Scrum of Scrums
- Totally Integrated Scrums
- Requires you already have a scaleable agile
methodology in place - How do you build cross-functional teams that
balance distribution with functional coverage - Are you trading cross-team visibility for
inner-team miscommunication?
26Distributed Agile Teams Scenario 5
- 2 new development offices
- Brazil
- Eastern Europe
- Focus expanded
- Coordinate departments
- Branch offices
- Customers
- Integrate new development offices
Complete Scenario 5 of the handout
27Distributed Agile Teams Case Study - Global
Software Development
- US-based company servicing Internal projects with
globally distributed development units - Distributed customers and dispersed team
- Interviews with dev. team customers
- Interaction between team customers
- Interaction inside development team
- Key Challenges
- Requirements engineering
- Software development process
- Communication and language
- Culture and context sharing
- Trust
28Distributed Agile Teams Case Study - Solutions
- Solutions adopted focused on
- Planning
- Training
- Standardization
- Requirements Engineering
- Trust and integration
- Identified critical success factors
- Software Development Process
- Training
- Planning and Engagement
- Team building
- Communication and Feedback
29Distributed Agile Teams Case Study - Outcomes
Trust
Dev Process
Planning
Training
Communication Focused?
Requirements
Standardization
-
Process Oriented?
30Distributed Agile Teams Offshoring Experiences -
IBM
- IBM using an agile approach to off-shore
- Challenges
- Decreased communication bandwidth
- Decreased visibility into project status
- Problems with configuration management
- Disconnection on project estimation
31Distributed Agile Teams Offshoring Experiences
(2)
- Classify the project
- How well does the team understand what is to be
delivered? - Does the team know how it is going to deliver?
- How complex is the project?
- Balance Agility with Discipline
- How dynamic are the requirements?
- How much order does the culture need?
- How many people are involved?
- How critical is the project?
- How many expert developers do you have?
- Tailor the Method
- Apply the Method
- Gather Method Feedback (Retrospective)
32Distributed Agile Teams Offshoring - Agility
vs. Plan Driven
- Barry Boehm, Richard Turner Balancing Agility
and Discipline, Addison-Wesley, 2003
33Distributed Agile Teams Offshoring Experiences -
Overview
- Provides an inventory of available
strategies/tools for different situations - Targets the process designer, not the end-user
- Relies on centrally planned assembled
development methodology - May contain agile-inspired techniques but not
organic - Hampered by IBMs Global Services Method
- Insight into unpredicted challenges
- considerable cultural issues
- High turnover / job-hopping
- Communicate through code product (dog-fooding)
34Distributed Agile Teams Review Whiteboard
- Does anything jump out?
- Trends in proposed solutions to management
challenges - Group opinions on observations
- Individual does this match your personal
experience?
35Distributed Agile Teams Conclusions
- Developer/Customer
- OSS developers tend to be their own customers
- helps mitigate communication issues
- often expert developers
- Domain expert developers rely on the customer
- Less frequently for understanding
- Just as much for guidance
- Size
- smaller projects tend to be less impacted by the
communication challenges - As team size grows, process rigidity increases
- A necessary formalization?
36Distributed Agile Teams Conclusions (2)
- More documentation can help
- Can be informal (screen shots, notes)
- GOAL Capturing collective understanding
- Shared Planning Tool
- Web-based project planning or collaboration
- Daily meeting substitutes
- Isolated Scrums, Scrum of scrums, sub. Weekly
- Travel No replacement for Face-Time
- Solution must focus on communication
- Adaptability requires immediate feedback, close
communication and task visibility
37Distributed Agile Teams Final Thoughts
- Process and/or tools dont replace critical
assessment. - Projects and teams (especially distributed)
change strategies must change too - If possible structure the project so that teams
are basically not distributed for major
iterations. - Agile toolset is not all/none use what works
- Distributed teams are a growing phenomenon
embrace it!
38Chandler Information
- Personal Information Management (PIM) software
suite - Focus on Information Workflows (GTD)
- Collaboration and Sharing
- Destruction of Information Silos Note ? Email ?
Calendar Event - Started Spring of 2001
- Apache License
- Cross-platform (Python)
- Effort 25 developers (variable)
- Cost 5 to 10 Million (Guess)
- Status Preview 0.7.2 (Nov 13, 2007)
- http//chandlerproject.org/
- http//en.wikipedia.org/wiki/Chandler_28PIM29
39Distributed Agile Teams Discussion Questions
- Whats the difference between agile practices and
agile principles? - Why differentiate?
- You are finishing a distributed agile project
- What were the big challenges?
- What worked?
- What didnt?
40References
- Kent Beck, Cynthia Andres Extreme Programming
Explained Embrace Change (2nd Edition),
Addison-Wesley (2005) p.18 - Keith Braithwaite and Tim Joyce XP Expanded
Distributed Extreme Programming, Springer Berlin
/ Heidelberg, 0302-9743 (Print) 1611-3349
(Online), 2005 - Keith Braithwaite and Tim Joyce XP Expanded
Patterns for Distributed eXtreme Programming
(April 2006) http//www.keithbraithwaite.demon.co.
uk/professional/papers/2005/europlop/patterns_dist
ributed_xp.pdf - Herbsleb, J. D., and Moitra, D. An empirical
study on Global Software Development Distributed
IT Projects, IEEE Software, March/April,
USA,2001, p. 16-20. - Brooks , F.P. The Mythical Man-Month, Addison
Wesley Pub. Co., 1975, 25th Anniversary edition,
2000. - Nidiffer, K. E. and D. Dolan, 2005, "Evolving
Distributed Project Management," IEEE Software
22(5) 63-72. - Scott Rosenburg Dreaming In Code, Crown
Publishers, (2007).ISBN978-1-4000-8246-9 - Christoph Steindl Distributed Agile, IT
Architect and IT Specialist Institute - Central
Region in Herrenberg, Germany, 2004.
http//www.agilealliance.org/system/article/file/1
420/file.pdf