Strategic or mission-critical application development requires developers to have more than just technical programming skills. They must also be fluent in the business context of the applications they develop, and have a working knowledge of the technical environment of the business. This makes global sourcing that much more difficult: whereas technical skills can be acquired in the classroom or from prior experience, complex business problems and esoteric technical environments are typically business-specific. As a result, they must be learned and mastered in a specific environment, and pose a challenge to global sourcing. The collaborative aspects of Agile practices - both among developers and with business partners - offer a solution to this problem. By effectively incubating high performing, globally sourced teams, Agile practices allow an organization to source IT application development not only for cost reduction, but for strategic solution development.
Time to Change
Consider a situation where a middle-office application supporting derivatives trading has matured. The application uses proprietary, company-specific components and interfaces, and is deployed in a complex server environment. It is subject to non-functional requirements, including scalability, security, and user interface guidelines. Because the application has matured, work on the application is primary maintenance or minor enhancements as opposed to major new development. Maintenance work, being less appealing than new application development, creates flight risk of the people who created the application. Suppose further that through partnership or direct ownership, an IT department can globally source application development needs. The CFO, aware of the lower cost footprint, is agitating to move the application maintenance offshore. The pressure to reduce costs as well as the desire to retain experienced employees will motivate the business and IT to move the application offshore.
Most of these offshore exercises begin by capturing as much system information as possible in a variety of different documents: use cases, technical architecture, FAQs, troubleshooting guides, and so forth. Documentation is believed to be a valuable investment because it's assumed to be a durable source of information from which a new team can find answers to questions, long after the old team is out of the picture. Unfortunately, no matter how many words are written, these efforts yield little more than low-fidelity information transfer. They provide theoretical descriptions or tactical answers. Very often they are either so abstract that they are meaningless, or so specific that they fail to provide context. In the end, all the documentation in the world will not enable working knowledge of a system by the people responsible for it.
Advertisement
Placing excessive value on documentation ignores the effort required to master situational complexity. This includes everything from navigating proprietary technical stacks specific to a company, to understanding the nuances of a business solution (particularly boundary cases), and to knowing how to certify that non-functional requirements are met. If a team isn't fluent in these different aspects of an application, it will be impossible for them to function. Above all else, team members won't know when they have all of the information they need to solve a problem. That is, if they don't understand the problem domain well enough, they won't know the questions they should ask in the first place. The lack of applied knowledge is amplified by the remoteness of a global team.
Relocating a complex application should not be an exercise in utilizing capacity, but creating capability. Developers are required to solve problems and make decisions in the ordinary course of their day-to-day work. To do this effectively they require a working knowledge of the application, the business domain, and the technical environment. They will not get this from studying code and documentation with some training and walkthrough activities. Indeed, a team poorly prepared to solve problems is forever dependent on other people to tell it what to do. This, then, is the problem that the IT organization must solve: even if there are pressures to transition an application, the IT organization is still expected to support it. To minimize risk, an organization must be very thorough in managing this change.
Hi-Fidelity Knowledge Transfer
Agile concepts and practices uniquely enable capability development because they provide for hi-fidelity knowledge transfer. The practices presented here allow a team to effectively transition responsibility for a complex application to a new team. The net result of executing these practices is not simply the transfer of application ownership, but the development of strategic capability.
Effective transfer starts by co-locating the current and new teams for a defined period of time. Having people work in the same physical location overcomes all kinds of communication barriers. It enables spontaneous conversation and allows people to glean information from the "ambient noise" produced by a project team. This involves more than just co-locating developers: it requires cross-functional roles including analysts, developers, and QA staff sharing the same physical space. This gives a new team first hand visibility and participation in the full end-to-end cycle required to deliver a solution in the corporate environment. When cross-functional teams include business participation, a new team has the added benefit of direct and frequent exposure to the language of the business.
Co-locating people doesn't guarantee that they will work together. The current team may simply task the new team in menial tasks that do little to build familiarity, or give them documentation to read. People in a co-located team should work in pairs so that the new team not only immerses, but "learns by doing" with constant feedback from experienced practitioners. Pairing is not one person shadowing another, such as an experienced person keying away at code while another simply watches. Pairing is two people actively discussing a same problem, trading off control of a single mouse and keyboard as they work. This gives a new person first-hand experience with the application itself under the direction of somebody fluent in the business and technical environments.
When transferring ownership of an application, Agile project management practices bring a dual benefit: they make the work people are doing visible and they expose the progress of knowledge transfer. An iterative development cycle that includes a regular planning meeting and a daily stand-up meeting exposes everyone's tasks to every member of the team. This gives members of the new team direct visibility into full scope of activities that are needed to maintain an application. These meetings expose the extent to which each member of the new team is executing important tasks and speaking confidently in the language of the business domain. This enables effective governance that the transition is being fulfilled successfully. A final component of Agile project management is the regular execution of retrospectives: bringing the team together to ask what is working well, poorly, and needs to change. This brings a cycle of continuous improvement to the knowledge transfer effort, so that failures can be corrected by the team itself.
When the emphasis is simply to "put global capacity to work," a new team will simply be tasked with things to do. Team members will not necessarily understand why they are doing these things. This might enable them to fix bugs in code, but it does little to enable them to take informed decisions. The goal-oriented nature of Agile Stories - simple, valuable, complete statements of functionality - provides a clear purpose for everything done by a development team. This provides essential business context for every technical task performed. This goal orientation is a critical enabler for developing capability: capacity works to tasks defined by somebody else, whereas capability solves problems.
Finally, for a team to be high-capability, it must be able to deliver work to a state of completion. This is driven by practicing continuous integration. That is, work isn't considered done when it is "code complete," but only when it is demonstrably ready for deployment: when it has high unit test coverage, builds, and is subjected to iterative QA that certifies the code. Continuous integration means that developers don't get "false positives" of success. They know quickly whether code they commit works or not. They also learn what is necessary to bring code to completion, essential in a complex environment.
Executing Transition
Transferring an application is an intangible business goal: while there may be a defined cost benefit, assessing the success of the transfer is difficult. Keep the following in mind when engaging in a transition initiative:
Tasking new people "to learn" will result in a lot of idle time, misguided effort, and wasted productivity. Use a defined development project, such as the addition of major new application functionality, to transition ownership of an application. Knowledge transfer is a byproduct of following these practices in the context of a project initiative.
While it may seem a straightforward process - co-locate, pair, execute iterative development, and so forth - doing these things will be difficult for people who have not done them before. Do not trivialize the difficulty and discipline involved with these practices. Consider engaging outside facilitation in relevant roles - project managers, analysts, developers, and QA - responsible for leading the transfer. While the rest of the team is focused on delivery, outsiders will be focused on the goal of transferring the application.
Highly-capable IT is driven by highly-capable people. All the process in the world won't overcome a team lacking in talent, skill and aptitude. This process works well with highly-capable IT professionals in the current and target teams. Screen the competence of the target team thoroughly, and be selective about the people hired or contracted.
Building Capability Versus Sourcing Capacity
Practices such as co-location and pairing may seem a high price of admission for global sourcing, especially when cost is the motivator. However, consider the cost of investing in capability development versus the risk of application failure: for the business, application failure is the far more expensive alternative. Inadequately transferring an application leads to asset decay and production defects that interrupt business and impair operations. This ultimately erodes corporate competitiveness. Application development capacity, then, has no strategic value to the business. To maintain competitiveness, global IT must be a capability and not simply capacity.
About the Author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement. He is a frequent speaker and active blogger on topics of Agile management, governance and innovation. He is currently a Client Principal with ThoughtWorks.
Articles 
Strategic or mission-critical application development requires developers to have more than just technical programming skills. They must also be fluent in the business context of the applications they develop, and have a working knowledge of the technical environment of the business. This makes global sourcing that much more difficult: whereas technical skills can be acquired in the classroom or from prior experience, complex business problems and esoteric technical environments are typically business-specific. As a result, they must be learned and mastered in a specific environment, and pose a challenge to global sourcing. The collaborative aspects of Agile practices - both among developers and with business partners - offer a solution to this problem. By effectively incubating high performing, globally sourced teams, Agile practices allow an organization to source IT application development not only for cost reduction, but for strategic solution development.
