Collaboration or Cooperation

Collaboration and cooperation are two totally different concepts. My translators tell me that, unfortunately, in the Chinese language they basically mean the same. I've written about that before.

With the help of several translators the slides that I use for my work contain these two symbols to represent collaboration:

协同

Cooperation is presented as:

合作

But then I have seen motivational posters where 合作 was shown next to the English word collaboration together with an image of two people climbing a mountain. One was offering the other his hand to help him up.

From competition it is a big leap to cooperation

As I've been told Chinese life is very competetive. Pupils in school compete with each other. Only the best grades will allow a student to enter one of the good Universities. And only with good grades at the University will it be possible to find a good job.

I've done a few interviews and people tell me that collaboration or cooperation at University were not a smart idea. Why help the competition.

Another additional explanation is that in China there are so many people that it were essential to be ahead of everyone else. The answer sounded like it were a question of survival.

In such a climate not to compete with coworkers but cooperate with them is a big leap.

This week I learned about another data point to understand why collaboration seems to be such an alien concept in China. In a military context 36 strategies were developed and written down in ancient China. Those 36 strategies have just one purpose: how to be smarter than the enemy and how to cheat and betray for one's own advantage. My source explained to me that in everyday business people apply the teaching of the 36 strategies.

Collaboration requires trust

Not to harm a coworker, not to interfere or sabotage other people's work makes sense in a corporate environment for workers on the same low level within a hierachical organization. After all management expects results and that is commercially usable output. There are rules and processes to make individual workers perform tasks within a value creation chain. When each worker cooperates nicely with the other workers in the chain something useable will be made.

Trust is not required to cooperate. Rules and processes make sure that nobody acts against the externally defined goal.

For collaboration trust is essential. Collaboration means two or multiple persons are working together on the same thing sharing knowledge, techniques, practices in the open. Mistakes are visible to everyone. Gaps in knowledge are visible. People learn from each other and thus may become better at something - potentially better than the others in the group.

When there is no trust, then none of that open behavior that exposes vulnerabilities makes sense. The more one shows vulnerabilities the more risk to be betrayed and taken advantage of is there. If you cannot trust the other people, then don't collaborate.

The most you can tolerate is cooperation.

Chinese developers work in silence

So far I have visited offices in Shenzhen, Xi'an, Shanghai and Beijing where thousands of software developers work.

They all work in complete silence.

Some of the offices have single person cubicles to use the existing floor space in the most efficient way to allow putting the maximum amount of desks in a given room. Others have cubicles for multiple persons where everybody faces the cubicle wall and shows his back to the others in the same space. The more nicely decorated offices, frequently also located in newer buildings, have long desks for multiple persons on either side and facing each other.

Initially I assumed that the cubicles itself were blocking communication and therefore nobody was talking to their coworker. I also observed that the cubicle workers were using extensively electronic chat tools to communicate. What especially struck me as a bit odd is that even those in the group cubicle were chatting through their computers in writing to each other. They could have simply rotated their chairs to have a face to face conversations. Their physical distance is just 2m at most.

In the more open and even in the really open workspaces the situation is the same. No conversation. The only sound one hears is typing, walking and chairs moving around.

People do get up and have group meetings in front of a whiteboard. But when they do it is one person doing the talking and others listen or answer questions from the one with the pen in hand.

Educated to listen, obey and perform tasks

Workshops that I've been doing start also with a lot of silence. People sit and watch attentively what the teacher is doing. They don't interact. At least not initially. It takes some effort to make them show some emotion and actively participate. There is some confusion on their part what they should do. It feels like workshop were an unknown concept and they seem to expect a lecture.

I've been told that the school system trains people to behave like that. At a young age Chinese learn to sit still and listen to the teacher. The teacher tells them about the subject and the pupils are expected to absorb the teacher's knowledge. At some point there will be a test and the pupils are expected to reproduce the teacher's knowledge - as accurately as possible. My sources tell me that interpretation or processing of the presented information is not expected and actively discouraged. That continues in University and then people behave as adults in a corporate context the same way.

So it is totally normal to listen to a superior, now called a leader or manager, obey his rules and perform assigned tasks.

No need to talk. No need to ask. Just do. And don't disturb the others.

The eight rules of ATDD

Recently someone at my current client was asking me about what they should do when "doing" ATDD. As the request was about a simple answer, I came up with a number of shoulds and one should not. After I wrote these eight rules down we had a good group conversation to clarify and understand what each rule means and calls for.

Intentionally I was trying to use language that is a bit vague in order to encourage thinking and discussion.

1 - You should learn the ways of your customer

Learn as much about your customer as you can.

Find out what the customer wants to do with the product you are creating. Find out how the customer usually works - without your product. Find out what he values, what preferences he has.

2 - You should learn your customer's expectations

At the very end it is the customer who either accepts or rejects your creation. As it is unlikely that you will deliver something that is completely broken, it is your customer's perception that makes or breaks the deal. Perception is connected to expectations. If you don't understand what your customer expects from your creation, then it will be difficult to make him accept it and be delighted.

3 - You should specify the behavior of your product

With a solid understanding of your customer's situation and expectations you should explain what your product will do. Share the specification of the future behavior of your product with the customer to collect further feedback to make sure that you truly understand his expectations.

4 - You should deliver expected behavior

When customer and you share the same view about the expected behavior of your product you should deliver precisely that. You may change it later, together with your customer, but it is important to deliver what you both have agreed upon as that is part of your customer's expectation and makes you trustworthy - a very important piece of entering a trustful relationship that enables close collaboration.

5 - You should continuously document actual behavior of your product

Using techniques and tools that allow you to execute the specification of the expected behavior that your product will exhibit you document that the product is indeed behaving as specified.

6 - You should create trusted blocks of code

By using a technique like TDD (Test-Driven Development) you craft the product making up your product in many tiny steps. Because you write the test before the production code you will have good coverage and you will not create any code that is not really required. That way you create blocks of code that you can trust. The better you specify what the code should do and only code the requested behavior, the more you know that your code is trustworthy.

7 - You should assemble your product using trusted blocks of code

Now that you have created all the small pieces test-first you can continue with the bigger blocks. You continue to specify behavior, but this time on a higher level, and for the implementation you use the chunks that you have created earlier.

8 - You must not verify

That is probably the biggest surprise for many people. I'm really advocating that you should not verify. Not verify anything anymore that is. Because, if you did all the things listed before, then there is nothing left that you would have to verify. You've done it already extensively and performing additional tests would be just a waste of time and money.

干杯 - Bottoms up

In most places on this planet humans like alcoholic beverages. They are usually consumed to celebrate something. Chinese are not different. Their favorite celebration beverage is rice wine. It is strong and has more than 35% alcohol. The picture to the left shows how it is served. The small glass is used to drink it while the larger one is for refills.

You raise the glass so that the bottom can be seen by everybody and drink all its contents in one go. Chinese call that "bottoms up". It is pronounced "gam bei" and written like that:

干杯

Paying respect

A little while ago I was invited to a business dinner celebration. People gather around a round table, have a lot of food and after a short while they start to salute each other, praise heroic acts someone performed during work and pay him respect - that's how they call it.

The first person stands up, looks for someone he wants to pay respect to, praises what he has done and invites him to raise the glass. They both exchange a few more words and empty their glasses. As soon as the glasses are put back onto the table someone next to them quickly refills them. The glass can never be empty.

That goes on for quite a while and, as I was able to observe, at some point they do skip the small glass to grab the larger one and do "bottoms up" with that one. It's becoming a contest about who is stronger measured by the amount of alcohol any person can consume.

It all comes to an end when either money runs out or people are too drunk to continue or there is another reason to leave the establishment. It was quite impressive to see how much people can consume.

Old Chinese motivational method

My current client has offices in the old Chinese capital city of Xi'an in central China, which has over 3,100 years of history. Over the last two weeks I had an opportunity to visit, see the city, the terracotta army and also work with two groups on the concepts behind Acceptance Test Driven Development (ATDD).

During conversations in the workshops one tester told an interesting story about "testing" in the very distant past. It was about a walled city that had walls of such good quality that it was very difficult to conquer. I searched for more information about the city of Tungwan and came across a Danish website with more details about the history of that city and its people.

I'm quoting from the Danish website to tell the story:

In 407 AC, a Tiefu Xiongnu named Liu Bobo founded the kingdom "Xia" in the modern Ning Xia area. He called it "Xia" because of the history that the Xiongnu descended from the ancient Xia Dynasty. In 413 AC he decided to build a capital, which should be absolutely impossible for the enemy to capture. He gave the responsiblity for managing the construction to his evil general, Chigan Ali. The city was named "Tungwan", which means the United ten thousand, as it was Bobo's goal to rule all China's ten thousand states.

The story then describes testing of the wall:

Chigan ordered that all soil that would be used for city walls, should be boiled (with rice) to make it hard and difficult to destroy. He often tested the quality of the wall, if an iron wedge were able to penetrate more than an inch into the wall, the foreman, who was responsible for this section of the wall, would be executed, and the corpse would be used as filling in the internal wall.

But that was not all. They applied a similar motivational technique to the manufactoring of weapons and armor:

Liu Bobo supervised himself the manufacture of weapons and armor. He gave the order that they should be tested in such way that the arrows were shot against the armor; if the arrows could penetrate the armor, then the black smiths, who had produced the armor, should be beheaded; if the arrows could not penetrate the armor, then the smiths, who had produced the arrowheads should be executed. In this way, both fortifications, weapons and armor became of very high quality.

Liu Bobo later changed his name to Helian Bobo. Apparently he was quite a violent person:

A Chinese historian described Helian Bobo like this: "He was arrogant and cruel, and he treated people like weeds. Often he entered a tower with bow and arrow, and whenever he got an impulsive suspicion, resentment or anger against someone, he would personally kill him. If someone stared at him, would he cut his eyes out. Anyone, who laughed too heartily, would have their lips cut open with a knife. Anyone, who dared to have a different opinion than he, would first get their tongue cut out, and then their head would be severed.

And as the father so were the sons:

Helian Bobo decided in 424 AC, for reasons which have not made their way to written history, to push his eldest son, Helian Gui, aside as a crown prince and instead appoint a second son, Helian Lun, to succeed him. Helian Gui was a very skilled general, immediately he led his soldiers against Helian Lun, defeated him and killed him. When a third son Helian Chang heard this, he conducted a surprise attack, killed Helian Gui, took command of his troops and led them back to the capital, Tongwan. It impressed his father so much that he appointed Helian Chang to be his crown prince. On the other hand the old man had little left for a fourth son, Helian Ding. It is said that Ding had too easy to laughter after Bobo's taste. Helian Bobo died in the summer of 425 AC, and his son, Helian Chang, succeeded him.

Words matter a lot - Speaking in images

Chinese is quite an interesting language. I'm now in China since end of June to coach several teams on Acceptance Test-Driven Development. So far I've not worked directly with a product team but instead have been working with a group of people tasked to provide tools and advanced concepts to product teams. We do spend quite a lot of time to make ATDD tools and teaching material suitable for Chinese developers. And it turns out that that in itself can be a challenge.

Language shapes how one things and the way of thinking shapes the language. Other factors, like culture and history, influence further. Before I left Germany for China I expected to encounter a lot of significant differences and was eager to find out what these were. After all the Chinese culture is more than 5000 years old.

Now that I'm in China I discover a few interesting points:

  • Chinese speak in images
  • Every image represented by a symbol has an associated sound
  • The meaning of all those images can be modified by other symbols
  • The current meaning of a symbol (image) is influenced/changed by contemporary culture and views

I don't speak Chinese. All that I say in this blog post is based on observation and conversations with native speakers.

As an example I'd like to use the English word collaborate. Collaboration is quite important to ATDD and agile development practices in general. I was quite surprised to learn the following.

Do we want to cooperate or collaborate?

One can use Google's translation service and it will tell you that collaboration in Chinese is:

合作

However, I was told by my Chinese associates that this translation were not right. Instead they prefer to write:

协同

合作 gets translated by the Baidu Translator to:

Baidu Translate Collaboration

Baidu is a Chinese search engine and the "official" search engine in China. Google Translate tells us that 合作 is:

Google Translate Collaborate

And just as Baidu says my Chinese associates told me that 合作 indeed has the meaning of cooperation in the sense that people or organizations work together while staying seperated from each other. Just as for me to them cooperation is a lesser form of working together than collaboration.

Worth noticing is that Google Translate shows a ranking for each potential meaning and while it seems to agree on cooperation as a noun it ranks cooperate and collaborate equally as a verb. Interesting is that other meanings of 合作 as a verb can be negative. Amonst the list of meanings is conspire and that is certainly not a good thing to do in the context of working as a team.

So let's try to translate 协同 using Baidu and Google. Baidu says:

Baidu Translation Collaboration 2

while Google knows just this about it:

Google Translate Collaborate 2

Which form of collaboration do we want in software development?

Learning about those differences in interpretation I am now thinking about which form of collaboration we want in a software development team.

I don't have an answer at the moment so this is going to be an ongoing process but I intend to come to this topic and follow up in a little while.

Can you do test-driven development with a manufacturing mindset?

ATDD is a communication technology to bring teams together. As software development is foremost a social activity performed by thinking human beings ATDD may challenge your organization because it may alter how you organize projects or even the organization itself.

With management primarily focused on improving efficiency (more output with same input or same output with less input) by chasing the speed demon you may face some serious obstacles when trying to adopt the test-driven development mindset required to successfully use Acceptance Test-Driven Development.

Do you take a nap after lunch?

As I write this it is lunch time here in China. I'm at the offices of my client in a very large office park with many buildings. Probably about 20,000 people are working here.

We just had lunch in the cafeteria and are back at the office, which is a big room with many cubicles that have low walls. And it is dark. The shades are down and the light has been turned off. You have to be careful where you step in the darkness. Only the main walkway in the center of the room is lit.

Everybody is having a nap.

They sleep with the head on the table sitting in their office chairs. They sleep on camping beds they brought in from home or they use some insulation mattress under their desk. Some are wrapped up under sheets or have put themselves inside a sleeping bag. The only sound you can hear is the air condition, some rare sneeze and some very light typing by people who don't want to sleep but continue to work or chat with someone via the internal messaging system.

Impressions of Chinese street life

Over the weekend I had an opportunity to stroll around and take some pictures of the life on the street. It was after dark and quite a bit cooler than during the day. So there is lots of people out on the streets. People sit in open air restaurants for dinner, shop or just meet with friends.

Street Life 1

Street Life 2

Street Life 3

Street Life 4

Street Life 5

Street Life 6

Street Life 7

Street Life 8

Street Life 9

Dance Show at Shenzhen Waterworld

My family and I went together with a Spanish speaking Chinese friend to Shenzhen Waterworld.

Amongst all the different attractions there was a dance show. To our surprise the performances demonstrated Latin American, Spanish and American music and dance styles.

Dance Show 1

Dance Show 2

Dance Show 3

Dance Show 4

Dance Show 5

Dance Show 6

Dance Show 7

Dance Show 8

Dance Show 9

Dance Show 10

Dance Show 11

Dance Show 12

Dance Show 13

See a listing of all posts on this site