Sourcing and Vendor Relationships Vol. 5, No.


Distributed Agile Development and the Death of Distance
by Matthew Simons

For many companies, the rapid growth in outsourcing, especially offshore outsourcing of development work, opens the door to a host of problems that come with having a far-flung development environment. If you practice — or want to practice — agile software development, this

Executive Report offers ideas on how to narrow the gap between the home
office and your partners around the globe.

Cutter Business Technology Council
Rob Austin Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Ed Yourdon

Access Experts
to the

About Cutter Consortium
Cutter Consortium’s mission is to foster the debate of, and dialogue on, the businesstechnology issues challenging enterprises today and to help organizations leverage IT for competitive advantage and business success. Cutter’s philosophy is that most of the issues managers face are complex enough to merit examination that goes beyond simple pronouncements. The Consortium takes a unique view of the business-technology landscape, looking beyond the one-dimensional “technology” fix approach so common today. We know there are no “silver bullets” in IT and that successful implementation and deployment of a technology is as crucial as the selection of that technology. To accomplish our mission, we have assembled the world’s preeminent IT consultants — a distinguished group of internationally recognized experts committed to delivering toplevel, critical, objective advice. Each of the Consortium’s nine practice areas features a team of Senior Consultants whose credentials are unmatched by any other service provider. This group of experts provides all the consulting, performs all the research and writing, develops and presents all the workshops, and fields all the inquiries from Cutter clients. This is what differentiates Cutter from other analyst and consulting firms and why we say Cutter gives you access to the experts. All of Cutter’s products and services are provided by today’s top thinkers in business and IT. Cutter’s clients tap into this brain trust and are the beneficiaries of the dialogue and debate our experts engage in at the annual Cutter Summit, in the pages of Cutter IT Journal, through the collaborative forecasting of the Cutter Business Technology Council, and in our many reports and advisories. Cutter Consortium’s menu of products and services can be customized to fit your organization’s budget. Most importantly, Cutter offers objectivity. Unlike so many information providers, the Consortium has no special ties to vendors and can therefore be completely forthright and critical. That’s why more than 5,300 global organizations rely on Cutter for the no-holds-barred advice they need to gain and to maintain a competitive edge — and for the peace of mind that comes with knowing they are relying on the best minds in the business for their information, insight, and guidance. For more information, contact Cutter Consortium at +1 781 648 8700 or

The problem is so thorny because software development is. Vol. Every aspect of a project is fundamentally changed the moment that team members lose the ability to walk down the hall or meet at the water cooler to communicate face to face. in fact some organizations are finding that the case for cost savings is not as strong as the hype suggests [3]. However.Distributed Agile Development and the Death of Distance SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE Executive Report. With the recent rapid growth in offshore development service providers. 5. cost savings is at the top of any list of drivers for distributed development. large development teams must work elsewhere in order to be together) n Use of vendors with off-site development facilities (reduction in travel costs by allowing vendor employees to work near their homes) n Quality of life (not requiring project team members to travel or relocate means happier teams that can include seasoned and mature individuals whose family commitments do not permit them to be road warriors) n 24/7 availability of development (for support or “follow the sun” development) . Yet its allure remains too powerful to ignore. but unfortunately the annals of software development history are crammed with sad stories of distributed projects gone wrong. based on communication. at its core. 4 by Matthew Simons Software development teams around the world have been trying to solve the riddle of distributed development for years. No. cost is not the only driver for distribution. Many organizations have tried. Some of the most common reasons for considering distributed development include: n Cost savings (utilizing offshore teams) n Schedule compression (bringing more resources to bear) n Scale (breaking a large effort into manageable components) n Access to technical talent (specialized technical skills may not be available locally) n Proximity to business sponsors (customers are not always located near developers) n Workspace unavailable (when space is at a premium.

there is a promising new option for those of you who are faced with making distributed development work for your organizations. this section provides a brief overview.martinfowler. Arlington. E-mail: rsaia@cutter. USA. 37 Broadway. In other words. Recent developments in technology have spawned a way of working. This Executive Report helps provide that answer. FeatureDriven Development. development teams have become increasingly able to cope with change during the construction of systems. ©2004 by Cutter Consortium.cutter. and Adaptive Software in the following ways: n Individuals and interactions over processes and tools n Working software over comprehensive documentation n Customer collaboration over contract negotiation n Responding to change over following a plan The priorities in the second half of each statement are typical of approaches for software development that were formulated in the era of structured including photocopying. call +1 781 648 8700. 4 www. and image However. or e-mail service@cutter. is against the law. The best known of these include Extreme Programming. Web site: www. All rights reserved. Suite . They were driven by the infamous “cost of change” curve that showed the rapidly escalating cost of changing your mind or finding a problem as the project progressed (see Figure 1). with the advent and evolution of object-oriented (OO) programming languages and enabling technologies such as automated testing tools and NO. +1 800 888 articles/newMethodology.html).com. E-mail: kleonard@cutter. SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE AN AGILE DEVELOPMENT PRIMER1 Agile software development is an umbrella term that is used to describe a family of approaches for software project management and execution that has evolved during the past five to 10 years. faxing. The Sourcing and Vendor Relationships Advisory Service Executive Report is published by Cutter Consortium. Reprints make an excellent training tool. The priorities shared by all agile 1If you are not familiar with “The New processes have been described by the nonprofit AgileAlliance organization (www.agilealliance. 5. within North America. VOL. E-mail: pshalit@cutter.2 Fortunately.cutter. What would happen if we applied this way of working to distributed development teams? The answer to that question might just mean a major step forward in our quest to make reliable distributed development a reality. +1 800 492 1650. Tel: +1 781 641 9876 or. Unauthorized reproduction in any form. Fax: +1 781 648 1950 or. Managing Editor: Rick Saia. within North America. Cost of change Requirements Analysis/design Code Test Integrate/live Project stage Figure 1 — The cost of change curve. Production Editor: Pamela Shalit. MA Methodology” (www. that have proven very effective at delivering software. but there are a number of others. known as agile software For information about reprints and/or back issues of Cutter Consortium publications. Group Publisher: Kim Leonard. the cost of change curve has become less steep (see Figure 2). E-mail: service@cutter.

as illustrated in Figure 4 (adapted from [1]). adapted from Managing the Flow of Technology. we come to projects with concurrent development at several business centers within the same company. It also allows them to realize incremental ROI as they go. Continuing upward on the scale of distribution complexity. Agile development was initially envisaged for and applied to 3 Cost of change Time Figure 2 — The new cost of change curve. People located 100 meters or more apart have only about a 5% chance of talking to one another in a typical week. That makes it useful for many organizations and teams. Outsourcing work to external organizations further inhibits communication. demanding constant customer participation to steer the development effort (working with people instead of with requirements documents). small. the recommendations in this report are just as applicable to your multi-story project as they are to your multi-continent project. colocated teams of developers and customers. Agile practices center around breaking development efforts into manageable pieces (as short as one to two weeks between deliverables). ARE YOU DISTRIBUTED? Amid the current hubbub surrounding offshore outsourcing. Offshore distributed projects belong at the top of the complexity scale because they must overcome not only the challenges of distance and of VOL.EXECUTIVE REPORT Agile methods have capitalized on this trend through working practices that maximize the development team’s ability to evolve a system based on the latest information of what the system is supposed to do. instead of waiting until the project is finished for big-bang benefits that might never materialize. and enforcing disciplined development practices (simplicity of design and automated testing). NO. Business-unit people like agile development because it demonstrates regular visible progress and enables them to evolve the system in response to rapidly changing requirements. 5. Development teams like agile development because it mitigates many of the risks of software development (such as “integration hell” at the end of a long project) and because there is mounting anecdotal evidence that experienced agile teams build higherquality systems more quickly than do teams using other methods. shows that communication falls off rapidly with physical separation [1]. The simplest and most often overlooked form of distributed development is what happens on a project that outgrows its workspace and is forced to spread out into multiple locations within the same office or at multiple offices in the same campus or region. Figure 3. 4 ©2004 CUTTER CONSORTIUM . but ignores a large and growing class of software projects that involve some degree of distribution. In other words. it is easy to forget that distributed development has many forms.

com .1% 1 10 100 1.000 10. 40% Likelihood of weekly communication 35% 30% 25% 20% 15% 10% 5% With organizational bond Without organizational bond 0 10 20 30 40 50 60 70 Separation distance (meters) Figure 4 — Communication probability as a function of distance: intragroup and intergroup. the standard deviation of project estimates can vary quite a bit. and temporal inhibitors. Bringing it all together for implementation in the production 10% 1% . Many have been unpleasantly surprised at late stages of a project to find that their understanding of “percentage complete” was less than accurate. 4 www. multiple organizations but also of language. In a distributed project. n Decreased visibility into project status. 5. your risk of experiencing one or more of the pitfalls VOL. Many teams face such problems as the following: n Disconnection on project requirements.cutter. n Configuration management. The customer and the development team can quite easily develop divergent understandings of the project requirements. managers. n Disconnection on project estimation. it causes great dismay when the longawaited software finally arrives. This can happen either because the requirements have changed or because they were not properly understood in the first place.000 Separation distance (meters) Figure 3 — Communication probability as a function of distance. It is often difficult for managers and sponsors of a distributed project to get an accurate sense of project progress and status. and developers estimate projects differently. NO. in which it is likely that these groups will never meet in person. each using their own amount of leeway based on personal experiences. Customers. Needless to say. if this goes uncorrected.4 Likelihood of weekly communication SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE 100% commonly associated with distributed projects increases (see Figure 5). As you move further up the complexity scale. cultural.

languages. Distributed agile development is a powerful new approach to software delivery that will allow Most approaches that are designed to address the challenges of distributed development tended to take decreased communication bandwidth as a given and have evolved structures and tactics to manage the risk this ©2004 CUTTER CONSORTIUM VOL. 4 . environment is one of the most difficult parts of any software project. practices. progress. But wouldn’t it be great if you didn’t have to consider the complexity or strategic importance of your project when deciding which work you can do off-site? Wouldn’t it be great to realize all the benefits of distributed development on your most important. And yet despite all of our controls and protections. Punishing change goes against the reality of modern business. or run over budget. They also tend to penalize customers for changing their mind. the erosion of trust caused by decreased personal contact causes us to adopt controlling behaviors and attempt to manage delivery risk with legal contracts. complex initiatives? DISTRIBUTED AGILE DEVELOPMENT FOR THE NEXT GENERATION OF DISTRIBUTED PROJECTS The way forward for leading IT organizations lies at the intersection of agile development and distributed teams. it becomes entirely possible for each site to develop radically divergent visions of project intention. and cultural divides). People build trust through communication. We keep the difficult. Customers are unhappy. n Erosion of trust. Projects fail entirely. we choose the work we distribute very carefully. distributed teams have been living in the world of requirements specs. So in response. and status. When these divergent versions of reality come to light. and everyone blames one another.EXECUTIVE REPORT 5 Less Complex More Complex Colocated development Team not seated together Team on different floors/ buildings Noncolocated team of >1 organization Team distributed across time zones and cultures Figure 5 — Complexity scale for distributed projects. and long periods of integration testing (which is often really a euphemism for “the time when we come on-site to actually make it work”). component designs. As teams get further and further removed from one another (spanning time zones. Some contracts for distributed development projects contain so much detail that they start to sound like requirement specs or project plans in their own right. Controlling the Chaos introduces into the process. strategic initiatives close to home and use offsite resources for maintenance work or well-defined projects. The principles and practices of agile software development that make it so effective at delivering complex systems with rapidly changing requirements work to directly address many of the prime risk areas of distributed development [4]. NO. underdeliver. where responding to market demand (a very good thing) often means changing your mind. Many distributed teams have faced serious or (in some cases) intractable problems integrating and deploying the components in the production environment. often it still doesn’t work as well as we had hoped. it can damage personal and professional relationships irrevocably and make working together a very unpleasant experience for both sides. As a result. 5. Additionally.

Before You Get Started . Experience with Nondistributed Agile Development Strategic Need Figure 6 — Where distributed agile development can work. Mastering agile development takes practice and concerted effort over months.. and there is a learning curve for all project participants and sponsors. it will behoove you to work with an off-site team that VOL. Since agile development was originally proposed for colocated teams of customers and . it would be wise to start a few teams on the path toward on-site agile even as you begin to lay the groundwork for distributed agile development. As illustrated in Figure 6.6 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE Technical Complexity Agile Distributed Agile t ec roj k P is R that you must put in place before you begin. Think of it as an advanced application of the fundamental practices employed by nondistributed agile teams. If your organization has not started using agile development practices locally. its managers. NO. There are some fundamental structures. once you have overcome the leaning curve. There is a learning curve associated with adopting standard agile development — not only in mastering the practices but also in achieving the shift in mindset that happens across the project team. Appropriate Off-Site Staff/Partner Don’t be tempted to pick a project and jump into distributed agile development headfirst. The differences in project-execution practices are subtle but critical. global IT organizations to change the way they think about what they do and what they can achieve.cutter. However. 5. not weeks. there is not a direct mapping between practices on distributed and nondistributed agile development teams. The rest of this report focuses on how to develop an organizational competency for distributed agile software development through the building of a portfolio of successful distributed agile development projects. qualifications. but you should seriously consider applying some of its best practices for any project in your portfolio that includes an element of distribution.. so it is wise to get them underway immediately once you have decided to try distributed agile development.” it would certainly be a more difficult and risky proposition. and building blocks In addition to building your own organization’s knowledge of agile practices. and sponsors. Many of these items have relatively long lead times. a distributed agile development approach is appropriate for a wide band of enterprise-level projects in the upper-right quadrant of the plot of “technical complexity” against “strategic need. While it may be possible to “go distributed agile” without first “going agile. there is almost no limit to what your organization can achieve with distributed agile development. Distributed agile development clearly derives from standard agile development.” Distributed agile development is not right for every project. 4 www. The lessons learned and best practices described here are based on personal experiences since 2000 working with and observing distributed agile development teams that range in size from five to 150 members.

If anything. Setting this up at a sufficient level usually takes approximately three times as long as you would expect. Plan your communication and rollout carefully so that the on-site team members will work to support distributed agile development and make it succeed. Succeeding with ©2004 CUTTER CONSORTIUM VOL. Since implementing distributed agile development will likely involve partnering with an external vendor. momentum and support should start to swing your way. Many organizations are not set up to support staff members of all levels traveling or working off-site. If you are outsourcing development. this should be the guiding principle: do not underestimate the culture shock that distributed agile development can create for your organization. Often. However.EXECUTIVE REPORT 7 consultants may need to come to terms with new types of relationships. n High-availability. NO. n High-quality speakerphones. They may also not be comfortable providing access to confidential information in a location that may not be subject to the same security practices as those used at the home office. Once you have built up a few successes and people become comfortable with the fact that they will have “new roles” rather than “no roles” in the world of distributed agile development. if you are unwilling or unable to provide your team with an environment that is set up to facilitate communication. organizations may be sensitive to sending businesscritical data off-site. The network administrators at each development site must work out how to provide fast and reliable twoway access between all the machines and resources the teams will need to share. Because some of these items may have long lead times. look for a vendor with a track record of successful agile delivery or (ideally) experience in applying agile practices to distributed projects. The items listed below may seem somewhat incidental. As you will see in the sections that follow on best practices. Adding the challenge of learning agile development to the challenges of executing distributed development could be a recipe for disaster. it is wise to get them underway as soon as possible. Seek out and develop advocates at every level of the organization and make sure they are involved in the planning and in the first trial projects. highbandwidth network connectivity (often virtual private networks). groups of people will need to collaborate via phone. Openness to Off-Site Development distributed agile development requires investment in enabling technologies and infrastructure. for example. If your distributed project is within your own organization. there are no general rules for promoting distributed agile development among your staff members. All these considerations must be managed. introduce on-site agile development at all project locations prior to rolling out distributed agile development. Technical and Physical Infrastructure has agile experience. 4 . Since every situation is different. most challenges of distributed development can be traced back to decreased communication bandwidth. implementing distributed agile development can be a radical shift with far-reaching cultural implications for many organizations. This is often an issue in offshore development when phones are not enabled for international dialing. You will see. Additionally. It is possible that some employees may view performing work elsewhere as a threat to their own positions — especially if that work has been shifted to a low-cost development center. that one of the fundamental requirements is frequent rotation of staff between the off-site and on-site locations. Any project team member should be able to pick up the phone and directly dial any other team member and talk for any length of time. organizations that traditionally have not employed As previously discussed. you should seriously question your desire to adopt distributed agile development. 5. This can be complicated when thirdparty systems are involved. n Unlimited telephone connectivity.

n Project technologies. Larger projects rapidly become more risky and n Project duration. Alternatives to the big public messaging clients (such as locally hosted messaging servers) exist but take time to procure and install. Pipeline especially the client’s domain experts. QA testers need to be able to provide rapid turnaround so they do not become a bottleneck in the development machine. The optimal team size for your initial efforts at distributed agile development is around 10 to 15 in total (including all roles at both sites). it can develop systems very quickly. VOL.8 An investment in high-quality (full duplex) speakerphones will do wonders to facilitate this communication. Your project must run long enough to allow the team to gel and evolve its working practices. n Project complexity.cutter. You would do well to put on your strategicthinking hat when choosing the first few pieces of work that you do with off-site teams. custom software development with modern OO languages is the best choice for distributed agile development. Some corporate IT departments have policies against the use of these tools. Allocating a room in both locations for the ad hoc use of the distributed team can do wonders to facilitate communication and establish a team spirit. To achieve the tantalizing benefits of off-site development. NO. and pictures of the teams. It can also provide some productivity gains for simpler or more well-defined projects. n Project space. The team can only achieve peak levels of productivity if the customer is able to supply an adequate pipeline of work for the off-site team. It also needs to run long enough to generate the metrics you can use to promote wider usage of distributed agile development. Experience has shown that distributed teams often come to rely on the immediacy and “availability indicator” features of IM utilities. highly strategic (and hence highly risky) projects. It is also a place where the conference phone is always plugged in and ready to host calls whenever they become necessary. but the practices recommended here may be a bit over the top for less complex development. Initial Efforts difficult given sheer size alone and demand broad experience with distributed agile development throughout the team from the outset. 4 . Smaller projects often don’t face the challenges that distributed agile development is designed to address and aren’t worth the overhead required to set up the distributed team. If you hope to use your initial efforts to help you build the case for greater usage of distributed www. This room is a place to post project status.NET. Agile development is significantly enabled by advanced programming languages such as Java or .com Once a distributed agile development team gets rolling. Consider each of the following project attributes in order to select something that will deliver an initial win: n Project size (number of people). artifacts. 5. Additionally. As the capability and confidence of your teams mature. The on-site team. it is important to take a longer-term view when developing an organizational capability for distributed agile development. SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE n Instant messaging (IM). but it is best to start carefully. You should consider this “throughput” factor when sizing and staffing your on-site and offsite teams. must be able to stay ahead of the off-site developers. While it is possible to apply agile practices to projects using other tools or languages. An alternative is to set up a conferencecall facility and give all project team members the ability to schedule calls. A project scheduled to run for three months is probably the minimum you would want to choose for your initial efforts. As discussed above. n Project visibility. you will be able to distribute a greater volume and variety of work. distributed agile development is well suited for highly complex.

the massive transfer of domain knowledge that happens through agile development in your organization. Representatives from each site must be actively engaged in the conversations that explore the boundaries of each piece of functionality. the lightweight documentation that agile projects rely on often lacks sufficient detail to be useful to people who were not present for the initial conversations. After successfully delivering your initial project. Additionally. A distributed team presents a challenge because the developers often are not colocated with the customers. n Existing versus new development. and the benefits you gain from it will continue to increase. which makes carrying out collaborative scoping workshops more difficult. 5. the biggest factor in whether your initial project leads to wider adoption of distributed agile development is probably your business sponsor. It can be easier to start up a new off-site team on an established code base and architecture without the overhead of solving fundamental questions on design and technical approach. The solution to the challenge of distributed agile project estimation lies in the effective use of staff rotation and a bit of extra care in preparing documentation. your sponsor will become your champion throughout the wider organization. nondistributed projects. Warning: don’t be tempted to skimp and use conference calls in lieu of face-to-face meetings. As your teams continue to learn. n Project sponsorship. Also. In these workshops. it is important that the people responsible for doing the work are also responsible for estimating the work. While it is certainly possible to start from scratch with distributed agile development. such as in “story cards” or “features” instead of in detailed requirement specs or use cases. you should choose a project that people will notice. You may want to consider trying out distributed agile for follow-on deliveries of existing. Each experience will allow your team to build and evolve the technical infrastructure. Once you deliver. but there are some mechanics to consider concerning who does it and where it happens. Initial estimation happens at the start of a project during the critical period when credibility and relationships are established and many of the rules of engagement are laid down. In agile development. 4 . keep in mind that the goals of future projects extend beyond simple execution. doing so may not be the most prudent choice for your initial efforts. NO. As the depth and breadth of your project portfolio grow. Another characteristic of agile methods is not relying on detailed documentation to capture scope. Project team members from both sites should be physically present at the sessions where high-level scope items are broken down for developers to estimate. Distributing the development team does nothing to change the practices used for estimating an agile project. relationships. This “human side” of the estimation and planning process just doesn’t happen over the telephone. In addition to successful execution. you will be ©2004 CUTTER CONSORTIUM VOL. your distributed agile development delivery model will mature and become second nature. Therefore agile projects are usually scoped out through collaborative workshops between customers and developers. BEST PRACTICES FOR ESTIMATING DISTRIBUTED AGILE DEVELOPMENT PROJECTS A key difference between traditional and agile project execution is that estimation and planning is viewed as a process that occurs throughout the project rather than as an event that happens once at the beginning and perhaps again at specified intervals. items to be developed are documented in simple ways. Select a sponsor who will remain engaged in the project and who can easily realize measurable benefits from the approach. and working practices that will enable future success.EXECUTIVE REPORT 9 able to increase the complexity of work you choose to distribute.

Anyone present for the initial discussions should be able to clarify points or answer questions as the developers go about estimating.10 intensive rapid-fire questioning and answering is severely limited when you try to do it over the telephone. n Project manager. EFFECTIVE TEAM STRUCTURES FOR DISTRIBUTED AGILE DEVELOPMENT One common model from the outsourcing world is to have an on-site project manager managing a team of off-site developers. Choose people who are receptive to adjusting their working practices VOL. 4 www. Successful transfer of domain knowledge to ambassadors from the off-site team is one of the critical factors that will allow your remote team to successfully execute distributed agile development. one person may. This model just doesn’t fly for distributed agile development. which will make them more effective communicators and team members. After the initial set of features has been estimated by the development team. the list should be widely circulated for review (with the proviso that this is only the initial list and is subject to change).com .cutter. you should set aside time to discuss and debate which roles your team will choose to use. In addition to traditional project management responsibilities regarding project planning and progress tracking. Search for advocates of distributed agile development. Evaluate soft skills (such as proactive communication and tolerance) with equal or even greater importance than pure technical ability. have traveled outside their home countries. As you set up your delivery team. the project manager on a distributed agile development project has prime responsibility for encouraging communication between the on-site and off-site teams. try to find people who have experience living in or working with other cultures or. If you can find people who have existing relationships with the off-site team members. Once everyone has had a chance to review and comment and the estimates have been adjusted as necessary. 5. He or she should help the team agree on communication patterns (discussed below) and constantly encourage on-site members to communicate with the remote site until they get Choosing the right people for your distributed development teams can mean the difference between success and failure. Make sure everyone on the team understands and agrees with the roles before you start development. If the ambassadors are unable to answer a question. they should forward it to their friends at the other site for discussion and clarification. On-Site Team Roles and Responsibilities and willing to travel or temporarily relocate if required. The following roles and responsibilities often prove effective for the on-site team on a distributed agile development project. at a minimum. NO. These people are likely to be more open to and interested in forming relationships across cultural boundaries. in some cases. this will allow you to start faster because those existing relationships will shorten the trust-building phase of project startup. Once an initial set of project functionality has been captured. Now you are ready to begin putting together the rest of your team and planning your releases. the ambassadors can return to the remote site and guide the development team through initial project estimation. have more than one role. If you are doing offshore development. These roles do not necessarily have a one-to-one mapping with individuals. A new way of working requires new roles and ways of interacting. you will have an initial idea of the size of the SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE project. The following are some team structures and characteristics that have proven effective across various distributed agile development projects and may prove useful for you. Customers and project team members should check the list for missing items and probe any items that seem to carry unexpected estimates (either much bigger or much smaller than anticipated).

Make sure the off-site team is dedicated to your project and has a common understanding of your planned approach for project execution. Proxy customers communicate constantly with the off-site team members. n Truth. n Proxy customer. The on-site QA team ensures that the code written by the off-site team works in a local staging or user acceptance testing environment that duplicates production as closely n Sponsor. Failing that probably unrealistic scenario. In this situation. the on-site developer can advocate for the off-site team and also brief the off-site team on critical technical communication or goings-on at the local site. it is necessary to employ proxy customers in the form of business analysts.EXECUTIVE REPORT 11 via testing and are responsible for showcasing the results of iterations to project stakeholders. Even if development does not take place at both locations. Engaging the sponsor will allow the sponsor to form his or her own opinion of distributed agile development and communicate it to the wider enterprise. For large teams or for teams where stakeholders cannot be dedicated to the project full time. in the habit of talking many times a day to their invisible colleagues. including the willingness VOL. Off-Site Team Roles and Responsibilities The ideal off-site development team would be made up of onsite team members who have been relocated to another site. Project circumstances dictate whether you should consider staffing a developer at the local site. NO. In addition. It is also beneficial for the sponsor to visit the remote site to meet the team and form personal impressions of the project members and their working practices. as possible. The Truth is the final authority on the priority of items in the backlog (although he or she will collect feedback from a variety of business and technical sources prior to making priority decisions). build your off-site team with proactive communicators who are willing to adjust their working practices to mesh well with the on-site team. n On-site QA. proxy customers approve delivered functionality ©2004 CUTTER CONSORTIUM n Developer liaison. look for off-site teams that have at least some familiarity with your organization or industry. To make distributed agile development work. 4 . proxy customers should be willing to travel in person to the remote site and (if the team is located in a different time zone) to shift their working hours on occasion to facilitate real-time interaction with the off-site team. The Truth interfaces with the development team via the backlog (the set of yet-to-bedeveloped features). Often. Proxy customers are responsible for keeping up to date with shifting business priorities and clearly articulating requirements to the off-site development team. This team will work closely with the developer liaison or on-site development team to make sure any issues are communicated and addressed. The sponsor must be positioned to receive communication and metrics about the project and to experience key events in person. “The Truth” (aka the product owner) is the customer representative who is empowered to act as the single point of contact for all project stakeholders. supporting them by answering questions as they proceed through each development iteration. some on-site teams prefer to staff a developer so that they can communicate with the off-site team at all levels. It has proven particularly useful when the off-site team is working on only one part of a large project that also involves an on-site development team. since this will lessen the domain/ cultural learning curve at the start of the project. The Truth is responsible for prioritizing and managing project scope. Another situation that may demand an on-site developer is if the deployment/ testing of the delivered system requires technical support before the customer/business analyst can review and approve it. The project manager also has the responsibility for creating a “one-team” culture and ensuring that all the other recommended practices in this report are applied at the right time in the right way. 5.

n Off-site tech . To further enhance communication. building up a competency for functional. n Iteration manager. One way to increase the productivity of agile development teams is to assign responsibility for the build system and development environment to a build and configuration master. Although off-site analysts will often be less experienced in the domain and project goals at the outset. by working SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE with the on-site analysts over time. On a distributed agile development project. Rotating among the entire team will give this person a big-picture view of everything that is going on and n Off-site tech support. and system testing at the remote development site is a great way to accelerate distributed agile development. this person is also often responsible for the communications and systems infrastructure between the sites. n Single point of contact (SPOC). The iteration manager also collaborates with his or her project manager counterpart to track and report project progress to sponsors. one project member sometimes takes on multiple roles. VOL. allows development teams to fix issues very quickly and increases the quality of code eventually delivered to the local team. and fostering a one-team attitude. they will come up to speed surprisingly quickly and eventually will be quite able to stand in as on-site business domain experts for the majority of questions from developers. some teams have found it useful to appoint someone to be the single point of contact between the off-site and on-site teams. The SPOC agrees to do whatever he or she can to enable the teams to work together — from tracking down a person who gets a phone call to ensuring that people adhere to the communications practices the teams agreed to at the outset of the project. building a positive culture.cutter. n Business analyst. n QA testers. NO. This concentrated technical knowledge can be useful at various points in the project (such as at deployment time when he or she is likely to rotate to the local deployment site to see the application into production).12 to send ambassadors to your site and accept visitors at its location. but instead pair programs with all members of the development team. off-site business analysts who work on a project through several releases often become invaluable system experts when on-site analysts move on or are rotated to other projects. and roadblocks that the teams face at each site. regression. Having someone locally available to act as the customer in 80% of the circumstances will significantly lower the communication barriers and increase the productivity of the off-site team. It is advisable to have one off-site developer who is specifically not assigned for work. Similar to business analysis. will enable him or her to serve as a single point of contact on the state of the code. Duplicating business analysts at the local and remote sites is a long-term strategy that can pay major dividends in distributed agile development. 4 www. Additionally. Additionally. instead of waiting for feedback from remote testers. visibility. the iteration manager has responsibilities similar to those of the on-site project manager regarding encouraging communication. it is worthwhile to specifically allocate someone to own the technical infrastructure of your distributed agile development project. As with the local team. Because outages in connectivity can bring progress to a grinding halt. and assurance that the off-site iteration manager provides to a distributed agile development team. issues. The ability to get rapid feedback from the test team as soon as code is delivered. 5. The overhead of overlapping project managers is more than made up for by the degree of control. The following roles and responsibilities for the off-site team have proven effective for distributed agile development projects. The iteration manager at the remote site communicates daily with the on-site project manager to discuss the risks.

By working together in person. Business analysts should also pair up on defining requirements and communicating with project stakeholders. Some applications need to interface with legacy systems with poorly documented data structures and interfaces. the project managers from each site should ensure that the teams socialize at work or in the evenings if possible. Some organizations have rigorous audit or go-live processes to which the off-site team must adhere. the more effective your team will ultimately become. project. and the best way to transfer information between organizations or social systems is to physically transfer a human carrier” [1]. Ambassadors 13 sheer effectiveness of communication nothing beats on-site visits. you will also need some ambassadors. For example. These ambassadors carry domain. 4 . In addition to projectrelated activities. But to really make your teams perform well. The first seeding visit usually occurs when members of the off-site team (often an iteration Once the seeding visits have been completed. or training of staff located there). “Human beings are the most effective carriers of information. a financial services application may require someone who is a certified accountant to specify requirements and test functionality. When confronting a special project consideration. always remember that the more you can do to locate or develop that knowledge remotely (through rotation. The most effective distributed agile development teams typically have about 20% of team members working outside of their base location at any point in time. Even project managers should pair to collaboratively come up with project plans and progress tracking and reporting mechanisms. During the seeding visits. everyone will not only put names to faces but also will get used to one another’s working styles and learn whom to go to with the various questions or concerns that will arise over the remainder of the project. and that carries through the conclusion of. 5. Some projects require specialized types of domain or process knowledge. you should maintain VOL. A seeding visit in the opposite direction may also be planned for just prior to. Proven team structures and disciplined communication practices will facilitate this exchange. NO. and team information between the development sites via regular visits. a business analyst. Maintenance Visits The basic challenge of distributed agile development is how to transfer complex knowledge about projects and processes that is held in the heads of a group of people in one location into the heads of a group of people in another location. the team members should just plain work together. This visit would send customer representatives (often a project manager and business analyst) to the remote site to meet the team members and be available to them locally for a short time. but for ©2004 CUTTER CONSORTIUM A seeding visit occurs the first time people from the off-site team visit the local site or the first time people from the local site visit the remote location. There are two basic types of visits: seeding visits and maintenance visits. Developers should pair program on code to reach a common understanding of coding standards and application architecture. the first development iteration. and a tech lead) arrive at the local site to help the customer articulate and document the business requirements during the early phases of the project.EXECUTIVE REPORT n Other specialists (as required). Seeding visits tend to last a bit longer (two weeks are the minimum) than maintenance visits to allow for sufficient team building and for initial knowledge transfer to occur. According to Thomas Allen in his groundbreaking study on how technology-based communities communicate. Seeding Visits manager. Using some or all of these roles on your project will provide a solid foundation for distributed agile development. recruitment.

A best practice for scaling up a development effort (whether or not the effort is divided across multiple sites) is to split it into independent components that can be worked on separately. With a bit of thought. consult with your techies to help you choose which work is sent off-site. and technical staff. as it has been shown to be one of the single most important factors for distributed agile development project success. Don’t be tempted into splitting teams based on business function or resource location alone. The trick to successful distribution of teams working on common code is to www. that after too much time has elapsed (six months is probably the maximum). the seeding visits become less critical. businesspeople. however.cutter. you should keep the “reactor monitoring” functionality on-site and send the “time and expense reporting” modules to the off-site team. the greater risk you incur. You should encourage and support this if it is even remotely feasible. Getting this right can be quite a complex chore that requires collaboration between project managers.14 some level of rotation (in both directions) throughout the course of the project. if you view distributed agile development as a long-term strategy for your development organization. however. NO. If you are considering multisite development efforts. Additionally. Another factor to consider when you are trying to decide which work to do off-site versus on-site is the complexity of the domain and the need for on-site experts. Splitting Up the Work figure out how to not get in each other’s way. While there is certainly overhead associated with maintaining such high levels of team rotation. If you are building software to run a nuclear power station and you have only one nuclear engineer (who will only work from the local site). 5. A one-week visit in each direction every six to eight weeks is probably the minimum workable level of cross-pollination. but the longer you go without a visit from either side. Sometimes you will find someone from the local site who is willing (or even anxious) to relocate to the remote location for a longer period of time. Be prepared to learn that you need to do some work to restructure the code so that it is more modular and cleanly separated. this simple case can be extended to cover split development teams across multiple sites. Over time. Once the team members have largely gotten to know one another. the local team member will have become sufficiently distanced from local events such that he or she will begin to lose value as an ambassador to the remote . Ambassadors and the Cost of Success It may strike you that this degree of staff rotation is exceedingly high and in fact may jeopardize VOL. The length of the project will determine the number of maintenance visits that will be required. you should view seeding visits as an investment for future projects. do not be tempted to skimp on this. as the constant presence of a local team member at the remote site will significantly boost communication and aid in knowledge transfer. Saving a few dollars doesn’t warrant putting the delivery of the entire project at risk. they can be replaced by less frequent maintenance visits. These maintenance visits can be of shorter duration than the seeding visits. distributed agile development teams are structured so that business analysis occurs at the local site and development occurs off-site. They serve to keep relationships fresh and to contribute to the flow of information between project sites. Longer-Term Ambassadors SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE some of the common benefits ascribed to distributed development (specifically cost savings when using offshore teams). as divisions that are not represented in the structure of the underlying code are essentially arbitrary and will not allow teams to work independently. Seeding visits will then be required only for big new projects or to introduce new team members to the organization. Remember. 4 In the simplest (and probably most common) case.

and details on project document repositories and shared machines. the on-site team went into deployment/support mode and the off-site team took a cut of its release to begin work on the next release. Once production was stable. the team could see its work all the way through the go-live process and provide rapid response to eliminate any bugs found in production. you should consider doing this portion of the development work on-site.EXECUTIVE REPORT 15 approach you choose for splitting up the work should account for the location and availability of critical intellectual capital and should be guided by the desire to reduce delivery risk and transfer greater application knowledge among all participating teams. Each project will have its own unique drivers. DISTRIBUTED AGILE DEVELOPMENT COMMUNICATION PATTERNS Compensating for the reduction of communication that comes with distance is a critical enabler of distributed agile development. chosen communication technologies. The plan should be reviewed and adjusted as part of the retrospective that follows each development iteration. The plan should be quite detailed and include items such as schedules of ambassador visits. when faced with the need to deliver and support regular successive releases. With so many options available. The following have proven useful on numerous projects and form the beginnings of a communication-pattern toolkit for distributed agile development: n Communication plan. Be wary of gizmos and gadgets that have novelty appeal but do little to enable and sustain basic communication on a continual basis. but whatever ©2004 CUTTER CONSORTIUM VOL. the market is teeming with high-priced. technology-based offerings guaranteed to improve off-site collaboration. project roles/ responsibilities (including special communication-focused roles such as the SPOC). It is advisable to schedule a special teleconference between the onsite and off-site teams while the project is kicking off to discuss and agree on the communication plan. In response to this need. If you cannot provide adequate access to dependent systems. it can be difficult to decide which practices. where those systems are available. A final item to consider is your project release schedule and any requirements for application support. Agile teams can work wonders with mocks and stubs (ways to quickly simulate external systems). In this way. meeting schedules. plans for the shifting of working hours to maximize real-time overlap (if required). low-overhead tools that provide instant access (such as telephones) instead of complicated tools that take time to configure and need to be scheduled in advance (such as videoconferencing). it is a good old-fashioned plan. If you observe colocated teams while Access to external systems upon which your system is dependent is critical for the development team. The project managers (from both the local and remote sites) should collaborate with one another and their local teams to reach consensus on how the two sides will work together. In one case. n Instant messaging. 5. 4 . instructions and etiquette guidelines for using the chosen technologies. tools. and technologies are best for enabling distributed agile development. While this team was busy supporting its production release. contact details for all team members. Build your communications infrastructure out of simple. the other team was building the next release. you need real connectivity to ensure everything will work when the system goes live. but at some point. NO. a distributed agile development team experimented with various approaches but ultimately found it best for one team to do both the development and early-life support of each release. It is important to ensure that everyone on the team (and anyone who joins while the project is in flight) has reviewed and agreed to follow the communication plan. The most important tool in your toolkit isn’t a technology at all.

information about project scope. Additionally. If you decide to use a Wiki. these tools provide the critical feature of visually showing online availability of teammates in remote locations. e-mail is not a very helpful tool for distributed agile development. and minutes from technical reviews) on the Wiki instead of communicating it via e-mail (or not at all) does wonders to foster a common view of the project across multiple sites. Subscribers will receive e-mails whenever those pages change. many Wikis have functionality that allows users to subscribe to certain pages. Some teams have found it VOL. As long as all team members agree to update the Wiki whenever anything substantive changes. By typing and editing plain text. 5. Making the Wiki a destination of choice for project team members is a great way to boost communication and foster a one-team feeling between physically separate workgroups. It also has the added benefit of allowing the team to add new members and bring them up to speed quickly as new members can get a great deal of context by simply reading the content on the Wiki. the entire virtual team will remain updated with the latest developments on each piece of work. By asking everyone who is involved with a particular piece of work (a story card or feature) to subscribe to the page that represents that piece of work. Wiki users can post content that can be immediately viewed by everyone with access to the Wiki. While the conversation may not always be directly related to the work at hand. you will notice that there is almost constant bubbling conversation. but it would certainly be wise to impose strict etiquette on e-mail usage and try to encourage team members to switch to some of the other communication tools described here. you should put some thought into the general structure it will use and appoint someone (the SPOC or project manager) to monitor content and reorganize or extend the Wiki structure when necessary. NO. You should also specifically discuss Wiki etiquette and usage with the team with some frequency. The technology that has proven most effective for simulating team chatter is IM. org/wiki. It would be too extreme to ban e-mail on a distributed agile development project. They can follow up via IM or phone. E-mail conversations between two people are much less efficient and interactive than a phone call or an IM chat: e-mails copied to large groups are copied only to those who the original sender believed would be appropriate and often spawn fragmented or unclear responses. 4 www.cutter. n . Medium to large distributed agile development teams (with 10 or more people) have made great and productive use of Wikis as both a lasting record of project communication and a daily collaboration tool. team members log out or change their status when they leave their desks). people are left off distribution lists — and the list of problems goes on and on. By ensuring that your entire team has IM accounts and uses them appropriately (that is. Posting important project information (such as n E-mail.cgi?WhatIsWiki) is an easy-to-use technology that facilitates the creation and editing of Web pages. A Wiki (see http://wiki. In addition to providing an extremely low-cost means of communication. it forms an important part of the communication context of the project that is largely lost by distributing the teams. hardto-find. project announcements sent via e-mail are not available to people who join the project after the announcement was circulated. you can create small virtual teams with essentially zero overhead. you can create a virtual community that massively increases the level of communication between your off-site teams. they will evolve organically and may end up containing a mix of useful and relevant information as well as some poorly organized. Despite its ubiquitous use. A final thing to mention about Wikis is that they require a bit of management. or out-of-date communication. SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE team names and numbers. Left on their own.16 they work.

Finally. technical teams must collaborate with their customers on a regular basis to choose what to work on next. Most of the project tracking and steering practices of agile development apply directly with very little modification other than making sure to include the right people in the various processes. Some teams find it effective to hold daily virtual standups during a conference call. NO. Do not make the mistake of thinking that everyone on the team will do the right thing to make conference calls successful. 5. are a very different type of communication pattern. implementing one or two virtual standups a week with on-site standups taking place on days when no virtual standup is scheduled. distributed agile development teams should continue to include phone calls in their communication toolkit. This person also asks for clarification when it is apparent that something is unclear. regardless of where they happen to sit.EXECUTIVE REPORT 17 usually takes a one-on-one form. That person is also responsible for following up with the other team on any cross-location issues. n Phone calls. Many distributed agile development teams have given specific responsibility to someone on each side of the conference call (often the SPOC) to moderate and maximize the effectiveness of the conversation. it is important to agree on some rules for phone contacts at the outset and for both sides to exercise flexibility in being contacted outside of standard working hours. need to find a way to include them in your distributed development practices. Steering n Standup meetings. they provide a bit of a project pulse and publicize problems and risks early so they can be dealt with or communicated more widely instead of coming as a surprise several weeks later. the conversation ©2004 CUTTER CONSORTIUM PROJECT STEERING AND TRACKING The iterative nature of agile development directly addresses many of the project tracking and visibility issues posed by distributed development. as voices and conversations carry much more context than plain words ever will. They also allow people to coordinate efforts and synchronize with one another before starting the workday. useful to perform a daily review of outstanding unanswered e-mails as part of their regular status meetings (a day spent waiting for an answer to an e-mail is often a day completely wasted). and you To rightfully be termed agile development. the shift away from e-mail is a difficult one and will probably require significant encouragement and support from project managers in both locations. Additionally. Questions of fact or questions with binary answers are fine for IM chats while questions of opinion or questions seeking context are best left for the phone. Because people have become so accustomed to using it. This person watches body language at his or her location and ensures that everyone who has something to add has a chance to have their say. If teams are separated by many time zones. Some teams use a hybrid approach. The goal of this collaboration is to move project planning away from being a point-in-time event VOL. which is attended by all members from all locations. Teams should be made aware and taught to think about issues that are appropriate for phone and issues where other channels are sufficient. although most people talk on the phone nearly every day. Other teams hold local standups and appoint someone to publish brief notes (on the wiki). Conference calls. Regular phone calls serve to maintain relationships in ways IM or Wikis never can. 4 . which are quite useful for some activities in agile development projects (such as iteration kickoff meetings or “virtual standups”). These meetings are essential to agile development. These meetings are designed to be short and to air any issues facing the team. Despite the availability of many text-based alternatives. A distinguishing characteristic of many agile development teams is their daily standup meetings.

the team should be able to lay out a rough release plan that provides a projection of the course of development over at least a few months. At a minimum.cutter. it becomes very clear which stakeholders are advocates for which priorities and how the various customer representatives see the project playing SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE out. These showcases not only serve to build trust and confidence in distributed agile development but also offer highly effective forums for collecting feedback on the system under construction and feeding that information into the projectsteering process (and back to the off-site team). That way. The remainder of the burden of tracking isn’t the responsibility of the project managers at all. and availability of key resources. by the time your customers are ready to have a look. it is strongly suggested that members (ideally a project manager. the on-site and off-site project managers should agree on a framework for project tracking at the outset. progress to date. On a distributed agile development project. it has essentially been accepted. and business analyst) from the off-site development team are present in person for the first few project-steering sessions. On a normal agile development project.18 and toward more of a continuous balancing act over the course of the project. but by being disciplined about maintaining a regular “plan. If for some reason your customers are unwilling to review regular showcases. NO. After the first couple of steering sessions. including shifting business priorities. Collecting and analyzing these three numbers will greatly enhance the project’s ability to measure its development capacity (as well as its skill at estimating). technical lead. it is critical to go through the exercise of showcasing those parts of the system that have been completed at the remote site to the local customers and stakeholders. You may find that there is a lot of overhead involved in preparing for and executing iteration showcases. At this time. showcase. they have the unique ability to demonstrate completeness along the way. returning for personal appearances only if major changes occur. During these initial sessions. the only real difference is that there may be several other factors to consider. 5. replan” cycle. the process of deploying and showing off the system will be silky smooth and all that much more impressive. you should find a way to simulate this by holding internal showcases every couple of weeks. this framework needs to include initial estimates for each unit of . refined estimates done at the time the work is started. project steering takes a multitude of factors as inputs. you essentially incrementally achieve system sign-off from your customers and stakeholders. It will highlight problems quickly and allow for projections going forward that are vital as inputs into projectsteering activities. but rather of the team itself. VOL. Tracking Agile development provides the capability to track projects at an extremely detailed level. technical risk. such as the following: n Does the off-site team have connectivity to required thirdparty systems as is necessary to begin developing a certain set of components? n Should we postpone a particularly tricky or new area of the system until the next scheduled ambassador visit to the off-site location? n What will the availability of the off-site team be during this iteration (may be different if the offsite location has holidays or festivals that are not synchronized with the on-site team)? Additionally. As mentioned above. and actual time spent to complete the work. By the time you deliver the final system. build. This detailed tracking serves to address many fears about distributed development that are based simply on the inability to see the team working. Because agile teams incrementally build production-ready code. schedules. After every development iteration. dates. the off-site members can return to their home base and participate in future steering sessions via phone. 4 www.

you begin to appreciate why successful distributed agile development teams often employ someone specifically to address this problem. It also allows teams of developers who are not colocated (and who may never have met) to trust one another enough to work on the same code. The key is to make sure that the automated build system builds quickly and then tests and deploys into an environment that simulates the production environment to the highest degree possible. Teams practicing collective code ownership allow any developer to change any piece of code with impunity — providing all the test suites pass following the change. NO. then VOL.e. more than 10 developers) or with concurrent development in multiple sites. Configuration problems can bring the critical rapid feedback cycles of distributed agile development to a grinding halt. the deployment phase may turn out to be somewhat of a nonevent. DEVELOPMENT PRACTICES AND TOOLS The various incarnations of agile development recommend a plethora of development practices designed to enable and facilitate agile ways of working. test. Veterans of the software development game have probably all had someone tell them (often wryly) when faced with a broken system that “it works on my machine!” The fact is that as systems increase in complexity from simple executables to complex. The value of continuous integration is that it solves small integration headaches immediately instead of trying to solve huge ones at the end.. Of all the development practices to choose from. continuous integration (the process by which developers integrate their code and build the entire system whenever they have made changes) should reduce or even eliminate on-site deployment risk at the end of a distributed agile development project.EXECUTIVE REPORT 19 teams must constantly be on the lookout for ways to reduce ambiguity in their communication between sites. Faced with reduced communication bandwidth. To mitigate this risk. This practice is so critical that on a project of any size (i. multitier enterprise systems that integrate with multiple other systems. the following are the four most critical in distributed agile development projects: n Continuous integration. test cases are the clearest way to describe requirements and to document the code that implements those requirements. This practice encourages developers to write code with a high degree of test coverage (to ensure it won’t be broken by someone down the line) and greatly improves the internal quality of the system. If the result of each iteration has been released into production. If practiced with discipline. When you add the fact that development will be going on in two locations that are often quite different in terms of technical infrastructure. DEPLOYMENT AND SUPPORT Depending on how the project has been progressing. you must have someone on the project whose job is to understand and manage the development. Communicating via test cases (both between business analysts and developers and among developers working on the system) is an agile best practice that is even more beneficial in a distributed agile development project environment. wanted to touch any code developed at the other site. it is often useful to make the construction and maintenance of the build system a distinct role so that it gets the attention it deserves. 5. the constant deployment demanded by agile development becomes an enormous challenge. and deployment environments at all project sites. distributed n Collective code ownership. n Test-driven development. Without a doubt. Distributed agile development between multiple sites would not be possible without collective code ownership — especially in light of how development teams that are separated by many time zones would otherwise have to wait a day for their off-site teammates to wake up every time they n Agile configuration management. 4 ©2004 CUTTER CONSORTIUM .

Once the system is live. 5. Depending on your strategy. They also make sure outbound ambassadors are loaded up with gifts for the off-site team and look after the inbound ambassadors that visit their own site. they actively encourage communication until the teams have bonded enough that they do not need encouraging. The best distributed agile development project managers work hard to foster a one-team feeling. you may still need to install the system in the production environment and perhaps go through some formal audit or acceptance testing prior to going live. if you were unable to fully practice continuous deployment. Making distributed agile development work requires people to change their working practices. NO. Transitioning a system that is developed using distributed agile SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE development to support isn’t really much different from transitioning any other system except that your system should have cleaner.20 when the iterations end. more fully tested code and will come with an automated build and testing system that should prove very useful to the support organization. Although the decreased personal interaction can negatively impact morale. often by posting pictures of the off-site team and encouraging the sharing of stories across locations. These culture. but take encouragement in the knowledge that it VOL. Things do go wrong. although you will need to consider your specific project situation and plan the participation accordingly. you should select a support provider and work to transition the knowledge from the development team to the support team. and people can feel powerless because of their inability to get involved in person. It should also be clear that you must proceed with care and work hard at planning and executing a portfolio of projects to build up your distributed agile development competency over a period of several years. The people who should visit are probably the configuration manager and one or more of the technical staff. and sometimes to come in to work early or stay late to maximize overlap with a remote . one thing that the most successful distributed agile development teams have in common is a culture of — for lack of a better word — fun. teams that are built for distributed agile development are not well suited to the challenges and duties of system support.and morale-related considerations are not just nice to have. By applying the lessons learned and best practices described above.cutter. These are very different jobs that require very different skill sets. It will still be hard work and require fortitude and determination. there are no additional special activities required to get the system live. CULTURE AND MORALE In addition to all the tangible practices discussed above. This final part of the project is an excellent time to schedule a visit to the local site by the ambassador at the remote site so that the people who built and configured the system are also available in real time to get it installed and launched. you will arrange for some period of transition from distributed agile development into live support. you can leverage the hard work of those who have gone before you and significantly increase your chances of succeeding with distributed agile development. 4 www. they can make the difference between success and failure on a distributed agile development project. CONCLUSION It should now be clear that distributed agile development has the potential to help your organization realize some powerful benefits. to travel away from home. They help establish common practices and do not allow finger-pointing when something goes wrong. distributed agile development also presents team members with opportunities to travel and to work with a new group of people on solving hard problems. Finally. As a general rule. However. Those who are having fun working together on a happy team will be willing to give the extra effort that is required to make distributed agile development succeed.

4 . Andriole. Simons. For the first year of operations of TW-India. Managing the Flow of Technology. “Be Careful Out There.” Cutter Consortium Business Technology Trends and Impacts E-Mail Advisor. 3. His most recent project used a 150-person development team distributed among London. he was based out of Bangalore and was primarily focused on how to extend the ThoughtWorks agile development approach to support offshore development. 4. he has managed large teams that are using advanced technologies to deliver strategic enterprise systems. “Offshore Outsourcing: A Tale of Two Bids. Steve. Good luck! REFERENCES 1. As you and your teams encounter and eventually overcome challenges that aren’t even addressed here.” InformIT. Simons has been involved with ThoughtWorks’s distributed agile development teams from the earliest days. NO. MIT Press. For most of the past 10 REPORT 21 ABOUT THE AUTHOR Matthew Simons is a project manager and distributed agile development advocate for ThoughtWorks. 6th ed. 21 August 2003. Mah. Simons is currently based in London. San Francisco. He can be reached at mtsimons@ thoughtworks. Bangalore. Chicago. Pearson Education. you will contribute to the art and science that is distributed agile development. Thomas J. “Internationally Agile. and you will continue to change the way we live and work. 2. and Calgary to build a point-of-sale system for a major UK retailer. 25 September 2003. He has particular expertise in adapting agile development approaches to large and/or distributed projects. Allen. 5. 15 March 2002. 1993. ©2004 CUTTER CONSORTIUM VOL.” Cutter Consortium Business Technology Trends and Impacts E-Mail Advisor. Mr. Mr. where he continues to help extend and proliferate ThoughtWorks’ distributed agile development model. can indeed be done. Matthew. Michael.

Epner Danny Ertel Ian Hayes David Herron Jonathan Hughes Wendell Jones Stuart Kliman Michael C. The team includes: • • • • • The Sourcing and Vendor Relationships Advisory Service Consulting Inhouse Workshops Mentoring Research Reports • • • • • • • • • • • • • • • • Eric Buel Bill Curtis Carole Edrich Michael J. and data that enable them to make sense of all sourcing options. relationship management. advice. negotiate contracts.About the Practice Sourcing and Vendor Relationships Practice Cutter Consortium’s Sourcing and Vendor Relationships Practice provides companies with objective information. structuring outsourcing contracts. and other essentials. plus consulting and training services. Organizations get advice on how to develop. • • • • • • • • • Agile Project Management Business Intelligence Business-IT Strategies Business Technology Trends and Impacts Enterprise Architecture IT Management Measurement and Benchmarking Strategies Risk Management and Security Sourcing and Vendor Relationships . choose an application service provider. Mah Marty McCaffrey Eugene G. create appropriate pricing schemes. real-world experience. and more. Each of these practices includes a subscription-based periodical service. Personalized consulting help is available to enable you to manage sourcing projects and relationships effectively. offering the expertise that comes from decades of handson. Zucker Other Cutter Consortium Practices Cutter Consortium aligns its products and services into the nine practice areas below. service levels. write enforceable service-level agreements. offshore outsourcing. and manage a sourcing strategy that frees up scarce and expensive resources so they can concentrate on development projects that are crucial to gaining or maintaining a competitive edge. The subscription-based component of this service addresses issues such as making the outsourcing decision. McGuire Bart Perkins William Ulrich William A. Products and Services Available from the Sourcing and Vendor Relationships Practice Senior Consultant Team Each of the individuals on the Cutter Consortium Sourcing and Vendor Relationships team is an expert in outsourcing. implement. develop and implement a metrics program.

Sign up to vote on this title
UsefulNot useful