Learning to Experiment

schedule Jan 10th 10:10 - 11:40 AM place HALL people 58 Interested

The best organizational changes in my career have happened as a result of emergencies. Support for the process of experimentation only seems to become enabled whenever the status quo has completely broken down. In those moments of crisis rebuilding with better has been possible, but why do we wait? In this talk I share our experiences with experimentation at Hunter and encourage you to develop a culture of continuous improvement and continuous experimentation that will get you to where you want to be without having to be in a crisis mode.

私にとっての過去最高の組織的変化は、緊急事態の結果、起こりました。ふつう、仕事上で実験できるのは、今のやり方がうまくいかないときです。危機的状況においては、抜本的な再建が可能です。しかし、指を加えて危機を待つ必要があるのでしょうか?本講演では、ハンター社が行った実験について話します。そして、継続的改善と継続的実験の文化を発展させて、危機的状況に陥ることなく、望ましい状態に進むことをお勧めします。

Today I am the director of a new software development department and we continue to utilize Mob Programming as well as many other practices. This presentation is about my journey through software development and specifically the experiences I have had with the process of software estimation. We are currently a department of 27 with 6 full time mobs; each team does not estimate software but instead practices pure Kanban and delivers vertical slices of software daily. Hunter is not the first place I had dropped the practice of software estimation for a project. Back in 2007 I was working in an Environmental Chemistry and Military Contracting organization that had a more traditional waterfall environment. During that time, we created a Gantt chart of how each project would go until one day there was an emergency that prompted us to do things slightly differently. I have come a long way and experienced many iterative steps through my software development journey. Let’s start with where we are today and work our way back discussing practices and insights we discovered on the way.

現在、私は新しいソフトウェア開発部門のディレクター(責任者)を務めています。私たちはモブプログラミングと他の多くのプラクティスを継続的に使っています。本講演では、ソフトウェア開発を通した私の旅、そして特にソフトウェア見積りのプロセスで経験したことについて話します。私たちの部署では、27人が6つのモブで終日作業しています。各チームはソフトウェアを見積もるのではなく、純粋なKanbanを実践し、ソフトウェアの垂直スライスを毎日提供しています。私がプロジェクトのソフトウェア見積もりを廃止したのは、ハンター社が初めてではありません。2007年にわたしがいた環境化学と民間軍事の組織は、もっと伝統的なウォーターフォールの現場でした。わたしたちがその時作ったのは、やり方を少し変えざるをえない事態が起きない限りはプロジェクトの先行きを見通せる、といったガントチャートでした。私はソフトウェア開発の長い旅を通じて、多くの実験を繰り返してきました。私たちの現在の状況からスタートし、どんなプラクティスを議論し、どんな発見をしてきたのかを話していきます。

 
 

Outline/Structure of the Keynote

-

Learning Outcome

-

Target Audience

everyone

schedule Submitted 9 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Matteo Carella
    keyboard_arrow_down

    Matteo Carella - Coaching resilient Scrum teams

    Matteo Carella
    Matteo Carella
    Agile Coach
    Agile42
    schedule 11 months ago
    Sold Out!
    45 Mins
    Thought & Practice
    Intermediate

    The concept of antifragile (things that gain from disorder according to Taleb's definition) is crucial if you want to coach a resilient team. In other words, a resilient team is able to survive uncertainty, volatility, stress and variability by changing adaptively rather than always remaining the same. We will see how this can be possible in some contexts, working on the boundary conditions that allow resilience to emerge as a bottom-up property of a work group, through experimentation and continuous learning on the field. I will also explain how in Vodafone (actually involved in one of the biggest agile transformation on scale) we conceived a framework to promote resilience and scrum teams agility on scale.

  • Liked Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting

    Narichika Kajihara
    Narichika Kajihara
    Agile Coach
    Yappli,Inc.
    schedule 11 months ago
    Sold Out!
    20 Mins
    Advanced Case Study
    Advanced

    「スクラム」のフレームワークは、もともとソフトウェア開発に用いられてきました。しかし「スクラム」の経験主義の原則は、短いイテレーションの中で、検査と適用を繰り返すことでプロセスのカイゼンを加速させる事ができます。また透明性の原則によって、ステークホルダーへの説明責任、今何が問題になっているのかを見える化させることができます。

    その「アジャイル」フレームワークを「エンジニア採用活動」に適用してみた内容について、発表させていただきたいと考えています。
    トラディッショナルな採用活動は秘密主義に根ざしており、独自な文化が根強く残っています。その中で透明性をもったプロジェクト運営をすることで、「採用活動の変化」「ステークホルダーの意識の変化」、検査と適用を繰り返すことでプロセスのカイゼン速度が向上した。

    開発部門以外にも適用した事例について、お話させていただきたいと思います。

  • 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 Kazuki Mori
    keyboard_arrow_down

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

    45 Mins
    Thought & Practice
    Beginner

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

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

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

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

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

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

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

    Yosuke Ota - スクラム1年生のチームが全員でRSGT2018に参加してわかったチーム開発、はじめの一歩

    20 Mins
    1st Step Case Study
    Beginner

    どのようにするとより良いチーム開発ができるのでしょうか。

    いま、私たちのチームは自信を持ってチーム開発をしています。1週間スプリント中の1日スプリント、当たり前に行われるペア・モブプログラミング、チームの活動に合わせた工夫のあるタスクかんばん、多くのプラクティスを実践することで安定してチームの成果を出しています。

    しかし、スクラム導入からしばらく、自信を持ってチーム開発をしているとは言えない状態でした。

    メンバーの状態に左右されるベロシティ、レビューで発覚する未完了、再計画されないデイリースクラム、さまざまな課題がそこには存在していました。スクラムのことを良く分かっておらず、言われたことをやっているだけの状態だったため、改善のサイクルをうまく回せないことが続きました。チーム開発に対する不安が大きい時期です。

    このような状態から大きく変わる転換点となってくれたのが、チーム全員で参加したRSGT2018でした。

    本セッションでは私たちのチームがわかったRSGTの素晴らしさと、チーム開発のはじめの一歩を紹介します。

  • Liked Ryosuke Nakamura
    keyboard_arrow_down

    Ryosuke Nakamura - 自律的で協調的なチームの作り方 ~複数拠点、多言語、職能型組織で始めるScrum~

    20 Mins
    1st Step Case Study
    Beginner

    職能型組織からメンバーが集められてプロダクトチームを作るような場合、それぞれの役割の間にあるグレーゾーンのタスクを誰が拾うのか、お互いのロールが何やっているのか見えづらい、などの問題が発生しがちかと思います。
    私たちのチームでも大きく以下の役割ごとの組織から集められたチームでした。

    • プランナー(プロダクトデザイン、企画、グロースを担う役割)
    • デザイナー
    • フロントエンドエンジニア
    • サーバーサイドエンジニア
    • QA(Quality Assurance)


    また、プランナーとデザイナーは東京、エンジニアとQAは福岡と物理的にも離れた中作られているチームです。
    もちろんそれぞれがいいプロダクトを作りたいという思いを持ってやっていたのですが、
    プランナー側には以下のような不満があり、

    • エンジニア側の見積もりが適切かわからない(必要以上にバッファー積んでないだろうか?)
    • エンジニア側が十分に効率よく働けているかわからない(人を余らせているのではないだろうか?)
    • エンジニアの売り上げに対するコミットメントが低いように感じる(締め切り守る気あるのだろうか?, オーバーエンジニアリングしてないだろうか?)
    • 変更を柔軟に取り入れてデッドラインも守るようにしてほしい(差し込み開発入れたいこともあるけど、走ってる大きな機能追加のデッドラインはずらしたくない)

    エンジニア側には以下のような不満がありました。

    • 見積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい
    • 開発する機能に関して背景や目的があまり納得できない
    • 開発する機能の優先順位がわからない
    • プランナー側が作成する要求や仕様が不正確だったり、不十分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする


    そんな中、社内アジャイルコーチによるエンジニアチームでの振り返りワークショップをきっかけに、エンジニアが週1の改善 MTG を開始し、不満をためることをやめ、プランナー側へ歩み寄るという行動を始めました。
    仕様が期待するものでないのは、エンジニア側からどんなものが欲しいのか伝えられてないからだということで、要求仕様の書き方の模範例を一緒に作る取り組みを始めたり、リモートランチなど直接的に仕事とは関係ないコミュニケーションの量を増やしたりしてお互いの理解を進めていく一方で、KanbanやScrumの社内研修をプランナーとエンジニアで一緒に受けてAgileな開発に関する共通認識を一緒に作っていきました。そして、Scrumからいいところを学ぼう、チーム改善のヒントを得ようとして開催された社内Scrum研修を受けた後、あれScrum導入してもいいんじゃない?とプランナー側、エンジニア側どちらともなく思ってScrumでの開発が始まりました。
    以下のような制約がある中の導入でしたが、それらを受け入れながら、チームの自律的、協調的な動きはScrum導入後加速したように思います。

    • プランナー組織構造の都合上、1人のPOは選出しにくい
    • QAを担当する独立した組織があり、社内にQAの責任者入るものの、実際の手動テストは外部委託
    • 開発チームに共通の言語がない(チームメンバーは中国人、台湾人、日本人、アフガニスタン人で構成され、日本語を話せない外国人、英語を話せない日本人がいる)

    私達は理想的なScrumを実践できている訳ではないかもしれませんが、継続的な改善とお互いの歩み寄りを積み上げ、またScrumのフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。

    この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。

  • Liked ohbarye
    keyboard_arrow_down

    ohbarye - プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making

    ohbarye
    ohbarye
    Engineering Manager
    Quipper
    schedule 10 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    ―――憶測や独断ではなく計測されたデータや事実に基づいて意思決定している者だけが石を投げなさい―――

    多くのWebサービスがそうであるように、Quipper が運営する「スタディサプリ」においても長らく"負債"と呼ばれる機能を抱えてきました。

    関係者曰く「なぜこんな機能を早く消してしまわないのか」…

    しかしA/Bテスト・統計的手法・エンジニアリングを組み合わせ、「その機能がどれだけ売上に貢献しているのか」という価値を定量化した結果、"負債"と呼ぶのは相応しくないと認識を改めることになりました。

    本セッションではその事例をご紹介しつつ以下の内容についてお話できればと思います。

    • Quipper が実践しているA/Bテスト
    • 定量データに基づく意思決定
    • 価値の定量化が開発体験やチームにどのような影響を及ぼしたか
  • Liked Tsutomu Yasui
    keyboard_arrow_down

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

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

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

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

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

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

  • 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 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 Atsuko Tsujioka
    keyboard_arrow_down

    Atsuko Tsujioka - リーダーシップを一度捨ててチームの輪の中に置いた話

    Atsuko Tsujioka
    Atsuko Tsujioka
    Engineer
    SMS Career,inc.
    schedule 10 months ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    株式会社エス・エム・エスキャリアの辻岡です。

    弊社は人材紹介事業を主に、医療介護通じて働く人と日本を元気にする会社です。

    私は社内の人材紹介エージェント(キャリアパートナー)が利用する業務システムの開発を主に担当しています。2年半前に弊社に転職しました。

    入社当初配属された部署には以下の課題がありました。

    • 現状の課題をあきらめがち
    • 全員目の前の火消しや依頼に対応するのが精一杯
    • 正社員が誰も実装してない。一切ソースコード見てない
    • 開発計画の正否の考え方が短期目線なものばかり
    • 社員数 << 他の会社から来てくれる人数。→人の管理者状態。
    • リリースしてもトラブルがあっても殆どキャリアパートナーに連絡しない

    etc…

    YAMAZUMI(山積み)

    ある日1つのチームを持つことになりました。

    彼らにアジャイル手法を伝え続けてチームの輪が出来始めた頃。

    私は一人で抱えたチームのリーダーシップを一度捨てました。

    そしてそれをチームの輪の中に置きました。

    リーダーシップを一度捨てることで全員がオーナーシップを持って課題を乗り越えていくチームができた事例を紹介したいと思います。

    発表スライドはこちら

    https://www.slideshare.net/AtsukoTsujioka/rsgt2019-127663850

  • 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 Masamichi Otsuka(radiocat)
    keyboard_arrow_down

    Masamichi Otsuka(radiocat) - あきらめないスクラム -事業拡大を続ける会社と成長を続けるサービスの中でチームがアジャイルであり続けるための闘い-

    20 Mins
    Thought & Practice
    Beginner

    株式会社ラクス は中小企業向けのクラウドサービスを提供し、18期連続増収で事業拡大中の会社です。私が所属するチームは主力サービスである 楽楽精算 の開発を担当する大阪の開発チームです。これまでに社内初のモバイルアプリやAIによる入力補助機能など、サービスの成長を支える新機能の開発を行ってきました。その取り組みを活かしてチームをさらに加速させサービスのさらなる成長を支えるために、2018年からスクラムの実践にチャレンジしています。

    本セッションでは、成長を続ける会社と主力サービスをとりまく不確実性の高いビジネス環境の中で、様々な変化に向き合いながらチームがアジャイルであり続けるために取り組んだこの1年間をスクラムの現場の視点で総括します。

    過去の発表資料はスクラムを始めた最初の半年がベースとなっており、スクラムを知らない人も対象としているためやや抽象化した内容となっていますが、本セッションではスクラムの実践についての知見があるかたを対象にスクラムの現場のコンテキストでお話する予定です。

  • Liked Toshiyuki Ohtomo
    keyboard_arrow_down

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

    20 Mins
    Thought & Practice
    Beginner

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

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

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

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

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

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

  • Liked Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Ikuo Suyama - Fail fast, learn fast - Celebration Grid:組織を変えるプラクティス [Management 3.0体験ワークショップ]

    45 Mins
    Thought & Practice
    Intermediate

    Celebration Grid

    失敗から学ぶことは、ビジネスにおいて重要なテーマであることは疑いようがありません。

    企業、組織、およびチームは、すばやく失敗し、失敗から学ぶことで、複雑な環境に適応しなければなりません。
    あなたの組織では、失敗を祝福していますか?
    成功したことのみを祝い、多くのことを学べる失敗をないがしろにしてはいませんか?
    それでは、すべての失敗を祝う必要があるのでしょうか?あるいは、両方を祝うのでしょうか?
    "セレブレーション・グリッド" によって、成功や失敗ではなく、 "学習したこと" を祝福しましょう。
    このセッションでは、"セレブレーション・グリッド" を実際に作成していただき、失敗を祝う方法や、学びを得るための実験をマネジメントする方法をお伝えします。

    Management 3.0

    Management 3.0 は、オランダ出身のヨーガン・アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念です。
    「人ではなく、システムをマネージするべき」というアイディアに基づいています。
    Celebration Grid は、Management3.0の中でもAppelo氏が「最も重要なもの」と位置づけるプラクティスです。

    CyberAgent AdTech Studioでの事例紹介

    CyberAgent ではこれまで2度ステファン氏によるManagement3.0社内研修を実施しており、20名以上の参加者が1年以上にわたり Management3.0 の取り組みを続けています。
    今回はその中でも「セレブレーショングリッド」のプラクティスを社内でどのように運用し、どのような成果が得られたのかを、成功と失敗の事例を交えてお話します。
  • Liked Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - アジャイル開発でコールド負けしないための5つのポイント

    45 Mins
    Thought & Practice
    Beginner

    多くの組織では、うまく進めるためのショートカットやツールを求める傾向にありますが、足元が固まっていない状態でさまざまなプラクティスやツールを導入しても無意味で、混乱したまま成果も出せずに終わってしまうこともあります。また、そのような状態で大規模な開発を進めるのは自殺行為です。

    本セッションでは、アジャイル開発をうまく進めるために最低限考えなければいけないポイントをスクラムの文脈で紹介いたします。これらのポイントは多くのアジャイルコーチングの場において強く伝えていることです。

  • Liked Kenta  Sasa
    keyboard_arrow_down

    Kenta Sasa - より高速に価値を届ける 〜アジャイルとDevOpsに対するイメージから見えたチューニング方法〜

    20 Mins
    Thought & Practice
    Beginner

    DevOpsとアジャイルと私

    先日までは開発チームに所属し、アジャイルな開発を目指していた私ですが、
    この頃はDevOps界隈にも足を突っ込み導入支援などを行っています。

    正直、DevOpsという言葉は定義が明確でないこともあり、
    あまり好きな言葉ではありませんでした。

    結局アジャイルとほぼ同じだし、呼び方を変えたくらいのもんなんじゃないの?
    という気持ちもありました。

    この頃の変化

    DevOpsやアジャイルの導入支援を行うにつれて、この2つに少し差を感じ始めました。

    「DevOps」と「アジャイル」という言葉自体の差ではなく、相談してくれる方々が持つ
    「DevOpsのイメージ」と「アジャイル(Scrum)のイメージ」の差です。

    DevOpsとScrumに対するイメージの差

    「DevOpsのイメージ」:価値を顧客に届けるためのワークフロー全体を改善する自動化ツールなど

    「Scrumのイメージ」:価値を顧客に届けるための「開発フェーズ」を改善する手法

    これは、Scrumは開発フェーズしか改善できず、DevOpsは全体を改善できる、
    と言いたいわけではありません。

    Scrumの実践者の中には企画やデリバリーと言った、俗に言う開発以外の領域も
    チームで実施している方もおられると思います。

    逆に開発のみに限定して実践されている方もおられると思います。

    共通する重要なポイント

    Scrum、DevOps、どちらの呼び方をしたとしても、以下の気持ちは変わらないはずです。

    • 「価値を高速に顧客に届けたい」
    • 「早くフィードバックをもらいたい」

    この目的を達成するためには、開発フェーズのみに着目するのではなく、
    もう少し視野を広げる必要があるチームもあると思います。

    重要ポイントを達成するために

    「開発しか考えていなかったなぁ…」

    「開発チームはめっちゃいい感じなんだけどこれで良いんだっけ?」

    という方は一緒に、「価値を高速に顧客に届ける」、「早くフィードバックをもらう」ための
    アクションを考えてみましょう!