distributed agile teams

1. Distributed Agile Teams SENG 615 � Agile Software Engineering Mark Dochstader 04 December 2007

3. Distributed Agile Teams: Introduction

4. Distributed 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

5. Distributed 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

6. Distributed 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

7. Distributed Agile Teams: Matrix

8. Distributed Agile Teams: Common Issues Nidiffer & Dolan: Evolving Distributed Project Management Strategic: Difficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintain. Project and process management: Difficulty synchronizing work between distributed sites. Cultural: Conflicting behaviors, processes, and technologies. Technical: Incompatible data formats, schemas, and standards. Security: Ensuring electronic transmission confidentiality and privacy. Communication: Lack of effective communication mechanisms.Nidiffer & Dolan: Evolving Distributed Project Management Strategic: Difficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintain. Project and process management: Difficulty synchronizing work between distributed sites. Cultural: Conflicting behaviors, processes, and technologies. Technical: Incompatible data formats, schemas, and standards. Security: Ensuring electronic transmission confidentiality and privacy. Communication: Lack of effective communication mechanisms.

9. Distributed 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

10. Distributed Agile Teams: Scenario 2 Early Days (V 0.1) 2.5 Developers Same location Different schedules Interest from potential users via Internet

11. Distributed Agile Teams: Distributed Agile Development (DAD) 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 Steve Tousignant, Tanith Korravai, Joshua Gross, Emmett Davis: DAD: Superset of Distributed Agile Development: The Appropriate Software Methodology for a Startup (2003) http://coblitz.codeen.org:3125/citeseer.ist.psu.edu/cache/papers/cs/30722/http:zSzzSzwww.rfbinternational.comzSzpaperszSzTousignant.pdf/dad-superset-of-distributed.pdf Steve Tousignant, Tanith Korravai, Joshua Gross, Emmett Davis: DAD: Superset of Distributed Agile Development: The Appropriate Software Methodology for a Startup (2003) http://coblitz.codeen.org:3125/citeseer.ist.psu.edu/cache/papers/cs/30722/http:zSzzSzwww.rfbinternational.comzSzpaperszSzTousignant.pdf/dad-superset-of-distributed.pdf

12. Distributed 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 Validation Series of 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 No indication of criteria used to assess performance 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 Limits transfer of knowledge Doesn�t prevent blocking Doesn�t reinforce solution integrity Customer guides development by monitoring written descriptions Focuses on the process changes inflicted by a distributed project and not the communication hurdles Validation Series of 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 No indication of criteria used to assess performance 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 Limits transfer of knowledge Doesn�t prevent blocking Doesn�t reinforce solution integrity Customer guides development by monitoring written descriptions Focuses on the process changes inflicted by a distributed project and not the communication hurdles

13. Distributed 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

14. Distributed 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? Ron Jeffries � Agile Manifesto author: I have watched many teams plan or track their iterations using the available tools. The process seems almost always to go like this: Some person in the room, often the ScrumMaster or equivalent, brings the tool's screen up on a projector. Then they go around the room one person at a time, asking that person what they worked on, what they're going to do next, and so on. At base, this is a reporting process not a conversational process. As such, it is a weak form of communication compared to, say, a discussion. The team is taking turns being asked questions by some leader and answering them. Ryan Martens of Rally Software: Agile Application Lifecycle Management (AALM) tools help growing teams expand and help larger incumbent teams manage synchronization. make it easy to round trip from white boards and cards to tool and back again. These products serve a critical visibility role that is almost impossible to achieve when you try to roll-up white boards. Ron Jeffries � Agile Manifesto author: I have watched many teams plan or track their iterations using the available tools. The process seems almost always to go like this: Some person in the room, often the ScrumMaster or equivalent, brings the tool's screen up on a projector. Then they go around the room one person at a time, asking that person what they worked on, what they're going to do next, and so on. At base, this is a reporting process not a conversational process. As such, it is a weak form of communication compared to, say, a discussion. The team is taking turns being asked questions by some leader and answering them. Ryan Martens of Rally Software: Agile Application Lifecycle Management (AALM) tools help growing teams expand and help larger incumbent teams manage synchronization. make it easy to round trip from white boards and cards to tool and back again. These products serve a critical visibility role that is almost impossible to achieve when you try to roll-up white boards.

15. Distributed 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

16. Distributed 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 S.D. Scott, K.D. Grant, R.L. Mandryk: System Guidelines for Co-located, Collaborative Work on a Tabletop Display, Proceedings of European Conference Computer Supported Cooperative Work, Finland (2003), pp. 159-178 Interpersonal Interaction: don�t violate underlying mechanics of interaction. EX: individual displays don�t allow Pointing Fluid Transitions between Activities: limit overhead writing, drawing, and manipulating artifacts. Transitions between Personal and Group Work: people use physical space to segment work personal / shared Tabletop Collaboration vs. External Work: group effort beyond the tabletop Use of Physical Objects: Simultaneous User ActionsS.D. Scott, K.D. Grant, R.L. Mandryk: System Guidelines for Co-located, Collaborative Work on a Tabletop Display, Proceedings of European Conference Computer Supported Cooperative Work, Finland (2003), pp. 159-178 Interpersonal Interaction: don�t violate underlying mechanics of interaction. EX: individual displays don�t allow Pointing Fluid Transitions between Activities: limit overhead writing, drawing, and manipulating artifacts. Transitions between Personal and Group Work: people use physical space to segment work personal / shared Tabletop Collaboration vs. External Work: group effort beyond the tabletop Use of Physical Objects: Simultaneous User Actions

17. Distributed Agile Teams: Scenario 4 Solid product with growing customer base Divergent focus Integrate 3 development teams New developers New customer group

18. Distributed 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) Keith Braithwaite and Tim Joyce: XP Expanded: Distributed Extreme Programming Agile Outsourcing (AO): Where an agile team is created at an appropriately low cost offshore location. Requirements are generated onshore, and communicated offshore using documents, people and tests. Agile Dispersed Development (ADD): As practiced by much of the Open Source community and some commercial companies. Developers tend to be physically alone, but connected through a variety of communication channels. Practices such as frequent releases and continuous integration are employed, Pair Programming and other team based activities are not. Distributed Agile Development (DAD): Customers are distributed. One development team is distributed evenly over several sites to remain close to the customers. Keith Braithwaite and Tim Joyce: XP Expanded: Distributed Extreme Programming Agile Outsourcing (AO): Where an agile team is created at an appropriately low cost offshore location. Requirements are generated onshore, and communicated offshore using documents, people and tests. Agile Dispersed Development (ADD): As practiced by much of the Open Source community and some commercial companies. Developers tend to be physically alone, but connected through a variety of communication channels. Practices such as frequent releases and continuous integration are employed, Pair Programming and other team based activities are not. Distributed Agile Development (DAD): Customers are distributed. One development team is distributed evenly over several sites to remain close to the customers.

19. Distributed 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 can�t use the existing agile practice Use process to guide development when distributed aspects violate principles of agile High-level: sophisticated tools and complicated process models not necessarily required seems at odds with the spirit of the manifesto with downplays reliance on tools Use XP practice as-is when possible � single code base, test-driven, continuous integration Substitute � remote pair programming Overriding Process � force time adj for scrums to maintain real-time communication. Require on-siteTravel High-level: sophisticated tools and complicated process models not necessarily required seems at odds with the spirit of the manifesto with downplays reliance on tools Use XP practice as-is when possible � single code base, test-driven, continuous integration Substitute � remote pair programming Overriding Process � force time adj for scrums to maintain real-time communication. Require on-siteTravel

20. Distributed 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 put everyone in one room is an absolutely necessary rule to apply when introducing XP. Need to start with team-centered, communicative and collaborative developers need for colocation as the prime mechanism to manifest the Communication value is weakened One Team: single team identity, non-business communication, activities that share jokes & culture reference - PLAY Balanced Sites: equal in skill & number. Empowered to make decisions. Distributed Standup: Sync adjacent sites (temporally) at leat once a day. Force an overlap. Relates to One Team; Balanced Sites One Team, One Codebase: share rights and responsibilities toward each others� work, just as colocated workers do. put everyone in one room is an absolutely necessary rule to apply when introducing XP. Need to start with team-centered, communicative and collaborative developers need for colocation as the prime mechanism to manifest the Communication value is weakened One Team: single team identity, non-business communication, activities that share jokes & culture reference - PLAY Balanced Sites: equal in skill & number. Empowered to make decisions. Distributed Standup: Sync adjacent sites (temporally) at leat once a day. Force an overlap. Relates to One Team; Balanced Sites One Team, One Codebase: share rights and responsibilities toward each others� work, just as colocated workers do.

21. Distributed Agile Teams: DXP Matrix Balanced Sites is about minimizing dependencies on communication Similar to different sites/ one team from Scrum example One Team, One Build = Scrum�s Auto build;One Repo Code is Communication Balanced Sites is about minimizing dependencies on communication Similar to different sites/ one team from Scrum example One Team, One Build = Scrum�s Auto build;One Repo Code is Communication

22. Distributed Agile Teams: The Scalability Problem Single Super Hacker Surgical Team Extension of the single programmer Rare resource Pair Programming Capture advantages with > 2 people Scrum Scale small, cross-functional teams Applied to a multi-site distributed team Surgical Team � Brooks Superstar does critical components; directs team to assist with or take over less critical parts Accepted "good" programmers are generally 5-10 times as productive as mediocre ones. Surgical Team � Brooks Superstar does critical components; directs team to assist with or take over less critical parts Accepted "good" programmers are generally 5-10 times as productive as mediocre ones.

23. Distributed Agile Teams: A Scrum Experience Easel Corporation (Early 1990�s) Scrum teams of distributed developers Any developer, Any Site, Any Task 50+ developers in US, Canada & Russia Large Library System (> 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 Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation Scrum Master: The person or persons in charge of the tracking and the daily updates for the scrum (equivalent to a project manager). Sometimes referred to as a Scrum Facilitator.Scrum Team: A cross-functional team (developers, B.A.s, DBAs, and testers) responsible for developing the product.Product Owner: The person responsible for maintaining the Product Backlog via continuous interaction with Clients and Stakeholders.Story: A customer focused description of valued functionality.Product Backlog: The stories to be completed.Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of stories that the Team has committed to.Sprint Backlog: The Team's interpretation of the product backlog containing concrete tasks that will be done during the next sprint to implement some of the top items in the Product Backlog.Burn Down Chart: Daily progress for a sprint over the sprint's length. OT: Solo SCRUM product backlog sprint backlog Sprint sprint retrospective Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation Scrum Master: The person or persons in charge of the tracking and the daily updates for the scrum (equivalent to a project manager). Sometimes referred to as a Scrum Facilitator.Scrum Team: A cross-functional team (developers, B.A.s, DBAs, and testers) responsible for developing the product.Product Owner: The person responsible for maintaining the Product Backlog via continuous interaction with Clients and Stakeholders.Story: A customer focused description of valued functionality.Product Backlog: The stories to be completed.Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of stories that the Team has committed to.Sprint Backlog: The Team's interpretation of the product backlog containing concrete tasks that will be done during the next sprint to implement some of the top items in the Product Backlog.Burn Down Chart: Daily progress for a sprint over the sprint's length. OT: Solo SCRUM product backlog sprint backlog Sprint sprint retrospective

24. Distributed Agile Teams: Easel Scrum Matrix XP Practices is vague but taken with the assumption of tasks like Pair programming that focus on communication Daily Scrum and Daily Product meetings are intended to focus on communication but the co-ordination required to manage leads to substantial process overhead, especially Product which also has a top-down control aspect and a smaller # of participants.XP Practices is vague but taken with the assumption of tasks like Pair programming that focus on communication Daily Scrum and Daily Product meetings are intended to focus on communication but the co-ordination required to manage leads to substantial process overhead, especially Product which also has a top-down control aspect and a smaller # of participants.

25. Distributed 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? Isolated Scrums � not cross functional; not generally agile Distributed Scrum of Scrums � Partition work across geo teams; Scrum masters meet regularly to coordinate Totally Integrated Scrums � Distributed teams with members at multiple locationsUse local Scrums Are you trading cross-team visibility for inner-team miscommunication? All Scrum masters located in Utah but teams are spread out across sites Isolated Scrums � not cross functional; not generally agile Distributed Scrum of Scrums � Partition work across geo teams; Scrum masters meet regularly to coordinate Totally Integrated Scrums � Distributed teams with members at multiple locationsUse local Scrums Are you trading cross-team visibility for inner-team miscommunication? All Scrum masters located in Utah but teams are spread out across sites

26. Distributed Agile Teams: Scenario 5 2 new development offices Brazil Eastern Europe Focus expanded: Coordinate departments Branch offices Customers Integrate new development offices

27. Distributed 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

28. Distributed 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

29. Distributed Agile Teams: Case Study - Outcomes Formalization of processFormalization of process

30. Distributed 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 IBM using an agile approach to off-shore Dr. Christoph Steindl Senior IT Architect � App Management Services Decreased communication bandwidth � Different time zones, only a couple of hours overlapping � Cost and quality of telecommunication Decreased visibility into project status � Difficult for project managers and business sponsors to measure the progress � Different interpretations of �xx percentage complete� Problems with configuration management � Troubles when integrating offshore and onshore pieces � Troubles with different development environments � Troubles with replicating the customer�s system environment on the offshore site Disconnection on project estimation � Different experience and background of people who estimate the work and perform the work � Little identification with estimate � Difficult to assess the accuracy or reasonability of estimates as the project progresses. IBM using an agile approach to off-shore Dr. Christoph Steindl Senior IT Architect � App Management Services Decreased communication bandwidth � Different time zones, only a couple of hours overlapping � Cost and quality of telecommunication Decreased visibility into project status � Difficult for project managers and business sponsors to measure the progress � Different interpretations of �xx percentage complete� Problems with configuration management � Troubles when integrating offshore and onshore pieces � Troubles with different development environments � Troubles with replicating the customer�s system environment on the offshore site Disconnection on project estimation � Different experience and background of people who estimate the work and perform the work � Little identification with estimate � Difficult to assess the accuracy or reasonability of estimates as the project progresses.

31. Distributed 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)

32. Distributed Agile Teams: Offshoring - Agility vs. Plan Driven Barry Boehm, Richard Turner: Balancing Agility and Discipline, Addison-Wesley, 2003 Barry Boehm, Richard Turner: Balancing Agility and Discipline, Addison-Wesley, 2003 Barry Boehm, Richard Turner: Balancing Agility and Discipline, Addison-Wesley, 2003

33. Distributed 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 IBM�s Global Services Method Insight into unpredicted challenges considerable cultural issues High turnover / job-hopping Communicate through code & product (dog-fooding) technical infrastructure for collaborating across continents shared repository connectivity Indian�s don�t say �no�, politeness can hide misunderstanding Job hopping has been a well-known issue in the Silicon Valley, the job market is over-heated in India.technical infrastructure for collaborating across continents shared repository connectivity Indian�s don�t say �no�, politeness can hide misunderstanding Job hopping has been a well-known issue in the Silicon Valley, the job market is over-heated in India.

34. Distributed 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?

35. Distributed 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? Agile is a very emotional topic making it hard to divorce desired results from actual outcomes Some arguments state that talented developers will make any approach work while weak developers are doomed regardless of methodology. While most may be agree to the later; the former is not so clear. Performance of agile over traditional approaches is debated, but if we accept at least some degree of advantage we can start to see how distributed agile approaches could be effectiveAgile is a very emotional topic making it hard to divorce desired results from actual outcomes Some arguments state that talented developers will make any approach work while weak developers are doomed regardless of methodology. While most may be agree to the later; the former is not so clear. Performance of agile over traditional approaches is debated, but if we accept at least some degree of advantage we can start to see how distributed agile approaches could be effective

36. Distributed 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

37. Distributed Agile Teams: Final Thoughts Process and/or tools don�t 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! Distributed teams are a growing phenomenon Offshoring, open source, global economy � all aspects of software development � Dist teams are here to stay. We need to focus on enhancing these inherently more complicated team structures. Distributed teams are a growing phenomenon Offshoring, open source, global economy � all aspects of software development � Dist teams are here to stay. We need to focus on enhancing these inherently more complicated team structures.

38. Chandler 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_%28PIM%29

39. Distributed Agile Teams: Discussion Questions What�s 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 didn�t?

40. References 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_distributed_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).ISBN:978-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/1420/file.pdf