Operational Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The Operations perspective

Some companies inherit a globally distributed development initiative or organization. This may be for instance through M&A activity. Many companies on the other hand are compelled by business conditions to use geographically distributed teams. For these companies, a key question that arises is whether to invest in a captive facility or partner with a vendor for services.

While making this decision, you should consider the following factors, since they could have long-term business implications:

• Location or country and its legal business framework
• Upfront investment in a captive set-up versus working capital for vendor relationships
• Extent of direct control required, which is typically higher in an self-owned facility
• Management bandwidth available to manage the remote location
• Exit strategy and costs in case of a captive facility

Our experience shows us that on average the minimum team size in a remote geographic location should be 50 people for a captive center to have a shot at being successful.

Regardless of whether one goes the captive route or the outsourced route, the distance and time that separate members of a distributed team tend to magnify the effects of everyday challenges to successful projects.

One of the key challenges is what work to hand off and how to hand off that work to the remote location. We’ve learnt that it is important to partition the work so that at least some level of local collaboration and face-to-face can occur, e.g. individual modules being developed by dispersed teams. That said it is important to communicate frequently and regularly. The frequency and intensity of communication across locations can be increased by using a mix of formal and informal communication channels; e.g. using interactive mediums such as IM to create a feeling of connectedness between individuals. Not only does this break down barriers, and foster a one-team feeling, it also leads to a better grasp of the “larger picture” across dispersed teams.

Another very effective tool for motivating individuals and fostering a collaborative spirit across teams is to reward and more crucially recognize achievement. When the context of the distributed development initiative is understood across locations, recognizing achievement and excellence builds awareness and credibility across teams. This in turn leads teams to trust that other team-members are working toward a shared goal and carrying their weight.

Within this collaborative environment, it is also vital to have standard process to perform common tasks, so work across teams can be coordinated effectively. For instance, developing and sharing standard processes for tasks such as application builds, unit testing, release management, software deployment etc. across teams. Here collaborative infrastructure assets would play a critical role, e.g. a wiki or a project portal, to which this information could be published.

A major benefit of adopting and following standardized processes and methodologies is that all team members understand the plan, their role in the plan, and how they affect others in the plan. Many collaborative tools provide some workflow framework, helping teams structure tasks and understand where they are in the development process. Key here is to have rapid feedback cycles to minimize costs. Agile practices and rapid release cycles increase this feedback, and also tend to overcome the command and control-mindset that seem to pervade certain distributed efforts.

A word of caution here. If you are planning to adopt a methodology, internalize it well within the local organization before extending it globally. For instance, if you intend to use global agile, you need to be first agile in your co-located team. You will need to build your expertise and find the sweet spots in your own process before extending it externally. Then you can test the waters in distributed development by identifying pilot projects that would give the most bang for the buck and thereby impress senior management. That’s where the virtuous cycle starts, success feeds on success and you get buy in from senior management and business heads for engagements with greater scope and duration.

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.

Infrastructure Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The Infrastructure perspective

Many organizations have a tendency of just picking up a project and jumping into distributed development, without adequately considering the fundamental framework, building blocks, and logistics, and more importantly the change in mindset needed for this shift in development process. All these need careful planning and organizing. Without enabling technologies for communication or collaboration, frameworks for project tracking, visibility, or transitions, and an appropriate engineering infrastructure, the very objective of having seamless cross-location operations will be defeated.

The greatest challenge of distributed development is ensuring that high-quality, flexible code is delivered promptly and predictably—regardless of obstacles such as communication barriers, different development environments, and distributed team structure potentially in different time zones. These challenges can be made easier by enabling the three critical components of infrastructure required for successful distributed development or the 3 C’s:

• Communication
• Computing
• Collaboration

These components need to be built out to ensure that distributed teams can work as one team throughout the lifecycle of a project, regardless of their location. Also, putting these in place is a job in itself, and should be built into the initial planning stage of any dispersed project.

The first is Communication: While electronic communication is a poor substitute for face-to-face meetings, a good communication infrastructure ensures continuous, unlimited, and bidirectional communication. Telephone, video, email and chat tools contribute to a mix of formal/informal communication channels. For instance, at Silicus we use a mix of communication channels, including Voice-over IP, videoconferencing and virtual meetings or net meetings. Also, we’ve found that using tools such as Skype, with photographs of individual team-members on their profile can reinforce the one-team concept by reducing the anonymity and sense of distance that plagues geographically dispersed teams. While it doesn’t replace the “Hey Joe” environment of a centrally located team, it goes a long way in fostering an informal channel of communication between developers across geographies. Also, it functions as an important supplement to the formal Manager to Manger communication between locations, and prevents disconnects between the teams at various levels because it facilitates transfer of information.

The second factor that can make or break a distributed engineering initiative is uniformity in computing infrastructure. Multiplicity in terms of operating environments, tools, and a fragmented network can lead to compatibility issues, difficulties in managing code bases, and can lead to transitioning problems. Managing infrastructure itself can become a focal activity in such cases, overshadowing the main motive of distributed development. To ensure that work across the geographies is aligned, it is important to also align the tools and computing environment that are used to produce this work. For instance, good practice is to ensure that every location is using the same set of tools and versions. VMware infrastructure can play an important role in compressing software development cycles. It allows the creation of a centralized pool of IT assets (e.g. virtualized servers, storage and networking equipment) and, using LabManager, enables teams to rapidly setup and tear down complex, multi-machine configurations for use in testing and development. Also, configurations can be moved seamlessly to and from remote location.  This results in lowers communications costs, and enhances the efficiency and productivity of distributed teams by allowing defects to be detected early and fixed early in the development lifecycle.

The third critical component is collaboration infrastructure. In highly distributed development teams, the ability to collaborate with people across space and time is very compelling. For example at Silicus, we establish point to point VPNs as the foundation for collaboration across locations. It’s important to keep in mind that distributed development requires a variety of additional activities as compared to single-site projects: these relate to the division of tasks, sharing of artifacts, coordination of handoffs, and integration of components. So, you have to invest in creating collaborative capabilities, and developing a technology platform to improve the coordination of work. You can use proprietary tools to develop this platform, or use FOSS - Free and Open Source Software. Some FOSS tools we have found to be very useful are FocalPoint for release and iteration planning; CVS/Subversion for Source Code Control, Eclipse as an Integrated Development Environment, Ant/Cruise Control for Build automation; Bugzilla for defect and enhancement request tracking; Testopia for Test plan Management; Emma for code coverage analysis; TestNG as a unit testing framework and for UI Test automation; JMeter for load testing; and Twiki, KnowledgeTree for knowledge and document management.

The goal is to promote a long-term view of the development assets needed for effective collaboration, and to leverage this collaboration infrastructure across multiple projects over time. It is recognition of the fact that the same forces that have fostered the use of distributed teams are also yielding new ways to keep team members in touch and involved with team activities, and also allow them to maintain a sense of importance and ownership in the work being performed. By utilizing available tools and keeping alive the spirit of teamwork, distributed development teams can be as successful as the centrally located teams of the past.

About the Author

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.

People Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The people perspective

Being an outsourced software development services company, we serve our clients globally from our development center in Pune, India. In our partnerships with leading software companies over the last 8 years, we’ve assimilated experiences of building distributed development teams.

From our experience, the issues managers face while adopting a distributed product engineering strategy span three broad areas:

• People
• Infrastructure
• Operations: both startup and ongoing

 I’ll dig deeper into each of these in subsequent posts, and start here with people:

People are the bedrock of an execution plan. In a rapidly changing environment, the importance of people or “knowledge workers” has come sharply into focus. While labor arbitrage was a primary driver for distributing development across several low-cost locations, there is increasing realization that lower costs are only one piece of the puzzle. Talent is global, and smart firms are reorganizing themselves to tap into this global pool.

The essential challenge of distributed development is to transfer complex knowledge about products or processes, held in the heads of a group of people in one location, into the heads of a group of people at another location. We’ve seen that a higher intensity of interactions between individuals is more critical than comprehensive documentation or elaborate processes and time-consuming tools, especially if requirements are rapidly evolving

So, the people perspective for distributed development is about practices that enable and ensure communication and interactions across locations. By selecting the right people and instilling a culture that facilitates communication we can not only achieve superior productivity but also ensure that we retain these teams on a sustainable basis. So, how does one achieve that?

For starters, by priming the existing team for an imminent cultural shift. If your organization currently does not leverage agile practices, then it would be important to instill these practices as also build processes and infrastructure that can be extended to a distributed team in the future.

What is important is to envision an effective team structure and a communication plan, within which specific roles in distributed locations are incented to encourage communication. Some roles, more than others, play a critical role in not only facilitating the transition to the new paradigm but also supporting it on an on-going basis. The project manager is a key promoter of the one-team concept. Business analysts who serve as proxy customers can ensure functionality is understood clearly and well in time. Onsite liaisons from the distant location also serve as key contributors to a successful transition. Depending on the team-size, the onsite liaison should be capable of serving as the project manager, business analyst, and proxy customer all rolled into one. Once this team structure is envisioned, it is important to communicate the anticipated change in roles, emphasizing the interaction mechanisms with the distant team.

Hiring team members at a distant location typically involves working with a vendor organization or your own captive operation. Either way, multiple organizations are involved, bringing with them potential cultural, language and time zone issues. Participation in the hiring process can ensure the right team members come on board. For example at Silicus we work with our customers to put their team together in what we call a Hired-to-Order exercise. On its own, our HR department is fully capable of staffing the engagement with the best and brightest, but we involve our customers in selecting team members based on specific requirements like skills, domain knowledge, experience, etc. The selection process is essentially a joint exercise between the project manager and the offsite HR person. During this process, the Project Manager can either be present physically at the distant location or be available via video conferencing for the interview sessions.

While pre-selecting candidates, we place as much importance on soft skills as their technical ability. People with experience living in or working with other cultures, or who have traveled outside their home country are more open to forming relationships across cultural boundaries. Hence we’ve found them to be more effective in communication. Additionally, people with familiarity with our customer’s software vertical or domain are able to jumpstart the learning curve and act as mentors to other team members. If you are setting up a remote location as part of an outsourcing relationship with a vendor, ensure that the vendor is well versed with agile practices and the team members you are hiring also have past experience in agile development.

Ok – so now we have distributed teams that are ready to engage as a single team, even if they are in different locations. But is this sufficient to achieve success? To further nurture the one-team culture, we exercise best practices that continue to cement relationships – both people-to-people as well as people to organization.

Many organizations have grown from small close-knit teams. Such organizations do not have the mindset of having staff members travelling or working off-site. Often these organizations could also be sensitive about sending critical data or source code off-site. Providing access to team members who are offsite entails putting security measures in place. We will discuss this aspect in a subsequent webinar on infrastructure best practices. Also, even after putting security measures in place, management and senior team members are distrustful. And then, some employees may perceive a team at a distant location as a threat to their positions – especially if the distant location is a low-cost development center.

These issues can be addressed by building practices that emphasize a one-team concept. Having a “seeding” visit before diving into the distributed development initiative is a good way to start.  A seeding visit occurs the first time people from the off-site team visit the local site or vice versa. The first seeding visit should usually occur when team members from either location meet face-to-face to help articulate the general vision for the combined teams in terms of roles, responsibilities, communication practices as well as day-to-day operational practices. Collaborating in this fashion leads to a shared vision between the distributed teams. Subsequently, regular maintenance visits or visits by team (goodwill) ambassadors who dedicate time at the offsite location for a period of time can build and sustain the one-team structure.

Encouraging the teams to participate more in product strategy and roadmap discussions ensures that your off-site team is dedicated to customer commitments and has a common understanding of your vision and approach for execution. Most often, remote teams are not viewed as a strategic part of your organization’s assets, giving them no incentive to remain passionate about developing your product. This stems mainly from the mindset that the remote team is part of the offshore (or a vendor’s) organization, whose job is only to carry out instructions and tasks – a command and control mindset. To get a remote team to deliver, especially for time-sensitive deliverables, team members get involved early in the process and are considered integral to the successful delivery of the code – not just as workhorses for cranking out a section of the code.

Finally, there are cultural exchange programs that can greatly impact the success or failure of distributed development. Occasional cultural programs, which aim to get the teams better acquainted with the other’s culture and way of life, go a long way in ensuring cross team integration. The HR manager could take the lead in drawing up a calendar of such events, especially if they include non-work activities that also introduce aspects of the other culture. A short game of baseball or cricket during maintenance visits is not only fun; it also presents the opportunity to glean insights into another’s culture.

So, if you haven’t already done so to build the next generation of your product engineering team, we believe it is time to start scouring the globe for talent! Remember that the benefits are no longer limited to large organizations alone.

About the Author

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.