Developing digital products in China with Bianca Grizhar

Join Murray Robinson and Shane Gibson as they as they chat with Bianca Grizhar about developing digital products in China. 

We discuss the cultural differences between Germany and China, and how Scrum improved team  collaboration. 

We talk about the benefits of working directly with people offshore in cross functional, cross organisational teams.

Whether you’re a product manager or a developer, this episode is packed with practical advice that will help you work more successfully with your offshore teams.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast, I’m Shane Gibson.

Murray: And I’m Murray Robinson. 

Bianca: And I’m Bianca Grizhar.

Murray: Hi Bianca. Thanks for coming on to talk to us today. 

So we wanted to talk to you about doing agile software development with people and teams in China. Cause you’ve had a pretty unique experience there. But before we go into That story, could we get you to introduce yourself to our listeners?

Bianca: Absolutely. 

So I became a product manager in 2006 in China. I didn’t know at the time I was a product manager. I’ve lived and worked in Germany, in Canada, in China, in the UK, in Spain, and now I’m in New zealand. I’ve worked in a number of different roles with ever changing titles in startups and agencies and universities, but in my thinking, I’ve always been a product manager. And now I am the product practice lead at TradeMe, which is really my dream role, combining my passion for really well running operations. With knowledge sharing and community building. 

Murray: All right. 

Tell us your story of working with NetCircle in China. 

Bianca: Actually it was a coincidence. I ended up in China. It was a very spontaneous decision to move there. I studied Chinese for a little bit. I really enjoyed myself. I wanted to find a job. And a friend said, Hey, you do something with computers, right? so these people, they also do something like that. Go and have a chat. And so I did. I spoke to these two young Germans who were running websites. And needed a system administrator, which clearly I am not, but we had some good chats. 

They said, Hey were building these dating websites. It’s a bit awkward because there’s only dudes working here. We really need some, female thinking, would you be interested? And I said, yes. And so that’s how I ended up at the Net Circle. Wasn’t my career plan at all, but seemed interesting enough. And I wanted to stay in Shanghai, which was an extremely exciting place to be in 2006. 

Murray: Why were you in Shanghai? I went to school mostly in Germany, a little bit in Canada. And so all my education was very Western focused. It was pretty clear to me that there was a big Eastern gap in my knowledge and experience. And so when I had the opportunity to move, I thought let’s go while we can and learn everything that I can about this country and the culture and the, people.

How big was the team there at NetCircle? 

Bianca: When I started, less than 10 people. It was complete chaos. Nobody had any real title. Nobody knew what anybody else was doing. Everybody’s working on something. By the time I left the net circle in 2014, it was 120 people in three different locations by that time. China was always the development office and Barcelona was more for marketing, community management, management, those kinds of roles, because it was easier to find people there.

Shane: What made two German dudes decide to start a development company, in China? 

Bianca: It was a coincidence. SO they were just out of school. It was still like the after glow of the first internet bubble. They had some early successes with some websites. They just wanted to travel the world, make some money on the side. And they happened to be in Shanghai when one of their ideas blew up and they needed to hire some people. And so they started a company.

Also at the time, it was still very cheap to be running a company and hiring talented software developers in China. So it was a good place to do that. I remember one of the first people that were hired after I started was a professor from university who just went where there was more money and we weren’t paying people a lot at the time, but apparently still more than what he was earning at the university. 

Shane: And was the target market for them the Chinese market, or was it Western market. 

Bianca: It was Western market. So they brought their ideas that they kicked off in Germany with them on this travel. And so we were building websites for German speaking markets from China.

Shane: So how did that work culturally? There must be a problem there in terms of just translation of, ways of working, what’s acceptable, the way things should be laid out. It just seems like there would be a massive culture clash 

Bianca: Yeah, absolutely. They weren’t the customers, they weren’t the audience, they couldn’t even read what we were saying on the websites, we had people from all over the world. In this little chaotic group that we have. And so we had people from, I think, 13 different countries at the maximum. 

Shane: So did you find that because it was so diverse, that actually the team solved the problems themselves to find a shared language . 

Bianca: Yes and no. It was great fun working there because everyone was talented and everyone got to do what they wanted in the beginning, but we weren’t really getting anywhere. So in terms of a business success, it maybe wasn’t working so well. And especially when we grew and actually started to have teams and multiple products, it became difficult.

Murray: So tell us about the difference in culture between Germany and China. What did you observe? 

Bianca: Yeah, that probably couldn’t be a more extreme difference between work culture. Obviously this is all going to be broad generalizations, and it’s always people who work differently. But broadly speaking, Germans are very direct, in the workplace. This is all about getting work done and so you speak up when you need to, you have discussions when you need to very low hierarchies which is one of the major differences to Chinese work culture that’s a lot more hierarchical. It’s a lot more doing what you’re told to do, even if you know that might not be the right thing. 

Murray: So then what problems did that create for the company? 

Bianca: So first of all, we didn’t really have people telling others what to do. And so that became a challenge for some of the more junior people that we were hiring, who weren’t used to working in a self directed way. So the Germans had a shared work culture and we’re discussing a lot. And I think that’s where we were talking strategy and technical implementation, those kinds of things but there weren’t discussions with the Chinese colleagues because we didn’t have, an organized way of allowing people to have those conversations.

Murray: Then you introduced an Agile way of working. Why did you do that? 

Bianca: So at 2007, we said, we need to be able to do some planning. We can’t have people just working on whatever they want and taking forever to ship anything. We’ll need to organize these teams in some kind of shape and form that doesn’t take forever. What’s out there. And we literally just had a look at different frameworks that we could apply that would solve our specific challenges being, yes, we want to organize our work, we want to ship, we want to deliver things faster to our customers. But also we have these teams that aren’t talking to each other and we’re not getting actually real benefit of these cross cultural teams that we have. And that’s how we discovered Agile and Scrum to give to the teams and try out if that would improve how they would work and collaborate.

Murray: And what was the result? How did you go? 

Bianca: It was really positive in terms of the teams and the collaboration and the communication. So having these regular rituals, having even a fixed kind of format to have standups, to have retros, really helped because it meant everyone in the room got to have their say. So that really helped. It also helped maybe quieting some of the more loud voices in the room. So that part was really great. That’s not to say that we didn’t get the same pushback that I’m sure many other teams and companies in the world got when they introduced Scrum, which was, Oh, it’s too many meetings. There’s too much talking. We never have time to develop. We had all of that happening as well. So had any of the team used Scrum before it was introduced?

No, I don’t think anybody had even heard about it. I am pretty sure we were the first to do it in China . So we actually hosted the first scrum gathering at the company. But just in the following year, there was the first official Scrum Alliance conference. 

By 2010, there were a number of people around talking a lot. There was a lot of interest also by some large Chinese companies. And then ThoughtWorks came in shortly after and had a large conference. So it took off. 

But when we did our things, we were a very unique company in our setup and in our teams. And so we had to find a unique solution for ourselves. Now we did introduce it across the board. 

And I did run into regular clashes with the other product owners, who did things differently. They weren’t the Chinese colleagues though. So that was the interesting bit. I remember having heated discussions with my French colleagues. Who, didn’t think he needed to write long user stories. So he had these user stories that said, just do it. And 

so that’s where our discussions were more on the management level than it was within the teams. 

Murray: THat’s an interesting example because, generally, the view is that a user story is a placeholder for a conversation because the requirements are being developed by the team, not by somebody outside the team, the product owner is responsible for prioritization, but doesn’t really have to write requirements.

And we’ve had quite a few people come on and said that being a product manager or product owner can often feel like you’re just spending all day writing JIRA requirements for people, but that’s not actually the job, the team’s supposed to do it. WEre the team in China able to take on those extra responsibilities outside just development? Were They able to be a really truly cross functional team that did everything? 

Bianca: They might’ve been able to, but that is not how we did things initially. So I also wrote the user stories. We did do very intense sprint planning sessions going through every detail, because obviously making sure everyone understands everything was key to good cross cultural communication. And we had language barriers . So we spent a lot of time going through and also changing things. It was more me providing the content and then using sprint planning for prioritization planning. 

Murray: I’m looking at Hofstede Insights, which is a country comparison tool on workplace cultural values. And one thing it says is that in German culture, there’s a high desire to avoid uncertainty. And in Chinese culture, there’s quite a lot of acceptance of uncertainty. Did you find that?

Bianca: That’s really interesting. I hadn’t thought about the differences with uncertainty. It does make sense to me though, from the German perspective, definitely. We like to plan, my parents are just planning their first visit to New Zealand and it’s been going for a year and a half. So it’s the most intense travel plans you’ll ever see. Absolutely no surprises in that program. I buy that. The German thinking is this is how we ensure success is by making sure there’s no uncertainties. And it fits the type of companies that have existed in Germany for a long time. On the Chinese side, I’m trying to wrap my head around it because There were certain agile methodologies that took off faster in China than others. For example, test driven development was massive. Developers that came to us, they were already, across that. That was their thing. And that seems to clash with the idea of being okay with uncertainty in my mind. So I’m not sure if I experienced that so much. Maybe this is related to the fact that somebody else has the responsibility, so you don’t need to worry about the uncertainty. 

Shane: How did you deal with just the language difficulty. We did. 

Bianca: Officially have English as our working language in the office. However, I did find myself switching between German, English, and Chinese in the same conversation multiple times a day. So it was quite a high mental load. Being the translator between the cultures was very key to my role. 

Another thought I just had is, this was my first professional full time job. I hadn’t previously worked in a german work environment. So for me, while I noticed that difficulties or the challenges that we had, people working together, I didn’t necessarily think of them as culture clashes because I didn’t have this idea of this is German work culture. And I was one of the oldest in the company. So that means everybody else was in the same boat. And that made it probably a little different. It was when I. I went back to Germany and I started working there many years later. I had a job where I was working with a lot of the old school, big German companies that have 60, 000 people. That’s when I really realized, okay, now I understand what we’re talking about in terms of German work culture. And to come back to what you were talking about earlier, Murray is I think Agile took a long time to take off in Germany. And that’s probably because of that managing uncertainty and different ways of doing things that were very established. 

An interesting thing that I’ve learned, particularly about the differences between German and English language is the grammar actually shapes the way you think. German grammar and German sentence structures are very outcome and goal focused, whereas English is about doing something. It’s about the process of getting to a goal from the grammar point of view.

Shane: Yeah, I used to work for a large software company. And, it was weird because there was a US head office and a German head office. So there was effectively two companies under one ownership, two development teams building different products in the same suite. When I worked with my German colleagues, they were very precise. Precise in language, precise in the way they work. When I worked with American colleagues, they weren’t so precise. And when you work with a New Zealand colleague, then it was fluffy. 

Bianca: BUt that’s why Agile was successful for us. Because there’s a framework it’s even to the point where this terminology and sentence structures that you use in the rituals, helped get getting closer together. Within the team and understanding each other better.

Murray: Did you have a problem where people wouldn’t speak up because they were concerned about authority? I’ve worked with Vietnamese teams where… only the most senior person would speak, and then they would speak on behalf of all of their Vietnamese colleagues because we were the customer. Do you have anything like that?

Bianca: I think that absolutely exists. There is probably a cultural influence on that. It’s probably also the organizational structure that you work in that has a big influence on that too. I have not experienced that specifically. What I did experience is that I’m in a room with the team that consists of. German people and Chinese people and maybe others. What happened regularly was that the Germans would have a heated debate. And this was so uncomfortable for my Chinese colleagues to be around, that they would physically retreat. They really did not want to be there. They were about to crawl under the table just to avoid being in that space. I think they were also really surprised to see that these German colleagues who were close to shouting at each other afterwards would be perfectly fine. Leave the room, have a friendly chat, go for a beer. So that’s more what I’ve, noticed. Not so much to do with authority, but just the way of how people would resolve a conflict. 

Shane: So I think you said that there were three or four squads. How were those teams selected? Because I’m assuming if it was self selection, people tend to flock towards their own culture. Did you find that? 

Bianca: The teams, were all working on different products, different websites that the company was producing. And so the teams were cross functional and I would say the selection was skills based.

Murray: Did they select themselves, or did managers say who should go on what team? 

Bianca: Probably both, definitely people were switching between teams. And sometimes teams emerged temporarily to work on a specific initiative or technical piece of work. This team that had all these technical experts who had been working together for a very long time, they were allowed to not do scrum and work in Kanban instead. And so they wouldn’t have to deal with, an annoying product owner constantly coming in and trying to tell them what to do. So there was a little bit of that pushback to this format that we had in the other teams.

Shane: So what do they do for shared language? Was it because they had been running with Scrum for a while, growing that shared language? And now they didn’t need the scrum ceremonies and language anymore because they’d formed their own language 

Bianca: The shared language is code, so this was development And they were working in very technical details. And I think they worked well together because they were coding in the same language. 

Shane: And so were they a team that was building for the other teams or they were still a team that was building a website? No. They were building services for the other teams 

So they could then speak to their customer directly. They knew exactly what They needed because it was a technical conversation. 

Bianca: Absolutely right. And that’s one of the major differences that I’m seeing with my work now from the work back then is I was the only person speaking to the customer as the product owner. Nobody in the team did. That was obviously a problem. But it would have been extremely difficult to arrange at the time with our customers being six hours away. Different time zones, different language, different culture. Would have been very difficult to do, but that was obviously, I was a gatekeeper for the customer voice. This is absolutely not what I’m recommending to do now. 

Murray: Going back to this issue of whether people spoke up. Were people open and honest ? in your retrospectives? What issues did they bring up? 

Bianca: It was the scrum master who would elevate any concerns that the team had. And I think that was intentional to remove it from an individual and an individual performance, which people were concerned about. 

Murray: Okay. Did you get feedback that people were concerned about saying things in retros because they thought they would be personally blamed? Or is it just an assumption?

Bianca: It was an assumption based on my experience , in the culture. People weren’t speaking up. That was one of the key things we wanted to solve. And so in a retro, that’s a safe space to speak up. I, as the person deciding who can and cannot be in the team shouldn’t be a part of that.

Murray: So your hypothesis is people weren’t speaking up in Chinese culture because they were concerned about being personally blamed and they felt much safer in a team culture where the team was responsible and there was somebody who could speak on their behalf 

Bianca: That’s certainly what happened. So my assumption there was correct. Potentially it wasn’t, but it worked.

Shane: What was the culture like around the whole backlog management, the prioritization, the product roadmap, the budget, getting funding for new teams? 

Bianca: I would say tHere wasn’t too much of a cultural influence on the backlog management and prioritization, because then it was around the work and it was around the product and the content and what we’re building. And that worked really well because the teams were discussing about, what’s the best thing, what’s the best outcome, what’s the most important thing to work on. And that point of shared language that you were making earlier very much applied there. 

Murray: So I was wondering if I could get your advice for people who are dealing with developers in, China, Vietnam, in the more common scenario where you’re the client product manager. You’ve engaged one of these big companies. They have their own layer of management, who are managing you. And then there’s another layer of management in China, managing the Chinese developers. 

Bianca: First of all, it’s definitely not cheaper anymore in China, if anything, it’s maybe more expensive now. And there’s a lot of risk around it. Also, I can’t speak for today’s China cause I left eight years ago. BUt you have two options. Either you, document your expectations and specify exactly what you want in a very detailed granular way, and be super clear and be micromanaging everything, anti agile, I would say. Or you have to understand how teams work on the other side and you can’t make assumptions that they will be working and thinking like, you do yourself. 

Murray: I think also you were working with the developers in China directly, in China. Whereas when somebody’s in a different company, maybe it’s even two different companies. There’s multiple layers of barriers in, between you as the client and, the developers. Which makes it very difficult, and I imagine it’d be quite different if you’re actually embedded with the people, and probably a lot easier in that case. 

Bianca: Absolutely. It is very different and it’s a lot easier. And that point that you were making about being removed from the teams applies the other way around as well. I’ve worked in an agency before and teams working for a client. And one of the reasons that I didn’t enjoy it was I never got to talk to the customers. It was always a step removed. And that’s the same, I would imagine for those offshore teams that just get a set of requirements through a number of people. They don’t understand the customer problem they’re solving. They don’t even know who the customer is. So then you have all of those problems that come with that setup. 

Murray: Can I just follow up on something you said about risk? What is the risk issue with working with China? 

Bianca: I would be worried about the data predominantly. 

Murray: Hey Shane, how about we go to summaries? What do you think?

Shane: One of the things you said is that you picked a workplace language. You pick English as the default language, but everybody moved in and out, but you actually consciously said we need a shared language and we’re going to start with that one. And the teams created the shared language based on language of work. So was the language of code, the language of user stories. And then using scrum gives them a language they can start with. But at some stage they’ll outgrow it and they need to move on to better ways of working for them. 

And the other thing is that there was no learned behavior from another culture. So because you hadn’t worked in Germany and because you hadn’t worked in a corporate environment and you hadn’t worked for a software developer, there’s a whole lot of learned behaviors you didn’t bring. So you didn’t bring what you knew would work and try and retrofit it into a culture that may or not worked, you just basically absorbed it and then as a team, did it. And so, I think one of the things I got out of this was that you were starting together with a shared problem, so you formed as a team. So this idea of blended squads, where, the cultures have to mingle, and deal with the adversity that gives, is probably a good thing, otherwise you end up with a them and us and nobody’s ever right.

So that was me. Murray, what do you got? 

Murray: Yeah, the only examples I’ve ever heard of people saying working with a team in a developing country went well is that the people involved went there, and they built cross functional teams. You have to work as one team, not as different teams. So you are one team, you and the Chinese people who are working with you, you all work for the same company, you’re all part of the same team you are all focused on the same goals, the same outcomes. And , therefore, you solved all the problems you had collectively. And you adapted to each other’s culture. And I think that was because you were young and new, and you didn’t come with a lot of baggage. And, it sounds like Agile helped you a lot.

I want to contrast that with the experience I’ve seen a lot of. I’ve worked with a lot of offshore teams, too but as a client. And in all of those cases, they were not getting the benefits that they expected. 

They did it to reduce costs and ended up costing them much more than they expected because it would generally take three or four people in the offshore team to do the work of one person in the onshore team beCause of big differences in capability and skill. Because you get a lot of young people who only have a couple years experience versus 15 years experience on shore. 

And also so many layers of management. If you have a team of five developers, you would have Maybe eight people managing them in between you and the client and the communication barriers were massive. Imagine if you’ve got three or four layers of managers between you and a developer, who are all trying to tell you what you want to hear. So everyone’s telling you it’s going great, but nothing ever gets done or the quality is dreadful. It’s a very common experience. And it’s so hard when there’s so many people in the way who are not telling you what’s really going on. So I think the secret is one team of people working together openly and honestly without all of those barriers. That’s the way to make it work. 

Bianca: I completely agree with that, especially around the incentive structure that you mentioned. It was people’s job to tell you everything’s going well, then that can’t work. So you need to have that direct feedback. And also that doesn’t sound like an agile structure to me at all. 

Murray: Oh everybody’s saying it’s Agile, it’s just that they’re pretending. They’re doing sprints!

Bianca: Yeah, 

Murray: Well, that’s what I’ve got. Did you want to reflect on anything we’ve said? Bianca? 

Bianca: I think you were on point there, saying this was the people, the team trying to solve problems together and using agile methodologies for it, which is why I’m still a fan to this day. And it has changed a lot since then. And the way we talk about it has changed a lot. Now in my role at Trademe, I hear a lot of people talking about agile practices but nice to bring it back to those beginnings and actually understanding why we introduced it and what problems we were trying to solve. 

Murray: Yeah, people and interactions over processes and tools. 

Okay. 

Where can people find you and read about you what you think?

Bianca: I do that typically in talks. I’m not really so much of a writer. I do have a LinkedIn, of course, that people can reach me at, but I like to have interactive discussions rather than pouring my thoughts out onto an article.

Murray: Great. Thanks for coming on Bianca.

Bianca: Thanks for having me.