Real life is about compromise
Designing an effective IT product delivery capability is a complex problem involving compromise. It will never match up to the perfect world described in the training course or the management book. The system you end up with is the result of multiple conscious or unconscious compromises, evaluated on the basis of benefits or drawbacks weighed up against the cost and difficultly of not compromising. One such compromise is the decision to surrender the ease of communication and collaboration that comes with co-located teams. Some examples of trade-offs we’ve seen from our clients in this scenario include the following:
Benefits
- Reduced operational costs.
- Proximity to customers or internal business units.
- Access to a wider range of people and specialist skills.
- Time zones allowing “follow the sun” support.
Drawbacks
- Loss of spontaneous face-to-face communication.
- Distance to customers or internal business units.
- Time zones reducing time for whole-team collaboration.
- Meaning can be lost when discussing requirements.
Difficulties and Costs in avoiding the need to compromise
- Teams are already in place and would be highly disruptive to move.
- Space is running out at the main site, putting pressure on desks.
Compromise is only effective with accountability
Crucial to making remote teams working effectively is to consider the whole picture and avoid optimising isolated parts of the system. We’ve learned from our work with Scrum that having a product owner with both the autonomy and the accountability to make decisions leads to the best overall outcomes. When making decisions about an organisation’s software delivery capability, the best outcomes are likely to arise when decision making and accountability are not split across functions such as engineering, QA, facilities, and product management. The risk is that each specialism optimises their output: providing the required headcount in development; the most cost-effective office space; leaving product management constrained in optimising delivery. We’ve seen product managers unable to procure high quality video conferencing equipment as it would exceed the facilities budget; hiring decisions and team composition optimised to make line management easier; and many other examples where simplifying the reporting lines would lead to more cognisant compromise.
How to make it work
In practice, the following three simple steps represent the work required to achieve high performing offshore development teams:
Presented as a hierarchy to highlight that unless the fundamentals are in place, processes and tools are unlikely to be effective.
1. Invest in people
During a recent trip to Hyderabad in India we had the pleasure of working with a highly effective and disciplined software engineering department. An enviable characteristic was their staff retention: the office spaces were decorated with numerous five- and ten-year long service certificates, which matched the sense that people were happy to be there. Digging deeper, we found:
- A programme of regular technical and non-technical training
- A strong social element supported by company events
- Effective technical and people leadership by senior staff on-site
By investing in this development office as a long-term strategic capability, this organisation developed an asset of significant value.
When deciding upon how your development capability should be realised, think about how the people doing the work will become engaged and committed to your organisation. A significant advantage in geographically distributed teams is that you are no longer constrained to the skills available within commuting distance of your office. Investing in people starts with attracting the right people, and then setting up a working environment that allows them to thrive and want to stay. Consider which of the typical models might work best in response to your particular set of challenges and constraints:
- Home or remote workers
- Virtual teams distributed across multiple sites
- Individuals, teams or functions provided by a vendor or consultancy
- Partial offshore development teams staffed by full-time employees
- Complete offshore development teams including all skills and product leadership
Each of these models has benefits and challenges – consider these as part of the whole picture.
2. Establish Purpose
Teams are more productive when they understand the business context of the task at hand. It is obvious when working with engineers that care about the product they are building, through their interactions with the business, the quality of their work, and their ability to overcome problems. Teams that are simply given requirements to “code up” tend to be the same teams that spend a lot of time re-working features and fixing bugs.
This effect is amplified when communication and visibility are made more distant. Remote teams with a sense of purpose will seek out and eliminate sources of ambiguity, whereas remote teams that are disconnected from the business risk becoming increasingly isolated and mistrusted. Decide for yourself which feedback loop will lead to the most effective delivery capability for your business:
Establishing a sense of purpose should be led by product management in whatever form that takes in your organisation. Establishing a vision and communicating it to the team is a great first step. A sense of purpose is kept fresh through regular updates on changing market conditions, competitor activity, and the impact new features have had with customers or users.
3. Experiment with processes and tools
There is no standard package that allows effective collaboration across time zones and locations. The only way to find the best available set of processes and tools to support your particular set of people, products and challenges is to experiment. Here are some of the immediate challenges to deal with and some of the tools that we’ve had success with:
Talking to each other
Google Hangout, Apple FaceTime, Skype are free services allowing video conferencing between two or more computers. We’ve observed laptops using these services being used to conduct daily scrum or stand-up events with varying degrees of success. Pitfalls to watch out for include low bandwidth, wasted time setting up calls, people forgetting to talk to individuals. All of these services have the facility to share screens, allowing planning tools or other artefacts to be worked on remotely.
Cisco teleconferencing seems to be the established market leader in hardware based video conferencing. It provides the best experience we’ve observed for group-to-group scenarios in meeting rooms. The setup costs are likely to be of similar magnitude to funding one medium development team for 2 weeks. Other drawbacks include a lack of portability compared with a laptop, and the likelihood of contention over this limited resource.
Slack is a modern chat application with a number of features designed to allow remote collaboration, some of which are free and others requiring a subscription. Some teams love it, others find it distracting.
Managing work and storing requirements
Trello is a free, lightweight tool allowing teams to collaborate around lists of things to do. Very easy to set up and use with no technical knowledge or training, but has no forecasting functionality.
LeanKit is a subscription-based work tracking system built with lean and Kanban processes in mind. It is simple to use but provides many features for planning, forecasting and capacity reporting.
Jira and TFS are subscription-based work tracking systems that support agile ways of working and are the most commonly used among our clients. The advice we most frequently offer in both cases is: keep it simple, and don’t waste valuable time creating complex custom workflows.
Collaborating effectively
Behaviour Driven Development (BDD) is a way for technical and non-technical people to speak a common language when deciding what to build. This technique is at the heart of our training course for effective distributed teams.
Online Whiteboards such as Miro can enhance collaboration by providing a visual stimulus during discussions on planning, design, analysis or retrospectives.
Three Simple Steps for distributed teams?
Invest in people, establish purpose, experiment with processes and tools. It should be that simple, so why is the reality so difficult? Compromise. In the hands of a pragmatic and accountable leader, compromise is a powerful approach that allows good solutions to surface quickly at the expense of time-consuming perfection. Most of the problems we’ve seen in practice with our clients arise from compromising the delivery capability in favour of politics, historic practices, or making sure middle management have something to do.
The tools themselves are rarely the differentiator; more critical is the ability for everyone involved in product development to feed back into refining the best working arrangement for the situation at hand. It is likely that distributed teams will rely more heavily on process and tools, as spontaneous interactions need to be replaced with formal catch-ups. As we’ve seen, it’s important to get the fundamentals in place before defining the process: for the feedback loop to be established, people need to be engaged in a problem they want to solve.
