あなたのLeSS(大規模スクラム)を作ろうゲーム(build your own LeSS game)

LeSS(大規模スクラム)はスクラムの大規模版です。(https://less.works/less/principles/large_scale_scrum_is_scrum.html)

LeSSはスクラムの改良版ではなく、今まで通りのスクラムです。経験的プロセス制御により検証と適応を行いながら様々な方法や仕事、そしてどのような規模にも対応可能です。そして、スクラムと同じ目的や価値を持っているフレームワークとなります。

このワークショップでは、自己組織化した学習する組織が幾つかのイテレーションで能動的な活動とふりかえりを通じて通常のスクラムからLeSSになる体験をしていただきます。

このセッションは複数のファシリテーターによってサポートされるワークショップとなりますが、英語のみのファシリテーターもおります事はあらかじめ、ご了承ください。

LeSS is not “new and improved Scrum.” It is regular Scrum, an empirical process framework, in which you can inspect and adapt to any method and work in a group of any size. It shares the same values and serves the same purpose as Scrum.
In this workshop, self organised learning groups will go through a few iterations of active participation and reflection to go from basic Scrum knowledge to LeSS.
 
7 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

まずは、Adam Weisbart’s氏の「あなたのスクラムを作るゲーム(Build Your Own Scrum game)」のアレンジ版で、開発チームは1チームの想定から始まり、みなさんでお互いの学習をサポートして頂きながら、基本的なスクラムの理解を進めて頂きます。

そして、みなさんに特定の文脈のなかで複数チームへと規模を拡大していく際にどのように原理原則を適応していくのが良いか議論をして頂きます。

LeSSのカードゲームを使ってみなさんなりの大規模スクラムを形作って頂きます。そして、全体へシェアして頂く流れとなります。

We will start with a modified version of Adam Weisbart’s Build Your Own Scrum game, with the assumption of doing it for one team. Learning groups will help each other to confirm and have better understanding about the basic Scrum.
Then we will discuss about the principles we want to use when scaling Scrum to multiple teams within some given context.
Using our LeSS card game, learning groups will build their own Large-Scale Scrum.
Then we will summarise.”

Learning Outcome

・スクラムの基礎に関する再学習

・LeSSの学習

Target Audience

スクラムを理解されている方でLeSS(大規模スクラム)を学びたい方

Prerequisite

スクラムをすでに学習されている方が対象となります

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Aki / Minoru Yokomichi - Delegation Poker でチームの自律性を高めよう ! 権限境界を明確にしてモチベーションを高める方法。(Management 3.0 体験ワークショップ)

    100 mins
    Workshop
    Beginner

    Delegation Board自己組織化の高いレベルのチームは他のチームと比べてより効果的です。意思決定はより正確に、もっと早く行うことができます。その上、モチベーションはより高くなります。したがって、自律的なチームを作ることは、各チームとそのマネージャーの目標である必要があります。
    マネジメントは、マネージャーだけではなく、グループの責任です。
    しかし、どのように我々はそのようなチームを作ることができますか?
    どのように私たちの組織の人をエンパワーメントできますか?

    Delegation PokerManagement 3.0 では、0/1の選択肢ではないので、7レベルの権限を使用しています。 このワークショップでは、デリゲーションポーカーを使用してチームのエンパワーメントと権限移譲を管理する方法を体験します。
    デリゲーションポーカーはManagement 3.0の1つの活動です。これをすることで、本質的なリーダーシップのトピックに取り組む準備をし、参加者に幸福のための行動計画を作成できるよう促します。

    世界で展開している進歩的な経営改善考え方であり、Management 3.0 を広めることで、日本の企業のワークシステムを改革し、個人の幸せと日本の社会に貢献することになり、エンゲージメントがされるとともに、企業の生産性が上がる。
    最終的には、顧客を満足させることが出来ます。

    Management 3.0 はオランダ出身のヨーガン アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念で、「人ではなく、システムをマネージするべき」という考え方です。

  • Liked Takeshi Arai
    keyboard_arrow_down

    Takeshi Arai - 心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法

    45 mins
    Talk
    Intermediate

    全社にカイゼン文化が浸透していて、それぞれの現場で独自のカイゼンが実践されています。

    エンジニア、総務、広報・販促、データ作成、インフラ、新規ビジネスなど、あらゆる部門で日々カイゼンが繰り返されています。
    総務や広報・販促のメンバーも「スプリント」「WIP」「レトロスペクティブ」など、アジャイル用語を日常的に使っており、コモンセンス化しています。

    もちろん、たった一人の人間の力だけでそんなソシキカイカクはできるわけありません。

    でも、そのリテンションのコツやマンネリ化を打破する方法など、根底に流れる価値観や
    私が実践する「たった一滴の魔法」を紹介します。

    会社も身体もリーン体質になる魔法です。
    お楽しみに。

  • 45 mins
    Talk
    Intermediate
    2017年9月、私は42歳にしてそれまでの「アジャイルコーチ」という肩書きを捨て、SET(Software Engineer in Test)として LINE 株式会社に入社しました。

    LINE 初の SET として、私は多くのことをイチから手がける必要がありました。テスト自動化に関する現状の把握、課題の明確化、達成すべき目標の提示、関係各者との協力関係の構築、そして施策の実施…。 入社したばかりの人間がやることとしては、なかなかタフなミッションに見えるかもしれません。
    しかしいざ始めてみると、自身の当初の想像をはるかに超えて、私は非常にスムーズにこれらを実施することができています。なぜならば、私がこれまで培ってきた、スクラム・XP・リーンなどのアジャイルの知識・経験の多くが、上記ミッションの実現に大いに活用できることが分かったためです。

    アジャイルの知識・経験は、新しいチャレンジを行う上で、非常に強力な武器となり得ます。

    当セッションでは、新しい会社・役割・ミッションのもとですぐに成果を出すために、また新しいチャレンジを行うために、アジャイルの知識・経験をどのように活かしていけば良いのかについて、自身の経験に基づいて具体的にご紹介させていただきます。
    また併せまして、SET として活動していくために役立つ、テスト自動化のスキルと方法論についてもお話させていただきます。
  • Liked Steven Mak
    keyboard_arrow_down

    Steven Mak - Temporal Modelling

    Steven Mak
    Steven Mak
    Ugly Code Cleaning Dude
    Odd-e
    schedule 5 days ago
    Sold Out!
    100 mins
    Workshop
    Beginner

    Domain Driven Design, DDD emphasize communication with domain expert to build models and hence make software. How do we start with modelling? Starting with objects? Relationship between objects and the world? Architecture? Object Oriented Design is very readable in static world. However, it looks like OO model becoming limited when it deals with interaction and events. Ideas like CQRS and Event Sourcing are based on time and events. In reality, inside an enterprise, we also see work flowing between departments and people. Event Storming Workshop is trying to see the events and process in a domain model.

    In addition, this workshop we shall explore the implications we shall have with software design, and relationship with other agile practices.

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - 「ふりかえり」の始め方と続け方

    20 mins
    Case Study
    Beginner

    このセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。

    ”ふりかえり”の目的は大きくは以下の2つです。

    1. 自分達の仕事のやり方をもっとうまくできるようにすること
    2. (うまくできるやり方を考えるために)仕事の手を止めて立ち止まること

    この目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。

    • どのようなデータを収集すればよいか?
    • どういう話し合いのやり方をすればよいか?
    • 継続的にうまくできるように気をつけることは何か?

    また以下のような"ふりかえり"あるあるに出会うこともあります。

    • ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまう
    • うまくできるようにするアイデアが実行されない
    • なんとなく続いているんだけど効果がわからない

    このようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。

  • Liked Takao Kimura
    keyboard_arrow_down

    Takao Kimura - Large-Scale Scrum(LeSS) 導入時の勘所(仮)

    Takao Kimura
    Takao Kimura
    Agile Coach
    Gaiax Co.Ltd.
    schedule 3 weeks ago
    Sold Out!
    20 mins
    Case Study
    Advanced

    アジャイル開発プロセスも大分認知されてきており、規模の大きいアジャイル開発プロセスに取り組む企業も多くなってきました。
    そこで、2016年に、「NexusとLeSSの概要と比較」にて、大規模なスクラムとしての、Less(Large-Scale Scrum)を紹介させていただきました。
    今年は一歩進んで、LeSSをどう導入していくのかというお話をさせていただきます。

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - Teamwork Revolution - モブプログラミングという働き方 -

    45 mins
    Case Study
    Beginner

    モブプログラミングとはチーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピューターで行うことです。

    日本においても、2017年に一気に話題となりました。
    そのきっかけとなったモブプログラミングという働き方で紹介した楽天のモブ=チームがその後どうなったのかについてお話します。

    私達のモブでは、時間を決めてワークショップ形式で行うのではなく、朝来てから帰るまで働き方として実施しています。そのため、開発だけでなく資料作りや営業やモブプログラミングの体験会などすべてにおいてモブワークをしています。

    • スクラムを中心としたアジャイル開発を精力的に行ってきたメンバーがモブプログラミングを通してどのように変化したのか
    • 実際に仕事の成果が出せたのか
    • モブとその外の関係性はどうなのか
    • モブ=チームのその後(※今後の活躍次第)

    などについてお話したいと思います。

    スクラムとモブプログラミングは、チーム全体のアプローチやチームビルディングという点で共通項も多い一方で、別の視点で仕事の本質やチームの本質について考えるきっかけになりました。

    モブプログラミングに興味がある方はもちろん、そうでない方にとってもチームについて考えるきっかけを得られるようなセッションにしたいと思います。

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - 見せる化活用、チームで活かすファシリテーショングラフィックの学び方

    45 mins
    Workshop
    Beginner

    みなさん、ファシリテーショングラフィックしてますか?

    会議の場で使われるのが一般的ですが、私は人の話を聞く時も、ちょっとした立ち話をする時になんかも「描きとる」ようにしています。描くことをすること自体が、フォーカスしてしっかり「聴く」ことにもなっていますし、描いたものからフィードバックを得て、話し合いが、物事が進みやすくなります。

    どんな場で、どう使いたいか?

    まずはファシリテーショングラフィックを始めてみようと思っても、どういう場で、どう使いたいかを想定してみないと、あまり素敵な結果を生まないこともあったりします。そこで、今回のワークショップは参加した方々の想定する場に対して、どういうポイントで描くのがよいのかなど、お話していきたいと思います。

  • Liked Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Walking Scrum History with Patterns

    Harada Kiro
    Harada Kiro
    Senior Consultant
    Attractor Inc.
    schedule 1 month ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Scrum is a set of well-defined rules that enable teams to work effectively to deliver valuable products. Scrum Guide is the rule book of Scrum. You are requested to follow the rules to get benefits of Scrum.

    But why do you need to follow Scrum rules? Scrum says it is crucial to inspect and adapt. So why not inspect how Scrum rules work.

    This session explores the history of Scrum with patterns. The first Scrum paper was published in a form of pattern language. By looking how these patterns have evolved, we hope to see how these Scrum rules are formed and have better understand why they are rules.

    This session concludes with the update of ScrumPLoP.

    This session can also be delivered in Japanese.

  • Liked Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-

    Yusuke Amano
    Yusuke Amano
    Scrum Master
    Cybozu, Inc.
    schedule 1 month ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    作るものに納得感がない、いつも納期に遅れる、改善ができない…

    このような問題を解決してチームワークを発揮するために、サイボウズでは2016年10月から私が所属するkintone開発チームでスクラムを導入しました。

    チーム全員が未経験の状態でスクラムマスターになり、沢山の壁にぶつかりながら試行錯誤を繰り返してきました。このセッションではサイボウズでのスクラム導入で取り組んだ活動をふり返りながら、開発プロセスや品質・チームの文化に起きた変化をご紹介します。

    さらに他チームや他部署のみならず総務や営業の現場にまで及んだマインドセットの変化・アジャイルプラクティスの導入についてもお話します。アジャイルの考え方は開発以外の現場でも活用できることを実感し、現場改善や組織変革のヒントにしていただければと思います。

  • Liked Steven Mak
    keyboard_arrow_down

    Steven Mak - Mentoring Technical Practices

    Steven Mak
    Steven Mak
    Ugly Code Cleaning Dude
    Odd-e
    schedule 1 week ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    My interest is to help developers adopt technical practices and being a mentor has played a big part. Through the years I've tried many ways to maximise the effectiveness of mentee's learning and also brings many challenges and discoveries. In this talk, I'll share my learning journey and hope it'll inspire you to help others improve their technical practices.

  • Liked Sora  Hasimoto
    keyboard_arrow_down

    Sora Hasimoto / kurasawa akane - マネージャー不在のチームで挑戦したペアスクラムマスター

    45 mins
    Talk
    Beginner

    わたしたちの開発チームは総勢10数名、マネージャーはいませんでした。(今もいません)

    右も左もわかっていない若手で半数ほどを占める、混乱していた開発チームが

    事業企画者と協力し顧客のための開発に向かうようになった数年間のわたしたちの取り組みを紹介します。

    チームや組織を前進させたい人や新米スクラムマスターが、次の一歩を進むためのヒントが得られるようなセッションにしたいと思います。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - Scrumが難しいのは幻想 -情熱の再定義-

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 3 weeks ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。

    このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。

    チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、

    なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。

    我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。

    結果、1週間でレビューを35回以上、振り返りを30回以上行っています。1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。

    チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。

  • Liked Daisuke Watanabe
    keyboard_arrow_down

    Daisuke Watanabe - Scrum One on One / 自律的なチームを育む実践知「1on1」コミュニケーション

    20 mins
    Case Study
    Beginner

    「最高の開発チームをビルドしたい、開発現場をよりよくしたい!」

    日々そう考えている皆さんと同じく、Gunosyの開発チームでも様々な課題を解決しながら組織のスケールアップを試みています。このセッションでは、私たちがプロダクト開発全体の価値の最大化の為に重視して実施している実践知「1on1」についてお話します。

    LeSS (Large-Scale Scrum)において、Scrumでは珍しく、マネージャーの役割についての記述があります。「マネージャーはプロダクトの一部だけを見るのでは無く、プロダクト開発全体の価値提供を見る。現地現物GoSeeによりプロダクト開発の改善を推進する事である」と提起されています。

    いわゆる上司と部下の「1on1」と、スクラムの流儀から実践知リーダーの自律的なチームを育む手段としての「1on1」。

    ここから生まれた課題と、それを乗り越える際に重視したポイントをご紹介します。

    LeSS、アジャイルコーチングの観点からの1on1手法、心得、改善の記録を紹介しながら、
    「1on1」をスクラム、コーチング、マネジメントとどのように協調させると最もプロダクト開発全体の価値提供につながるのか、皆さんと一緒に考えていきたいと思います。

    私たちの取り組みが、皆様の開発現場での改善の一助になれば幸いです。

  • Liked Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。

    Yasunobu Kawaguchi
    Yasunobu Kawaguchi
    Agile Coach
    Rakuten Inc.
    schedule 3 weeks ago
    Sold Out!
    45 mins
    Panel
    Advanced

    「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(三宅芳雄・三宅なほみ 教育心理学概論 第一章 P.13-14)

    多くの人がスクラムを利用して開発するものは、たぶんなんらかのソフトウェアサービスで、その先には利用者がいると思います。アジャイル開発やDevOpsでどれだけ技術的に研ぎ澄まし、円滑にリリースができるようになったとして、ターゲットとしている利用者像が間違っていれば、成果に繋がらず、投資や予算が尽きた時点で終わりです。

    過去のソフトウェア開発は、作ってすぐには顧客に届けることなんてできない前提で作られてきました。そのために、じっくりとテストを重ね、ビジネスインパクトを計算し、エンドユーザーに届くときには「絶対に使い物になる」ものを作ろうとしました。しかし現代、作ってすぐユーザーに届けることは当然の事になりました。そのために、テストの自動化、クラウド、DevOps、A/Bテスト、カナリアリリース、マイクロサービスなどのプラクティスが普及してきたのです。

    プロダクトオーナーシップは汎用化が非常に難しい分野です。うまくいく方法は一つではないし、売れるということはすなわちユニークな優位性があるということであり、すなわちコピーできない。できたら簡単に優位性は失われるからです。しかし、その考え方まで理解を深めれば、取り入れられる部分が出てきます。

    本セッションでは、大手企業の中で、新規の事業開発を手がけられてきたパネリストの皆さんが、どのように予算をとり、新しいエンドユーザーの仮説を検証し、マーケットにアプローチして、小さな成功を掴み取ってきたか、話し合ってみたいと思います。

    パネリスト
     山崎 篤 氏 (コクヨ株式会社)
     (ほか調整中)

    本セッションプロポーザルに対してコメントにて質問をいただければ検討いたします。

  • Liked Atsushi Nagata
    keyboard_arrow_down

    Atsushi Nagata - アジャイル開発の品質はOODAにおまかせ!

    Atsushi Nagata
    Atsushi Nagata
    Counselor
    NISSIN SYSTEMS
    schedule 3 weeks ago
    Sold Out!
    20 mins
    Experience Report
    Advanced

    アジャイル開発を進めていくとき、品質保証とか品質改善とか、みなさんどのようにお考えでしょうか。私はずっとQA側からアジャイル開発とどのように向き合うか考えてきて、最近DevQAという言葉を使ってアジャイルチームとQAのコラボレーションを試してきました。それをまとめてみると、実はQAやテストエンジニアの活動はOODA(Observe, Orient, Decie, Act) になっていたことがわかりました。OODAを進めようとしている人は、これからはPDCAではなくOODAだというのですが、現実は排他的なものではなく、補完しあうものだと思います。スクラムのPDCAとQAのOODAがかみ合って回っている姿、それがDevQAです。そして、そこからアジャイルにおける品質保証というのが考えられるのではないか、というお話を議論したいです。

  • Liked Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - 妨害リスト(Impediments List ) を会社全体で運用して見えてきた組織課題の解決の仕方

    20 mins
    Experience Report
    Beginner

    妨害リスト(Impediments List ) を会社全体で運用して見えてきた組織課題の解決の仕方について、お話したいと思います。

    妨害リストを運用するからこそ、客観的に「問題vs私達」にフォーカスすることができます。Scrumで運用されている妨害リストですが、開発組織外でも運用することで会社全体でプロセスを阻害していることを解決することができた事例について紹介させて頂きたいと思います、

  • Liked Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - 企業が成長し続けるために欠かせない、自己組織化されたチームづくり

    45 mins
    Case Study
    Advanced

    100名を超える多様なバックグラウンドを持ったメンバーひとり一人が気持ちよく働ける環境づくりと、いかなる環境においても活躍できる普遍的に優秀な人材として成長し続ける組織作り、文化作りについて紹介させて頂きます。また、チームとして成果を最大化させるために大切にしていること、大事にしている価値など、どのように強いチームを作っているのかを紹介致します。

  • Liked Terry Yin
    keyboard_arrow_down

    Terry Yin - 6 Years Of Teaching Certified Scrum Developers: Re-spec, Re-design & Re-entry

    Terry Yin
    Terry Yin
    Programmer
    Odd-e
    schedule 1 month ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

    Every time we did our 5 day Certified Scrum Developer class, it's a rich learning experience for both us and the clients. After doing it for 6 years and also practicing what we teach, I've summarised the topics into three rhythmic steps, which I "dance" over not only during my CSD classes but also in other technical coaching situations, again and again. I call these steps Re-spec, Re-design and Re-entry.

  • Liked Mitsunori Seki
    keyboard_arrow_down

    Mitsunori Seki - 外部委託から内製化スクラムへの切替支援を通してわかった、現実的なスクラム導入のポイント

    20 mins
    Experience Report
    Beginner

    エンタープライズ系の企業にて、iPhone/Androidアプリ開発を外部委託していたチームが、内製化スクラムに切り替えた時に実施したことや、それらを通してわかったことについて概説します。

    支援を始めてから最初の3ヵ月は、開発チームの改善は進みましたが、企画チームの改善には、まだまだ課題が多く残っていました。
    その後の3ヵ月で、どのような施策を立てて、どのような改善を実施し、その成果はどうなったかについて、事例を通してご紹介いたします。

    ※支援をはじめて最初の3ヵ月の取り組みについては、2017/08/22にご紹介したスライドをこの画面下部に添付しておりますので、そちらをご参照ください。