Join For Completion

One of the DistributedTeamPatterns

You manage a project where the team members are distributed on engineering centers that are geographically far apart. The time difference is significant. The product you are working on is close to completion. A number of users are on-site with engineering to perform the final system testing.

You expect that you will find a number of issues during the final tuning and qualification of your product before release. How can you make the problem identification and correction efficient and focused?

Intense testing by users to qualify the system for commercial use will certainly result in a number of issues that must be corrected before you can deliver. To deliver on time is important, still it is not an option to deliver before the qualification team is ready to approve the release. The fact that your developers and testers are not co-located does inevitably slow down your rate of correction. Some issues must be dealt with very quickly as they prohibit testing of functionality further down the workflow (hiding other problems).

When working individually with the testing users, there is always a risk that we make changes that are based on the opinion of a single individual. There is also a risk that developers are not focusing on the right issues to fix based on a global priority. When we are working directly with individual testers, we will often accept their issues as our highest priority. It is a heavy process to coordinate all the input to decide on the right order for corrections, and difficult for each developer to keep to a global “official list” rather than fixing what the tester tells them directly.

Issues are recorded in a tracking system, but it is time consuming and inefficient to write detailed explanations. The most effective way for a tester to explain the problem and the necessary corrections to the developer is to run the system with the developer watching. A developer at a remote site will need a written explanation with details to be able to fix the problem.

The remote team members will not feel the same pressure or be motivated by working side by side with the users. Still, these team members are equally important for completing the project.

Therefore:

Gather the whole team (developers, architects, domain experts, and internal and external testers) together in one location for the final tuning of the product before delivery.

Twice per day, have a status meeting where the corrected and new issues are presented. Use this opportunity to make sure that requested changes are urgent and agreed, and make the users consolidate the priorities of what is most important to correct.

You will need dedicated space. If possible, place the whole team together in one room (a Prepared Workspace created for the occasion?). It can be off-site given that the testing can be done properly, with good connectivity back to the engineering site. You may have to bring in extra equipment to do the testing at one location. Make use of the possibility to team up a user and a developer so that they can do the smaller corrections on the fly as they are detected (“pair bug fixing”). This can be very efficient. The financial side will always be an issue for engineering. The cost of this exercise is most likely low compared to what the users gain in improved quality, but it is hard to measure and prove that this is the case. The best approach is to start small, and use the experience from pilot activities to help in the decision making with management.

If it is not feasible to get the testers to come to the engineering site, engineers may have to travel to user locations instead.

— oOo —

Consequences:

• You have increased the chance of delivering a high quality product on time. Communication is face-to-face and there are no time zones or other obstacles to deal with. With the testers and the developers at a single site, you can reduce the formality and level of detail in tracking defects.

• By bringing testers and developers together twice per day, it is easier to coordinate priorities and make all aware of the ongoing modifications, and of the current problems. The risk of tuning the system to individuals is lower, as the testers are able to discuss with each other on tuning of the functionality. Users that participate in the testing activity get trained on the new system. If done with care the event can be defined as training and get financial support from your training organization.

• The team created from combining users and developers can give engineering very useful contacts in the user community for later. The users will feel ownership of the product, and may be a good help in introducing the new system in a positive way to their peers. Hopefully they also left the activity with a better understanding of engineering and product development challenges.

• There is always a risk of exposing the unfinished system to users. Even if bugs are corrected and the system tuned before the actual shipment is done, users taking part in the testing may communicate a poor image to their colleagues, creating a perceived but untrue image of a poor product that it may be difficult to get rid of later.

This pattern was applied on two different teams in our department in 2003. Testers came in from several field locations, and we had an empty lab that was converted into a testing room. It had space for several work areas where a tester and a developer could sit together, plus a big meeting room table where status meetings were done twice daily. Systems were borrowed from the on-site training center. They also helped out in providing field personnel to take part in the testing. For both projects, the final tuning was very successful, and the systems were delivered on time.

FaceTime? also helps the dispersed developers to get to know each other better. It's frequently a good idea to spend some time on joint social activities (ones that neither culture involved will find offensive, naturally--taking your Indian co-workers out for barbecue is probably not a GoodIdea) just to improve the comraderie.