In my previous post, I explored how offshore Agile software development offers many benefits over more traditional, Waterfall style approaches, but only if some of the obvious difficulties in communication, overheads and language issues are addressed. So how do organizations overcome those difficulties to make offshore Agile work?
Over many years at Capgemini, we have gained experience with distributed Agile projects, whether onshore or offshore, and have learned a great deal about the dynamics of Agile software development teams. Based on our experience, this article outlines a number of key recommendations for making Agile work across distributed teams.
Cultural exchange
It is highly recommended to facilitate a cultural exchange of the people involved in the project. Prior to starting any implementation, it is good practice to ensure a preliminary stage where the basics for the project, such as an overall model of the requirements, estimates, plan, and a baseline architecture are set. This is an ideal moment to have the client and everybody in the team meet face-to-face, and get acquainted. Despite the obvious costs of arranging this meeting, teams will connect much more easily and collaborate more smoothly later on in the project. This is especially beneficial for long-running Agile projects.
Facilitate continuous communication
In Agile projects, communication is key. Distributed projects need to facilitate the ability to continuously communicate. With the distance between team members involved in offshore projects, online communication methods are essential. Where possible, it is important to use phone, but preferably video conferencing for kick-offs, retrospectives and stand-up meetings. Many teams also use simple chat programs for asking questions and sharing knowledge.
Solve language issues early
Many organizations, especially in public service, rely on communication and documentation in their native language. Even code is often written in the native language. To the offshore team members these languages are new and awkward. Even with team members sent to language courses, non-native languages leave room for misinterpretation. It is vital to offshore projects, especially when using Agile approaches, to set up a workflow for translating documentation and code before coding starts. Solving language issues should even be part of the contract.
Standardize requirements
User stories are an immensely popular technique to gather requirements in Agile projects. However, as with traditional use cases, user stories can appear at different levels of granularity and suffer greatly from ambiguity. In many of our projects we therefore successfully apply smart use cases, a more standardized technique for defining requirements. By nature, smart use cases are defined at the same level of granularity, and take a much more standardized approach, facilitating easier distributed communication on individual work items.
Standardize work item workflow
At the start of iterations, many Agile projects spend a lot of time breaking down user stories into individual tasks, and on estimating the required effort in hours, with the goal of being able to negotiate the amount of work that can be handled during each iteration. Iteration kick-off workshops are costly, and even worse, require the whole team to be present. It is good practice to minimize these kick-offs. Work item breakdowns and estimates are required much less if across work items work is aligned to a standardized work item workflow – with steps such as design, coding, developer testing, testing and acceptance.
Visualize work item workflow
Once a standardized number of steps in the work item workflow are defined, the actual status of the individual work items can be visualized easily on a dashboard. Where co-located teams usually stick post-its on a whiteboard, distributed teams will need a distributed dashboard. Usually this is a website that is accessible to all team members, including the client, or aligned with bug tracking or source control tools.
Work item teams
Rather than the traditional divide between analysis and design, onshore and development, and testing offshore, there are great benefits in working in teams that consist of team members on either side of the line working jointly to implement individual work items. By operating in such work item teams, or feature teams, there is a much more implicit focus on getting the work done. Work item teams tend to be more coherent and much more motivating and stimulating.
Standardize architecture and technology
A much-heard complaint in offshore development is that “they” don’t understand the software architecture and the technology that is used. However, it is important to realize that aspects such as software architectures, frameworks, complex domains and service oriented architectures are complicated by nature, and that for any team, whether co-located or distributed, it will take time to get used to any proposed solutions.
Obtain stability
Offshore projects have a bad reputation for team instability. There are sometimes cases where members of the offshore team quit over the course of a weekend, or are replaced by new members who don’t have the required skills and knowledge. It is vital to keeps teams stable, especially in long-running projects. As working in Agile teams is experienced as much more motivating and pro-active, Agile helps to reduce team instability.
In conclusion, whether offshore Agile projects can be as successful as onshore Agile projects depends on a great number of factors in addition to the ones outlined above. But once the obvious difficulties in communication, overheads and language issues are reduced, offshore Agile projects can actually work particularly well, given a collaborative and standardized approach.
This post was also published at IDG Connect at:
Offshore Agile Software Development: A Practical Guide to Making It Work