Key takeaways
|
I read an article saying that Scrum doesn't work in Asia. What its author said is quite right. However, it’s not impossible, and I have some tips for installing agile/DevOps successfully in Asia that I’d like to share with you.
I'm Tsuyoshi Ushio. I've been an agile/DevOps practitioner and coach for 15 years. I have helped a lot of companies to install agile/DevOps in Japan and Vietnam – startups and established companies in gaming, SI, services, and enterprise. I'm currently working for Microsoft as a technical evangelist for DevOps. I can vouch from personal experience that it is difficult to install agile/DevOps in Asia. This table hints why.
(Click on the image to enlarge it)
Figure 1: Country’s cultural resistance to agile-style work.
Alistair Cockburn, one of the fathers of the Agile Manifesto, tweeted this table. The tweet said that Japan is the most difficult country in which to install agile-style culture and its agile resistance index is exceptionally high.
However, if you understand Japan’s cultural background and how to work with it, installing agile there is not difficult. I'd like to introduce one typical installation process of agile/DevOps in Japan, which works well in Japanese culture.
And since Japan is the most difficult country in which to install agile but has similarities with other countries in Asia, I believe this approach would work well across Asia.
I have used these five steps for installing DevOps in Japan:
- presentation and demo,
- value-stream mapping,
- install Western culture and readiness for DevOps,
- DevOps hackfest, and
- continuous improvement (kaizen) and continuous monitoring.
I'll explain these steps.
1. Presentation and demo
From my point of view, Westerners are good at learning from theories and abstract concepts. However, Japanese people usually prefer to learn by example. It’s a difference in learning style. If you want to share the idea in Japan, you need to first focus on a practical example.
Because agile and DevOps are ambiguous concepts, different people have different ideas about what they mean. It’s important to share the understanding of what they mean with the stakeholders of your project.
That is why we need to start with a presentation that includes a demo. The demo is important, as it will illustrate a real-world case. This approach works well for Japanese people.
2. Value-stream mapping
(Click on the image to enlarge it)
Figure 2: Value-stream mapping.
Value-stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that are needed to deliver a product or service. It helps to identify the problems in the process and reduce the lead time.
It also it works well for addressing the people element.
Figure 2 is an example of value-stream mapping. It represents all process steps from coming up with an idea all the way through to releasing it into a production environment.
Each process step has a lead time and a process time. By drawing this map, you can easily identify the waste in the process and find opportunities for improvements and automation.
I always call all stakeholders to attend a value-stream-mapping session: developers, operations, program manager, UCD, etc. You need to ask everyone who has permission to change the process to participate in this event.
Japanese culture is hierarchical. Unfortunately, devs and ops don't have power, so you need to include upper management.
Unless a manager is there, devs and ops will be afraid to change the process because they don't have permission to do so. They believe that they can't change company rules and processes by themselves. But by including the right person who has that power, the activity can produce beneficial change. Many upper-management people have a passion for making positive changes but it’s necessary to put them where they can learn what needs to be changed.
Once they experience this kind of success, employees start to learn that they can change the processes and rules more easily than they had expected.
Value-stream mapping also excites people about their ability to make change. Fear will lead to initial resistance but after a value-stream-mapping session, people learn that they have the ability to reduce lead time. They realize they can do it. This recognition is important.
You can estimate lead time from value-stream mapping, which helps secure permission from upper management. How can management resist approving if asked, “Hey, we can shorten the lead-time from eight months to one week. Can we install DevOps?”
3. Install Western culture and readiness for DevOps
A lot of people might observe that Scrum and DevOps come from Japan. The origin is Toyota and Nonaka’s paper!
Yes, true. However, people with Western cultural backgrounds took the source material and invented agile and DevOps.
(Click on the image to enlarge it)
Figure 3: Agile and DevOps are based on Western culture.
For this reason, if you directly install Agile and DevOps in Japanese culture, it causes conflict: the Japanese emphasis on hierarchy tends to clash with the idea of a self-organizing team, the evaluation systems used in Japan are not necessarily suited to agile, there are learning style differences, etc.
What should you do? You can install the Western culture before installing the work practices. Of course, you do not have to change the whole culture – just the part of it that will bring improvements in productivity.
A lot of people think that they can't change their culture. I used to think the same thing. So I tried to adapt agile to Japanese culture and our customs. However hard I tried, though, the power of agile was limited because I needed to compromise a lot. Teams operating in my adapted agile were not as productive as teams in the U.S.
Before joining an international team at Microsoft, I’d only worked for Japanese companies. I have started to realize the differences between Westerners and Japanese – the learning style, mindset, values, and so on. I have become convinced that agile and DevOps are based on Western culture. And once I tell team members about the cultural differences, they recognize the differences and start to learn from them. The installation of agile and DevOps becomes much smoother, and we can apply agile more deeply than before!
I now always use this strategy, which works very well. But before joining Microsoft, I'd never noticed the differences!
For example, Japanese people tend to focus on input rather than outcomes. People value someone who has been working for a long time.
Someone who produces a valuable outcome within a short span of time is not welcome. That is why Japanese workers have low productivity and why they work such long hours. Someone finishing work at 5 p.m. and leaving for home is considered and sometimes told that they are lazy.
(Click on the image to enlarge it)
Figure 4: Low productivity in Japan.
Furthermore, Japanese people want to make everything perfect. It leads to a lack of prioritization (and a lack of ability to prioritize). We want to polish EVERYTHING.
Led Zeppelin said, “Sometimes words have two meanings.” They were right.
If a friend of mine is overwhelmed, I might say, “Hey, you need to prioritize your backlog, then focus only on the important stuff!”
My American friends will pick the most important item, focus on it, and ignore the less important ones for now.
My Japanese friends will pick the least important item, mark it out of scope, but still try to deliver it. If they can fix it, they will. It’s a small issue and easy to work on, so they just do it. Then my Japanese friends focus on finishing the rest of the problems without taking a rest. They don’t prioritize and teams work long hours to try and deliver everything.
(Click on the image to enlarge it)
Figure 5: The approach in Japan versus the U.S.
This Japanese mindset is far from agile/lean thinking. Western people focus on how to produce with less effort. It is one of the fundamental differences between the two cultures. For this reason, jobs of equal value could take ten times longer in Japan than in Western countries. The statistics show that Japanese labor productivity is just 62 % of the U.S. level.
If a Westerner explains an important concept, someone who has a Western cultural background usually easily grasps the idea. However, a Japanese person might misunderstand the concept even if they can understand the words. People of the two cultures often see the same thing in different ways.
Once we understand and share the practical differences between the cultures, we can mutually recognize the actual meaning of the words.
However, people in Japan just don't recognize this difference. Once I explain the difference and show how they can become more productive, they are pleased and try to follow the idea. I call this mindset "Be Lazy" – in other words, try to minimize effort and maximize output. I find that Japanese like this concept once they try it. I also explain other differences between the two cultures.
(Click on the image to enlarge it)
Figure 6: The “Be Lazy” mindset.
My teams are pleased with the results. For example, one team successfully shortened the lead time from 13 days to two days in a few months!
Another important area to pay attention to is the readiness for agile/DevOps. Japanese are very good at “learning by example” and doing things even before fully understanding them. This is quite different from Americans, who love to understand everything. Japanese people have trouble understanding a concept without seeing an actual example. Many of them misunderstand the agile/DevOps concept. Their rate of misunderstanding greatly exceeds what I see in the U.S. For that reason, I recommend observing their agile work and checking to see if they are missing something.
It’s important to make sure that Japanese have already absorbed the concepts of DevOps, agile process, mindset, TDD/BDD, OOP, and so on before proceeding. If they didn't understand one of those things correctly, fill the gap. That works well. And remember that they can learn especially quickly if you share actual examples.
Another thing to remember is that many SI companies in Japan use the waterfall work style. If you want to install agile/DevOps in your company, you need to find someone who has already experienced agile development. The sales guys from SI companies might say they can do agile but don't take those words at face value. You should carefully talk with them to find out whether they have a real understanding of agile mindset and culture.
4. DevOps hackfest
This is an additional effective technique for DevOps. If you have already gone through value-stream mapping, you have likely already found a lot of waste and room for improvement. You already know which processes you can automate.
(Click on the image to enlarge it)
Figure 7: The DevOps hackfest.
Having done that, you can go ahead and automate it with some professionals. I help my customers to implement DevOps and hold hackathons with them to automate their build/release pipeline. Not only does it accelerate automation and shorten the lead time but also it is a good method for skills transformation.
5. Continuous improvement (kaizen) and continuous monitoring
Improvement is not a one-time activity. Also, just one hackfest won't change everything immediately. Let people continuously track their outcomes.
Don't rush them. Sustainable pace is important. Let people kaizen at their own speeds. Let them think by themselves.
It may sound strange to say this, but many Japanese people are bad at thinking for themselves at first because of the Japanese custom of following the commands of an elder. However, if you keep delegating to them and encouraging them, they start thinking and innovating!
Conclusion
This process might seem overly simplified but it has produced good results for me. I believe that you can install agile/DevOps in Japan that operate like those in Western countries, if you follow this approach.
Asians might start with a different culture and mindset, which could prevent them from taking on proper agile/DevOps. Once they understand the Western mindset, however, the differences become an advantage. For example, Japanese can be more innovative, if they can be productive. The different way of thinking leads to different points of view in your team. However, it won’t work unless you can be competitive through productivity.
Right now, I’m working on further developing and refining the “cultural installation” method by collaborating with a cultural-change professional, Rochelle Kopp. She knows both Japanese culture and Silicon Valley culture very well (and is the author of books on both, including The Rice-Paper Ceiling: Breaking Through Japanese Corporate Culture, Valley Speak: Deciphering the Jargon of Silicon Valley, and a new book coming out soon called Creating Engaged Employees in Japan.) I plan to keep on improving the methods described in this article by working with her and my customers.
An American friend has told me that Japanese agile/DevOps adoption lags five to eight years behind the U.S. But I have a dream: one day, people in Japan will develop software and install new ideas at the same speed as they do in the U.S.
About the Author
Tsuyoshi Ushio works at Microsoft as Technical Evangelist - DevOps. He is an organisational change professional using Agile and DevOps concept and techniques. He’s helped various sizes of organization from start-ups to major enterprises to adopt agile principles for more than a decade. He’s now interested in DevOps that would change the world of software development. A speaker of Agile 2011 and Agile Roots 2014. A best seller book author in Japan.