Improvement, Success and Failure: Scrum Adoption in China

Recently, InfoQ China did an investigation on how Scrum is adopted in China. We picked 5 cases for this article: they come from different types of companies, used different processes, and got different results.

The small sample size is small, and the companies didn't take the same steps, still, as we focus on how they adopt Scrum (whether successful or not) we will learn a lot from them. As Mike Cohn said in his forward to "Scrum and XP from the Trenches":

"...we can all learn how to do Scrum better by hearing stories of how it has been done by others, especially those who are doing it well ... Instead of best practices, what we need to know are good practices and the contexts in which they were successful. Read enough stories of successful teams and how they did things and you'll be prepared for the obstacles thrown at you in your use of Scrum and XP."?

The questions asked by InfoQ were:

1. Why did you use Scrum on your project?
2. How did you adopt Scrum in the project, and why?
3. What's the biggest problem during the adoption, and how did you solve it?
4. What's the benefit that Scrum brought to your project, your company?
5. Why didn't you adopt Scrum successfully? Would you please describe the process?

The interviewees and their enterprises are described in the table below. To respect their companies' security needs, we didn't use their real names in the article:

Q1. Why did you use Scrum on your project?

Julie:

The requirements change too fast; the product roadmap isn't clear; we need to improve efficiency, communication, make sure that the business department can get results a.s.a.p.

kaverjody:

Due to the defects in the waterfall development model, and other problems in our A&D department, we couldn't make improvements without changing the development method. The top managers made the decision that we would use Scrum to resolve the current problems, e.g. the cost of software maintenance is very high, delivering new version always took us a long time, etc.

Alex:

I first heard the concept of Agile when I joined NibiruTech on Oct, 2007. At that time, the most common Agile practice was the daily standup meeting. I had no idea about the effect of such a meeting. I tried hard to understand it and then found Scrum.

Well, you know, as a startup company, we had not much experience in management. We wrote a management system by ourselves, and we used it together with Trac for management. Scrum really impressed me, so I decided to popularize Scrum inside the company.

Q2. How did you adopt Scrum in the project, and why?

Julie:

We're not using pure Scrum. Instead we mixed Scrum with many ideas from Agile, including practices from XP, and made improvements using Scrum retrospectives starting from the current development environment and requirements, and we finally found a way by ourselves. For example, if in one retrospective we find that we need to improve code reviews, then we would introduce new code review mechanisms in the next Sprint.

We used a bottom-up way. First, we did local experiments, with a small scope, and then made it spread more and more widely. We also did improvements to the process during the adoption:

2006 / 03 to 2006 / 06 - used it in one team, about 8 people
2006 / 06 to 2007 / 12 - used it in three teams, around 25 people
2007 / 12 to 2008 / 01 - used it in one department, 6 teams, around 50 people
2008 / 01 to today - using it in distributed teams. We're still building collaboration methods, tools, processes, etc.

kaverjody:

It was decided by the top managers that we would use Scrum in our organization.

Alex:

I didn't think about how to adopt Scrum at that time, I just shared all the information with CEO and my teammates.

When asked by InfoQ, "How did you decide what steps to take, during the experiment? Did you just concentrate on the existing problems, and take some appropriate agile practices to resolve them? Or some other way? " Julie answered:

Actually we didn't use the buzzword "Scrum" at first. We discussed with the business guys about the release date, resulting in a release every month. Then we had daily stand-up meetings for management; and project conclusion meetings for improvement. We put both production reviews and team retrospectives into the conclusion meetings. The product manager would explain the current situation, and all the team members would discuss our achievements, challenges and shortfalls. For the planning meeting, we followed Scrum from the beginning. MS Project isn't suitable for a small project, so we changed to a Scrum Excel spreadsheet, and later to Xplanner.

After some months, we called everyone together and hold an Agile method-sharing meeting, summarized all the practices that we've used, and explained the meaning of XP, Agile and Scrum. Then almost everyone looked as if wakening from a dream: "Wow, we did use Scrum in the past months!!!"

Our achievement was also confirmed by the top managers, and we're allowed to share our experiences with other teams, so we picked some teams as pilots. Since developers might switch between teams, it would increase management cost if one team uses MS Project and another uses XPlanner, so finally we got an order to use Scrum in the whole company.

Q3. What's the biggest problem during the adoption, and how did you solve it?

Julie:

First of all, we needed to get the boss to support us. And then, to tell the truth, adopting Scrum is pretty easy, much easier than CMMI.

The most difficult thing is that you need to resolve the problems revealed in the process, such as:

1. "We don't have clear requirements, resulting in a high cost of communication in late stages. We spend too much time discussing with the product manager again and again."
2. "Delivery cycle is too long: our Sprint is 3 or 4 weeks long, but the product manager hopes we can deliver two versions per week."
3. "We cannot master the historical requirement and the product architecture based on the Scrum characteristics."
4. "The delivery date is fixed by the business guys, so we don't have time to do unit tests, nor code reviews."
5. "We cannot clearly see the bottlenecks between tasks, or how to coordinate everyone."
6. "We need at least one week for analysing the data after deployment, it's impossible to conclude how to make improvement right after the current sprint."
7. "The pace of development is too fast, we don't have enough time to stop and do a good retrospective. The historical requirement isn't fully used."

kaverjody:

For me, the biggest difficulty is in misunderstandings of Agile among my colleagues. They might just see the concrete tools and development practices, but don't understand the idea behind the decisions. Why we choose these tools? Why we pick up these practices? Do we have standards while choosing the practices? It is only in the choosing process that we can see what Agile values.

There's no way to reach the goal in one step, we can only educate the colleagues continuously. And also, we need to analysis and resolve the problems in time, and hold a case study after that, explain why we resolved the problems this way, and how to deal with the similar problems in the future.

Alex:

I think there are two big difficulties before adopting Scrum:

1. The support from top level.
   I think it's a common problem. But Jeff Xiong has published an article on InfoQ China: Agile step by step: how to do agile bottom-up, which says, if the top level doesn't support Scrum, then block the top level and just do Scrum inside the team. Thank god, our CEO and CTO both support Scrum.
2. Scrum training for employees.
   My colleagues don't understand Scrum clearly, so I organized a Scrum training. We discussed our questions together. And during the adoption, everyone became more and more familiar with Scrum. Of course, the guy who popularizes Scrum must be familiar with Scrum.

Later, InfoQ asked everyone to introduce their solutions in more details, Julie said:

As to the first problem - "unclear requirements", we made an universal template for all the requirement document, and add a requirement discussion meeting before the planning meeting. Product manager, testers and developers will join the discussion.

And for the second problem - "long delivery cycle", we added management for daily "sustaining" product maintenance requests, in addition to our regular deliveries. The product manager collects the maintenance requirements, such as "modify pages", "add/delete data". These requirements are submitted to the engineers in the stand-up meeting every Tuesday and Thursday morning, to be delivered the same afternoon.

Alex said:

We are in a good state of adopting Scrum. Maybe it's because I didn't grasp Scrum very well, and only used some features, but I have a belief: we should find our own version of Scrum in the iterations, in the successes and failures. We happened to have a project with unclear requirements. During the sprint planning meeting, we listed out the technical steps on the board based on the known requirements, took the implementation order as the priority ... the iteration was only 10 days, so that we still could manage the schedule as a whole. In the stand-up meeting, everyone puts the items which will be implemented today on the board. It can improve the team's self-organizing ability.

Q4. What's the benefit that Scrum brought to your project, your company?

Julie:

I think it's hard to measure the benefit created by Scrum. We did an investigation inside the teams and got some general information:

kaverjody:

It's hard for me to draw a conclusion here. The benefits that I can see include: we can get the feedback on features more frequently; we can figure out some problems on the early stage, e.g. multi-site development and cooperation, retrospectives and improvements.

Alex:

We're using Scrum in the whole company, including Development, Sales and HR. We don't introduce Scrum to the new employees, they can become familiar with Scrum during everyday work. I cannot say how big the revenue is, but it helped us work happily, full of energy, and we finished our iterations before the deadline. We're preparing for the next project. In short: we're still adopting Scrum.

Q5. Why didn't you adopt Scrum successfully? Would you please describe the process?

David:

Our problem is: some guys on the top level misunderstood Agile and Scrum, made Agile a formality. For example, we have a Scrum Master on one big project, which went very well. One project manager found it good, and began to push Daily Scrum in several projects; but he doesn't know what's Agile, what's Scrum, so Daily Scrum became Daily Report because of him, and the core principles of Scrum aren't followed.

Everyone must attend the Daily Scrum at the fixed time, to tell the manager about his/her tasks today; then the manager decides whether he/she should take more tasks or not. It sucks. The "Daily Scrum" was cancelled, finally, as everyone felt it was too boring. And later there was no one talking about Agile in the company.

Fiona:

I'm in a distributed team, and the Chinese team only knew a little about Agile at first. One day, the PM abroad sent us several links, which talked about a strange word - Scrum. We were only given one or two days to read the introductory documents on Scrum, and then we began the Stand-up Meeting. Actually, everyone knows the importance of communication, but we have 6 to 7 hours' time difference, so when they came to work in the morning, we would be going to clean up the table and go back home. It didn't improve our communication, and was given up after one or two weeks,. We tried to do stand-ups inside the Chinese team, but the biggest problem was the culture difference between teams and the project planning. The stand-up meeting didn't bring us much value, and became a formality very soon, and finally given up.

We didn't have planning meetings. We had a so-called Product Owner, but he never explained the details of each story, nor did he define the Done status. We tried Retrospective by ourselves, but the feedback got no response from the team abroad, and we gave up later.

When we first used ScrumWorks, the Product Owner did prioritize all the stories, and we did estimations. But now everyone can throw stories into ScrumWorks, and no one says which is more important than others - we developers have to decide it. If we left hundreds of stories in this sprint, they would be just thrown into the next one.

Too many things happened in this project, although it still goes on despite all the difficulties, but anyone talking about Agile in our company will make me feel queasy.

Summary

There happened to be a heated discuss about Scrum in Agile China Google Group right after I finished the Chinese version of this article, which might be reported later. But reminded me of the famous words of Shakespeare: "There are a thousand Hamlets in a thousand people's eyes." So: what do you think about Scrum? And how did you adopted Scrum in your organization? Would you please share your experiences with us?

About the author

Jacky Li is the Lead Editor of InfoQ China/Agile Community, specializing in Java and Agile software development, and has been devoted to popularizing Agile in China. He is the translator of InfoQ minibook: Starting Struts2.