|
Today's world of globally distributed software development presents lots of challenges—but offers great opportunity.
July 02, 2007
URL:http://www.drdobbs.com/embedded-systems/globally-distributed-development/200001947
Khurram is responsible for worldwide enablement of the IBM Rational team software tools.
I recall the days when everyone came to one place to work on software development projects. Today, it's not uncommon for teams to work together on entire projects and never meet face-to-face. But while globalization has reduced the frequent-flyer balance of today's developers, it hasn't reduced the risk and complexity involved in successful project delivery.
Nor has the lure of global development and delivery (GDD) gone unnoticed by management. Organizations in every market are using GDD as a competitive variable. Although most IT organizations know what benefits to expect from GDD, they usually are less sure about how to achieve them. Still, that hasn't affected the speed of GDD adoption. Frequently, business demands force IT organizations to take on GDD before they can establish strategies and platforms for success. And as the train leaves the station and the scope and scale of GDD efforts increase, so does the occurrence of failure. This pattern continues until frustration results in organizations concluding that GDD is more trouble than it's worth.
GDD is neither simple nor natural. Software development has always been a team sport. If you separate a project team by geography and organization, you increase the complexity involved in achieving successful outcomes. Yet global flexibility is the core foundation for achieving advantages in cost, time, and quality. To be successful in GDD, you must protect the team aspect of software development.
The foundation for maintaining team cohesion in GDD is a global process framework that provides the orchestration necessary to ensure that global teams sing in tune together. A process framework provides GDD projects with team cohesion and direction without sacrificing the flexibility necessary for agile development. Instead of forcing GDD teams to adopt a single, "common" process for all projects, it provides teams with the ability to adopt methods and best practices that are visible, practical, and governed. The platform ties global teams together and reduces the risk of failure as global development initiatives become more complex. With a global process framework, you can easily codify lessons learned and achieve continuous global process improvement.
But process is of little value without the ability to institute it. In globally/organizationally distributed teams, GDD platforms become a fundamental instrument for success. The platform should be capable of uniting global development teams with process. It must be capable of providing them with the ability to work locally while they collaborate globally. In global development, the natural communication between development team members is greatly diminished. This can introduce gaps in communication and understanding. A platform that keeps the work of the global team connected and available "in context" across the lifecycle can reduce the risk of these gaps turning into misinterpretations.
Tacit and informal communication and collaboration on software projects form the bonds for strong team cohesion. This lets local development teams informally self-correct and self-direct their collaboration, communication, and coordination methods. It's not unusual in these teams for process to be perceived as something that makes life difficult, and more burdensome than beneficial. However, process is essential in directing GDD teams because a great deal of active and informal collaboration is lost in the divides between distributed project teams. Process becomes the bridge between GDD teams and provides the direction and orchestration necessary to ensure successful project delivery. Communication and collaboration that normally wouldn't have been formally defined or captured is necessary to reduce the risk of misinterpretation. The value of a process framework increases significantly as the number of teams and organizations involved in GDD grows. That's because a framework still provides GDD projects with the flexibility to select the right methods and process, while providing organizations with the ability to measure, improve, or retire methods and processes appropriately.
It is important to remember that although the analogy of manufacturing has been often related to software development, they are different. When organizations embark in GDD, they shouldn't treat service providers or auxiliary teams as "software factories." Innovative software development requires creative freedom. A focus on "just enough" process is essential for GDD teams to stay creative and innovative. Process shouldn't be so formalized that creative freedom is lost. A global delivery process should focus on what activities need to be performed and who should perform them, but should provide creative freedom between teams on how the activities are completed, so long as the lines of communication remain open and understood by all parties involved.
For example, in defining and implementing a software specification, there is a tendency to believe that the more detailed and precise the specification is, the better the expected results from offshore teams. However, in practice, wasting collaboration and communication time between distributed teams on the clarification of unnecessary implementation specifics and style contribute little to meeting the requirements of the end product. Implementation style is difficult to direct across GDD teams. Agreeing and incorporating common and understood best practices across GDD teams is the best way to establish cohesion on implementation style. Global methods and process should focus a team's energy on managing and communicating the architecture and requirements. It shouldn't waste time defining the step-by-step directions for how distributed team members should do their jobs.
In GDD, a "my way or the highway" attitude to development is rarely effective. Your process framework must enable GDD teams to work as they naturally do. One approach is to first establish a development methodology that your global process framework advocates. To make your framework as versatile, understood, and applicable as possible, it should focus on providing methods that use common industry best practices. You should also include methodology, process, and adoption of best practices as a part of your services procurement selection criteria.
Process engineering and customization has traditionally been a labor-intensive activity with less than stellar practical application. However, the advent of process frameworks and the platforms that automate and enable them can provide GDD teams with the support necessary for successful application. The Eclipse Process Framework (EPF) project (www.eclipse.org/epf) is one process framework definition that provides this facility. To demonstrate the framework, the project includes an exemplar tool (the Eclipse Process Framework Composer) and process content (Open Unified Process/Basic Unified Process). IBM Rational (the company I work for) provides a commercial implementation of EPF with IBM Rational Method Composer (www-306.ibm.com/software/awdtools/rmc), which includes the IBM Rational Unified Process. Microsoft provides its Microsoft Solutions Framework (www.microsoft.com/technet/solutionaccelerators/msf), which is aligned with Visual Studio Team System.
Although global process frameworks provide teams with the right direction, they fall short in helping with the day-to-day challenges involved in delivery. Gaps in communication, coordination, and synchronization are a natural consequence of GDD and your goal is to minimize these gaps. The GDD platform available to you can make a significant difference in the risk, overhead, and level of complexity involved in dealing with these gaps.
It's important to recognize the overhead and risks introduced in GDD early, and establish an effective strategy and platform to address them before you get too deep. If you don't provide a platform for GDD, project teams will find tactical and "best fit" project solutions as they deal with the complexities of delivery. These "best fit" solutions are usually reinvented on a project-by-project (or project manager-by-project manager) basis. As the scope and scale of GDD initiatives increase, project managers and technical architects will find that they have a harder time finding "best fit" project solutions that provide success with confidence. The net effect is that the risk of success for GDD increases as does the overhead required for managing it.
This isn't a call to establish a platform that contains more than you need before you get started with GDD. What it means is that you should establish a GDD platform for your organization that aligns with your GDD plans and future IT strategy early in your adoption. Your GDD platform should provide the organization with unified support and the ability to selectively adapt with the varying needs of your GDD projects.
The need for lifecycle visibility and collaboration increases significantly with GDD. A common approach for GDD projects is to functionally divide work so that distributed teams can complete their activities individually. For example, a company may do all of its analysis, design, and release management in the U.S., while working with teams in India for development and testing. Although their work has been divided functionally, it is still critically interdependent. Since real-time collaboration between these distributed teams is limited, they frequently have to collaborate passively with each other. This involves accessing and leveraging the related work and activities of their peers in an agreed upon manner within the context of their work activity. Coordination, synchronization, and communication become critical because any questions or answers that can't be resolved independently result in delays or "best guess" answers for work to proceed. When an effective GDD platform is not instituted, GDD project members must figure out how to maintain coordination, synchronization, and communication themselves. On these projects, delays and rework are frequently encountered enemies as well as greater complexity and overhead.
It is important to remember that distributed teams that are not a part of the project owner's organization need equal or greater access and support to the GDD platform. Offshore teams commonly don't have the benefit of actively participating in the highly collaborative requirements, analysis, and design activities. Therefore, they have a greater reliance on the GDD platform as a means for communication. The GDD platform must also be effectively utilized by stakeholders involved in analysis, design, and other collaborative disciplines and activities. Frequently, teams that perform these activities will use informal channels of collaboration and communication outside of the GDD platform, excluding distributed teams from the interaction. There may be a belief that the interaction or story can be "retold" in the form of specifications, models, and the like. While important for keeping teams focused on project goals, these are not replacements for the context provided by direct observance and participation.
Commercial examples of GDD platforms include the IBM Rational Software Delivery Platform (www.ibm.com/developerworks/platform) and Microsoft's Visual Studio Team System (msdn2.microsoft.com/en-us/teamsystem). Along with others, these are transforming into "collaborative development environments" and are poised to revolutionize today's GDD platforms. IBM Rational's Jazz project (www.jazz.net) is one example. Organizations may also consider implementing a multi-vendor global development platform by selecting best-of-breed tools and technologies for software disciplines and leveraging their integration support. However, it is important to select a platform that tightly couples the software development activities and work products of your GDD team across the lifecycle while providing the flexibility and support to free your team members to work as they normally do.
Ultimately, the best GDD platform improves the cohesiveness of your GDD project teams from beginning to end and makes working globally and organizationally distributed as close as possible to working locally as a single unit.
An effective GDD metrics and measurement strategy reduces organizational and political noise and keeps distributed teams focused on project goals. It is naive to believe that challenges in GDD are limited to technology and process. When multiple cultures, organizations, and disciplines are involved, the political climate can blur and distract GDD project teams. To minimize this, organizations should encourage a spirit of transparency on GDD projects as much as possible. One method of implementing transparency is to provide all GDD team members with access to reports on global project progress, normally reserved only for project owners and project managers. The best metrics to encourage teaming for project success require the mutual cooperation of all globally and organizationally distributed project teams. For example, you may hold everyone responsible for the overall change request turnaround time from submission to implementation and release. It is somewhat ironic that this metric is often used to measure a project manager's effectiveness when the metric is clearly far more influenced by the efforts of the GDD team. GDD metrics should encourage a spirit and understanding that everyone succeeds or fails as a whole.
Whenever you indicate that you are going to measure something or someone, the next question is how you will do it. Remember that a measurement and metrics strategy is only effective and credible if it can be implemented and governed. Your GDD platform should enable the organization to effectively implement and govern measurements and metrics.
A GDD metrics and measurement approach can also benefit procurement of software services. Today, contracting and outsourcing are normal components of software development projects. This has increased the competitive climate in global procurement of software development services and has provided organizations with multiple choices. Many organizations are taking advantage of this flexibility and are using multiple service providers by "multisourcing." Unfortunately, the evaluation criterion used by most organizations to determine the best service providers for a job is still mostly subjective. This increases the risk of failure because it's hard to know which service provider will deliver the best service for a planned project. With an effective measurement strategy, organizations can select the best service provider for the job based on qualitative data. This approach can also help organizations manage their partner ecosystem through natural selection. Ultimately, it reduces the risk of globally distributed development through better predictability and measurable results because it encourages service providers to align with the goals of the contracting organization. In turn, service providers are rewarded with future contracts and long-term relationships. It also has the potential of reducing vendor management costs by providing organizations with a framework for managing the performance of service contracts.
Your GDD platform is fundamental for instituting your metrics and measurement approach with as little pain and overhead as possible. Many tools that support GDD teams also provide measurement and reporting, but are usually limited to their specific domain. It's important to ensure that your platform can provide holistic measurement and reporting as well as the governance necessary to ensure the integrity of your measurements. IBM Rational Project Console and IBM Rational Portfolio Manager (www-306.ibm.com/software/awdtools/portfolio) both provide comprehensive global lifecycle measurements and reporting that is tightly coupled with the IBM Rational Software Delivery Platform (www.ibm.com/developerworks/platform). Microsoft also has project management tools that can provide ALM reporting as a part of Visual Studio Team System.
Globalization continues to erase boundaries for business and IT with no signs of slowing, and the resulting opportunities are hard for anyone to resist. With the right global process framework, platform, and measurements, you can ensure that your IT organization won't be stuck at home.
|
Challenges of Distributed Development
by Steffan Surdek
Haven't all project managers dreamt of having developers working on their projects around the clock? For some reason, individual developers just aren't willing to do this. But with distributed development, this dream can become a reality. With distributed development teams, depending on how development is spread around the world, coding can go on almost around the clock. But because of the time differences among the countries involved, effective communication among the teams is a big challenge. Communicating through e-mail works to a degree, but there is always a lag in the response time. You need to schedule conference calls either early in the morning or late at night for all teams to be available at the same time. The lag is also reflected when you find a last-minute defect that absolutely has to go out immediately. If your team is geographically dispersed, you might not get a fix or even a response until the next day, which might have a very negative impact on a release.
Communication is one of the biggest challenges faced by distributed development teams. This problem has many different faces such as linguistic difficulties, collaboration among the teams, and issues related to different cultures. Some of these issues are easier to address than others. Linguistic challenges appear in several forms. At one extreme is a situation where some or all members of a remote team simply do not speak the same language as you. You need to ensure that the common terms used in the project are understood by both sides. Use this as your basic common vocabulary and work your way up from there. You must also validate that team members understand each other. A good technique is to repeat back what a team member has said to you in your own words to validate that your comprehension is correct.
Team collaboration is critical, and teams working in different locations require common source code repositories, requirements repositories, and defect-tracking tools. Collaboration mechanisms such as web- or online-data-conferencing tools can help the various teams share screens or work with a shared whiteboard in meetings. Instant messaging tools also help the teams collaborate and communicate better. You need to ensure that information flows among the teams and that all teams evolve to collaborate fully. Be wary of team members who try to make another team look bad. My favorite example of building teams that are equals revolves around code reviews. In these situations, the main or more experienced team (especially at the start) may feel they need to review everything a newer team does. But moving forward, you must involve people from the remote teams in the code reviews of the main team. This brings two important benefits:
You need to understand cultural differences and find compromises when required to keep the project running properly. You also need to be able to distinguish cultural differences from bad habits. The bad habits (such as not sharing, not doing code reviews, bad coding practices) need to be discouraged and weeded out as you go. One of the biggest challenges in regards to cultural differences is the unwillingness of certain team members to say they do not understand what you are saying because it is not appropriate to do so in their culture. The primary symptom of this is when one of the teams simply says "yes" to everything you say without challenging anything or asking questions. Then, they go off and do what they think is required. You usually only know at the end of the cycle that they've gone their own way and implemented the wrong thing. There are two ways to prevent this situation:
To be successful in your distributed development project, you need to have well-defined processes in place. These processes range from requirements gathering and coding standards to code reviews, defect tracking, and defect processing. You need to ensure that all team members follow the same process. Leaders must reinforce these processes and take the initiative of confronting team members when the processes aren't followed. Set the quality bar where you need it to be and ensure people are reaching that bar. Performing design reviews before coding starts is also critical. By performing checkpoints early in the process, you ensure that you get what you really need.
Distributed development teams can be really powerful, but to be successful, you need to see the big picture. Distributed development is really multiple teams working as one. DDJ
Steffan is a senior software developer, project manager, and G11N coordinator for the IBM Rational Portfolio Manager core development team. The opinions expressed in this article are those of the author and not necessarily those of IBM Canada Ltd. or IBM Corporation. |
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.