Pros and Cons of Tools

In recent years, remote collaboration tools have become better and better, such as Screenhero, it supports screen sharing, enables two people working remotely to operate concurrently by controlling the mouse and conduct voice chat. Objectively speaking, the functions currently provided by the collaboration tools have basically eliminated the adverse effects brought by remote working, and paved way for us to give our subjective initiative into full play.

It is an annoying process to submit a regular project to all stakeholders, including the status of development and testing, although it is required by our customers. Generally, we have to collect all necessary data and display them in charts or graphs. It takes a long time to use common document tools, and we have to carefully maintain them and sometimes modify the data. But now our job has become quite relaxed thanks to JIRA, Trello, Mingle, and other task management tools that automatically generate reports. It will be perfect if we can persuade customers to log into the system to read the reports on their own.

By employing these tools, we can easily learn about the arrangement of each iteration, since the physical Kanban only allows us to know the content of the current iteration. The virtual Kanban tool can avoid the situation where different teams may see out-of-sync progress indications. In the final analysis, even if we have got a lot of tools, we may not reduce the opportunities for the face-to-face and real-time communications.

Active Communication

While the project is running smoothly, everything seems to go well, but challenges still come out occasionally. After the customer team is more familiar with the offshore team, it starts to ask some interesting questions. For example, have testers done any work after the project started? How about the size of a test case? Why is the priority of defects higher than the priority of story cards? Now that the estimation is so inaccurate, why do we have to estimate the story card ? How many codes should be written for an automated test?

Many problems actually arise from customers’ misunderstandings, so we must correct their misunderstandings in time to prevent them from spreading and taking root and sprout. Under mature conditions, we can introduce advanced practices to help customers improve the level of practice and enhance their confidence in cooperation.

When customers feel they have lost “control” over the offshore team, they will begin to distrust it. Because of such mentality, whenever customers feel they need some information, they will ask the offshore team to provide to them. Of course, we can send such information to them on time, but we’d better take one more step, that is, discuss with them over all the information that they want, and send it to them regularly, which will avoid randomness and possible omissions. At the same time, the regular information provision is more conducive to horizontal and vertical comparison. In order to prevent customers from not knowing what they are unaware of, we must actively introduce more contexts to them. Project overview or technical architecture is a good start. Such information that “sees both trees and forests” is easier to understand. If customers value product quality very much, but they have no idea of what the offshore team is doing, they are sure to feel anxious. Therefore, we shall regularly discuss the existing defects with customers and let them know about the product quality, the priority of defects may be easily determined if we are lucky enough.

We usually assume that since all information is in the version control system and task management system, customers can take the initiative to look up the information they want. In fact, almost none of them will read it proactively, we still have to send them a status update report to inform them of what they want with a minimum of time and effort.

There are some situations where text communication is used, such as e-mail, content description in story card, and defect description. We can fully understand what we are describing, but those have no context or do not know the cause and effect fail to do so. How to describe something without our familiar contexts is an important skill for customers to accurately understand what we express.

What should we do to deal with different types of collaborative teams?

■ The collaborative team is an independent product team, but when it has to develop the tight integration function, how can we cooperate with this team?

■ The collaborative is working with us on the same code base. How can we cooperate with each other?

■ For distributed teams that do not share the same code base but have a small amount of interaction, can the method of sending periodic reports (such as weekly reports) to each other improve the communication between them?

Many teams are keen on defect analysis, but they should consider how to feed back the analysis results to the development team. Is there any action that the development team can take? Without effective action, the feedback loop cannot be formed, what is the point of doing this kind of work?

Many project teams have met the problem of not reaching the end customers (users), and I believe this is a “common problem” with offshore projects. However, user experience is the only way to test products, so I think we should help customers build a user feedback chain. After undertaking the project, we can create product prototypes before developing the business-related functions, so that customers can show them to users and collect their feedback, which will effectively mitigate risks.

< Prev   CONTENTS   Source   Next >