LeSS Conference Experience - Munich 2019

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.

Tremors

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.

My Learnings

On Product Manager in the Team

(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.

On "Product Teams" and "Feature Teams"

(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.”

Introduction to the Japanese Edition of the LeSS Book

(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実践者研修を世界中で教えてきました。システム思考は研修のアジェンダの1つでシステムモデリングをツールとして使っています。最近、東京で研修をした数週間後にサンフランシスコで研修をしたのですが、2つの研修は対極にありました。

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

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

まとめ

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