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が日本のプロダクト開発をしている会社の助けになることを願います。そして、個人的に日本と私に多くの気づきを与えてくれた日本の人たちに感謝いたします。

How to form teams? A story of self-designing teams

(by Ahmad Fahmy and Craig Larman. Originally published at Scrumalliance.org in 2013)

Self-designing team workshop

How long does it take to reorganize to adopt Scrum in an organization? Three hours ;) …

Background and Goal

Bank of America’s Merrill Lynch (BAML) Global Securities Operations Technology decided to adopt Scrum, and needed some changes to do so. Key among those was forming real “Teams” in Scrum: dedicated true cross-functional and cross-component teams of about seven people that could independently perform all the tasks (analysis, development, testing, …) to deliver completely “done” end-to-end functionality.

Before adopting Scrum, the organizational structure was primarily single-function groups (business analysis group, development group, test group). Further, developers were sub-divided into single-software-component subgroups, and there was “private code ownership” in each component group (rather than “internal open source”). Consequently, doing one customer-centric “vertical” end-to-end feature involved massive handoff, coordination challenges, since it would span the business-analysis group, component1-group, component2-group, component3-group, and test group. The silos of component groups resulted in long and difficult integration and regression cycles, leading to a seven-week release-phase.

Therefore, as an early step in their Scrum adoption, the department needed to reorganize the existing groups into new teams – true cross-functional and cross-component (Scrum) Teams.

How to form the new teams, from a total of 35 people? Who should decide the team membership?

People and Traditional Assumptions

As (Ahmad here) an “ex-program manager” in a department moving to Scrum with self-organizing teams who was very interested in the framework and its successful introduction, these questions were present in my mind. I had previously learned of the idea of self-designing teams from our Scrum coach, and considered it an interesting idea, though perhaps not relevant to our situation.

Why not relevant? For one thing, the manager directing the department, at first assumed – we all assumed – that he and the other senior managers would decide the membership of the new teams. This was a default assumption because of our prior culture (and that found in many organizations): managers decide these matters.

But – unknown to me at the time – he (the department head) had had a meeting with the large-scale Scrum consultant and coach who was helping the group, Craig Larman, during which he offered an idea described in the book Scaling Lean & Agile Development: self-organizing team creation or self-designing teams.

Craig shared the story of a department of about 100 people in Hangzhou (China) that was adopting large-scale Scrum, and faced a similar problem:

Instead of deciding on the new teams, the Chinese department manager Lv Yi (along with Bas Vodde, a Scrum expert who worked in the group) invited everyone into a large room, explained the goal of new Scrum teams, and simply asked the group members to decide among themselves. The group agreed it needed four hours for this, and Lv Yi said, “I’ll come back in four hours, and if some people have not decided by then, I will decide.” Four hours later and after much talk and activity, the group had self-designed their new teams. Then, volunteer ScrumMasters were brought to the center of the room, and the teams picked the ScrumMasters that they wanted.

Craig pointed out that this approach was consistent with the self-organizing principle of agile organizations, moving from a command-control management culture to more self-management. He asked, “What does it communicate to the people if managers say, “We are going to adopt Scrum and self-organizing principles”, but then managers decide and tell people what their teams are, and who their ScrumMasters are?” Craig also asked, “And if someone doesn’t like their new team, who will they blame, if the managers decided things, and what action will that disgruntled team member take to fix it? And on the other hand, who will they blame if they themselves decide their teams, and what actions might they take if they don’t like the way things turn out?”

He also suggested experimenting if a team could (internally) “hire or fire” (from their team) their ScrumMaster, rather than one being assigned.

The department head, quickly got the point, and said, “I love the idea! Let’s try it.” Another manager in the meeting seemed open and curious, but also concerned that it might not work out in terms of creating well-balanced teams. To help address this concern, Craig suggested that the session start with an overview (by a senior manager) of the goals and the need for diversity of skills, experience, age, and gender in the teams.

The department head had a bit of reputation as “Mr. Command and Control”, so it came as somewhat of a surprise to many, including myself, when he publicly announced that he was allowing his entire department to self-organize with self-designing teams as part of the Scrum adoption.

The Big Day

The department head scheduled a half-day session for the self-designing teams event, and invited his entire department. He invited me to join the session as an observer. But minutes before the meeting he asked me to facilitate the session rather than merely observe! I agreed.

There was a lot of chatter ahead of the meeting. One of the most seasoned developers quietly pulled me aside before the meeting and expressed his concern to me that he might not be picked. I was taken aback. I thought, the whole thing smells of grade school.

The room in London held 42 people, including 35 future team members, and some ScrumMasters and other observers. The session started with the department head giving an overview of Scrum, though some people had previously been to an introduction with Craig. I could sense that some were not only skeptical of the idea of self-organizing into their own teams, but also of the idea of Scrum in general – primarily those that had not been previously been to a Scrum introduction and did not quite understand the ideas or motivations.

One of the more senior business analysts expressed his concern that Agile would not work for larger groups and may be better suited for small discrete change items. At this point, I interjected and asked the room to vote on their current ability to deliver large-scale change programs, deliver value, and delight the sponsor in our current (traditional) organization and ways of working. The majority voted the current organization’s ability to deliver could be dramatically improved.

At this point, he concluded with two constraints on design of the teams:

  • teams needed to be co-located
  • teams needed to be cross-functional and cross-component; they should be able to (or be able to learn to) deliver any item from the Product Backlog

He left after his last remarks, and I was left with many skeptical people in a big room. We had three hours to reorganize a department that had worked within a fixed pattern for decades.

I didn’t have a script to follow, or a formula. Instinctively, I got an idea to run the session as four cycles of 25 minutes, with a five-minute review at the end of each, plus some breaks.

Facilitating Self-Designing Teams

I gave no indication to the already skeptical room that I was making it up as I was going along, let alone the fact that I didn’t believe that this would work. I had discovered long ago that the chances of a new protocol or ritual to be accepted by the hive is much higher if I introduced it as if its been done for years.

I asked everyone in the room to write their name and primary skill on a Post-it note. Four flip chart sheets which would serve as team boards were put up in the corner of the large room. I instructed the group that they had 25 minutes to form themselves into teams. They were all taken aback as they thought they would have three hours to do it. I told them that in this technique no one is allowed to sit for the three hours and one must physically move to the team board. And without further ado, I set the timer and they were off.

Cycle One: “We’re all for improvement, we just don’t want to change anything”

Immediately, cliques began to form based on groups who already worked together. When the “Pomodoro” timer rang, I was a little disheartened. The miracle I was hoping for hadn’t happened. The group had shuffled into their current teams, basically organized by software component. The teams seemed to relish in this, as if to say, “See, we ARE meant to be together.”

I set the timer for five minutes, and we started the first review. I went to the first team and I asked the room for feedback. I noted every defect (variation from an ideal team) on a pink sticky note and put it on the wall next to the team board. This was done fairly quickly and we were able to keep to the five minutes. When finished, each team averaged six defects.

Cycle Two: Celebrating the Courage to Change

Now it started to get really interesting. This is when the group started to get a lot more vocal. I got the sense that people found it very difficult to move around. I wandered around the room trying to help the teams along. Whenever I found one of the more senior members of the team commanding others to go, I would interject and try to facilitate the conversation, with techniques such as the “5 whys”: Why do you need so many X developers? And so on.

Eventually, people in one of the long-established teams said that deciding who had to leave was too difficult, and that perhaps it would be best to invite the manager back to decide. Injecting some harsh humor, I responded with, “Perhaps he can decide what we all have for lunch as well? If we do that we will just be reinforcing the ‘command and control’ culture.” At that point, one of the team members acknowledged they were being ridiculous and volunteered to go to the team that was deficient in his primary skill. I immediately celebrated this fact loud enough so the entire room could hear. This was a bit of a tipping point, and then, finally, other members followed suit.

During the review the teams averaged around two-three defects each. Things were looking a lot better. It felt as though we were finally over the hump and we could get there. Cycle two was complete.

Cycle Three: Ahmad Discovers Another Logjam-breaking Technique

During the third cycle, things slowed down again and people stuck stubbornly to their long-standing teams. There was still an imbalance between two of the teams, one having a surplus of a skill and the other having a deficiency in the same skill.

I proposed that the deficient team physically walk to the surplus team and ask for help. They liked this idea, did it, and were successful. Having seen it work, I asked the other teams to do the same.

Review time. One team had zero defects; the other teams had only two in total. Not bad. I asked the teams to do a sanity check and really “look” at their teammates. This was done and we noticed an imbalance of business knowledge on one team. Once this was corrected, we were nearly done.

Cycle Four: Choosing ScrumMasters and Team Names

The department head and his management team had pre-selected four ScrumMaster candidates. These were chosen based on the profile that was given during Scrum training, as well as on people volunteering for the position. With the department head absent from the room, I decided to modify the situation: I informed the teams that they could select their ScrumMaster from the four names suggested or choose anyone from their own team to be their ScrumMaster. I asked the pre-selected ScrumMasters to leave the room. I gave the teams five minutes to deliberate. In the end, the teams selected from the original candidate ScrumMasters. There was some vying for one of the ScrumMasters, but this was quickly resolved through a silent vote.

We now had four true cross-functional and cross-component newly formed (Scrum) Teams. The mood in the room was good. I decided to inject some humor and finish on a high note by asking the teams to name themselves. This was probably the most animated I saw them on that day, with lots of laughter and lighthearted debate over the names. This too was over in five minutes.

I took a picture of each team under their team name. This made the experience more real for many, including myself.

Retrospective and Wrap-up

I asked everyone to write down positive and negative feedback on the exercise before they left, and this article summarizes their feedback in the appendix.

Once done, the session ended.

I immediately emailed the pictures of the teams to the department and senior management.

This is how a department was transformed in three hours. Now it was on to the business of delivering great software with agility in our world of frequent change and learning.

After this session – and after the subsequent two self-designing events described in the next section – there was one team member swap the day after the session. This was done at the team member’s own initiative, and we view that as a sign of success for the self-organizing team mindset. It is very unlikely that would have happened if a manager had assigned people to teams.

Reflection

Balanced teams could have been created by the management team and in all likelihood they would not be much different from the teams created through this process. A major difference, however, is that the self-designing teams session sets the tone for the cultural change an organization undergoes when properly adopting Scrum. It dismantled many of the command and control constructs early on in a very dramatic way. There was a sense of empowerment at the end of the three hours that was not there before (see Appendix B).

The need for strong facilitation is also vital to run this session smoothly and effectively. An experienced SrumMaster or agile coach is ideally suited to run a session such as this.

Considerable thought needs to be put into whom is in the room. These sessions should not be limited only to technology people, but should include any groups responsible in delivering business value. This is critical as it’s disruptive if team members are “injected” into the teams at a later stage. This can harm the nascent culture that is being created, as well as team morale.

It is important to have a good room environment. For example, the large conference-room table in the room was an impediment and was the number-one complaint (see Appendix B).

Improving the Self-Designing Teams Process: More Experiences

Fortunately, after that first experience, we have facilitated two more self-designing teams sessions within the bank, and have improved the process based on inspection and adaptation.

First, before a self-designing teams event, arrange introductory Scrum education (for example, in a Certified ScrumMaster course) for most participants, so they understand the ideas, motivation, and context.

We have made two major changes to the session and process that we recommend:

  • The whole group (rather than a manager) defines the ideal makeup of a new team, at the start of the session. Key precondition: They do this based on having been previously educated about true Scrum teams in general, and with teaching and feedback from the facilitator.
  • ScrumMasters are not pre-selected; rather, the teams vote for their ScrumMasters from a pool of volunteers who have demonstrated knowledge and interest.

The updated session schedule is summarized in Appendix A.

Scaling to 100 team members

After facilitating three self designing team formation sessions, I was recently asked to help facilitate the creation of 14 teams across 100 people. Due to the scale, I did the following:

  • added another hour to the original format
  • divided the room into 3 parts and solicited the help of two other scrum masters to help facilitating the review
  • a pre-defined criteria was provided, but the “room” was giving 25 minutes to overload the team definition rules.

The result was that the team formed an hour early in three hours. The process can indeed scale so long as a scrum master facilitates the review process of no more than five teams.

Summary

Of course, it doesn’t take only three hours to truly and successfully adopt large-scale Scrum; forming the teams in a three-hour session is only one of many obvious and subtle change elements. But it is noteworthy how much can be quickly changed when the organizational will and appropriate hands-on worker and leadership support is in place. And it is noteworthy that with some facilitation, people are quite capable of deciding amongst themselves how to organize into teams, without command-and-control management.

The views expressed in this article are those of the authors and do not necessarily represent the view of, and should not be attributed to, Bank of America.

Appendix A: Potential schedule

Section Lengh (minutes)
Introduction & Background 20
Ideal Team definition. Define the primary skills required within in any team. This creates a rough guideline, rather a strict rule. 20
Cycle #1 25
Review 15
Cycle #2 25
Review 15
Break 10
Cycle #3 25
Review 15
Team names & Photos 15
Retrospective: “Plus-delta” feedback 5
Conlusion and Next Steps 10

Follow-up session scheduled for the following day to discuss any potential change requests.

Appendix B: Session Feedback

Positive

  • The process, facilitation & timekeeping, 11
  • The sense of empowerment, 7
  • The creation of well balanced team, 8
  • The sense of team spirit that was fostered, 3

Improvement Areas

  • Inadequate room choice, 6
  • Session too long, 5
  • More management/facilitation involvement required to break deadlocks, 5
  • Pressure from the “room” applied to join a team you are not happy with, 3
  • More information required ahead of the meeting regarding individual profiles, session objectives & the type of work teams will be working on, 3
  • Reluctance of team members to move to leave the initial teams created, 3
  • Chaotic at times, 2
  • Process does not create balanced teams, 2

2018 LeSS Conference Materials Up

This was my very first time in New York. The 16 hours flight from Singapore didn’t make the conference experience less exciting. I was expecting to see some skyscrapers, however, got something looking like Amsterdam, hmmm. It’s nice that the LeSS conference got to keep its style as always. This keeps my hopes up for the next year LeSS conference in Munich.

Dependency Board

The keyword I heard a lot from people describing the conference is “humble”. This is also how I felt. People were sharing their experiences, which were full of courage, failures, surprises, marginal success, and occasional big victories.

I especially liked my ex-boss Tero Peltola’s keynote LeSS Huge at Nokia (Download Materials). Nokia LTE was the second LeSS adoption Tero did. I was involved as an Agile coach for years. It’s great to see the organizational changes from the most critical stakeholder’s perspective. Don’t miss the session video at InfoQ.

Next, I also liked LeSS Huge at BMW from Konstantin Ribel and Craig Larman. It’s interesting to see in such a big company as BMW autonomous driving how changes happen both from bottom-up and top-down. The materials are here. The video will be published later in November.

Craig’s second-day keynote was Blind Spots: Cognitive Biases and Systems, an interesting exploration of human cognition and the impact on organizational behaviour. Download Materials.

One thing I have been doing for a long time, but still find challenging is Product Backlog Refinement Workshop, especially when it takes more than a couple of teams together. This led me joining Nils Bernert’s Large group Product Backlog Refinement in LeSS & LeSS Huge. There I got more tools under my belt and learnt different facilitation tricks for splitting and detailing. Download Materials.

In Greg Hutchings’s Using Innovation Games (™) to compliment LeSS, I learnt about several tools that can help product exploration and also where to find more resources. You may take a peek on Youtube.

On my conference team table, I’ve heard a lot of excellent stories from Anton Bevzyuk regarding their practices. So I skipped his session How technical excellence helps in LeSS adoption and went to Michael James’s Test Driven Development (TDD) on flipcharts, which is a very interesting why of explaining TDD to non-tech people. However, when I finally saw Anton’s slides (Download Materials), I felt I really missed something great. Too bad, next time!

There were 22 planned sessions, together with team-based conference activities, multiple tracks of open space sessions and panel discussion. To download the session materials and watch session videos, please find them in the 2018 New York conference program.

2018 LeSS Conference - Teams and Conference Review

Team-based conference - iteration 3

Over a month ago, we had the third LeSS Conference in New York. Also this year, we made it into a Team-Based Conference. For more information on that, better read the description of team-based conference from the previous conference.

Self-designing team workshop

This year Alexey Krivitsky facilitated the self-designing team workshop. This is the initial workshop to form the teams that you are in for the conference. The aim of this is to demonstrate techniques that can also be used in a normal LeSS adoption. Alexey did it in an interesting way. He first let everyone find a buddy and then combined the buddies into teams. For the teams, he tried to maximize the diversity by calculating a diversity index and then have multiple rounds of adjusting. This was an interesting approach as you have one person who you are familiar with and the rest not. I had not experienced this approach before.

I ended up with my buddy Viktor Grgic and in an interesting team which we named “The Team”. Unfortunately, it seems we didn’t make a photo of our team, so I’m not able to share that. However, there were some teams that photo-ed themselves, so some examples,

7 Odd Men

7 Odd Men

LeSS Out

LeSS Out

LeSS Wanted

LeSS Wanted

(If you are reading this and have a team photo that isn’t here, let me know, I’ll add it)

The Conference

During the conference, the team meets up between the session. There they reflect on the session that they went to and share that information with the other team members. Therefore, you get to know something about all the sessions (your team went to). Also, our team would discuss the upcoming session.

Of course, in practice, the team reflection sessions end up to be a lot about not just sharing your conference experience, but about sharing your experience of LeSS adoptions in your company (or not yet). I personally enjoyed the team reflection sessions quite a lot although I missed quite some of them due to interruptions.

Conference Review Bazaar

The conference ends with a Conference Review Bazaar. This is, of course, an instance of a Sprint Review Bazaar in LeSS and we attempt to use similar facilitation techniques to practice those. In the conference review bazaar, the teams first need to work together for an hour to create their conference experience. This could be anything. The most common ones are a flipchart with the summary of the sessions or quotes from the different sessions. Some teams, however, get much more creative and they create a game, a movie, let other people create movies, or whatever they can come up with.

My team, the team, decided to build a huge paper plane and we wrote our learning on post-it notes and put them on the plane. We threw the plane around and also tried to throw it off the balcony. Making the plane was fun but it didn’t turn out to be the best idea as it wasn’t very much showable to the other teams.

The session ended with the Bazaar where all the people visited all the groups to see their creations and learn about their experiences. To make it a bit fun, this is turned into a competition where people can ‘vote’ for the ones they like most. Clearly our plane didn’t win.

Some of the conference review bazaar output photos are below.

Flipchart summaries of the conference

Summary
Summary
Summary
Summary
Summary
Summary
Summary
Summary

Plank challenge

One team created the plank challenge where you have to do the plank exercise while answering questions. Some photos from that:

Summary
Summary
Summary
Summary

Other games

Several other teams created other games, such at the wheels of wisdom:

Summary

Some game to pick numbers and colors

Summary

Some contest to immitate people

Summary

And then this…

Summary

In the end, the votes were counted

Summary

Closing

All in all, I personally had a lot of learning and fun. It was great to see so much people sharing with each other in a beautiful space. I’m already looking forward to next year (Munich). Thanks to all the participants.