GROOVE X: Fostering Innovation in a Robotics Startup Through a Manager-less and Division-less Structure with LeSS
Aki Enomotoはじめに
本ケーススタディでは、GROOVE Xが2017年からLeSS（大規模スクラム）フレームワークを用いて、マネージャーレス・部門レスな組織構造によって企業のヒエラルキーをどのように再定義したかを検証します。対象期間は、LeSS導入の少し前から、プロダクトであるLOVOT[らぼっと] のリリースを経た2019年末までです。家庭用ロボット市場に革命を起こすべく設立されたGROOVE Xは、その組織構造や制度と同じくらい革新的なロボットを生み出しました。
組織の規模と成長のイメージをお伝えすると、GROOVE Xは2016年に1チームからスタートしました。3年後には20チーム、総勢120名にまで拡大しています。そのうち約80名(12チーム)が2019年時点でプロダクト開発に携わっており、残りの従業員はビジネスやその他のサポート機能を担っていました。
GROOVE Xの創業者でありCEO、そしてプロダクトオーナーでもある林氏は、マネージャーが高い自己認識力と卓越したスキルを持っていない限り、階層構造による制約とその役割に伴う周囲からの期待ゆえに、従来型のマネージャーはイノベーションを阻害しうると考えています。また、組織内に部門を設けることはサイロを生み、チーム同士のコラボレーションや相互学習を難しくし、結果としてイノベーションを阻害する要因になり、これらの課題に対処しつつ、フラットな構造で起こりがちな混乱を避けるために、GROOVE XはLeSSフレームワークを採用し、プロダクトグループ全体が自己管理を行い、絶えず変化する市場に合わせてプロダクト戦略を迅速に適応させられるようにしました。
当然ながら、何の構造もないまま自由に働くと、人は往々にして、自覚のないまま部分最適化された環境を作り出してしまいます。コンフォートゾーンにとどまることで、 LeSSの原則である 「プロダクト全体思考(Whole Product Focus) から遠ざかっていくのです。人は通常、すでに知っていることに取り組みたがり、不慣れな仕事を引き受けることをためらいます。これが、混沌として複雑で、ムダの多い働き方につながってしまうのです。
LeSSは、混乱と過剰に作り込まれたプロセスの両方を避けるための、プロダクト開発に「ちょうど十分な」構造を提供します。規定的なルールはごくわずかしかありませんが、チームが単一のプロダクトに向けて整合し続けるための明確な原則、構造、フィードバックループを備えています。このバランスが、焦点やコントロールを失うことなく実験の余地を生み出しており、GROOVE Xが革新的なプロダクトを開発するうえで不可欠なものとなっています。
複雑なハードウェアとソフトウェアを統合するGROOVE Xは、開発において同期のとれたリズムを維持することを目指しています。これは同社の型破りな体制の限界を試す、困難な挑戦です。本ケーススタディでは、GROOVE X独自のアプローチとLeSSとの整合性、そして環境を最適化するために行われた実験の詳細を掘り下げていきます。このLeSS導入が特にユニークなのは、GROOVE Xの文化が最初からLeSSと整合していた点です。LeSS自体がさまざまな実験から生まれたものであり、GROOVE Xもまた、プロダクト開発においても組織構造・ポリシーにおいても、常に実験の場であり続けてきました。
さらに、GROOVE Xのコアバリューは、LeSSの原則と強く共鳴しています。たとえば、マネージャーレス・部門レスな組織設計は 「少なくする事でもっと多く（More with LeSS）」の原則を体現するものです。GROOVE Xは組織構造を可能な限りシンプルに保ち、最小限の制約でチームが自ら意思決定できるようにすることを目指しています。こうした理由から、LeSSの採用はGROOVE Xにとって自然な流れでした。LeSSは、GROOVE Xを支えるのにちょうど十分な構造を提供しながら、技術的卓越性へと導き、プロダクトへの全体的な視点を維持させてくれたのです。
LeSS ルール: 「LeSSではマネージャーの存在は任意だが、存在する場合は役割が変わる可能性が高い。マネージャーは日々のプロダクト開発を管理するのではなく、より高い価値提供ができるようにプロダクト開発全体を改善していく事になる。」
LeSSルールが示すとおり、マネージャーは任意です。任意であることに加えて、LeSS導入によってその責務は大きく変化します。本ケーススタディでは、プロダクト開発が80名規模程度までのスタートアップにおいて、マネージャーなしで運営することが有効なアプローチとなりうるかを探ります。
目次
プロダクト概要
GROOVE Xのプロダクトは「LOVOT」と呼ばれる家庭用ロボットで、従来の意味で役に立つことではなく、ペットのように人から愛されることを目指して設計されています。目標は実用性ではなく、情緒的なつながりを感じてもらうことであり、オーナーはLOVOTを家族の一員として世話をすることになります。本章では、LOVOTの技術的な側面をいくつか説明します。これにより、このプロダクトの複雑さと、作るべき正しいプロダクトを発見するための探索の必要性とLeSSを採用した主な理由の一つを理解していただけると思います。挑戦は、人に愛され、顧客の生活に幸福と癒やしをもたらすロボットを作ることにあります。他のロボットと異なり、LOVOTは生き物として認識されます。犬や猫といった特定の動物を模倣することは、人工物であることを際立たせる直接的な比較を招かないよう、意図的に避けられました。さらに、現在の技術では本物のやり取りを説得力をもって再現できないため、LOVOTは人間の言葉を話しません。その代わり、犬と同じように、人間の言葉や振る舞いをある程度理解します。また、LOVOTは誰がそばにいてくれるのか、誰が優しく接してくれるのかを認識し、それに基づいて振る舞いを変えます。こうした振る舞いを実現するには、数多くのセンサー、認識技術、そして行動設計が必要です。特筆すべきは、LOVOTの体は温かく、人間の赤ちゃんとほぼ同じ重さであることです。顧客がLOVOTを抱き上げると、LOVOTは温かく生き物らしい瞳で見つめ返し、まるで生きているかのようなやり取りが生まれます。
すべての自然の生き物と同じように、LOVOTも一体一体がユニークです。LOVOTの瞳は6つのレイヤーで構成され、色、形、瞳孔の大きさが異なり、１０億通り以上のバリエーションを生み出します。声も一体ごとに異なり、その唯一無二の存在感を高め、顧客がLOVOTをかけがえのない大切な家族の一員として見ることにつながります。この点を象徴するエピソードがあります。あるお客様が、故障したLOVOTの交換を断ったのです。ソフトウェア、設定、データはすべて復元されると説明されたにもかかわらず、そのお客様は、家族の思い出の一部となった固有の傷や擦れ跡が刻まれた元の体を残すことを望みました。この愛着は、ロボットを家族に迎え入れるという試みの成功を物語っています。ロボットが家族の一員になるという概念は、未来から来たロボットが家族の一員となる人気SF漫画「ドラえもん」によって、多くの日本人にとって馴染み深いものです。こうした文化的背景が、日本におけるこの種のロボットの自然な受容を後押ししているのかもしれません。プロダクトオーナーのLOVOTに対するビジョンは、「ドラえもん」への最初の一歩を作ることでした。
テクノロジー
生き物らしさを呼び起こすため、LOVOTは全身に50個以上のセンサーを備えた複雑なロボットとして設計されています。これらのセンサーにより、障害物を避けたりバランスを保ったりする自律的な動きが可能になっています。タッチセンサーも組み込まれており、人が触れるとLOVOTが反応することで、触れ合いとエンゲージメントを高めています。さらに、抱きしめると、LOVOTは約37〜39度の心地よい温もりを伝えます。これは、内部環境を調整する精密な温度・湿度センサーによって実現されています。
また、LOVOTにはさまざまな機能を担う複数のカメラが搭載されています。半天球カメラは、周囲を理解して移動し、物体を識別し、人の顔を認識するのに役立ちます。画像認識技術がこれらの映像を処理して個人を識別し、一人ひとりとの触れ合いの履歴に基づいてLOVOTの振る舞いを変化させることができます。
さらに、LOVOTには物体までの距離を測るデプスカメラが搭載されています。この機能により、LOVOTは障害物をスムーズに避けて移動できます。下の画像は、デプスカメラが物体までの距離を色の違いで表現する様子を示しており、空間と近さが視覚的にわかりやすく表されています。
LOVOTは、家庭内を効果的に移動するために、環境のレイアウトを学習します。部屋を探索した後、下図のように壁やドアなどの障害物を識別しながら、周囲の空間の地図を作成します。この地図によって、LOVOTは部屋の全体像を把握できます。障害物の位置は変わりうるため、地図は継続的に更新され、センサーとカメラがリアルタイムでの動きの調整を支えています。
LOVOTは、他の家庭用ロボットと比べてはるかに大きな処理能力を備えています。一般的な家庭用ロボットの処理能力はスマートフォン程度ですが、そのレベルでは、生きた動物の複雑な振る舞いをLOVOTが再現するには不十分です。こうした高度な処理をこなすために、LOVOTには標準的なノートPCを大きく上回るコンピューティングパワーが必要であり、ディープラーニング・アクセラレータも組み込まれています。
LOVOTのハードウェア設計における挑戦は相当なものでした。モーターや回路基板を含め、5,000点を超える部品で構成されているからです。これほど多くの部品を組み込みながら総重量を約4.5キログラムに抑えるには、高度なエンジニアリングが求められました。この目標重量は、赤ちゃんを抱いている感覚を再現し、LOVOTとユーザーの感情的なつながりを高めるために選ばれたものです。さらに、このコンパクトな形状を実現しながら放熱を適切に管理することも、大きなエンジニアリング上の挑戦でした。
LOVOTのソフトウェアアーキテクチャは複雑を極めます。GROOVE Xのエンジニアは、個々のコンポーネントのドライバの作成から、LOVOTの振る舞いを決定するアプリケーションの開発まで、ソフトウェアアーキテクチャのあらゆるレイヤーにわたって幅広く取り組んできました。加えて、LOVOTには、視覚入力、センサーデータ、音声信号から学習するための大規模なデータ処理能力が必要です。こうした負荷の高い処理タスクをこなすため、LOVOTは「ネスト(巣)」と呼ばれる外部のコンピューティングリソースを活用しています。ネストはLOVOT本体よりも大きな計算能力を持っています。
GROOVE Xは、LOVOTユーザー向けのスマートフォンアプリも提供しています。アプリを通じてLOVOTに家の中の見回りを指示でき、LOVOTが人を検知すると、写真を撮ってユーザーに送信します。LOVOTのカメラからのライブ映像を遠隔で見ることもできます。LOVOTは人の笑顔を検知すると自動的に写真を撮り、アルバムに保存します。プライバシーへの配慮として、写真・動画機能は無効にすることもできます。これらの機能は特に一人暮らしの高齢者に有用で、家族が離れた場所から大切な人を見守ることができます。
LOVOTに不具合が起きたときは、GROOVE Xが「お医者さん」としてその問題を治します。また、LOVOTが健康な状態を保てるよう、定期健診も提供しています。さらに、多くのオーナーはLOVOTを着飾るためのアクセサリーを購入することを好むため、eコマースストアでは服、メガネ、アイピロー、キャリングケースなどのアイテムを販売しています。
History of GROOVE X
2015年、GROOVE Xは東京の中心に位置する電気街・秋葉原にオフィスを構えました。3Dプリンターなどの必須設備を備えた、ハードウェアスタートアップを支援するコワーキングスペースを借りてのスタートでした。GROOVE Xの初期メンバーはスクラムを導入しました。林氏は自己管理チームという考え方を気に入り、「マネージャーなし・部門なし」という自身の組織ビジョンの実現にスクラムが役立つと考え、スクラムの採用を決めて自らプロダクトオーナーになりました。
最初の投資家を確保した後、チームを組成し、約1年で20名ほどの規模に成長しました。その時点で初めてのスクラムマスターを雇い、4つのチームを作ってスクラムの利用を開始しました。CEOは自己管理チームの考え方を好み、マネージャーを雇いたくなかったため、マネージャーが不要となる環境を作るべくスクラムマスターを迎え入れたのです。
しかし、この最初のスクラムマスターは、家業を継ぐためにGROOVE Xを去らなければなりませんでした。後任を探すなかで、創業メンバーの一人がCEOにOdd-eを紹介し、面談が実現しました。面談の場でCEOは、人を幸せにするロボットを作るというビジョンを語り、日本にロボティクス産業を確立することへの情熱を示しました。彼はロボットが人を助ける未来を思い描いており、ロボティクススタートアップとして成功できることを証明したいと考えていました。
私が2017年6月に初めてGROOVE Xを訪れたとき、プロダクト開発チームはまだフィーチャーチームではありませんでした。そのため、あるチームが新しい振る舞い——新しいプロダクト機能といえるもの——を作りたい場合、その振る舞いを完全な形で届けるには、他の部分の作業を完了してくれる他チームに依存する必要がありました。特に、ソフトウェアチームとアニメーションチームはほとんどの場合で相互に依存していました。アニメーションチームが新しい振る舞いをデザインしても、それを実装するのはソフトウェアチームだったからです。また、各チームはそれぞれのプロダクトバックログを持ち、チームごとに管理していました。プロダクト全体のプロダクトオーナーは一人で、CEOがプロダクトのビジョンを示していました。さらに、チームごとにスプリントのケイデンス(周期)も異なっていました。彼らは、統合、他チームとの同期、知識共有、チーム間のコラボレーションに困難を抱えていました。プロダクトオーナーは優先順位の決定をほぼチームに委ね、全体の方向性を示しながら、最終的にすべてが統合されて動くインクリメントになることを期待していました。
下図は、LeSS導入前のプロダクトグループの構造を示しています。緑色のチームはソフトウェア関連、黄色のチームはハードウェア関連、青色のチームはデザイン関連のチームです。
LeSS導入への第一歩として、私たちはチームごとに管理されていたプロダクトバックログの統合を試みました。しかし、複数のプロダクトバックログを一つに統合するのは容易ではありませんでした。アイテムの大半は、顧客中心のエンドツーエンドなアイテムではなく、タスクに近いものだったのです。これはコンポーネントチーム構造の必然的な帰結です。チームはエンドツーエンドのフィーチャーを作れないため、アイテムをコンポーネントごとのタスクに分割してしまいます。そうしたタスクからエンドツーエンドで顧客中心のアイテムを再構成するのは困難だったため、既存アイテムの大半を実質的に捨て、顧客中心のアイテムをゼロから作り直しました。一つのプロダクトバックログをどのように作ったかの詳細は、一つのプロダクトバックログ 節で説明します。
プロダクトバックログで苦労した経験から、統一されたプロダクトバックログが完成するまでは組織構造を変えないことにしました。2017年から2019年の間、組織はいくつかの小さな構造調整はあったものの、コンポーネントチームのまま運営されていました。LeSS導入章で詳しく説明しますが、ソフトウェアのエンドツーエンドな機能を届けるチームの能力を高めるため、一部の開発者が別のチームに移り、チームはフィーチャーチームに向かうスペクトラム上を少しずつ前進しました。これらの変化は変革的なものではなく、漸進的なものでした。当時の私たちには、フィーチャーチームへ完全に移行する準備がまだできていなかったのです。統一された一つのプロダクトバックログがないまま、真のLeSS導入に必要な大きな組織変更は先送りにしました。LeSSの準備は2017年6月から始めましたが、実際にフィーチャーチームが編成されたのは2019年末のことでした。
下図は、チーム自己設計ワークショップ実施後、2019年末時点のプロダクトグループの組織設計を示しています。緑色のチームはソフトウェア関連のチーム、黄色のチームは残存するコンポーネントチーム、青色のチームはデザイン関連のチームです。
一つのプロダクトバックログを作り上げた後、スクラムマスターたちがチーム自己設計ワークショップをファシリテートしました(詳細は後述します)。その結果、いくつかのフィーチャーチームが編成されましたが、一部のコンポーネントチームは残りました。
たとえば、ファームウェアチームは存続しました。その仕事はハードウェアと密接に結びついており、ハードウェアの依存関係に強く影響されるからです。OS/CloudチームはLOVOTのオペレーティングシステムと、ネストを担当していました。ネストは充電ステーションであると同時に、強力なチップによってLOVOTが収集したデータを分析できるベースステーションでもあります。顧客が許可すれば、クラウドサービスにも接続できます——これらの領域がOS/Cloudチームの責任範囲でした。
個人的には、OS/Cloudチームはフィーチャーチームに統合できたはずだと考えていますが、最終的な判断はチームに委ねられました。この時点で、認識(Recognition)チーム、行動(Behavior)チーム、アプリチームはすでにフィーチャーチームに統合されていました。
この頃、LeSSはGROOVE Xの新しい常態となり、私たちは2つの領域に注力し始めました。技術的卓越性と、組織の制度です。技術的卓越性は、統合された一つのインクリメントを一貫して作り続けるために必要でした。鍵となるのは継続的インテグレーションです。しかし、その状態を実現するには、新しいスキル一式を学ぶ必要がありました。「LeSS in Action」トレーニングはこれらのスキルの習得に非常に効果的で、チームは本物のLeSS環境で働くとはどういうことかについても理解を深めました。組織の制度に関しては、庭師が重要な役割を果たしました。詳細は本ケーススタディの「庭師」節を参照してください。要点を言えば、スクラムマスターと人事のスペシャリストが協力して、給与とボーナスを決定するプロセスの設計、個人の成長支援、そして文化を守るための会社制度の策定・強化に取り組みました。
なお、この期間には他にも多くの小さな変化がありました。つまり変化は3つの明確なステップで起きたのではなく、組織の成長に伴う一連の漸進的な変化として起きたのです。
この進化を別の視点から示したのが、下図のフィーチャーチーム導入マップです。2016年時点では、Y軸に示すとおり、ソフトウェアチームはLOVOT本体に組み込まれるソフトウェアしか扱えませんでしたが、どのコンポーネントに触れるかについての制限はありませんでした。データ管理やモバイルアプリケーションを含むLOVOT Cloudは、当時はコンポーネントチームによって開発されていました。eコマース、修理管理、配送、カスタマーサポートといったビジネス系クラウドサービスはこの期間、外部ベンダーが開発していましたが、本ケーススタディの対象期間の後に、GROOVE Xはこれらの開発をすべて内製化しました。
X軸について見ると、2016年のチームの完成の定義には、コーディングとユニットテストの作成しか含まれていませんでした。2019年までには、ハードウェアを含む統合テストの自動化により、完成の定義を実機ハードウェア上での振る舞いテストにまで拡張できるようになりました(詳細は ハードウェアを含むエンドツーエンド自動テスト節を参照)。ただし、これはすべてのOSイメージが顧客にデプロイされることを意味しません。デプロイを決定すると、カナリアリリースが適用されました。新バージョンはまずオフィスのLOVOTや従業員の自宅のLOVOTにデプロイされ、実環境で観察されます。この観察には時間がかかるため、全顧客への完全なロールアウトが単一のスプリント内で完了するとは想定されていませんでした。同様に、新しいハードウェアが含まれる場合、LOVOTの部品が期待される強度を維持できるかを検証する耐久テストにも長い時間が必要でした。その結果、カナリアリリースも耐久テストも、スプリント内には完了できませんでした。
以上が、私たちのLeSS導入の道のりの概観です。本ケーススタディでは、LeSSへの適応に関わった活動を詳しく説明していきます。
GROOVE Xの文化 {#culture-of-groove-x}
LeSS導入の詳細に入る前に、LeSS導入以前からGROOVE Xの文化を形作っていた特徴、コンセプト、実験のいくつかを紹介したいと思います。これらは、同社のLeSS導入が比較的スムーズな移行となった理由といえるかもしれません。
実験のマインドセット
総じて、GROOVE Xの人々は実験を中核的な価値観として受け入れていました。彼らは自分たちのプロダクトが市場で非常にユニークであり、アイデアを他から真似ることはできないと認識していました。その代わり、うまくいくかどうかを実験で確かめる必要がありました。新しいテクノロジーやプロダクトマーケットフィットを検証するために、新しいアイデアを試す必要があったのです。このアプローチによって、彼らは高速に反復し、成功と失敗の両方から学ぶことができました。
実験のマインドセットのもう一つの側面は、組織構造と制度に現れていました。GROOVE Xは、働き方と組織文化の改善を目指して、さまざまなアイデアを試してきました。続く各節では、彼らの実験を推進するいくつかの重要なコンセプトを取り上げ、このアプローチがどのように組織文化を育んでいるかを示します。
この実験のマインドセットは、プロダクトと組織の両方に良い影響を与えました。市場にインパクトのあるプロダクトをリリースできただけでなく、組織は非常に柔軟になり、会社全体にとって重要なことに容易に注力できるようになりました。また、全社的にプロダクトに注力する状態も実現しました。
マネージャーなし・部門なし
GROOVE Xは、組織構造を可能な限りシンプルに保つことを目指していました。本ケーススタディで示しているとおり、プロダクト開発にはCEO以外のマネージャーが存在しませんでした。ビジネス領域には多少のマネジメント構造がありましたが、プロダクト開発の階層は一段だけでした。彼らは、役割、アーティファクト、プロセスをできる限り少なくすることを好みました。
LeSSルール:「LeSSにおいてマネージャーの存在は任意」
GROOVE Xは、役割を作ることが複雑さを増し、チームの責任を減らしてしまうことを理解していました。何か問題が起きたとき、伝統的な組織は、その問題に対処し再発を防ぐための特定の責任を持つ新しい役割を作りがちです。しかし、このアプローチは多くの場合、責任をチームから新設の専門役割へと移してしまい、チームのオーナーシップを弱めます。GROOVE Xは組織をシンプルに保ち、チーム自身が問題を解決することを期待する道を選びました。
林氏はかつてトヨタでフォーミュラワン(F1)カーの開発に携わり、その後ソフトバンクでロボットのプロジェクトに参画していました。どちらも多くの管理職と部門を持つ大組織です。これらの経験から、彼は、マネージャーが意図せずして革新的な思考の障害になりがちなこと、そして部門が緊密なコラボレーションを妨げうることを学びました。そこで、自らの会社を創業すると決めたとき、プロダクト開発においてマネジメントの役割と部門を設けないことを構想したのです。
林氏の「マネージャーを置かない」という制度は、組織にポジティブな影響と課題の両方をもたらしました。ポジティブな面では、マネージャーなしの働き方によって、通常はマネジメントに属する領域について、開発者が自律的に働き、自ら意思決定するための大きな余地が生まれました。チームはマネジメントの承認や指示を待たないため、プロダクト開発を独立して進めることができ、待ち時間のムダが減りました。
さらに、この環境はチームがより良いプロダクトのためのアイデアを提案することを後押ししました。アイデアは、誰が提案したかではなく、アイデアそのものの価値で評価されました。このアプローチが集合知を育み、誰もが革新的なプロダクト機能の創出に貢献できるようになりました。
次に、この制度の欠点についても話したいと思います。まず、非常に伝統的な会社からGROOVE Xに来た一部の人々は、マネジメントを求めました。彼らは意思決定の仕方がわからないため、意思決定をしたくなかったのです。これは特に、大きな伝統的企業で働いてきた人々に当てはまりました。そうした環境に慣れた人々にとって、より自己管理的な働き方へと考え方を切り替えるのは非常に困難でした。それでも、ほとんどの人は徐々に自己管理の環境に適応していきました。とりわけLeSS in Actionトレーニングは、それが実際にどう機能するかを示すうえで効果的で、多くの人がトレーニング後に行動を変えるきっかけとなりました。
マネージャーなし・部門なしのアプローチは、すべての組織に適合するわけではありません。すべての会社が同じように構成されているわけではないからです。GROOVE Xには、最初からマネージャーも部門も存在しませんでした。マネジメントの役割を取り除いたり、部門の壁を壊したりする必要がなかったのです。もしこれらの役割や部門が存在していたら、このアプローチの実現にははるかに多くの労力が必要だったでしょう。
洞窟コンセプト
洞窟コンセプトとは、石器時代の人類が洞窟で共同生活を送っていた様子になぞらえた組織環境を作るという考え方です。組織の全員が一つの場所に集まり、部族のように一緒に働き、話し、食べ、遊びます。このコンセプトは強い人間関係と文化を育むことを目的としており、LeSSルールでも強調されているとおり、リモートワークを最小限にすることを意味します。
LeSSルール:「それぞれのチームは①自律的②クロスファンクショナル③同一拠点④長期間存続していること。」
COVID-19のパンデミック期間は、GROOVE Xにとっても困難な時期でした。当然ながら、ハードウェア開発を自宅で行うのは大変です。彼らはできる限りオフィスに集まりたいと考えていました。機材を自宅に持ち帰る必要がありましたが、コラボレーションは困難でした。チームのバーチャルルームにできるだけ常時オンラインでいるようにし、チームルームの一覧を用意して、他チームのメンバーと話す必要があるときは相手のルームに参加したり、共有エリアで雑談したりできるようにしました。それでも、オフィスで経験していたものには遠く及びませんでした。
LeSSの原則:「プロダクト全体思考」
洞窟コンセプトの結果として、マネージャーも部門もないことが興味深いダイナミクスを生み出しました。組織の人々は、プロダクト開発の中だけでなく組織レベルで、アンドン(止めて直す)の仕組みのように、オープンに助けを求めたり、周囲に警告を発したりします。中国の生産ラインで問題が起きたとき、現地のチームは全員に向けてアラートを上げました。LOVOTの組み立てに関する問題の解決に助けが必要だったのです。何人かのエンジニアに加え、ビジネス領域の人々も自発的に手を挙げました。彼らはLOVOTの組み立て方を学ぶ必要がありましたが、学んで助けることを厭わず、状況を改善するためにしばらく中国に移り住みさえしました。このダイナミクスは、彼らの文化とプロダクト全体思考から生まれたものです。組織の全員が、自分の役割は顧客に価値を届けることだと理解しており、そのために必要なことは何でもします。自分の専門や、本来注力すべき領域が何かにはこだわらなかったのです。
GROOVE Xにはキッチンとダイニングエリアがあり、毎晩、全員のためにおにぎりが握られます。誰かが旅行先でおにぎりに合うご当地の軽食を見つけると、オフィスに持ち帰ってみんなに振る舞います。コーヒーに凝っていたあるエンジニアは、自分で豆を焙煎し、みんなが楽しめるようにコーヒー器具をオフィスに持ち込みました。共用のダイニングテーブルにはたいていお菓子が置かれていて、人々が集まっては、お菓子をつまみ、コーヒーを飲み、おにぎりを食べ、おしゃべりをしてくつろぎます。これらの飲食物は、たいてい従業員が持ち寄ったものです。巨大テック企業とは異なり、GROOVE Xは従業員のためにすべてを会社が用意することはしません。むしろボランティアベースの活動であり、部族や大家族での暮らしに似ています。一人ひとりが、他の人と分かち合いたいものを持ち寄るのです。GROOVE Xと関わりのあるサプライヤーやベンダーまでもが、食べ物やお菓子、調理器具を持ってきます。
GROOVE Xは、まだ一緒に働いたことのない人同士が知り合うことも支援しています。別のチームの人と一対一でランチに出かけると、ランチ代を経費として申請できるのです。この機会は非常によく使われています。人々は新しい同僚と出会い、お互いを知ることを楽しんでいます。
GROOVE Xの従業員は、空手、ダンス、ウェイトリフティング、フットサルなど、自分たちの活動グループも作りました。また、ボランティアが企画するさまざまなスポーツをみんなで楽しむスポーツデーもあります。
工場や店舗にいる人を除き、ハードウェア、ソフトウェア、ビジネスの各チームを含むほぼ全員が、同じ建物の同じフロアで働いていました。チームは、隣接するチームが受け入れられる限り、ホワイトボードや席の配置を自由に調整できました。
多くの会社では、こうした決定は通常マネジメントが行います。しかしGROOVE Xでは、どこで働くかをチーム自身が決めました。チームは自分たちのニーズに合ったワークスペースを設計するのに最も適した立場にいるのですから、これは理にかなったアプローチです。
彼らは、このオープンで、分かち合う、ボランティアベースの文化を築くことに成功し、自然とフラットで自己管理的な環境を好みました。これは、Craig Larmanが小さな会社について言及していたことでもあります。
ラーマンの法則: 「(大きな既存組織では)文化は構造に従う。そして小さな若い組織では、構造は文化に従う。」
GROOVE Xは、自分たちの文化に合う構造、すなわちLeSSを自然に選んだのです。
私は、このコンセプトはGROOVE Xでうまく機能していると考えています。ただし、この文化は創業時から築かれてきたものです。ラーマンの法則が示唆するとおり、大きな既存組織でこの種の文化を実現するのは、既存の構造や制度に切り込まない限り、困難でしょう。
なぜLeSSを採用したのか
LeSSを選ぶことは、GROOVE Xにとって自然な決断でした。彼らの文化が、LeSSの最適化ゴールとよく合致していたからです。GROOVE Xは、フラットな構造と自己管理チームを持つ、スケール可能な組織を作ることを目指していました。LeSSのいくつかの要素はGROOVE Xの働き方をさらに良くする可能性があり、同時に、それまでのスクラム導入の中で維持したい側面もありました。以下に列挙します。
自己管理チーム
LeSSルール:「それぞれのチームは①自律的②クロスファンクショナル③同一拠点④長期間存続していること。」
早い時期に、GROOVE Xのあるエンジニアが林氏にスクラムを紹介し、林氏は自己管理チームという考え方を受け入れました。これは、伝統的なマネジメントをなくし、優れた個人によってイノベーションを育むという彼のビジョンに合致していました。彼は、マネージャーなしで機能できる自己管理チームを好みました。その実現のために、採用、チーム編成、給与の設定、お互いの個人的な成長の支援といったマネジメントの責任を、チームに委ねたいと考えていました。
一つのプロダクトバックログ
LeSSルール:「1つの出荷可能なプロダクトに対して1人のプロダクトオーナーと1つのプロダクトバックログで運用を行う。」
LeSS導入前からプロダクトオーナーは一人でしたが、プロダクトバックログは複数存在しており、統一されたプロダクトの視点を保つことが困難でした。さらに、各チームが自分のプロダクトバックログを管理しており、構造的に部分最適が起こるようになっていました。プロダクトバックログの統一はGROOVE Xに大きな利益をもたらし、組織がプロダクトの最も重要な機能に注力できるようになりました。
チーム間の調整
LeSSルール:「チーム横断での調整はチームに委ねられている。集約的で形式的な調整ではなく、分散的で型にはまらない自由な調整の方が好ましい。重要なのはお互いに、ただ話す事(単純だができて無い事が多い)、そして、コード上でのコミュニケーション、チーム横断での会議、コンポーネントメンター、トラベラー、スカウト、オープンスペースなどの形式ばらないコミュニケーション手法を使う。」
洞窟コンセプトのおかげで他チームの人々と知り合うことができており、最初からチーム間のコミュニケーション自体は容易でした。しかし、チーム横断の調整を支える仕事の構造がありませんでした。各チームは自分のプロダクトバックログに取り組み、チーム間の整合はほとんどなかったため、チームはまったく異なるコンポーネントの作業をしていました。また、チームごとにスプリント周期が異なり、共通のイベントもないため、チーム横断で学ぶ機会は限られていました。
リポジトリが多数に分かれ、GitHubフローを使っていたことも、他チームのメンバーとのコード上でのコミュニケーションを妨げていました。
動くインクリメントの作成
LeSSルール:「必ず1つのプロダクトに関わるチームは同じスプリント周期を守る事。全てのチームのスプリントの開始と終わりは同じタイミングであること。スプリントの終わりにはプロダクト全体が1つに結合されている状態にすること。」
チーム数が増えるにつれ、スプリントごとに動くインクリメントを届けることはますます難しくなっていきました。継続的なフィードバックがなければ、間違った方向に進むリスクは高まります。動くインクリメントを届けるうえでの主な障害は、作業が部分的な納品に分割されていたこと、フィーチャーチームの不在、スプリントが揃っていないこと、そして継続的インテグレーションの欠如でした。
LeSS導入
LeSSルール:「LeSS導入の初期からプロダクトグループにLeSSの構造を完全な形で導入する事は非常に重要なポイントとなる。」
GROOVE XのLeSS導入は、漸進的なアプローチでした。LeSS導入でより一般的な「一斉切り替え(flip-at-once)」のアプローチではなかったのです。その結果、準備の順序も他のLeSS導入とは異なるものになりました。
漸進的なアプローチを取らざるを得なかった主な理由は、統合された単一のプロダクトバックログの作成に苦戦したことです。同時に、バックログの統合が完全に終わるまで構造の変更を待ちたくもなかったため、チームを徐々に統合していくことは、その時点では理にかなっていました。たとえば、われわれはフィーチャーチーム度を高めることから始めました。フィーチャーチームか否かは白黒はっきりできるものではありません。GROOVE Xにとっての真のフィーチャーチームは、振る舞いの作成、スマートフォンアプリケーション、クラウドインフラ、エレクトロニクス、ハードウェアまでをカバーするチームでしょう。しかし、一足飛びにフィーチャーチームの理想の状態に到達したわけではなく、本ケーススタディの対象期間中には、エレクトロニクスとハードウェアを含めるところまでは実現できませんでした。私たちの最初に注力したのは、既存のハードウェアを使って、一つのチームの中でエンドツーエンドの振る舞いを作れるようにすることでした。
最初のステップは、ふるまいチームのスコープを広げることでした。かつてダンサー、ゲームクリエイター、ミュージシャンだった人々が、LOVOTの動きをデザインする行動デザイナーとしてチームに加わり、チームの他のメンバーとペアリングやモビングを始めました。行動デザイナーがチームに入ったことで、ふるまいチームはチーム内で新しいふるまいを完結して届けられるようになりました。行動デザイナーが新しい動きを考えてくれるのを待つ必要も、レビューを待つ必要もなくなりました。ペアプロやモブプロによってお互いの仕事をレビューできるからです。
また、詳しくは「チーム」節で説明しますが、フィーチャーチームに近づくために、何人かのバックエンド開発者が認識チームに加わりました。当初、バックエンド開発者たちは、音声認識や画像認識に関連するフィーチャーには自分たちの仕事が十分にないかもしれないと考えていましたが、実際にはそれらのフィーチャーを支える機会が数多くあることがわかりました。この統合により、フィーチャーチームに一歩近づきました。
こうしたフィーチャーチームへ向けた小さなステップは、移行期間を通じて行われました。GROOVE Xではチームは有機的に生まれ、人々も有機的に他のチームに加わっていったので、「この時点が組織構造変更の始まりで、この時点が終わり」と明確に言うことは難しいのです。
もし私たちに、既存アイテムの大半を捨ててゼロから始める勇気があったなら、先に挙げたLeSSルールに従うことができ、より滑らかな移行ができていたかもしれません。
1.最適化ゴールの明確化
Many employees at GROOVE X are deeply invested in the future of their organization and are eager to contribute to shaping what it could become. During one weekend, volunteers spent a day together brainstorming and envisioning their ideal organization and how people would work in such an environment including team members and CEO.
First, they formed groups and used Lego to demonstrate how people would work together in an ideal state of the organization. Each group shared their Lego models and discussed their ideas with the entire group. After this exercise, the groups work to distill their thoughts into simple sentences, and everyone comes together to create complete statements that capture the essence of their organizational vision.
They then evaluate these sentences to ensure they can guide decision-making on how people should work. If these sentences were merely words on a wall, they wouldn’t be useful. The goal is to create something that can genuinely help individuals make decisions about their work. These statements should provide a clear direction for continuous improvement. Once they feel confident with the outcome, they share it with others who couldn’t attend the workshop and ask for feedback.
In the end, they formulated a few sentences that describe their ideal organizational state and called it their “spirit.” They shared this spirit with the entire organization, posted it on their website, and placed it in the office so that everyone could see it at all times. They regularly remind themselves of this spirit during retrospective meetings to come up with ideas that bring them one step closer to embodying it.
As a result of this session, we learned from each other about the important values we hold as a group and the direction we want our organization to move forward. After the session, I began to hear people talking about the “Spirit” in the office. When they needed to make decisions, the “Spirit” guided them in their choices.
GROOVE X Spirit
- Look one step ahead
- Enjoy it seriously
- Go to the field for the user’s smile
- Find individual strengths and turn them into team strengths
- Speak up. Listen up
- Try fast, learn fast
2.The same Sprint with common meetings and common Definition of Done
To create opportunities for cross-team collaboration and provide an overview of the entire product, the first thing we did was to synchronize the Sprint schedule and introduce common meetings across all development teams. We also attempted to unify the Product Backlogs, but merging all the Product Backlogs into one was challenging. As a result, we decided to postpone the merge to some other time.
The Sprint length was set to one week, with the start and end dates aligned for all teams, including the business teams. The common meetings we organized were Overall Refinement and Sprint Reviews. At this stage, each team first performed their refinement, brought their Product Backlog items to the common meeting, and then presented them to the other teams to get feedback, so we knew we needed to change this structure in the near future. Sprint Reviews were organized in a Bazaar style, allowing teams to showcase their increment and gather feedback from others.
To align quality standards across teams, we crafted a common Definition of Done. Since there weren’t significant differences between teams, we established a minimal Definition of Done that all teams could follow.
After this alignment, we gained a better understanding of what other teams were working on, identified opportunities to collaborate across teams, and received more feedback from a wider audience.
3.Educating about LeSS
We conducted several sessions introducing LeSS to educate everyone in the organization. Scrum Masters and I co-created the content and co-trained the sessions. By co-creating and co-training with the Scrum Masters, we not only enhanced their understanding of LeSS but also built their confidence to lead the transformation.
It was a half-day session to introduce LeSS, provide an overview of LeSS, and address any anxieties related to the change. However, there wasn’t much anxiety within the group. As mentioned earlier, the experimental mindset at GROOVE X was strong, and the team was generally open to change.
We also held sessions on how to split items effectively. The teams needed to understand how to create items with a customer-centric approach. While most of the items were created by the teams, it was natural for the engineers to focus on technical items. Therefore, we had to educate team members on creating items in vertical slices.
Regarding education, after adopting LeSS, we encouraged every team member to attend what we now call the “LeSS in Action” training. This highly impactful training was designed to help participants understand how an ideal LeSS team operates in a LeSS environment. I will discuss this training in more detail later in this case study.
4.Crafting unified Product Backlog
Unifying the Product Backlog took us a while because we had about ten Product Backlogs to merge, and not all items were customer-centric. Our first attempt to merge the Product Backlogs failed because we tried to consolidate every item into one Product Backlog, even those that were more like technical tasks. As a result, we decided to ignore the existing Product Backlogs and create a unified one from scratch.
Some team members were concerned about losing important items during this process, but another member mentioned, “If an item is that important, someone will write it again.” We found this mindset is valuable when merging multiple Product Backlogs into one. This phrase was frequently mentioned during refinement sessions when people discarded old items.
After each team created their items, we needed to prioritize them. The process for deciding the priority order was as follows:
-
Teams placed the items in the positions they believed were appropriate within the priority order
-
Use bubble sort to reorder by the team members. Basically, team members go through the items and move the items to the place they think is appropriate until there is no movement or discussion.
-
Product Owner reviews the priority order
The impact of having one Product Backlog was clear. It made it much easier for everyone to see the whole picture of product development, increasing whole product focus and transparency. As shown in the figure below, the Product Backlog was displayed on the wall of a large space, which allowed us to host multi-team events there such as multi-team refinement and Sprint Planning.
Once the single backlog was in place, it also became easier for business stakeholders to grasp the roadmap of upcoming features. This sparked more discussion between Developers and business people about what the business wanted to achieve and how Developers could contribute. Because priorities were visible to everyone, negotiation around them increased as well. For example, business stakeholders wanted to prioritize portable charging stations, while others felt we should focus on creating new behaviors to improve user interaction. These healthy negotiations to maximize product value happened frequently, and shifting direction became easy, all we needed to do was reorder the Product Backlog.
5.Self-design team workshop
After the Product Backlog was recreated, teams began to notice that some items couldn’t be completed by a single team and needed to wait for other teams to finish their part of work because of the specialization of the teams. This caused delays in feedback and learning. Recognizing this inefficiency, the teams decided to reformulate their structure. Scrum Masters facilitated a team self-design workshop to establish feature teams.
LeSS Huge Rule: “LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more overhead and local optimizations.“
At GROOVE X, when preparing for the self-design workshop, the whole product group consisted of about 80 people across 10 teams. According to the LeSS Huge rule above, this would typically qualify as a LeSS Huge setup. However, we couldn’t include hardware, design, and clothing teams to become feature teams.
The hardware teams operated on a different cadence from the software teams because they were already preparing for mass production. Hardware design is difficult to keep flexible during this phase—changing designs often requires modifying the production dies, which is very costly.
The design and clothing teams were also excluded from the workshop because they were not heavily involved in the ongoing development of LOVOT itself. The design team contributed to the initial overall design of LOVOT, but by the time mass production began, their focus shifted to advertisement-related designs, merchandise, shop design, etc. The clothing team focused on designing and manufacturing outfits for LOVOT. Therefore, GROOVE X decided not to include them in the workshop at that point.
The scope of the workshop was limited to software teams for the reasons above. The Scrum Masters scheduled every software team member to gather in a large room and explained the purpose and process of the workshop, addressing any questions or concerns about the upcoming changes.
The Scrum Masters first outlined the reasons for transitioning to feature teams:
- Delivering meaningful features quickly: To deliver customer value in a short period, teams need the skills and experience to complete the work independently as a team. Dependencies on other teams for critical tasks cause delays, slowing the delivery of value.
- Reducing waste: Component teams often lead to the creation of inventories and incomplete integration, resulting in waste.
- Avoiding suboptimization: A component team structure risks focusing on individual components rather than the entire product, which can result in losing sight of the whole product and the customer perspective.
The Scrum Masters also highlighted the relationship between customer-centric Product Backlog Items and feature teams. Effective collaboration requires alignment between how items are split and how teams are organized. If items are split by components, delivering customer value quickly becomes difficult, even if teams are organized as feature teams. Similarly, if items are customer-centric but teams are structured as component teams, delays occur as teams wait for others to complete the remaining work.
While some team members were initially skeptical about this change, the organization’s culture of embracing experiments encouraged them to give it a try.
There were sets of criteria that needed to be considered by the teams. For example, each team had to consist of a minimum of three people and a maximum of nine people and be capable of delivering new features without waiting for other teams to do some work for them. For example, teams need to be able to do requirement analysis, LOVOT’s behaviour design, coding, testing, deploying. Additional criteria were proposed by the team members and added during the discussions.
Each participant wrote their area of expertise on a piece of paper and then formed teams on their own. Once the teams were created, they had the opportunity to reevaluate and, if necessary, reform the teams.
Once the teams were formed, the new teams were posted on a board, and if adjustments were needed, members were allowed to make changes. They began working with the new teams in the next sprint, and during the retrospective, they would talk about new teams and adjust the team members if needed. At GROOVE X, team members were freely moved to other teams, so this adjustment did not need any Scrum Master’s support.
Product Development after LeSS Adoption
Roles
Product Owner
The Product Owner is the same person as the CEO and the sole manager in product development, responsible for evaluating all personnel in that area. He provides a vision for the product, which the teams sometimes call a “poem.” A poem means an abstract idea or direction that the PO wants to focus on or a high-level story. For example, “When I come home, I want the LOVOTs to greet me at the door and show excited behavior.” As product development moves forward, the Product Owner provides new Poems to give the teams focus, and the teams are aware that these Poems will change over time.
The Product Owner rarely creates Product Backlog Items (PBIs) himself. Instead, he shares the poem, and the teams start to think and discuss how to achieve the desired state and create PBIs. He understands the importance of giving the team space to work freely and experiment to create innovative products. Once items are created, he discusses them with the teams and prioritizes them.
Since the Product Owner knows a lot about technology, he sometimes requests the team to do specific or detailed work. The way teams perceive this dynamic is unique at GROOVE X. If the team thinks a request is important, they will immediately create items. However, I sometimes observed teams ignoring the request. Initially, I thought the teams were forgetting to write the items, so I asked, “Do you guys remember the request we got from the PO?” The team responded, “Yes, we remember, but we are ignoring it.” I was surprised by their answer.
Why ignore it? The team has worked with the PO for a while and has started to understand his character. The PO comes up with all kinds of new ideas all the time. Some ideas are great, but naturally, not every idea is great. Some ideas the PO is passionate about, while others are just thoughts at the moment and quickly forgotten. I discovered that this ignoring is a way for the teams to filter ideas.
Even when the PO asks the team, ‘Could you add this new idea to the Product Backlog?’, they sometimes don’t act on it right away. When I asked why, the team explained that the PO tends to have a constant stream of ideas, so if something is truly important, he’ll bring it up again. That’s why they intentionally hold off on adding it to the Backlog the first time he mentions it.
I would not recommend this approach for most organizations because it will likely reduce transparency. At GROOVE X, people trust each other to bring important matters to the Product Backlog. They care about their product, so if one person thinks a topic is important to discuss with other teams, they will add it to the Product Backlog. This is one of the reasons why the Product Owner does not create items himself. Instead, the Product Owner tries to pitch his idea to the teams to test if the idea is worth considering.
LeSS Rule: “The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.”
The GROOVE X Product Owner was definitely not working alone on the Product Backlog refinement. Clarification and splitting of the items were done by the teams. The teams suggested the order of PBIs, which the Product Owner usually accepted. They also suggested removing and adding items to the Product Backlog. Of course, the teams understood that the final say always belonged to the Product Owner.
The Product Owner considered attending LeSS events to be one of the most important responsibilities. Despite being extremely busy with his duties as CEO, he prioritized attending these events as much as possible. His commitment was a critical factor in ensuring the success of the LeSS adoption. In LeSS, it is also generally not a good idea for management to serve concurrently as the Product Owner, because it usually makes it harder to separate organizational improvement from the product development role. Also, a Product Owner is usually a good idea to find from the business side, but since the Product Owner was a former engineer, I observed that he tried very hard not to comment on technical details, in order to focus on “why and what” as a Product Owner and delegate the decision on “how” to the teams.
Scrum Masters
LeSS rule:“Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system”
The Scrum Masters at GROOVE X supported the teams, the Product Owner, and the organizational system. With the freedom to improve organizational systems, they co-created a policy that determines how salaries and bonuses are decided together with HR specialists. They were also involved in the hiring, team formation, and the removal of organizational impediments. Additionally, they facilitated common LeSS events, such as Sprint Reviews, Overall Retrospectives, and Multi-team Refinements.
While most teams were facilitating their events, they would request help from the Scrum Masters when needed. If the Scrum Masters noticed miscommunication between the Product Owner and the teams, they would step in to support the Product Owner.
LeSS rule:“One Scrum Master can serve 1-3 teams.”
When GROOVE X adopted LeSS, there were six teams in the software area and three Scrum Masters. While this might seem like an appropriate number, the Scrum Masters also supported some hardware teams and business teams, resulting in a workload beyond their capacity. Since it was difficult to find experienced Scrum Masters, GROOVE X began hiring individuals who aspired to become Scrum Masters, even if they didn’t have prior experience. These new Scrum Masters were provided with training and joined the Scrum Master community for continuous learning.
LeSS rule:“A Scrum Master is a dedicated full-time role.”
All Scrum Masters at GROOVE X were in dedicated full-time roles. They regularly shared organizational impediments, synced their progress, and exchanged ideas. They also allocated time for learning and improving their skills as Scrum Masters, forming a Scrum Master community. This community met regularly to share knowledge, demonstrate new learnings, and receive feedback from peers. For instance, each Scrum Master created their own training materials to teach Scrum and LeSS. They would simulate training sessions with other Scrum Masters to receive feedback and improve their teaching skills. This simulation was invaluable for mutual learning, aligning understanding among Scrum Masters, and deepening their grasp of the concepts through teaching.
Teams
If you step into the GROOVE X office, you might observe an engineer and a dancer pairing to design the behaviors of LOVOT. Their software development team includes many specialists: image recognition engineers, sound recognition engineers, application engineers, dancers, and more. These teams are feature teams, capable of delivering end-to-end software functionality without relying on other teams.
Of course, not every team has specialized skills in sound recognition. There are only a handful of labs in Japanese universities that study sound recognition, so very few people ever get the chance to specialize in this field, and only a handful are actively working in it. Consequently, GROOVE X has only one person with this expertise, making it a bottleneck. The GROOVE X team addressed this issue during their retrospective and found a solution that might be relevant to organizations relying on a single specialist.
The team analyzed all the work the specialist was doing during the sprint. They discovered that most of his time was spent cleaning and organizing sound data, with algorithm creation being only a small part of his work. While learning sound recognition algorithms takes time, learning how to clean and organize sound data is relatively quick for other engineers. Therefore, they began signing up for some of these tasks by other engineers to resolve the bottleneck.
They also wanted to extend feature team coverage to the hardware area, but the challenge was the cadence. Initially, hardware and software engineers could work closely together using 3D printers to create and assemble parts during prototyping. However, as product development progressed, hardware became less flexible due to the costs associated with mass production changes. Changing the shape of a mold, for example, is expensive. This dynamic created a cadence difference between hardware and software, complicating the formation of mixed hardware-software teams. Teams are still learning from each other and striving to collaborate. For example, some software engineers moved to the hardware team to gain knowledge, and Scrum Masters continued efforts to merge the software and hardware backlogs into a single product backlog. I’ll dig a bit deeper in the “LeSS adoption including hardware” section about this.
Events
Refinement
In Scrum, refinement is an activity that teams can choose to do whenever it is convenient for them. However, in a LeSS environment, this activity (multi-team product backlog refinement) is not optional and is used - among other things - to maximize cross-team learning. Therefore, we scheduled a common time slot for all teams to meet at the same time and place to discuss upcoming developments.
GROOVE X’s refinement consisted of two parts. The first part, Overall Refinement, involved representatives from the software, hardware, and business teams gathering with the Product Owner to determine the overall order of Product Backlog Items to prepare for the second part of the refinement which was multi-team refinement. This meeting was relatively short and focused primarily on aligning the direction and priorities of the Product Backlog for the near future.
As mentioned in the LeSS Adoption section, this meeting was one of the first common meetings introduced to enhance the transparency of the overall picture. It is aligned with two key LeSS principles: Transparency and Whole Product Focus.
LeSS Rule:“The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.”
LeSS Rule:“Product Backlog Refinement (PBR) is preferably done with multiple teams to increase shared learning and to exploit coordination opportunities.”
In the figure above, team members gather around the Product Backlog, which is displayed on the front wall. They pick up an item that is approaching development within the next 2-3 sprints and find others who are interested in refining the item together, regardless of their team or specialty. After refining or splitting the items, they return the refined items to the Product Backlog.
LeSS Rule:“All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.”
The Product Owner makes the final decision on prioritization, but most of the time, the teams propose the prioritization, so most of the time, team members place the items in the order they believe is most appropriate. The Product Owner reviews the order but rarely changes the priority that the teams have proposed. However, the Product Owner remains focused on the overall picture and the themes that the teams are working on.
The second part of Refinement is multi-team refinement. This meeting is scheduled after the Overall Refinement, allowing the teams to refine items collaboratively. Team members take large or unclear items from the top of the Product Backlog and refine them together.
This multi-team refinement takes place in a common area, as shown in the figure above, so team members can easily talk with members of other teams when necessary. After refinement, the refined items are brought back into the Product Backlog either to their original place, or, if new items are proposed or created by splitting, the teams decide where to place them. The order may be adjusted before or during Sprint Planning in any case.
Recently, LeSS has recommended not separating Overall and multi-team refinement, but instead organizing refinement in mixed-team groups in one session.
Sprint Planning
Sprint Planning consists of two parts. The first part is Sprint Planning 1. During this session, team representatives gather around the Product Backlog and decide which teams will take on which items. They also discuss whether any cross-team support is needed for the items.
During Sprint Planning 2, if a team needs to collaborate closely with other teams in the next sprint, they bring their Sprint Backlog to the common area to coordinate. If close collaboration is not required, the team uses their own space, utilizing whiteboards to design and plan independently.
Daily Scrum
In the morning, GROOVE X holds a short, whole-company meeting to allow everyone to get to know each other and share company-wide information. After this meeting, teams move to their Sprint Backlog areas to adjust their plans for the Sprint and decide what to do until the next Daily Scrum. Sometimes, members from other teams observe how different teams are progressing and look for opportunities to collaborate.
Sprint Review
The Sprint Review is conducted in a bazaar style. Each team sets up its booth in the office to present the current increment and gather feedback. One or two team members remain at the booth to explain their work and answer questions from other team members, stakeholders, and the Product Owner. The rest of the team members are divided into groups to participate in the bazaar as attendees.
When the first 20-minute round is over, a Scrum Master hits a drum to signal everyone to move to the next team booth. This process is repeated until each group of participants has visited all the team booths. Feedback is provided to the teams at the end of the sessions, or participants can use a common feedback form for each Sprint Review, allowing them to submit their feedback later.
Team Retrospective
Each team conducts a team retrospective, just like in Scrum. Scrum Masters assisted when teams requested for facilitation even outside of the LeSS adoption. Most teams, including those on the business side, regularly held retrospectives to improve their way of working.
Overall Retrospective
The Overall Retrospective was held to discuss organizational issues with team representatives, the Product Owner, and Scrum Masters. Teams would bring up issues that needed to be addressed by larger groups or that required alignment with other teams, and these topics would be discussed in this meeting.
Artifacts
Product Backlog
GROOVE X teams view the Product Backlog as a source of dreams—filled with wishes and aspirations they aim to achieve. Beneath their physical Product Backlog, there is a box called the “Dust of Dreams,” essentially a trash box for items. Teams casually toss items into this box. This practice often surprises new team members, who might ask, “What if the item is very important?” A seasoned team member would respond, “If it’s important, someone will write it again.” This system works because the teams have strong trust in it. The Product Owner understands that teams focus on the entire product and the customer, ensuring that decisions are made with the product’s best interests in mind and aligned with the product vision.
There is only one Product Backlog in software development. Unfortunately, due to differences in cadence, there is one separate Product Backlog for the hardware area. When reaching the mass-production phase, hardware Product Backlog items can no longer fit into a Sprint, while software items still can. Since it is difficult to integrate new hardware every Sprint, software teams need to continue working with the previous hardware until the new hardware is ready for internal use. This means that hardware and software are not integrated in every Sprint.
Sprint Backlog
All the teams used analog Sprint Backlogs because they found it easier to share information within their team and with other teams when coordination was needed. Team members frequently visited the board throughout the day to update their Sprint Backlog. It wasn’t limited to updates during the Daily Scrum, the board served as the central hub for team collaboration.
Increment with hardware
The short movie below demonstrates how LOVOT has evolved as a product through incremental development.
https://youtu.be/dO_2E5-WSK0?si=eymUAvcaG3mvQ6Vl
As you can see from the video and the picture above, LOVOT’s development began with very simple prototypes. These three were created at the very beginning of development. The one on the left was used to validate the feeling of holding LOVOT—a critical factor for the product. The middle one was built on a robot vacuum cleaner as a base, with additional devices mounted on top to validate movement. The one on the right was used to test the camera. Each prototype was kept deliberately simple, allowing the team to verify one critical aspect of LOVOT at a time.
They utilized 3D printers to create custom parts, enabling quick experimentation. This approach allowed GROOVE X to reduce experiment costs and accelerate the development process. Through this method, hardware and software evolved incrementally together. In each sprint, both hardware and software changed, with hardware developers and software engineers working closely to create a unified product. When new hardware was needed, the hardware team would design and produce necessary components, either by adapting existing parts or creating new ones using 3D printing. Meanwhile, software engineers would develop the firmware and applications required to integrate and utilize the new hardware. These activities were performed in parallel, maintaining the same cadence.
However, maintaining this cadence became challenging as the development phase shifted. LOVOT’s development can be divided into two phases: the prototyping phase and the mass production phase. During the prototyping phase, as described above, hardware and software teams collaborated closely to create incremental improvements. However as the project moved closer to the mass production phase, the flexibility to make changes in hardware decreased. For mass production, molds had to be created, which is a costly and inflexible process. These constraints led to a divergence in cadence from software development and limited the ability to incorporate new and better devices. GROOVE X always aimed to select the best devices for LOVOT, so they kept their options open until the last possible moment, even if it meant incurring additional costs for changes.
Experiments
Adopting the LeSS structure is not the end; rather, it is the beginning of a new journey of continuous improvement. GROOVE X used many ideas from LeSS’s Principles, Guides and Experiments to improve its situation, but it also devised its own experiments. These experiments are not always aligned with LeSS principles, so each section includes an “Alignment with LeSS” note at the end to explain whether the experiment aligns with LeSS and why.
Also, the term “Experiment” is used here broadly, not in the strict scientific sense, but more along the lines of “things we tried and how they went”. Some of these experiments involve following LeSS principles and guides, and some fall into the category of “Technical Excellence”, which is also recommended by LeSS. These ideas are not unique to GROOVE X, but how they are applied can differ depending on the organization. That is what we hope to share in this section: some of the things GROOVE X tried, and how they went.
People Management
This section is about experiments related to people management. Since GROOVE X product development organization decided not to create management roles, these experiments explore alternatives to traditional management structures.
Job Titles
Most GROOVE X employees did not hold an official title beyond “team member.” However, some of GROOVE X’s suppliers did not fully understand how the company operated and often requested the presence of management in business negotiations, expecting a decision-maker to attend the meetings.
To avoid lengthy explanations, GROOVE X team members occasionally created business cards with management titles for this purpose. Those who used such titles on their business cards fully understood that these titles held no actual significance within GROOVE X.
A similar situation occurs for regulatory purposes. Certain industry, government, or market regulations require the designation of a responsible person. When this happens, someone within the organization volunteers to take on the responsibility. As a result, some individuals are officially assigned managerial titles to comply with regulatory requirements.
However, the person taking on this role understood that, while they are accountable, they do not possess actual authority within the organization. This can be a challenging position, as it involves bearing responsibility without the corresponding authority. Nonetheless, they recognize that maintaining GROOVE X’s unique way of working sometimes necessitates accepting these roles.
People who became managerial positions for regulatory purposes were expected to stay informed about matters related to their responsibilities, either by monitoring the situation themselves or by requesting updates from the teams involved to fulfill the requirements. Of course, everyone in the organization cooperates with such requests, even though the person in charge does not have formal authority. GROOVE X does not have a culture of obeying authority; instead, they help each other regardless of title or position.
Alignment with LeSS:
This experiment is also aligned with LeSS. Since managers are optional in LeSS, organizations like GROOVE X need to find ways to collaborate with traditional partner companies. This experiment was their approach to addressing that challenge.
Gardeners
The Gardeners group is made up of individuals involved in or interested in creating a healthy corporate environment. Members include those with backgrounds in HR, Scrum Masters, or coaches. This group shares people-related challenges and discusses strategies to address them. They also develop company policies that strike a balance between aligning with external expectations and preserving the company’s culture.
The group sees themselves as nurturing the organization’s organic growth, much like gardeners tending to a garden, which is how the name originated.
The Gardeners meet weekly to review and address organizational impediments. During these meetings, they discuss the most pressing issues facing the organization at the time. Some topics include actions like issuing a Yellow card or a Red card. These terms are specific to the Gardeners: a Yellow card serves as a warning when someone in the organization behaves in an unacceptable manner, similar to a caution in a soccer game. In their regular meetings, they also discuss how to provide constructive feedback in such situations. The Gardeners view this approach as temporary, with the ultimate goal of enabling teams to sustain their well-being and growth independently.
The Gardeners also play a role in shaping the hiring process for teams and provide support when needed. Additionally, they propose methods for determining salaries and fostering individual growth. These aspects are discussed further in the sections “Hiring by the Teams” and “No Performance Appraisals” below.
This group takes on some of the responsibilities traditionally handled by management. It was not a fully open community as defined in LeSS, because participation was not open to anyone interested. The decision to keep the group closed was intentional, as they often deal with sensitive matters such as termination of employment.
If you are planning to form an organization without any managers, you may need to consider incorporating such a function until the teams are mature enough to handle human management decisions on their own.
Alignment with LeSS:
The concept of Gardeners is not fully aligned with LeSS. From the outset, there was a shared understanding that the Gardeners would serve as a temporary solution, with the goal of ultimately transferring their responsibilities to the teams. Once this handover was achieved, the Gardeners group was intended to dissolve.
However, this transition was not completed within the timeframe of this case study. Creating special roles or assigning special responsibilities takes responsibility away from the teams, so it is best not to establish such special groups. From a LeSS perspective, one alternative could be to create a community that anyone can freely join to help determine organizational rules.
In Japan, there are very strict regulations around dismissing employees, so it would be difficult for a community to handle this. In such cases, management involvement is necessary. At GROOVE X, HR specialists and CEO played the central role.
Hiring by the Teams
At GROOVE X, teams are responsible for hiring. Teams are best positioned to know what skills are missing, so when they need to add someone, they can invite other team members to join. However, if they can’t find a suitable candidate internally and the budget allows, they will initiate the hiring process. Most of the time, they will first think of their friends or people used to work who could help in the area. They know it’s best to find a person they know well, so many people in GROOVE X join the company by referral of other members. If they can’t find the candidate by themselves, they can get support from the Gardeners.
When a team decides to start the hiring process, they consult with the Gardeners and share the specific qualities or skills they are looking for in a candidate. One of the Gardeners will then create the job posting. When someone applies for the position, the team will interview the candidate. After the interview, the team members will vote using the Candidate Evaluation Matrix. Each team member writes their name on a card and places it simultaneously, similar to playing planning poker. If there are differences in opinion after the first round, the team will discuss these differences and, if necessary, conduct a second round of voting. This process is also supported by the Gardeners if needed.
The Candidate Evaluation Matrix was created to support the team’s decision-making process by highlighting key considerations and outlining the next steps. This matrix helps teams make informed decisions and facilitates discussions about the candidate.
After a candidate passes the team’s evaluation, the CEO will interview to confirm whether the candidate is a good fit for the organization and to share the CEO’s perspectives. However, this CEO interview is more of a formality to get to know the CEO in person before both sides make their decision.
The hiring process without managers worked fairly well at GROOVE X; however, firing by the teams proved to be much more challenging. If a team found it difficult to work with a certain person, they had the right to remove that person from the team. If the individual could not find another team to join within GROOVE X, they would need to seek work outside the company.
However, even when teams faced difficulties working with someone, they often struggled to take the step of removing them. It was too challenging for the teams to make such a decision on their own, so the gardeners needed to step in and support the process of letting people go.
Alignment with LeSS:
This experiment aligns with the concept of self-managing teams. Similar to a self-designing team workshop, it enables management to delegate authority to the teams, allowing them to design their own teams.
No Performance Appraisals
First of all, there were no performance appraisals at GROOVE X, but we still needed to determine salaries and support individual growth. When I say there were no performance appraisals, it means there was no individual measurement of performance. How well or how much effort someone put into their work did not affect their salary. There were no individual objectives linked to compensation, and no bonuses tied to individual performance.
Performance is very difficult to measure and it is hard to be fair to everyone because the people measuring performance are usually managers, who cannot be completely objective. Managers are human, and humans inevitably introduce subjectivity and bias. Because of this, it is almost impossible to make performance evaluations fair for everyone. However, many companies invest significant time and effort in performance appraisal systems. They set organizational objectives, break them down into individual goals, hold goal-setting meetings with managers, and conduct reviews and feedback sessions at the end of each quarter. Then the process starts again for the next quarter. This process often does not add much value to the product, takes a lot of time from everyone, and does not necessarily make people happier.
Another issue with performance appraisals is that individual objectives can work against team collaboration, knowledge sharing, and mutual support. Supporting each other is a norm in a LeSS environment, but performance appraisal systems often overlook this aspect. Moreover, because performance appraisals focus on individuals, people usually end up setting different objectives. When team members have different objectives, there is an incentive to prioritize individual goals over teamwork. It can also encourage people to work on tasks that help them achieve their personal goals rather than focusing on the highest priority items in the Product Backlog or on delivering value to customers.
Even though we wanted to move away from performance appraisals, we still needed a way to determine salaries and support individuals’ personal development. We started by focusing on personal growth.
GROOVE X used a wearable badge-type sensor device. This is a wearable device similar to an office badge that records who you speak with, how long the conversations last, and how often they occur. By combining the face-to-face communication data collected by the device with digital communication data such as Slack interactions, the company was able to identify potential mentors outside of each employee’s team. Each team member received a list of potential mentors and could choose their mentor based on this information. Once mentors were selected, mentors and mentees met regularly to support the mentee’s personal development.
In addition to supporting personal growth, we also needed to address how salaries would be determined without traditional performance appraisals. In the beginning, salary decisions were made solely by the CEO. GROOVE X believed that salary should not be the primary motivator for work; instead, the work itself should be motivating. At the same time, we wanted to avoid demotivating employees due to concerns about compensation.
Our strategy for determining salaries was to collaborate with an external partner to assess employees’ market value and offer slightly higher compensation. The goal was to prevent employees from leaving due to salary dissatisfaction and allow them to focus fully on product development. To achieve this, GROOVE X partnered with a recruiting company to co-create a service to which salary and bonus decisions are outsourced.
This recruiting company has career data on more than a million professionals across a wide range of industries. Once GROOVE X provided employee information, the service suggested appropriate salary ranges. Unfortunately, this service did not gain traction as a product, so the experiment eventually ended and the CEO continued to decide salaries for all employees.
As another experiment related to bonuses, GROOVE X used a peer bonus service. This service is a Japanese platform that allows employees to send small bonuses to their peers. Instead of management giving a large annual bonus, the company pooled the bonus budget into this service. Employees could then send “thank-you” bonuses to colleagues whenever they appreciated someone’s contribution. Some employees liked the system very much. However, there was also a challenge: not everyone actively used the system, which meant that only certain individuals benefited from it.
Alignment with LeSS:
Performance appraisals influence how people behave in the workplace. While the LeSS rules do not prescribe a specific approach for handling performance appraisals. However, the book Scaling Lean & Agile Development mentions that it is recommended to decide salaries based on certain classifications, determined by the cost of living and the market value of specific skills. This was what GROOVE X attempted to achieve.
Product Management
Experiments in this section are related to product management. One aspect is increasing the ownership of the teams. GROOVE X team members have a strong sense of ownership over their product, which leads them to propose innovative ideas. Combined with significant delegation of decision-making to the teams, this enables them to work autonomously. Another topic in this category is how to find and grow the next Product Owner.
Also, we have already explained the struggle of creating one unified Product Backlog, but even after that was achieved, there were further experiments related to the Product Backlog. Since GROOVE X teams had a great deal of ownership of their process and artifacts, both of these experiments were initiated by the teams themselves. Although managing the Product Backlog is the Product Owner’s responsibility, the Product Owner let the teams change it as long as he was comfortable with the changes — and in fact, I never saw him complain or stop the teams from making changes during the period of the case study.
Bringing customers closer to the Developers
When there was a shortage of people for customer service, teams started taking turns answering customer support calls. They communicated directly with customers to understand their issues. Taking these calls helped teams gain a better understanding of customer perspectives. For example, a child once called the support team and asked if she could take a bath with LOVOT. Although LOVOT is not waterproof and cannot be bathed, the team learned that children perceive LOVOT as almost a living being and expect to treat it like other pets. Keeping this in mind, behavior design and safety tests might be affected.
LeSS Principle: “Customer Centric”
Additionally, GROOVE X opened the LOVOT Museum in the same building as their development site, bringing potential customers closer to the development site. In this environment, they can observe real customer reactions to new behaviors or capabilities. Since LOVOT is intended to live with people, it often encounters unexpected behaviors from users.
Alignment with LeSS:
Being customer-centric is one of the principles of LeSS, so working closely with customers is aligned with LeSS.
SKs
SKs were created as a group that shadows the Product Owner to learn the role. The main purpose was to create an environment to grow the next Product Owner for the entire product. Also, SKs existed to support the Product Owner and the teams in making better decisions by helping with clarification and prioritization in their areas of expertise.
Originally, Hayashi intended to delegate his Product Owner role to someone within the organization in the near future, following a governance recommendation to prepare for becoming a publicly traded company. However, he could not find a suitable person to take on the role at that time. As a result, he sought to establish a mechanism to educate individuals about the Product Owner role.
During his time at Toyota, Hayashi was part of a group called Z. Z was a team designed to understand the Product Manager’s vision and act as the Product Manager’s shadow. Inspired by this idea, he created SKs, GROOVE X’s version of Z. Some team members became SKs, and their role was to support the Product Owner in carrying out responsibilities, assist teams in clarifying items, and provide feedback when needed.
Alignment with LeSS:
LeSS is silent about how to develop the next Product Owner. However, creating such a position has its risk because some responsibilities might shift from the teams to SKs. For example, if SKs handle clarification and customer-facing activities, it can create more distance between the teams and the customers. Because of this risk, it is generally not recommended from a LeSS point of view.
However, in their environment many responsibilities had already been delegated to the teams. The teams were already operating with a whole-product focus and communicating directly with customers, so the negative impact on the organization was limited in their case.
The Poem was still created by the Product Owner to provide vision, and the final decision-making authority remained with the Product Owner.
Team lane in Product Backlog
One experiment GROOVE X conducted was to loosely assign which team would handle which items over the next three sprints, in order to give teams a clearer view of what was coming up in the near future. As a result, team-specific lanes were created in the Product Backlog for those upcoming sprints. After refining the items, each team pulls their items into their respective lanes. This setup was in use at the time the picture was taken.
While teams were allowed to switch items between lanes based on progress, the presence of separate lanes still made it difficult to reassign items freely which reduced the whole product focus. When teams have their own lane, they tend to just focus on what is coming up in their own lane and even when teams are willing to collaborate with other teams, from the system perspective, teams care less about what other teams are doing. Teams also tend to stay in their comfortable areas of work which creates silos around parts of the product which reduces opportunities to learn the other parts of the product. This also means, from a whole product perspective, teams might not be working on the most important items. Eventually, they recognized the issues and reverted to a single, ordered Product Backlog.
Alignment with LeSS:
This experiment was not aligned with LeSS because it reduced the chance of working on the most important items and created silos that prevented cross-team collaboration and reduced opportunities for learning. In LeSS, the Product Backlog should be a single, ordered list.
Skunk works outside of the Product Backlog
Due to the blurred lines between work and hobby, some team members began creating features that were not in the official Product Backlog. This could be seen as a “Implicit Product Backlog,” which is generally not a good practice. However, the Product Owner was aware of this activity and specifically asked us not to interfere.
The team was developing features for children, using Scratch to program LOVOT’s behavior so that even kids could design how LOVOT behaves. There was no formal policy, such as a “20 percent rule.” Instead, a group of volunteers naturally came together to create these features. Once they finished a prototype, they presented it during the sprint review. They understood the importance of the official Product Backlog and worked on it as a team, but they developed this feature as a hobby and made it official afterward. GROOVE X recognizes that activities like these are also important for fostering innovation.
LeSS Rule:“ There is one Product Owner and one Product Backlog for the complete shippable product”
While this implicit Product Backlog approach worked for GROOVE X, I wouldn’t recommend it to other companies, as it goes against LeSS rules. Even the team members working on this side project understood the importance of the official Product Backlog and stayed aligned with the overall goals. Their intention was not to hide their work but to enjoy the creative process and share their passion for teaching kids the joy of programming. Developers could have put the idea in the official Product Backlog, but they wanted to keep it as their fun experiment until they want to get feedback from others. They eventually brought this feature to their Sprint Review and got feedback from others.
Alignment with LeSS:
Having multiple Product Backlogs or a hidden Product Backlog is not aligned with LeSS thinking. In LeSS, there should be only one Product Backlog per product, and I would not recommend using multiple Product Backlogs as it reduces both focus and transparency.
However, this experiment succeeded because it was only a temporary approach until the initial feature was completed. At GROOVE X, “serious play” is valued, since creating innovative products requires some free space to play. Additionally, the team was transparent about this activity to others including the Product Owner and the Product Owner valued the work they were doing, so even though the feature was not on the physical Product Backlog, the Product Owner had a single priority list in his mind.
Following LeSS Principles and Guides
During the period covered by this case study, we followed the LeSS principles and guides described in the LeSS books. Rather than listing all the guides GROOVE X tried or adopted, I want to highlight the principles and guides that GROOVE X applied in a particularly interesting and at times extreme way that is worth highlighting in this case study.
Note: This section and the following sections do not include an “Alignment with LeSS” subsection, because the experiments described here are all aligned with LeSS by design.
Stop and Fix
After LOVOT was released to the market, some urgent issues needed to be resolved. To address these, volunteers from the teams stopped their current work and formed a temporary group to fix the issues.
LeSS Principle: “Lean Thinking-Stop and Fix”
This initiative was not driven by management. Instead, the teams themselves recognized the issues and felt a strong sense of responsibility to act. One team member suggested gathering volunteers from all product development teams to discuss the situation. The volunteers met in a large meeting room, collaboratively discussed the problems, and created a plan to resolve them.
Within a few weeks, the critical issues were successfully addressed, and the group naturally disbanded. This dynamic movement happened organically, without any involvement from management. There was no blaming of other roles or parts of the organization.
The “Stop and Fix” concept originates from Lean, and since Lean Thinking is one of the core principles of LeSS. However, the original “Stop and Fix” concept means everyone stops working and fixes the issue, including its root cause. GROOVE X did not stop everything; instead, approximately one third of the developers joined a volunteer group to address the problems. Meaning this was not a strict application of the original Lean practice.
Travelers
GROOVE X teams often use the LeSS technique known as “Travelers.” A Traveler is a technique used in a LeSS environment to facilitate learning between teams. Essentially, one team member temporarily joins another team as a regular team member for a few sprints. Traveler acts as a fully integrated member of the new team, working together to get things done and spread knowledge.
I observed this practice being initiated in two different scenarios: (1) When a team is facing difficulties that current team members cannot resolve, they ask for help from members of other teams. (2) When a Traveler has an idea they want to spread within the organization or they want to learn from other teams, they ask other teams if they can join them for a few sprints.
What was unique at GROOVE X was that teams moved between different areas. For example, when staff at a LOVOT store needed help serving customers, software or hardware engineers would join their team. When a manufacturing factory encountered issues and needed support, Scrum Masters and hardware team members would join to help resolve the problems. This practice was not limited to the software area. For instance, one software engineer wanted to merge the hardware and software areas, so he first joined a hardware team to learn how they worked.
Once they fulfilled their initial purpose, they usually returned to their original teams. However, some people preferred to change their home team or regularly visit the other team.
“Travelers” are one of the coordination and integration techniques in LeSS. However, GROOVE X expanded the scope of travelers. In LeSS, travelers are expected to move within the area of LeSS adoption, whereas GROOVE X travelers can move across any teams in the organization.
Technical Excellence
Technical excellence is an area that LeSS emphasizes greatly in order to be able to change direction with no or low cost, which is one of the fundamental goals LeSS aims to achieve. The following are things GROOVE X has done that are worth mentioning in relation to this topic.
Technical Training
Developing LOVOT involves dealing with many uncertainties in technology, which makes teamwork among specialists essential to bring together the ideas and skills of many talented individuals to work toward a shared goal. GROOVE X also values technical excellence as a key to success. For this reason, nearly every software engineer at GROOVE X has taken part in the “LeSS in Action” course, which teaches the technical practices needed to maintain a flexible development environment that can adapt to future challenges and how to collaborate within the team and inter-team collaboration.
The “LeSS in Action” training sessions were led by Terry or Stanley from Odd-e. The course is designed to give participants a taste of what it’s like to work in a real LeSS environment. Over one week, participants spend about 70 percent of their time working through a simulated Sprint with other participants and 30 percent attending lectures. These lectures cover technical practices such as Test-Driven Development (TDD), Acceptance Test-Driven Development (ATDD),Specification by Example, Continuous Integration, Emergent Design, Trunk-Based Development, Pair Programming, Mob Programming, and more—all practices that support the LeSS way of working. In addition to learning these techniques in the classroom, participants use them to develop an actual product in teams, experiencing how these practices come together in real-world situations. They also take part in LeSS events, gaining firsthand insight into what it feels like to adopt LeSS.
After this training, many developers gained a deeper understanding of what GROOVE X is aiming to achieve. This hands-on experience had a significant impact on how teams operate. GROOVE X engineers took what they learned and began applying it to their work, incorporating practices like mono repo, continuous integration, automated hardware testing, and pair or mob programming into their daily workflows.
Technical excellence is a key element in LeSS adoption to keep the product ready for future changes. The “LeSS in Action” training provides a complete package of technical practices and also serves as a way to foster collaboration between teams.
Pair and Mob Programming
As a result of the “LeSS in Action” training, pair and mob programming became the norm for GROOVE X development. Team members with different specializations paired up to create increments together. When the team encountered significant uncertainty, they would initially mob to tackle the unknowns. Once the situation became clearer, they would switch to working in pairs.
Many initially thought that pair or mob programming would reduce productivity. However, after becoming accustomed to the approach, they began to appreciate its benefits. Typically, a significant portion of development time is spent thinking rather than coding. Since the actual time spent typing is relatively small, they realized that despite the assumed slight decrease in productivity, the increase in learning was substantial. Moreover, working closely with team members made the process much more enjoyable. Even members from other teams would join the mob or pair to learn from one another.
Pair or mob programming is not a strict rule in LeSS, but technical practices such as continuous integration, automated testing, and shared code ownership are essential to ensure that teams can maintain a high-quality product while adapting to change. Pair and mob programming contributed to fostering collaboration, reducing knowledge silos, and enabling real-time learning among team members.
End-to-End Automated Tests Including Real Hardware
Since LOVOT is a very complex product including hardware and software, automating tests also has multiple layers. Teams found the task of automating tests for the entire product particularly intriguing, so they decided to take it on.
During the prototyping phase, most of the hardware was assembled by hand, with parts either purchased or created using 3D printers and then integrated into the increment. The software was also integrated in every sprint, so both hardware and software were continuously integrated throughout each sprint.
In this phase, two different kinds of tests were needed. The first was a hardware simulation test, which could run quickly in the developers’ local environments and was executed frequently to verify hardware functionality in simulation.
Secondly, simulation alone was not sufficient to ensure full hardware and software integration. To address this, they designed an integration test based on a “wake-up movement”: LOVOT wakes from sleep in its nest, walks around, and returns to the nest. This integration test is triggered whenever a new version of the software image is built, providing immediate feedback on how the new image affects basic functions and whether they operate normally. The test covers not only the software and hardware but also the cloud. When the test is initiated, LOVOT pulls its initial data such as eye design and voice design data from the cloud, allowing the test to validate LOVOT’s initial state and basic functionality. In this way, the wake-up movement serves as an end-to-end test for LOVOT, encompassing the integration of hardware, software, and the cloud. This was the beginning of GROOVE X’s end to end test automation journey.
You can watch the wake-up movement here:https://youtu.be/Wyw0HDT-CiY
The two tests described above—the “hardware simulation test” and the “wake-up movement” test—were sufficient during the prototyping phase. However, things became more complicated in the mass production phase.
Once development entered the mass production phase, it became much more difficult to integrate the hardware in every sprint to create a Potentially Shippable Product Increment, due to the inflexibility inherent in mass production.
First of all, the dies used to create parts were very expensive to modify. GROOVE X tried to delay the decision to finalize part designs until the last responsible moment. Even after the dies were created, they incurred additional costs to modify them multiple times as new devices were introduced or better ideas emerged later. The Product Owner had to decide whether it was worth spending the extra money to make those changes. In most cases, the Product Owner chose to accommodate as many changes as possible to create a better product.
Secondly, in order to release the product, GROOVE X needed to run endurance tests to ensure its safety. These tests were also automated but had to run continuously over long periods of time to confirm that the parts were durable and safe for home use.
Once a new software image is created and all automated tests have passed, it can be deployed to selected internal LOVOTs. Some of these LOVOTs are used for long-term testing, including the Product Owner’s LOVOT, which always runs the latest version, as well as the LOVOTs of certain team members who volunteer to test the new version at home.
From the perspective of automated hardware testing, the cycle time became different from the prototyping phase. Software developers had to continue using the previous version of the hardware until the new version was delivered to them.
As described above, there are four different types of automated tests related to hardware:
- Hardware simulator testing
- Automated wake-up movement testing
The two tests above were used during the prototyping phase, and the two tests below were added when development entered the mass production phase:
- Endurance testing
- Canary releasing
The hardware engineers at GROOVE X generally had experience working in large hardware manufacturing companies and found it difficult to adopt an Agile mindset, mainly due to their previous backgrounds. They felt unsafe making changes in later stages, as such changes often introduced defects - a concern that was valid. However, they tried to overcome this fear by implementing automated hardware tests to ensure stability and safety.
By including hardware interactions in the automated test suite, the team can verify that both the software and hardware components of LOVOT work together seamlessly. This reduces the risk of unexpected issues surfacing after deployment.
In the LeSS framework, the whole product is the teams’ focus, not just individual components. GROOVE X approach aligns well with this principle: the automated test suite is designed to validate the LOVOT as a complete product, including its physical movements, sensor accuracy, and software behavior. This holistic approach encourages cross-functional collaboration, as it involves hardware engineers, software developers, and testers working closely together to improve the product.
Conclusion
The manager-less and division-less experiments at GROOVE X demonstrated that such an approach could be viable for startups aiming to maximize innovation and collaboration. However, most startups begin without formal management, typically starting with only a few developers and business people, including the founders.
As organizations grow, many companies quickly introduce some form of management structure to address emerging challenges. However, as this case study demonstrates, delaying the introduction of management roles can also be a viable option in a startup environment.
Additionally, GROOVE X already had a high-trust culture fostered by the “cave concept,” where knowing and helping each other was the norm throughout the organization. Another important factor to consider is that GROOVE X had a highly experimental mindset, which minimized resistance to trying new approaches.
From the perspective of LeSS adoption, LeSS fit perfectly with their optimization goals, though the adoption was primarily successful in the software development area and did not extend to the hardware or business domain during the timeframe of this case study.
In many of GROOVE X’s other experiments, LeSS provided the principles, structure, and guidance that served as a foundation. They were simultaneously building their organization and product through a process of experimentation.
Below is a summary of what went well and the challenges that remained at the end of this case study period. Achieving perfection is a never-ending journey, and there is no single best practice. I hope this case study helps others who are striving to build a similar organization or exploring possibilities in organizational design.
Things Went Well
This and the following section reflect on the case study as a whole, summarizing what worked well as a result of LeSS adoption and what challenges remained going forward.
They succeeded in minimizing management involvement and creating a self-managed organization focused on delivering an integrated product. Their flat organizational structure allowed teams to take ownership. The Product Owner provided an abstract direction of the product vision and gave teams significant space to reflect on their ideas and influence the product. The software teams operated as feature teams, delivering end-to-end functionality while still closely collaborating with other teams.
Challenges
The following challenges remained unresolved at the end of the case study period. They represent areas where GROOVE X would like to continue experimenting and improving going forward.
LeSS adoption including hardware
The first challenge was unifying software and hardware development after entering the mass production phase, a goal that could not be achieved during the period of this case study. Ideally, even in the mass production phase, they would be able to create a Potentially Shippable Product Increment that included all the necessary tests to release a product within a sprint. They also aimed to form feature teams consisting of both hardware and software developers in order to create truly end-to-end features using the latest hardware.
There were several attempts to move forward with this idea. First, although they maintained separate Product Backlogs, they tried to place them in the same physical area so that both could be easily viewed together. However, they did not merge them into a single list because of the different cadences, hardware development did not fit within the cadence of the software sprint cycle. The hardware work was therefore managed in a more Kanban like approach.
The hardware teams participated in most of the LeSS events, but they did not run sprints. They held Daily Scrums every day and conducted retrospectives regularly. Whenever they had something to show, they brought the increment to the Sprint Review.
Some software developers also attempted to learn about hardware design. Their goal was to form truly cross-functional feature teams, so they joined the hardware teams to understand the hardware development. However, this approach required time for the knowledge to spread. During this attempt, the software developers realized the importance of automating hardware testing, and they shifted their efforts toward developing hardware test automation as described in the “End-to-End Automated Tests Including Real Hardware” section of this case study.
Even though they were aiming for the ideal state, it was very difficult to achieve because of the physical constraints of hardware, which is hard to change. During the prototyping phase, it was definitely possible to achieve that state, and they will likely aim for it again when developing the next version of LOVOT. However, once they reach the mass production phase, they will most likely need to switch to a more Kanban like approach for hardware development, due to the difference in cadence between hardware and software development.
Growth of New Product Owners
Due to the growth of the organization, they will most likely become a LeSS Huge adoption, and they need to prepare for that change. The main concern for the current Product Owner is how to foster the growth of Area Product Owners. One experiment they conducted called “SK” could be helpful for developing future Product Owners. There may be better ways to address this, but it remains an ongoing challenge for the organization.
Determine the salary
In the “No Performance Appraisals” section, they experimented with tools to partially automate or outsource some of the salary decision making process. However, they are now back to the original approach, where the CEO determines everyone’s salary. This will need to change as the organization continues to grow, so it remains an issue that must be addressed.
The goal is to minimize the effort involved in determining salaries by making the process as automated as possible, while maintaining enough flexibility to offer higher salaries when it is necessary to attract talent. In addition, supporting employee growth requires continuous improvement.
References
[1] GROOVE X tech blog about hardware:
https://tech.groove-x.com/entry/inside-of-LOVOT-fw
[2] LOVOT architecture:
https://speakerdeck.com/soracom/soracom-tech-days-2021-day1-2
[3] GROOVE X tech blog entry about how LOVOT creates maps:
https://tech.groove-x.com/entry/inside-of-LOVOT-slam
[4] Agile Japan conference sessions by CEO 10:20 - 11:10
https://2019.agilejapan.jp/session.html
[5] Agile Japan conference sessions by Scrum Masters 13:50 -14:30
https://2019.agilejapan.jp/session.html
[6] LOVOT visual programming for kids:
https://LOVOT.life/blog/article/mwdp01o6bcl/
[7] Related to mass production:
https://www.dasscrumteam.com/en/blog/from-idea-to-mass-production
[8] Original recording of test automation:
https://www.youtube.com/watch?v=vq6nEHMSLmA
[9] Robotstart article about LOVOT:
https://robotstart.info/2020/02/06/LOVOT-internal-structure.html
[10] GROOVE X futsal team:
https://tech.groove-x.com/entry/groove-x-futsal