Let’s start this discussion with the obvious question – Why on earth would you want to spend time on a feeling of “trust” when you are about to embark on a development project? Sure, trust is nice to have, but do you really need to spend time worrying about the quality of interactions between members of a software development team? Will it honestly bring anything to the bottom line of a project? Do we care if everyone has a warm, positive image of their fellow team members?
To answer that question, let’s set up a mental picture of a virtual development team, including the product owners, and the DevOps team they are integrated into. We will imagine the core development team is a relatively small, five-person agile team because that methodology is prevalent in the industry and certainly across groups with DevOps implementations. They are an outsourced team, remotely located, away from the client premises, but they have good communications and infrastructure. We won’t imagine a lot of barriers for them – except that they are starting as a new group on a new project. This team starts out with a clean slate, but even so, they are going to start right away working on building trust inside their team, with the larger DevOps team they are a part of, and with the stakeholders in their project.
Now let’s imagine a second-team, much like our first team, except they are not going to worry about building trust. They are experienced developers, they know what they need to do and they assume everyone involved in the project just wants to get down to work without a lot of overhead.
These two teams are not just theoretical for the purposes of this article. There have been several studies done with teams that do and don’t spend time on building trust early in the process of starting a project (good examples here). The situations studied can be more or less complicated (virtual teams in an offshore situation, in a nearshore situation, and in a combination of co-located and off-site locations) but regardless, the results have shown that spending time early in the process developing trust across the entire team paid strong dividends. These teams had less overhead in terms of management supervision, less rework, and higher productivity, collaboration, and satisfaction.
The studies that have been done have also pointed out that some of the dynamics of trust in teams are useful in both understanding why trust is so important and how to build trust quickly and effectively:
- When a new team is formed – it has a general disposition for trust both internally and with the larger team, it is brought into. It might seem that people are naturally suspicious of new teams, but in fact, the actual situation is the opposite. New teams are an unknown quantity and if they take immediate advantage of it – they can build on a general disposition to trust with positive exploration and interaction to make a solid foundation for positive interaction.
- There are well-documented phases in the development of teams that can be built on and used as building blocks if specific goals are set out and activities that need to be done to start work are aligned with team and trust-building. The diagram at the right of this article is a general guide to the phases and goals that can be used to build team trust while accomplishing necessary project initiation tasks.
- The critical phase is the Project Team Inception. If it is expanded beyond the development core team to include as many of the larger team and stakeholders as possible in face-to-face interaction and team-building exercises and if it includes joint project planning, it begins to form a base of both work-related and personal relationships. This phase is predicated on people getting together in one place, as an onsite, to break down preconceptions and begin to recognize team members as individuals with personalities, values, and skills.
- Although the first phase, Establishing the Team, is not envisioned as an onsite, the next two – Project Team Inception and Project Team Organization are and whenever possible, the Transition to Development phase will also benefit from face-to-face interaction because it will ensure everyone is on the same page, understands their working environments and is comfortable at an operational level.
Going back to our two teams – let’s imagine what happens to our second team if they don’t use “waste time” on building trust during project initiation:
- They are an unknown quantity, so although there is a general disposition to trust new teams, if they do not focus on building trust early, they are likely to be given less important work or set on an independent track that is thought to not jeopardize critical work. The assumption is usually that if they “prove themselves” they will be moved to a stronger, more integrated position in critical work. In actual situations, it is more likely that silos will form and they will actually begin to feel they cannot trust the rest of the team and will react to them as outsiders, building defensive barriers that are very hard to break down later.
- Work division and the cultural distance between teams will increase. In these situations, the usual response is to add more supervision and oversight over the virtual team to ensure they “stay on track.” These reactions increase overhead and are even more likely to increase the cultural distance between teams. As the situation worsens, micro-management and ask-before-doing practices lower productivity and trust throughout the team.
- Finally, in the worse cases, the virtual team is not trusted to make their own decisions and independent contributions to work. They become agile in name only – they are not valued, their input is not requested or trusted when it is given.
Certainly, these are outcomes, as team members and stakeholders, we all want to avoid. With any team, but especially with outsourced virtual teams, the lack or loss of trust between team members and across the entire team, in general, can create serious situations. So, what can we do to build trust quickly across a project team and maintain it throughout the project lifecycle?
- Don’t depend on trust growing organically from the general disposition to trust new teams and team members. If barriers grow, they can be very hard to remove. An organic trust may turn out to be fairly strong, but it can be easily lost over one issue or one bad interaction and once it is lost, there may be no simple way to return to a trusting relationship without serious intervention.
- Putting a priority on building trust as a goal allows for open feedback and measurement of positive interaction. Shared experience in both formal, work-related and informal inactions builds understanding. Face-to-face interaction, nearness, builds trust much quicker than remote interaction regardless of the technical tools we bring to bear on the problem. Although bringing teams together in one location has a cost, it is more than offset by both the time required to bring teams to full productivity and the lowering of barriers to communication and understanding.
- Integration of team building and the transition to shared work is critical during face-to-face interactions. The exposure of abilities, skills and individual integrity grow from both sides – the accomplishment of work and the unexpected that comes out in informal situations. If actual work is not accomplished during onsite, the exposure of skill and feeling of shared responsibilities will not grow. If informal interaction isn’t capitalized, the vision of team members as whole individuals will not fully form and cultural distance will not be lowered.
- As the phase outline directs, to accomplish work, it is important that actual work processes be integrated into startup activities as soon as possible. For agile development teams and DevOps teams, this means getting into scrum and agile processes as soon as possible, even if it means interactions will feel somewhat artificial at first. Why not use stand-up to organize and take responsibility for project planning tasks? Is there anything more boring than sitting through a bunch of meetings where you have no identified role, responsibilities or tasks? Why not break down tasks to parallel working groups that can bring results back to the larger team for review, refinement, and approval?
- Team building exercises must be carefully planned and customized to fit the situations at hand. There are many references that can be used but they break down into two critical areas – the actual team building activities and an understanding of the goals behind the activities. Selecting and customizing activities for situations is impossible without a deeper understanding of what they are meant to accomplish and how they are organized to meet goals. Although you can find and may have many references on the subject – you will find answers for both sides of the question from Gamestorming, a compilation of business games for many purposes and game design. Businessballs also has some good general resources and Innovation Games are an excellent resource for activities that can be used to build strategies, plans, and teams.
- Just as important as planned activities, simple interactions like going out of the meeting rooms to eat together are excellent opportunities to build understanding and trust. Especially valuable are opportunities to try something new for everyone involved – like going out for a meal that involves cultural exploration with a new cuisine or interesting location. The shared experience can generate bonds that last over a long period and help bridge cultural divides.
Ok – but how long do you need to allow for the activities we’re talking about? It certainly depends on an amount of planning and logistics before the onsite meetings begin, which in turn depends on schedules and the distance between teams, but upfront activities could amount to a couple of weeks or more of elapsed time in most cases. The actual onsite can be accomplished in a week or a little more, depending on the complexity of planning involved and how much of a transition phase you want to include. Every bit of time you can spend on both informal and work-related activities has a payback and using the beginning phases of a project is critical to becoming a productive team quickly. You may also want to consider additional meetings for longer projects and between project segments – team building is not a “one and done” exercise because bonds may weaken over time.
Team building is also just as important in lowering barriers for reasons beyond trust, although many of the issues in teams still come back to that simple bit of interaction. Issues that can be addressed with team building – although it can be more difficult in some situations than others – include:
- Geographic and social-cultural distance – Shared experience usually lets us find out we are not as different as we assume
- Language – Even though we may share a language, we often distrust the understanding of others until we have had a chance to interact and share ideas.
- Differing tools and methodologies – Work practices and approaches can become “religious wars” unless we take time to break down our goals and find a common understanding of what we need to accomplish. This happens much quicker when we discuss issues face-to-face.
- Communication and collaboration – Good communication involves the trust of inquiry and an open sharing of ideas and concepts. It is much easier to work through barriers with someone you feel you know than a stranger.
If the geographic and cultural distance is great, and the effort to overcome the issues of travel, time-shifting and understanding are critical to the work being done, it will certainly require more time and planning to deal with the problems. Because in the end, the success or failure of a project and the goals that drive it are at risk, you have to consider if the issues can be overcome reasonably. In the case of outsourcing software development, especially in cases where benefit from agile and DevOps based methodologies are expected – the geographic and cultural distance can be lowered by working with nearshore outsourcing services.
Scio Consulting has experience with the issues of building trust and the planning required for successful integration of teams for outsourced software development engagements. We provide nearshore-based teams for our clients in North America that are ready to travel or receive teams locally in our offices during the planning and onsite activities. We would be glad to discuss how our experience can bring value and lower risk in your situation.