Remote Delivery

A Guide to Software Delivery through Collaboration between Distributed Teams

Zhengping Qu

• Publisher: CRC Press
• Year: 2021
• eBook ISBN: 9781000381528
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Networking
• Index: Computer Science

This book records the author's years of experience in the software industry. In his own practices, the author has found that the distributed work pattern has become increasingly popular in more and more work environments, either between vendors and customers or between different teams inside a company. This means that all practitioners in the software industry need to adapt to this new way of communication and collaboration and get skilled enough to meet the greater challenges in integrating the distributed work pattern with agile software delivery.

By centering on the difficulties in communication and collaboration between distributed teams, this book digs into the reasons why so many remote delivery projects end up anticlimactic and provides solutions for readers' reference. It also cites successful cases in promoting agile development in distributed teams, which has been a vexing problem for many software development companies. In addition, readers can find suggestions and measures for building self-managing teams in this book.

Remote Delivery: A Guide to Software Delivery through Collaboration between Distributed Teams is a very practical guide for software delivery teams with their members distributed in different places and companies engaged in software customization. Developers, QAs, product managers, and project leaders can also be inspired by this book.

Foreword 1: Taking Up Delivery Wholeheartedly

Three or four years ago, Zhengping Qu said that he planned to write a book on offshore delivery while having a meal with me. At hearing this, I felt so glad that we would finally have a monograph on this subject, and he was just the right person to do so. At that time we had been working at ThoughtWorks for about eight years. It is a company engaged in agile practice and customized software development. After years of dealing with customers coming from different industries and posing different requirements, we have gained rich experiences in software delivery, which is our common interest. Later, both of us left this company, and I transformed from “Party B” into “Party A.” A new identity enables me to look at software delivery more comprehensively, but it also makes me confused at the same time.

Half a year ago, Zhengping Qu visited me with the manuscript of this book – a product filled with his wisdom and more than two years’ efforts, and told me that it was about to be published. I could hardly wait to finish reading his works.

Distributed Team

It takes less than three hours to fly from Beijing to Osaka, and about two hours to drive from Wangjing Street to South Third Ring Road (driving across Beijing from northeast to south), but it may take us several months to visit our neighbors or colleagues who live on different floors in the same apartment building. In this day and age, it is no longer accurate to define a “distributed team” simply based on “time” and “distance.”

As mentioned in this book, when two teams are more than 30 meters away from each other, they will not communicate frequently and efficiently, a distributed team is then incubated. For example, a team in my company was recently relocated to an office building 200 meters away because of office expansion, since then we seldom connect with it or hear about it. It has to try every means to sustain communication with other teams, but the effect is not desirable.

The theme of this book is “offshore team” – the most “extreme” distributed team, but it tries to solve the problems common to the teams only more than 30 meters away.

Suppliers (Delivery Teams) Barely Satisfactory

My former employer, ThoughtWorks, is dedicated to excellent software delivery. Working in this company for almost ten years once convinced me that all software development teams were more or less the same. It was not until I left this company and became “Party A” that I came to see the “true colors” of all sorts of software delivery teams. I’m not the person who likes giving lectures, so here I will just share my personal experiences in working with some of these teams.

In each cooperation with a new delivery team, I’d like to ask them for the address of codebase, since it would help me fully learn about the competence of this team. But such a simple request was seldom met. they always made excuses to turn me down. Some teams never used version control tools, but saved codes in shared directories. Some teams were unaware of unit testing; at a code review meeting for a strategic project, I stared at the empty test directory and asked the developer, “Have you done any unit testing?”

“What’s that?” he looked at me blankly.

Besides, the work style of their technical supervisors was also worth noting: once a version of software was tested, they would use their personal computer to create a software package for deployment to a production environment.

The above practices, not following industry norms and as primitive as doing manual work, are commonplace in the process of software delivery.

There may be some conscientious suppliers, but most of them are not satisfying: not complying with process specification, making low-quality products, failing to cut high maintenance cost, and ignoring cultivation of employees. These phenomena demonstrate that suppliers pay no attention to the growth of employees while going after interests, and they are too complacent and conservative to make further progress. With such poor performance, they are hard to be counted as specialized software development teams.

“Party A” Resting on its Laurels

The companies that afford to hire software suppliers are “big” ones, no wonder they have “big company diseases” with varying degrees of symptoms. Lots of business articles have enumerated the typical “diseases,” such as heavy department wall, bureaucracy, asymmetry between rights and responsibilities, being content with the status quo, conservative, and less innovative. In addition to the company as a whole, even the subordinate IT division is plagued by these “diseases.”

To be frank, the suppliers are somewhat coddled by “Party A” which only wants to stay in the comfort zone, rather than make new breakthroughs. How can it be strict with its suppliers? Of course, not all “Party A” companies stick to established ways. an increasing number of them have started transforming their IT division. It has become an inevitable trend for traditional enterprises to go for digital transformation, but it will not be roses all the way.

The IT division of my current employer (Daimler Greater China) is one of those that seek transformation proactively. But the transformation of such a traditional division with hundreds of employees is no easy job. it calls for the coordination of suppliers, and there are too many things to try and change in the process. The book of Zhengping Qu came at the right time; its pertinent suggestions will help “reformers” avoid detours. All the contents are based on his years of practical experiences, unlike the intangible “golden sentences” preached by those star-like consultants.

Party A and Party B Need a New Relationship

In fact, I don’t like being called “Party A” or “Party B.” I think it has created confrontation between the two parties, but there are no better terms to replace them. In outsourcing services, two parties have long been fixing their eyes on contracts, requirement documents, acceptance reports, and PPT files. Party A makes no effort in examining the details of deliverables, and Party B is indifferent to the real thoughts of its customer. Everything is just fine as long as the two parties have no objection to statements and figures.

However, the landscape has shifted in recent years. more and more traditional companies have embarked on digital transformation, making software play an ever more important role in their business and presenting greater challenge to software delivery, which calls Party A and Party B to build a new collaborative relationship. They shall speak frankly and sincerely and make progress together: Party A shall carefully check Party B’s deliverables and suggest improvements, while Party B needs to discover Party A’s real concern more actively. It is a challenging process for the two parties.

In plain language, this book tells what a professional software development team looks like. With real cases and his personal experiences, Zhengping Qu points out a right direction for his industry peers to improve software delivery.

Han Kai
Chief Software Architect, Daimler Greater China

Foreword 2: Pursue Ideal Software Delivery

After working for years, I have found that many problems in our work are actually caused by people, or more specifically, by communication between people. Though speaking the same language, everyone has his own standpoint, perception, expression and presentation, so the outcome is often not desirable, like the setback in building the Towel of Babel.

In the domain of software development that relies on creativity and multi-party collaboration, especially at the current time when project scale, work pace and distance are several times more than before, the poor communication will widen the gap between requirements and results.

Because of these realistic difficulties, Zhengping Qu is especially admirable for writing a guidebook on offshore delivery. When he made the decision to do so, he was writing the article “Today and Tomorrow of Offshore Delivery” – an entry for the ThoughtWorks Blogger Contest – which seemed like a prelude to the later publication.

“Offshore development” is not something new. When companies look for suitable software implementation, they prefer simple and independent delivery in order to lower cost and ensure quality. But in the past fifteen years, with agile development increasingly popular in China and even becoming the mainstream software development mode, the practices and ideas it promotes have a tangible impact on “offshore development.”

This book on offshore development brings together Zhengping Qu’s rich work experiences and ThoughtWorks’ software delivery practices. It speaks highly of the team that maintains face-to-face communication, implements positive feedback mechanism, employs visualized measurement, eliminates resource waste, and excels at self-organizing. Such a near-perfect team is not only suitable for offshore development.

In my opinion, an energetic and trustworthy team is an ideal condition for software delivery. Domestic teams have made no impressive performances in software delivery over the years; I do hope they could find a clearer direction for doing their work after reading this book.

Many thanks to the writer for bringing us an instructive guidebook!

Zhang Kaifeng
Editor-in-Chief, ThoughtWorks Insights

Preface

The year 2005 was a watershed in my career.

Before that I had been working in a state-owned enterprise for three years, engaged in software development. At that time, the performance of software totally relied on the personal ability of developers; however, the one who was responsible for software debugging in production environment was distracted by welding of circuit board and testing of wireless signal transmission.

Later I found a new job in a software outsourcing company where I met my Waterloo in the first project. I was assigned to develop a warehouse management system before receiving any systematic training. I could understand every function depicted in the technical documents, but the finished product was disappointing. To be honest, I cannot figure out how the customer runs this system until now. While looking back on that period, I came to realize that lack of experience and guidance was the main reason for this failure. First of all, none of us carefully assessed the requirements of the customer. We took for granted that it was enough to do what he asked us to do, instead of making suggestions proactively. All team members had kept busy as the project progressed, but we were unable to deliver rich staged results to the customer. What’s worse, we only contacted the customer via e-mail and weekly teleconference, our conversation was all about existing problems and next-week’s work plan. We had no more communications on optimization of the project.

Despite of ...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• Foreword 1: Taking Up Delivery Wholeheartedly
• Foreword 2: Pursue Ideal Software Delivery
• Preface
• Chapter 1: Current Situation of Distributed Teams
• Chapter 2: Communication between Distributed Teams
• Chapter 3: Collaboration between Distributed Teams
• Chapter 4: Application of Visualization
• Chapter 5: Waste in Distributed Teams
• Chapter 6: Self-Managed Offshore Teams
• Chapter 7: Customer-Oriented Offshore Teams
• Chapter 8: The Future of Distributed Teams
• Postscript
• References
• Index