It is with much trepidation and anticipation, that I decided to make the pilgrimage to Munich to attend this year’s LeSS Conference at the Paulaner am Nockherberg that happened between 12th to 13th of September, my very first. I know myself enough that travelling anywhere that wrecks havoc to my bio-clock has typically turned out torturous and eventful for me. However, I am curious as to what to expect and what I can gain attending THE annual LeSS event. There is a lot that I know that will put me into my uncomfortable zone - a brand new place I have yet to visit, a country with a language I do not speak, fresh new faces with people from countries and cultures very different from what I have grown used to in my 40 odd years growing up in Singapore.

We booked an Airbnb place, near-ish from the conference venue. I was warmly received by my Shanghai colleague, Joseph, on the early morning of 9th September, who waited at the train station, which is close to where he stays, and happens to be a short walking distance from where he currently coaches - BMW; Incidentally BMW is presently, undergoing a huge organisational transformation, to adopt LeSS, and find a better approach towards product development for their Autonomous Driving Program.

The next 2 days for me was an eye-opener, especially from the perspective of a developer of the LeSS website. I joined the LeSS trainers meeting. I got to meet LeSS stalwarts such as Jürgen De Smet, Elad Sofer, Cesario Ramos, Ran Nyman, Wolfgang Richter and Craig Larman, which gave me first-hand interactions and feedback directly from whom cared most about the LeSS community and the LeSS website. It was obvious everyone placed a strong emphasis on building up the technical capabilities of developers, that being an important pre-cursor, before even attempting to introduce organisational changes towards LeSS. We will, therefore, be introducing a feature to allow LeSS trainers to add recommended courses and events that shepherd developers towards levelling up their technical foundations on the LeSS website.

I turned up Day 1 of the Conference to the majestic venue of the Paulaner am Nockherberg restaurant and beer garden. It was breathtaking. Huge halls, a cosy beer garden for team events and social activities, which fit well, for the nature of the conference. My colleague, Ivan, was anxious about the potential chaos that might ensue, during Day 1 of the Conference when a large number of people would turn up at registration, encountering registration exceptions, and given his previous experience in 2018 NYC LeSS Conference. It turned out, given sufficient logical signs and directions along the Conference entrance, it quickly proved that self-organisation works. We had zero incidences of registration exceptions, and both Ivan and I ended with nothing to do at the “Registration Exception” handling table.

Bas kicked-off the conference and shared that LeSS Conference 2020 will happen in Amsterdam. In the keynote by Cesario and Nadine that followed, on “LeSS at ING Business Lending”, they shared, how ING moved from their existing Spotify Model in their LeSS Adoption. Teams went through preparations for the transformation, attending CLPs and technical training, while dislocated teams were organised around the business lending product. They used technology to enable mob programming across geographies.

There was a huge bazaar thereafter, that enabled people to quickly get acquainted with one another and within a short 15 minutes or so, teams with at least 5 members with maximum diversity were formed.

One key takeaway, after attending Michael James’ “What Are The Biggest Disadvantages of LeSS?”, is that, there is a wealth of knowledge, to be unearthed, from people in conference participants, that perhaps, has a good fiddle on what is and is not, a good thing to do, if one is to tilt an organisation, inch by inch towards becoming more agile. We learnt a lot, sharing experiences and pains, which each of us in the teams formed in the workshop, that gives us empirical evidence, of what paths, organisations have taken, that moved the needle, either away or towards being more agile.

In Jacek’s talk on “Working with pain in organisational change”, I learnt that it is important to be aware of how the pains experienced by individuals during a large organisational transformation, triggered by the intricate cause and effect between our System 1 Thinking and System 2 Thinking, will, work against the best-intended efforts during a LeSS adoption. By first finding a commonly shared belief with everyone involved as a starting point - gearing teams up with technical practices training in TDD, Continuous Integration, etc, becomes useful and important, in preparing an organisation for the flip, which relies heavily, on being able to practice and execute those technical practices well.

I did an Open Space topic on Kent Beck’s strategy for scaling software development collaboration - Limbo, suggested by my colleague - Terry. There were a lot of discussions and questions surrounding, how the fast small diff commits of TCR proposed in Limbo, would work, where you still had to pay attention to code quality, yet, direct you towards the intended solution for a feature. There was a lot of questions surrounding how the cadence of the commits, might result in chaos with conflicts and whether refactoring, might take a back-seat, given, it may take more time and larger change-sets. I had an extended discussion over lunch with Robert Batůšek from Solar Winds, as he missed my Open Space session while attending Lv Yi’s “Number of Backlogs and Multilearning”. He is excited and eager to experiment to introduce Limbo/TCR in his coding-dojo sessions with his teams in the Czech Republic. He has been organising software craftmanship coding dojos with his teams where he works, in Solar Winds.

In a parallel Open Space topic by Michael James and Aki, they shared, how Odd-e Japan, worked with a robot companion startup. A lot of vibes and interests surrounding the hardware and software integration and sprint cycles. I see a lot of these topics and interest in quite a few other occasions in the last 6 months or so. IoT, 3D printing, and product companies that build more tangible and material products are emerging very quickly recently, that could explain, the explosion of such interests.

In Day 2, Craig talked about Chicken Breeding. A huge takeaway for me was that a lot of problems that we are faced with in organisations today, have been well studied with case studies and opinions around how you might go about tackling them. These are well-studied problem space, with well-formed opinions and knowledge that are there, for the last 3 to 4 decades. A must-read book for me, out of the session, is “Governing the Commons” by Elinor Ostrom.

The talk by Anshul, “Banking on LeSS” struck closest to heart for me. I have spent 6 months in his organisation, helping with the LeSS Adoption, along with my colleagues Terry and Ivan. Bas had spent a year before, getting the organisation ready for the changes to come. Anshul shared, how over the last 1.5 years, the journey taken by his organisation, to adopt LeSS. A lot of training and preparations were done before they made any organisational changes. Teams were sent for CLP training, and technical training (Certified Scrum Developer courses), and working spaces were re-structured, that befits and allowed easy open space collaboration and interactions. Product owners and line managers were coached and they formed a Scrum Masters community, which were initially shunned by the managers. He shared the term NATO - “No Action Talk Only”, which were used by managers to describe the scrum masters community. That brought about many chuckles from the audience.

Reflecting on my 2 days at the conference and 2 days at the LeSS Trainer meeting, I miss the Italian food in Munich ! There is a lot of energy and interest surrounding LeSS and the vibrancy of the communities in Europe is invigorating. I was pleasantly surprised to see fellow Singaporeans, who had flown 12 hours to Munich, to attend the Conference, some as speakers, others as attendees. Good to hear about their expectations and experiences over the last 2 days. I, came across, a couple of interesting individuals - a Physicist who is now a Finance Manager, a Chemist turned Agile Coach, an Electrical Engineer turned team scrum master, etc. Wasps at the beer garden during mealtime and social events were a constant annoyance for me. Those filled Oktoberfest Beer Mug were not good for tiny Singaporean arm and wrist of mine. All in all, meeting people, sharing experiences, sharing what an idea means and what each of us heard, from the conference, was a huge huge gift to offset my to-be yet again, jet-lagged body !

Last week I had a pleasure (and pain :)) of attending Less Conference in Munich. Here are a few words why it is such a great experience and why I would recommend it to anyone working within a team.

Firstly - it was a team-based event. It was my first experience of such a formula. I couldn’t have imagined how it would affect my learning abilities. By the 2 p.m. on the first day, my brain capacity was reaching its limits (hence the pain part :)) and then I’ve learned some more. I don’t know how but the atmosphere made it possible.

The second reflection I had was about the people. Wow. Just Wow. Being a Scrum Master for 3+ years I thought I had at least some things figured out. Well maybe, but being in the presence of practitioners with this amount of experience just knocked my socks off. When I overcame the feeling of being so small in comparison, I took a lot with me. From the calm mentoring from Less Trainers (Craig, Greg, Wolfgang and others) giving me a different perspective on the ideas I was kind of stuck with, to the empathetic connections we all made during workshops and talks regarding our everyday challenges. Also from the great Team, I had the joy to work with - Tremors.

Lastly - I’ve made a few connections in my mind that I think wouldn’t have happened any other way. I can honestly say it was one of my career-changing moments. I got inspired and I feel I have the guidance that I was looking for.

I am very thankful for this experience - unlike any other. It was evolving on many levels. You can not deny the amount of substantial knowledge you could get but for me, it was all about the emotional journey I needed to take.

(by Bas Vodde and Craig Larman)

On Product Manager in the Team

This post is the second in a series related to product management and product teams. Like the previous post, this one is partly influenced by Marty Cagan’s article on “Product Teams” vs “Feature Teams”. Marty seems to see the role of Product Manager different than we do, but the difference is probably more about the team than about the Product Manager. That said, this post is especially influenced by the frequent recurring question, “Should a Product Manager be on the Team?”

Being on the Team in LeSS

First, let us clarify that a little bit by exploring what “part of the Team” means in LeSS.

The Team has a shared responsibility for the result of a Sprint. A shared responsibility means that, even though people on the team probably have a primary specialization and a preferred focus area (which may not be the same, because of learning), all of the members of the team are responsible for all the work that the team does. In practice, this results in vague boundaries between the individual team members primary specialization, and in some teams not even a meaningful distinction.

A Team in LeSS (and Scrum) is also self-managing. What’s the implication of that on a team taking a shared responsibility? Key point: the team will need to have (1) a clear shared goal, (2) at the same time. We want to stress the temporal aspect here as it is rarely discussed but really important! When a new self-managing team is formed in which previously the team members were used to traditional siloed single-function roles, then if they continue that pattern, the team will struggle with finding ways to parallelize their work. The first and easiest questions is, how can we test before the implementation is done? Then, the same question needs to be answered related to the other roles that used to work in a sequential lifecycle with handoff, “How can we do the UI design at the same time as the implementation?”, “How can we do the analysis at the same time as the implementation”.

The fundamental problem that self-managing teams with shared responsibility have to solve is: How can we together in parallel work on activities that were previously considered sequential?

What would it mean if the Product Manager were part of the team?

When a Product Manager is part of the team, it will mean that the Product Management responsibilities are a shared responsibility within the team. However, one problem to solve here is that a significant amount of Product Management activities usually do not – or even can’t – happen at the same time as the activities of the rest of the Team for the selected work in the Sprint. This is mostly because of the delayed feedback of some of these activities. For example, if a Product Manager is out observing users or talking with them, then this activity is usually not at the same time and for the same goal as what the team is working on right now.

Just to be clear, we are not saying that it’s good that Product Managers don’t work on the same goals at the same time as the Team, we are simply observing that this is often so, and that it’s hard to change that in the context of the customers they work with and the organization they work in.

Considering this, we have seen two common alternatives of Product Management working with the team:

Product Manager as part of the team

This means the whole team takes on Product Management responsibilities (not just the person with Product Management preference). The team together discusses how to get closer to customers, understand them better, emphasize better, and discover potential new outcomes to achieve or new features to create.

It is likely to happen that the Product Management activities do not directly relate directly to the other work selected in the Sprint. In that case, the team needs to cope with the temporal differences, the work selected in the Sprint and the Product Management responsibilities related to understanding the customer, without creating separate roles within the team. For example, the entire team gets together at the beginning of the Sprint (Sprint Planning 2) to understand the Product Management activities and decides how they together are going to work on these.

Note that there is a similarity and overlap between Product Management activities and Product Backlog Refinement. Product Backlog Refinement is similar look-ahead work. A difference is that it is often possible to do Product Backlog Refinement work with the entire team together while it might not be feasible to always send the entire team to the customer (though maybe that’s not a bad idea…)

Product Manager who works with a team

Although in LeSS we love the Product Manager – and hence Product Management responsibility – to be part of the team, in practice we often see a Product Manager working with teams. In this case, the Product Manager focuses on Product Management activities (such as competitor and market analysis, and much more) and helps the teams to understand the market, customer, and problems to solve. Sometimes a Product Manager might work very close with one or several teams for a long time when the team works with customers or features that they know most about. However, in that case the Product Management responsibilities are not (yet) fully shared within the team.

In some cases, this is a first step to eventually moving the Product Management responsibilities into the team. In other cases, that won’t happen because (1) the focus of the team changes whereas the focus of the Product Management might not (e.g. in case the Product Manager is focused on a particular customer or customer segment), or (2) the Product Manager’s responsibility is intrinsically hard to share in the team, which might be the case when there’s lots of travel and customer relationships that needs to be maintained.

Conclusion

So, should the Product Manager be a part of the team? Which also means, should Product Management be a shared responsibility in the team? If you can do that, great! Alternatively, Product Managers can work with the team to help them understand the customers better.

On the Product Owner Role

Final note: We are talking about Product Management here and not the role of Product Owner. In LeSS, the Product Owner focuses on overall Product vision, prioritization, and investment decisions. In product companies, the Product Owner tends to be one senior person from a Product Management group, but not all Product Managers will be Product Owners.

(by Bas Vodde and Craig Larman)

On “Product Teams” and “Feature Teams”

This post has its origins in a post by Marty Cagan at https://svpg.com/product-vs-feature-teams/ in which he compares what he calls “product teams” with what he calls “feature teams.” We’re not quite sure where Marty’s definition of “feature team” originates from, as what he calls “product team” seems to be more like a feature team to us than his definition.

That said, the article is strong even when some of the reasoning is weak.

Weak Reasoning

logic weakness - Marty sets up his own definition of feature team (a straw man) and argues against his own definition; i.e. an argument from false premises.

logic weakness - Notice how the article’s argument is framed: either (1) you have “product teams” that are empowered and focus on outcomes, or (2) you have “feature teams” that aren’t. This is an example of the “false dichotomy” logic/argument fallacy, so widespread that we highlighted seeing this as a major thinking tool in the first LeSS book. And of course our suggestion is to consider more options beyond the false binary. For example, here’s a radical idea: How about a team in a large product group that can either be empowered to focus on an outcome with their own innovative discoveries, or that can take on a presented feature request and implement it? Mind… blown!

term weakness - Perhaps the name “product team” is more attractive to you. But notice that the name strongly suggests – although we acknowledge it doesn’t enforce – to the naive ear the idea that the team is creating their (narrow) product. For a fresh 7-people start-up with one team working on the Product, this is fine. For a growing start-up or a larger organization, these many narrow small “products” leads to a profound sub-optimization at the global level in terms of working on highest value, the switching cost of adapting to work on another existing “product”, lack of global vision and alignment, and difficulty of multiple teams to work together on a larger broader product.

You might think, it is just a term. But if you work for a long time in organizational development, you will notice that the choice of terms and the widespread misunderstandings that will arise from those choices is more influential than you might have imagined. We predict that “product team” will easily over time and space get misinterpreted as “each team has a product.”

Note: “feature team” suffers from similar weaknesses, as Marty’s article proves. The main reason for sticking to the term “feature team” is historical. The original use of the term in in Microsoft’s Visual C++ v1 and Ericsson’s AXE basestation – two wildly successful products. Also, we keep using the term because of our failure to find a better one.

Strong Points with which We Heartily Agree

That said, beyond these weaknesses, the article is reasonably good and there are some points that are really important and with which we strongly agree:

• The article reminds everyone of the importance of focus on the customer. Teams involved in building great products need to focus on the customer, understand the customer, live the customer.
• It reminds everyone the most productive feature teams focus on outcome and not on output, and with the freedom to innovate to achieve the outcome (thus the LeSS Guide: More outcome, less output). Teams become much stronger when you give them problems to solve than when you give them tasks to implement.
• It raises some important Product Management dysfunctions that we also frequently encounter.

The article also raises some other questions, which we will discuss in a follow up post. Specifically the question on whether a Product Manager should be a part of the Team. Unfortunately, the answer isn’t trivial and hence another post… “On Product Manager in the Team.”

(translation by Aki Enomoto)

This article was written for the Japanese translation of the LeSS book. The Japanese translation was added after the English one

Intro to Japanese edition of Large-Scale Scrum (English)

I still remember the first time I visited Japan about 15 years ago. For a European, who was living in China at the time, Japan was a different planet. Trying to understand Japan has taught me a lot about the country and myself… and LeSS. I’m grateful for this and would like to share a few of these learnings.

Respect for people

Having lived in several countries and traveling much too much has increased my interest in national culture. About ten years ago, I decided to explore the effects of national culture on agility. I read everything I could find about national culture. One of them was a book called “dealing with the Dutch.” The book explained Dutch culture to expats living in Holland. Something it mentioned, which I hadn’t realized but is probably very true, is that Dutch people cannot stop have an opinion. Even worse, they always want to share (force?) their opinion with others. They do this in a very direct way, which many Dutch consider to be transparent and honest.

I never doubted that the Dutch directness equates honestly until I lived in China and worked in Japan and Korea. These experiences made me realize that the Dutch directness is not honesty but probably rudeness. Dutch people are so consumed with expressing their opinion that they forget to consider the person they are expressing that to. They don’t take the other person into account.

A couple years ago, I visited a traditional Japanese company. I don’t Japanese and they didn’t speak English, but my colleagues said it is good if I’m there. They gave me detailed instructions on what to say, where to sit, where to watch, and what to do. The amount of conventions that I had to follow made me very uncomfortable. But in retrospect, all of them were about showing respect. Showing respect to the people you are visiting, talking to and working with.

Respect for People is one of the Lean pillars and originates from the Toyota Production System. I don’t think I would have understood that principle in the same way without having spent significant amount of time in Japan. I still have a vivid memory I have is watching a Japanese woman apologize to a beggar on the street that she isn’t able to give him anything. Showing respect, no matter what position you are or whom you are talking to, always respect the people you are talking to. Thanks for teaching me that.

Self-managing teams

Outside of Asia, people frequently ask me whether Scrum works in countries like Korea and Japan. Their reasoning is that Scrum is based on non-hierarchical systems and these countries have strong hierarchical society so it can’t possibly work. However, after spending a lot of time in Japan and Korea, I don’t agree with that reasoning and can clarify that.

A mistake that people make is equating hierarchy with management style. Hierarchy is the amount of power a person gives to a person that is socially above him. Management style is what you do with that power. Hierarchy can help self-managing teams as long as it isn’t combined with a controlling management style.

Hierarchy can help a LeSS adoption. This might feel strange, but makes sense. What happens when you adopt a non-controlling management style in a hierarchical environment? That would mean the manager sets expectations, shares vision, and perhaps set goals… without deep involvement on how people achieve these goals. A hierarchical relationship can benefit self-management because in this case, the team would not request additional instructions as it is clear they are expected to figure it out themselves.

No surprise that Toyota and Lean have a strong team focus. When you read the works of Taiichi Ohno then a lot of his management style is clear in goals and expectations and but not controlling.

Systems Thinking

My last observation that I’d like to share is more recent. The last years I’ve taught a lot of Certified LeSS Practitioner courses in the world. Systems thinking is one of the topics that I cover during this course using systems modeling as one tool. Recently I had a course in Tokyo and two weeks later a course in San Francisco. The difference between the two courses was like night and day.

In the Tokyo course, after explaining the notation of systems modeling and agreeing on a dynamic to model, the people quickly filled up the entire whiteboard. In the San Francisco course, the opposite happened. The people had a hard time agreeing on a dynamic to model, wrote two variables on the whiteboard and got stuck. They would argue about a detail and wondering how to proceed with the exercise. Of course, these are generalizations and are not always true, but still the contrast was surprising.

Why would this be? Of course, I can only speculate and relate to cultural theories that I’m familiar with. Eastern societies are more collective (hence self-managing teams working really well), long-term and holistic while western societies are more individualistic, direct cause-effect thinking, and short-term focused. This domightes clarify the difference in how easy it is to get started using systems thinking.

Conclusion

I’ve visited Japan often enough to say that it is part of me, it has changed me and my thinking forever. I’ve also visited often enough to know that I can never truly be part of Japan. It is a unique society with its strengths and lots of drawbacks. When I didn’t visit Japan for a couple of months, I miss it though and I suspect that I’ll continue to be there regularly for the rest of my life. For LeSS in Japan, I have high hopes. It will go slow and steady but there is a definitive cultural fit. I hope it can help transform Japanese product companies. And personally, thanks to the country and the people for all the insights you’ve given me.

大規模スクラム(LeSS)の日本語出版に寄せて

私が15年前に初めて日本を訪れた日のことを今でも鮮明に覚えています。中国に住んでいるヨーロッパ人にとって、日本は異なる惑星のようでした。日本は私に多くのことを教えてくれました。国や私自身、そしてLeSSについて。私はすごく感謝をしており、皆さんに私の学びをいくつか共有したいと思います。

人への尊重

多くの国に住んだ経験と多くの旅の経験（多すぎる）が増えるにつれて、各国の文化について興味が湧いてきました。10年ほど前に、国の文化がアジリティにどのように影響するかを探求することにしまし、国の文化に関して書物を読み尽くしました。そのうちの1つが「オランダ人の扱い方」という本でした。この本はオランダの文化についてオランダに住んでいる外国人向けに書かれたものです。この本に書かれていたことで、私も気がついていなかったことが書かれていました。それは、「オランダ人は何に対しても意見を言わずにはいられない」ということです。悪く言うと、「自分の意見を相手に共有（強制）する」というものです。しかも、オランダ人は包み隠さず率直に意見を言うことが透明性であり、誠実であると考えていると書いてありました。

私はオランダ人が考える率直さと誠実さが同意義であるという考えに疑いを持っていませんでした。しかし、中国で生活したり、韓国や日本に訪問するなかで考えが変わってきたのです。これらの国で経験を通じて学んだのはオランダ人の率直さは誠実ではなく、無礼なことであるということです。オランダ人は自身の意見を伝えることに夢中になるあまり、伝えている相手のことを考えることができてないのです。

数年前に私はとある典型的な日本企業を訪問しました。私は日本語を話せませんし、彼らも英語を話せませんでした。ただ、私の同僚はそれでも私が同行することに意味があると言っていました。彼らは私に何を言うべきか、どこに座るべきか、どこを見るべきか、何をすべきか詳細に説明してくれましたが、私にとって多くの指示に従わなくてはならないことは心地よい体験ではありませんでした。しかし、ふりかえって考えてみると、それらの指示は全て相手を尊重する為の行為だったのだと思います。訪問先の方々、話しをしている人たち、一緒に働いている人たちに対する敬意だと。

人間性尊重と言うのはリーンの柱であり、トヨタ生産方式からきた考え方です。もし、私が多くの時間を日本で過ごしていなかったとしたら、この考え方の本質を理解することはできなかったでしょう。また、今でも鮮明に覚えているのですが、ある女性が路上で物乞いをされ、何もあげれないことを申し訳ないと、謝っている姿をみました。人間を尊重するというは相手がどのような人であれ、話している相手を尊重することなのであると言う事を学びました。これを学ばせて頂いたことに感謝いたします。

自己管理チーム

アジア以外の場所でよく聞かれる質問として、スクラムは韓国や日本のような環境でうまく適応できないのでは？と聞かれることがあります。彼らの主張はスクラムが非階層組織を基本としているが、これらの国では社会全体が強く階層化されているので、機能しないのではないかと。私が多くの時間を日本や韓国で過ごしたあと、これらの意見に私は賛同できないですし、理由も説明できます。

よくある勘違いなのですが、階層型組織とマネジメントスタイルを同じに捉えている人が多いのです。階層型組織は自分より階層が上の人にどれくらいの権力を持たせるかということを示します。マネジメントスタイルはその権力をどう使うかです。階層型組織でも指示型のマネージメントスタイルでなければ自己管理チームを作ることは可能です。

階層型組織がLeSS導入の助けになることもあります。これは奇妙に聞こえるかもしれませんが、道理にかなっています。指示型でないマネジメントスタイルを階層型組織に適応したらどうなるでしょう？この場合、マネジメントは期待値を設定し、ビジョンを共有し、おそらくゴールも設定するかもしれませんが、どのように、そのゴールを達成するかについては深く関与しません。このような場合は階層型組織であっても自己管理チームであることのメリットを享受できます。なぜなら、チームはマネジメントに進め方を聞くことはなく、自分たちで考えることを期待されている事に気づくからです。

トヨタやリーンがチームを重要視していることは不思議ではありません。大野耐一の言葉を注意深く読み解くと、彼のマネージメントスタイルは明らかにゴールや期待値の設定のみであり、管理しようとはしていません。

システム思考

最後に私がみなさんと共有したい気づきは、最近あったことです。過去数年で私は数多くの認定LeSS実践者研修を世界中で教えてきました。システム思考は研修のアジェンダの１つでシステムモデリングをツールとして使っています。最近、東京で研修をした数週間後にサンフランシスコで研修をしたのですが、２つの研修は対極にありました。

東京の研修ではシステムモデリングの仕方について説明したら、参加者の方々は何をモデル化するかすぐに合意して、ホワイトボードをあっという間に埋ってしまいました。サンフランシスコの研修では全く逆のことが起こりました。何をモデル化するのか合意できず、２つの要素をホワイトボードに書いた時点で止まってしまいました。詳細について議論が始まり、どのようにこのワークを進めるべきか困惑していました。もちろん、これは一般化していますし、必ずしも同じ結果に毎回なるわけではありませんが、この２つの研修の対比は驚きでした。

なぜこのような結果に至ったのでしょうか？もちろん、仮説でしかないですし、私が知っている限りの文化に関する見解でしかないですが、東側の社会ではより協力しあうことに重きが置かれ（故に自己管理チームがうまく機能する）、長期的な視点を持ち、全体感を重視するの対し、西側の社会では個人が重視され、直接的な因果関係を注視し、短期的な視点を持っていると考えられます。これにより、システム思考のワークショップの結果に説明がつきまし、どちらの考え方がシステム思考に向いているのかは明らかだと思います。

まとめ

私は日本によく訪問するので、私の一部分と言っても過言ではありません。私の考え方に大きな影響を与え、与えられた影響は今後も変わることはないでしょう。同時に私が本当の意味で日本の一部にはなれないことも知っています。とてもユニークな社会であり、強みと同時に欠点もあります。私が数ヶ月の間、日本を離れていると、恋しくなる場所ですし、私の人生で常に訪問をし続ける場所であると思います。日本のLeSSに関して私は大きな期待をしています。ゆっくりと安定して進んでいくと思いますが、文化との相性が非常に良いと感じています。LeSSが日本のプロダクト開発をしている会社の助けになることを願います。そして、個人的に日本と私に多くの気づきを与えてくれた日本の人たちに感謝いたします。