Distributed Development Enablers Part 2: Process

In this series of articles on Distributed Development, this is the third article.

The first article was about 'Challenges Faced In Distributed Development'

https://www.dhirubhai.net/pulse/challenges-faced-distributed-development-sunil-mundra/

The second article was about 'Distributed Development Enablers Pat 1: People

https://www.dhirubhai.net/pulse/distributed-development-enablers-part-1-people-sunil-mundra/

In this article, we will look at process-related enablers.

Co-Located Meetings

• Inception/Project Kick off Workshop

The importance of an inception workshop, though held perhaps only once in the lifecycle of the project, cannot be overemphasized as some of the key decisions which impact almost all aspect of the project are made in this meeting. These include business and technical scope, key project drivers such as time to market, cost, quality and so on. Moreover, arriving at a common understanding related to business vision, as-is and to-be processes, end-user journeys, risks, dependencies, and assumptions also happen in this workshop, which is spread over several weeks. Not to be forgotten is the fact that relationships between stakeholders are cemented in this period, as most stakeholders get an opportunity to spend time with each other during and after business hours.

Obviously, it may not be possible for the entire team to participate in person in this workshop due to travel and logistical constraints. The exception would be when the team is small, and there is adequate travel budget. Nonetheless, it's absolutely critical that all roles across all locations be represented in this meeting in order to maximize the effectiveness of meeting the key stakeholders in person. No amount of documentation can be a substitute for the richness of conversations in person, and this benefit becomes even more important when team members are distributed. The team members who have attended the inception are in a much better position to pass the context to the rest of team in their respective locations.

Participation of those not physically present via video conferencing should be explored. The time and effort invested in this will pay off. Should the project span multiple releases, the option of those who have not attended the Inception Workshop now attending Release Planning meetings should be also considered.

An Inception Workshop turns a Group into a Team. 

This fact should be leveraged to the maximum possible extent, especially when team members are distributed.

• Joint Stand-Ups

The importance of stand-up meetings as an effective working habit of an Agile team is undisputed. The meeting provides an opportunity for the entire team to get together and focus on the work at hand, assess progress towards the goals for the iteration, and discuss risks and blockers, if any. This practice assumes even greater importance when the team is distributed, as the need for the entire team to be aware of who is doing what work, dependencies and blockers, is critical.

Given this fact, the team has to strive to hold stand-up meetings which include all members of the team. This can be quite challenging if there is a big time difference between the locations of the team-members. This is one of the main reasons that drives reserving of overlapping working hours between the locations.

As much as possible, video-based tools should be used for the joint stand ups. Using a teleconference number is obviously the next best option.

As in the case of co-located stand-ups, the team-members should speak with reference to the story card wall. In case of a distributed team, an electronic card wall should be used as a reference, as it is the single source of truth for the entire team. An electronic story card wall is particularly useful in cases where team members are dialing into the stand-ups from their homes.

• Joint Retrospectives

Just like stand-ups, the importance of this practice is heightened when the team is distributed. For things that have not gone well, it is very easy to fall in the trap of blaming the team members who are not part of the retrospective, when not held jointly. Even a single instance of this has the potential to lessen the trust between teams.

Given that the entire team is not in one location and consequently the nature of communication being complex, the team needs to provide adequate time for the meeting. The complexity arises due to all team-members being required to vote on action items and maintaining anonymity during ‘safety check’. Strong facilitation skills are also called for due to the above mentioned reasons.

A tool which helps in exchanging information in real-time and which acts as the ‘single source of truth’ is a must for retrospectives of distributed teams. There are several tools available which serve these purposes. Some free examples are Ideaboardz and Scrumble.

Maximize Overlap Hours

One of the biggest challenges for distributed teams is maximizing overlap hours across locations. The challenge is accentuated when time zone differences are significant, as they are between India and the US West Coast, and also when onshore team members ‘push’ their offshore counterparts to adhere to what is convenient for them.

It is critical that everyone, regardless of location, is ready to demonstrate flexibility towards maximizing overlap in working hours. The advantages of synchronous communication while being at work far outweigh the compromises, within reasonable limits, which team-members would need to make. The goal obviously should maximize overlap with minimum sacrifice and compromise by each team member. Teams can come up with creative ways to do so—some team members, by rotation, coming in early or leaving late, teams across locations taking turns to come early / leave late and being flexible about taking calls from home.

Not only does maximizing overlap hours help towards improving communication and collaboration, but the willingness to compromise and be adaptable helps tremendously in creating a ‘one team’ feeling.

Periodic ‘Dev’ Showcases

By definition, a showcase is supposed to be done at the end of an iteration to demonstrate working software to the stakeholders. A practice which helps distributed teams to reduce unpleasant surprises and to build trust and confidence is for the teams to showcase their work in progress to those who are distributed without waiting for the end of the iteration. This can be done upon completion of each story, but it need not always be that way. Even showcasing code and interfaces through use of mocks, if necessary, adds a lot of value to the entire team. These showcase meetings can be kept short and crisp and once the teams get into the cadence of doing these on a regular basis, the time taken for these will be minimal and non-disruptive.

This practice is particularly useful when iteration length is two weeks or longer. It greatly improves the predictability of iteration end demos.

In the next, and last, post in this series, we will examine Tools and Infrastructure-related enablers.

Originally published on

https://www.thoughtworks.com/de/insights/blog/distributed-development-enablers-part-2-process

Tags: #DistributedDevelopment #AgileProjectManagement #AgileMethodologies