Global Measurements
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.
Conclusion
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. |
