In this session, Luiz "Q" Quintela gives and overview about Scrum at Scale from it's origins until today and what differentiates Scrum at Scale from heavily prescriptive frameworks. This session focuses on organizational change, minimal viable bureaucracy and how to use Scrum at Scale to linearly scale the work of multiple teams.

 
 

Outline/Structure of the Thought & Practice

Scrum At Scale - History and Introduction

The Scrum Master Cycle.

The Product Owner Cycle.

Organizational Sctructure.

Sample Case Studies.

Learning Outcome

What Scrum of Scale is and how is structured.

How to adopt Scrum at Scale at your organization.

How to linearly scale Scrum to achieve twice the work in half the time.

Target Audience

Scrum Master, Product Owners, Executives that are interested in scaling Scrum to increase output and decrease time to market.

Prerequisites for Attendees

Knowledge of Scrum is required.

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - ファシリテーションの難しさと楽しさ

    20 Mins
    Thought & Practice
    Beginner

    ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

    そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
    そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

    その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。


    ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)


    このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

  • Liked Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano / Toshiyuki Ohtomo - チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方-

    45 Mins
    Thought & Practice
    Intermediate

    私(@ama_ch)が所属するサイボウズでは、「チームワークあふれる社会を創る」というビジョンを掲げてグループウェアを開発しています。

    自分たち自身のチームワークを高めるために、2016年にスクラムを導入しました。私の所属するkintone開発チームでは、スクラム導入から1年以上が経過し、新たに下記のような問題に直面していました。

    「スクラムを導入したは良いけど、まだ加速しきれていない気がする」
    「チームが壊れないようスケールさせるにはどうすれば?」

    これらの問題を解消し、最高のプロダクトを目指すチームを作るために社外のスクラムマスター(@toshiotm)を巻き込んで、より良いスクラムの実践を探求してきました。

    1年間の実践を通じて、私たちのチームには以下のような特徴が現れました。
    - 複数拠点をまたぐリモートモブ中心の開発
    - 新卒エンジニアが1週間で活躍し始める
    - スプリントごとにチーム構成が変わる
    - 仮説検証マインドにもとづく高速な改善
    - スクラムマスターが不要になる

    この1年の活動をふりかえり、スクラムが本当の意味で機能し始めたチームに起きた質的な変化、スケーリングの取り組み、私自身に起きたスクラムマスターの役割の変化などについて、一緒に推進してきた社外スクラムマスターと一緒に考察したいと思います。

  • Liked Shigeki Morizane
    keyboard_arrow_down

    Shigeki Morizane - 全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~

    Shigeki Morizane
    Shigeki Morizane
    CTO
    Levtech Co., Ltd.
    schedule 1 year ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。

    これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。

    でも、どちらもSCRUM!全部SCRUM!

    規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - 超Scrum入門〜未完成フラクタルと15minSprint〜

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Advanced

    https://www.youtube.com/watch?v=7xhxIYYMmTc

    チームがうまくいっていることはスクラムチームの大きな目標です。

    いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。

    良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。

    数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。

  • Liked Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - Effective Retrospective / とにかく楽しいふりかえり

    45 Mins
    Thought & Practice
    Beginner

    みなさんは楽しくふりかえりをできていますか?

    スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。

    マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。

    場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。

    場とは何か。そして、場を作るためにどんなことをすればよいのか。また、ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。

    以下のことを中心にお話いたします。

    • ふりかえりの3つの目的と3ステップ
    • ふりかえりにおける「場」とは
    • 物理的・心理的に場を作るための方法
    • ふりかえりをより楽しくするための方法
    • ふりかえりのさまざまな手法
  • Liked Takuo Doi
    keyboard_arrow_down

    Takuo Doi - 行動分析学に基づくScrumの導入

    Takuo Doi
    Takuo Doi
    CTO
    Lifematics Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Intermediate

    Scrum / Agileは非常に人間的なアプローチです。

    そして、それが大きな魅力である一方で、これまで、プロセスで縛ることにより開発を実践してきた人にとっては、理解できない、導入できない原因ともなっています。

    アジャイルの実践者に現場の課題を相談した際に、よく返ってくる返事の一つが、「It depends(状況による)」です。

    この言葉はまさしくそうなのですが、アジャイルコーチが入っているような現場ではなく、あまり経験のない人にとっては、自分たちの状況を見てもどうしたらよいか分からなく、手当たり次第に思いつきを実施してみたり、原理主義のようにプラクティスを遵守しようとしたりしてしまう原因となっています。

    本セッションでは、心理学の一分野である行動分析学に基づき、Scrumの課題を見付け、その課題を解決する方法を見つける科学的な方法を提案したいと思います。

    本セッションの内容により、改善を促したいプロジェクト/チームをどのようにScrumがうまく機能する体制にし、文化として根付かせるかの汎用的な手法を知ることができます。

  • Liked Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - 心理的安全性ゲーム

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Beginner

    チームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

    「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。

    このゲームは文字通り、心理的な効果を体験できます。たとえゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。そうしたやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。

    4-5人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。さらにどんな改善が見られるか、再度ゲームをやって試してみましょう。

  • Liked Yoshihiro Yunomae
    keyboard_arrow_down

    Yoshihiro Yunomae - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた

    20 Mins
    Advanced Case Study
    Intermediate
    モバイルゲームの運用では、プレイヤーを飽きさせないために、週2~3回のコンテンツのアップデートと、月1回の機能アップデートを実施します。このため、開発チームは継続的に価値を出し続ける工夫が必要となります。

    アカツキのある大規模開発チームにおいて、人数の割に開発の進みが思わしくなく、作業が属人化されていました。結果的にプレイヤーに継続的に価値を届けるのが困難となっていました。これは、以下の2つが根本的な原因でした。

    ・チームの開発スタイルが確立する前にチームが肥大化したことにより、コミュニケーションフローが整備されていなかった
    ・開発業務中に運用業務の差し込みが入り、度々開発が中断していた

    これらの根本課題に対処するため、以下を実施しました。

    1. 開発チームを分割し、コミュニケーションパスを設計
    2. Scrumをベースに、複数のチームが並行バージョン開発出来るように開発フローを設計
    3. 次々バージョン開発チームが運用業務を行うようにし、次バージョン開発チームの業務中断を抑止

    本セッションでは、並行バージョン開発を取り入れた経緯と、取り入れた並行バージョン開発の手法を詳細に紹介します。
  • Liked Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Misa Fukuhara - 「自分を立てなおす対話」をやってみよう! ♥ 智慧の車座ワークショップ

    120 Mins
    Workshop
    Beginner

    みなさん、仕事上で理不尽な思いをしたり、仕事でなんだか不完全燃焼していませんか?

    自分ではなくても前は仕事をバリバリと精力的に活動していたのに、今は元気がないなぁって人がまわりにいませんか?

    社会人生活や人生において、ロジカルには解決できない問題がたくさんあります。

    そのような問題を解決・解消するひとつの方法として、皆さんに「対話」を紹介し、少しでも健やかに日々を過ごしていただきたいというのが、このプロポーザルを出した理由です。

    本セッションでは、プロコーチ、組織コンサルタント加藤 雅則さんの著作『自分を立てなおす対話』で紹介されている『智慧の車座』をやってみたいと思います。

    https://www.amazon.co.jp/dp/453231707X

    智慧の車座は、問題を抱えたテーマオーナー(相談者)と、複数の支援者の対話を通して、「問題をほぐし」「智慧を出し合い」解決方法を模索する対話法です。

    このワークショップ参加後に、以下のような状態になればよいなあと考えています。

    1. 「自分を立てなおす対話」とは何かを知る
    2. 「自分を立て直す対話」を(なんとなく)できるようになる

    人生に迷っているあなた、このワークショップに参加して、暗闇荒野に進むべき道を切り開いてみませんか?

    興味を持たれた方はぜひ、投票をお願いいたします。

    「対話こそ、金より輝かしく光よりいのちあるもの」(ゲーテ)

  • Liked Masato Ishigaki
    keyboard_arrow_down

    Masato Ishigaki - プロダクトオーナーとして『開発プロセス』を思考せよ〜EBM(Evidence-Based Management)を軸とした『プロセスの見える化』と『ムダからの解放』を実践したインパクトについて〜

    Masato Ishigaki
    Masato Ishigaki
    Product Owner
    DMM.com
    schedule 1 year ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    チームとして、良い『開発プロセス』を設計することは重要です。
    ROIを高めながら、どうやってプロダクトを『最速』でリリースし、仮説検証を『高速』で繰り返せるかを常に考える必要があります。
    そこで、重要なポイントとして気づいたのは、EBM(Evidence-Based Management) の概念におけるT2Mの部分『プロセスの見える化』と『ムダからの解放』です。
    今回は、理想の開発プロセス(EBM(Evidence-Based Management) to 『Lean x Scrum』)から、VSM x SIPOC分析による『プロセスの見える化』の実現から分析プロセス。
    そして、見える化することでわかる『ムダ』の解放をどのような工夫で行ってきたかをお話できればとおもいます。

  • Liked Masayuki Tanaka
    keyboard_arrow_down

    Masayuki Tanaka / Ryoichi Nagadome / Takayuki Ono - 東名阪をまたいだLeSS Huge(大規模スクラム)においてスクラムマスターとして実践したこと

    20 Mins
    Advanced Case Study
    Advanced
    Yahoo! MAP、Yahoo! カーナビ等を開発する私たちが所属する事業部では大規模スクラム(LeSS Huge)を導入し1年が経ちました。
    10チームを超えるLeSS Hugeにおいて東京、名古屋、大阪それぞれの拠点のスクラムマスターからLeSS Huge立ち上げ期〜現在まで実践してきたことをお話しします。


    「LeSS Hugeの立ち上げはスムーズにいった?」
    「拠点が離れているのにスプリントレビューはどうやっているの?」
    「他拠点とのオーバーオールリファインメントなどのセレモニーは問題なく実施できる?」


    1年の取り組みを振り返りつつ、直面した課題と解決のためにとったアクションをお話ししたいと思います。
  • Liked Rie Chonan
    keyboard_arrow_down

    Rie Chonan / Tadataka Ebihara - プロダクトオーナーは突然に 〜メカ屋出身プランナーと奇妙な冒険〜

    20 Mins
    1st Step Case Study
    Beginner

    プロダクトオーナーの育成、支援はスクラムマスターの役割であり、難しさである、という事は巷でよく聞く課題です。

    確かに、私も過去に現場でそのような状況に直面することがあり、プロダクトオーナーの立ち位置やチームとの関わり方、支援の方法について悩むことがありました。

    一方で、私たちClova関連チームのプロダクトオーナーは、POという役割も、スクラム開発も初めてという状態での抜擢。

    未経験による悩みだけでなく、ソフトウェア開発とのギャップを感じていました。

    このような状況で、私たちはプロダクトオーナーが抱える悩みや問題は、開発チームの課題として一緒に解消する事にしました。

    本セッションでは、Clova関連チームのプロダクトオーナーと共に登壇します。

    複数の立場から、開発チームとの関わり方やプロダクトオーナーが躓きやすいポイントを紐解きながら紹介できたら幸いです。

  • Liked Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - ちゃんとやってるのになんかうまくいかないスクラムからの脱出

    20 Mins
    Advanced Case Study
    Intermediate

    こんにちは。椎葉です。

    僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい!」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

    そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

    僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

    このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

    同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです!

  • Liked Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi / Manabu Shibahashi / Yumiko Yoshida - 喧嘩できるチームを作るワークショップ

    100 Mins
    Workshop
    Advanced

    「チームのメンバーで喧嘩できてますか?」

    自分が言いたいことが相手の意見と対立しそうで、伝えなかった…。
    言ってもわかってもらえないと思ったので言わなかった…。
    このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった…。
    そんな体験はないでしょうか?

    自分の伝えたい考えをきちんと伝える。相手が伝えたい考えときちんと向き合う。
    これはチーム内での会話の仕方でもありますが、チームの空気感というか文化からも影響を受けると考えます。

    「喧嘩できる」というのは対立構造ということではなく「喧嘩ができる」チームの空気感があるというある意味「健全なコミュニケーション」が行える状態についてお伝えしたいと思います。

    その改善として、このワークでは組織や文化の理論もお話ししながら、学びと体験をお届けします。

    2018/10/19
    同ワークショップを企業で実施した時の記事が公開されました。

    http://bit.ly/2OCzYA9

    ワークショップを作る時に描いた図

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / Haruna Iizuka / Masahiko Morita / Megumi Tsuchihashi / Ryota Nagatomo / Saki Ota / Saki Tanaka / Takuya Uchida / Tsubasa Kanemura / Yuki Misumi - 学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー

    45 Mins
    Thought & Practice
    Intermediate

    チームがうまくなるために、「学習」と向き合うことはとても大切です。
    私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。

    ところが、最近新卒向けの研修に携わった際に衝撃を受けました。

    ビジネス採用として入社したためプログラミング未経験だった新卒の彼らは、当初は黒い画面(ターミナル)すら怖がっていましたが、数カ月後にはメンター陣からのインプットを頼りに、

    • 1 day timebox
    • 1 hour timebox
    • モブプログラミング
    • プロトタイピング
    • ユーザーインタビュー

    などをまわしながら、3週間でプロダクトを作れるようになっていました。
    その道のプロフェッショナル達がエクストリームだと思うこと/どうはじめたらいいのか悩んでいることを平気で突破してしまったのです。

    もちろん彼らはプロダクトを本番リリースしたわけではありません。
    もちろん彼らは運用しながらお金を稼いでいるわけではありません。
    でも彼らはプロダクトづくりの経験をもっていませんでした。
    でも彼らはプログラミング経験ももっていませんでした。

    私達は、

    • 学習し続けていく中で固定観念に囚われてしまうことがあること
    • 学習をしていないことが圧倒的成長スピードを生むことがあること

    という事実に向き合う必要があります。

    学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn(学びをリセット)がキーになります。

    このセッションでは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。もっとうまくなるための学習する/Unlearnするチームについて一緒に考える時間にしましょう。

  • Liked Kenta  Sasa
    keyboard_arrow_down

    Kenta Sasa / Iwao Harada - 明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ

    100 Mins
    Workshop
    Beginner

    皆さん、開発をエンジョイしてますか?
    開発を行っていると楽しいこともありますが、様々な問題が発生してツラいこともあると思います…

    そんな問題に直面したとき、皆さんはどう対応していますか?
    Try & Errorを繰り返しながら、困難な問題と闘い続けているのではないでしょうか?

    そんな皆様、お喜びください!

    このセッションは、Scrum Patternsを使った問題解決の紹介するだけでなく、実際にそれを体感できるワークショップを開催させてもらおうと思います!
    多くの現場で有効なパターンを学ぶことで、明日の現場に役立つ方法を持ち帰ることができます。

    パターンとは既に実証済みの解決策

    パターンは建築家アレグザンダーの提唱した『パタン・ランゲージ』で挙げられており、パターンの構造は以下のようになっています。

    ❝ある「文脈」で繰り返し起こる「問題」「解決」する方法。その方法にはいくつかの「制約」が課せられているかもしれない -- 結城浩

    私たちはそのパターンを通して、先人たちの知恵を学ぶことができます。
    パターンは時に知っていると思い込んでいる事に関しても新しい視点を与えてくれたり、改めて解決方法の目的の真意を思い起こさせたりします。

    そんなパターンを中心にみんなで問題を議論し、よりよい解決方法を見出したいと思っています。

    皆さんがお持ちの悩み、既にパターンに書いてあるかも?

    ワークショップに関して

    ワークショップを開催するのは、アジャイルコーチやスクラムマスターを中心とした、パターン大好きメンバーが集まったグループ "Scrum Patterns Tokyo (通称SPaT)" です。
    パターンを知らない人や、アジャイル開発初心者でも楽しめる場を提供したいと思います。

    1組4、5人で4組を想定しており、各チームに1人SPaTメンバーがフォローに入ります。

    みんなでパターンランゲージを楽しみましょう!

    ワークショップ登壇者

    • 天野 祐介
    • 原田 厳
    • 稲野 和秀
    • 木村 卓央
    • 川口 恭伸
    • 小坂 淳貴
    • 笹 健太

    参考サイト

    Scrum Patternsに関してはScrum PLoPのサイトがあります(英語)
    http://www.scrumplop.org

    ※本セッションではSPaTが日本語訳したパターンカード(仮)を使用します。

    英語が苦手な方でも問題ありませんのでご安心下さい。

  • Liked Tatsuya Kinugawa
    keyboard_arrow_down

    Tatsuya Kinugawa / Rochelle Kopp - そのときサーバントリーダーはどう振る舞うか

    45 Mins
    1st Step Case Study
    Beginner

    サーバントリーダーシップを実践するにあたって様々な場面で振る舞いを考えさせられることがあります。

    上司への向き合い方、配下リーダー陣への向き合い方、はたまた彼らのメンバーに向けてもこれまでとは違う振る舞いをすることが多いです。

    本セッションではRochelle Koppさんと一緒に具体的なシチュエーションを題材にしながら旧来のマネジメントとサーバントリーダーシップの振る舞いの違いについて実例を挙げながらお話したいと思います。

    これによりこのマネジメント手法がより身近なものに感じて頂ければ嬉しいです。

  • Liked Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Scrum@Scale Guide を読んでみよう

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Thought & Practice
    Beginner

    Scrum@Scale Guide を読んでみましょう(RSGT2019までには日本語版が出ているはず)。

  • Liked Toshiyuki Ohtomo
    keyboard_arrow_down

    Toshiyuki Ohtomo / Yusuke Amano - プロセスを良くするだけではチームはゴミを大量に作り続ける 〜より良いプロダクトに欠かせないPO支援〜

    20 Mins
    Thought & Practice
    Beginner

    スクラムマスターはプロセスにリーダーシップを発揮します。
    では、プロダクトのリーダーシップは誰が発揮するべきでしょうか?
    プロダクトオーナーです。
    皆さんの現場で、開発チームとプロダクトオーナーの間に距離を感じることはないでしょうか。

    より良いプロダクトを作るには、開発チームとプロダクトオーナーの相互の対話が欠かせません。
    サイボウズの社内で複数のスクラムチームを支援する中で、開発チームだけでなくプロダクトオーナーを支援する必要があるということを学びました。
    ここでは、スクラムマスターとしてスクラムのセレモニーをプロダクトオーナーにとっても欠かせない場にしていった経験を共有したいと思います。

    • プロダクトオーナーの抱える問題
      • プロダクトバックログアイテムの分割
      • セレモニーの時間が取れない
      • 開発の見通しが立たない
    • プロダクトオーナーを支援する取り組み
      • プロダクトバックログリファインメントの質を高める
      • スパイクの活用
      • スプリントゴールの設定
      • スプリントレビューで未来を語る
      • スプリントレトロスペクティブでメトリクスを活用する
  • Liked Fumitaka Inayama
    keyboard_arrow_down

    Fumitaka Inayama / Kazuki Mori / Ken Takayanagi / Shigeki Morizane / Toshiaki Nomura - フルバージョン登場!「プロばこ」で学ぶ作業プロセス・デザイン・ワークショップ

    100 Mins
    Workshop
    Beginner

    「考えていた作業計画と実際の作業が全然違っていてチームの作業が進捗しない」
     「改善をしているはずだけどトラブルが起きてからの事後対処になっている」
    などの経験をしたことはありませんか。

    チームメンバを招集して、チームビルディングも儘ならないでプロジェクトを始めてしまって、後手後手にチームの仕事のルールを決めたり、メンバ同士の関係作りに時間を使うくらいなら、最初に『プロばこ』でワークショップをご体験ください!!

     フルバージョンで登場する「プロばこ」は、チームの作業プロセスのデザインと合意形成のフローを体験できるパワーアップしたワークショップです。

    rsgt 2018では、QualityとDeliveryの2つを制約条件にチームの作業プロセスをデザインしました。フルバージョンでは、さらに2つの制約事項がチームの制約として追加されます。

     あなたのチームは、さらに複雑になる制約条件をくぐり抜けられる作業プロセスをデザインできるでしょうか…