In past years, I have tried and experience different style of doing Retrospective but cannot completely understand it's importance of how to do it with the team , till lately.

 
 

Outline/Structure of the Talk

In this talk I would like to talk about

  • My Experience
  • Introduce the style that my team have integrated into the group
  • Importance

Learning Outcome

  • Finding the best way to do retrospective for your team
  • Understanding it's importance in the team

Target Audience

Anybody is welcome

schedule Submitted 1 year ago

  • 平鍋健児
    keyboard_arrow_down

    平鍋健児 - 野中郁次郎のスクラム〜The New New Product Development Game と知識創造理論と海兵隊

    平鍋健児
    平鍋健児
    CEO
    ESM, Inc.
    schedule 2 years ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    アジャイル開発は海外から来た手法だと考えていませんか?実は、アジャイルの根底には、戦後にトヨタで開発された生産の流れ化、改善手法であるTPS、および、80年代製造業で行われていた暗黙知を利用した新製品開発手法の分析があります(XPにもScrumにも参照されています)。


    現在広く採用されいてる「スクラム」の呼称は、野中郁次郎らが1986年に書いた論文「The New New Product Development Game」に由来しており、そこには、製品への要求を顧客との共体験を通して学び取り、それを仕様書ではなく体で開発に運ぶ、思いの伝達者としての実践知リーダーシップのありかたが生き生きと書かれています。

    今回は、スクラムの本来の意味である、製品に関する知識獲得(顧客と要望に関するものと作り方に関するもの)、協調的マネジメント手法、デザイン思考との関連、知識創造モデル(SECI)、海兵隊の組織論、を中心に、 野中先生の「日本発のスクラム」のお話します。

    そして、エンジニアの仕事の意味について考え、日本の現場でプロダクト開発、サービス開発、ソフトウェア開発に携わる人たちを応援したいと思います。

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase - 説教「お前のそれ、スクラムじゃないから」

    Miho Nagase
    Miho Nagase
    Agile Coach
    Attractor Inc.
    schedule 2 years ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    これまでアジャイルコーチとして様々な現場で、アジャイルやスクラムの導入のお手伝いや、実践の支援をしてきました。

    もっとも頻繁に、そして恐々聞かれる質問が「うちってちゃんとスクラムやれてるんですかね…?」です。

    教科書的なスクラムを否定しつつ、そもそも教科書さえちゃんと読めない人が多すぎます。

    説教をします。

  • Harada Kiro
    keyboard_arrow_down

    Harada Kiro - A little history of Scrum / スクラムのちょっとした歴史のお話

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 2 years ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムは軽量で理解が容易になフレームワークだと自分で名乗っています。でも、習得はちょっと難しい。ツンデレですね。

    スクラムのルールをまとめたスクラムガイドは、表紙を入れても19ページしかありません。

    でも、スクラムは、最初っからそんなにシンプルだったわけでもないし、ずっと同じ姿だったわけでもありません。最初はフレームワークと言ってませんでしたしね。

    このセッションでは、ちょっとだけスクラムが出来上がってきた歴史をふりかえってみようと思います。

  • Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - スクラムフレームワークを使用する具体的な方法。僕の場合。

    20 Mins
    Talk
    Intermediate

    こんにちは。椎葉です。僕は2010年から楽天でWebアプリケーションエンジニアとして働いています。より良いものを届けたいという思いからスクラムの勉強を始め、2011年ごろから社内で導入を進めてきました。その影響もあってか、今は部署内のどのチームもスクラムを取り入れた開発を行っています。

    スクラムを導入しようとした当初は「あれ?これ具体的にどうやったらいいんだろう?」と悩むことが沢山ありました。タスクってどれくらい細かくすればいいの?とか、見積もりって具体的にどうやったらいいんだろう?とか。

    それに加えて難しいなと思ったのは環境です。組織がスクラムに適した形ではなかったり、メンバーもこれからみんなで成長していこうという状況だったり、開発チームの中の誰かがスクラムマスターをやらなきゃいけなかったり。

    そんな中で色々と悩みながら一歩ずつ前進しながら取り組んできたのですが、試行錯誤を繰り返した結果「だいたいこうやると良さそうだなー」というやり方が自分の中でできてきたので、それを紹介したいなと思います。

    それによって、同じような悩みを持った方が「そういうやり方もあるのか」と感じて一歩踏み出すチカラになれたらいいなと思います。

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - ピンポンゲームでスクラム体験ワークショップ

    45 Mins
    Talk
    Beginner

    アジャイルやっていますか?スクラム組んでますか?「スクラム」のもっとも重要なポイントは、チームみずから課題を明らかにし、一つ一つ解決していくところにあります。簡単なゲームを通じて、スクラムのプロセスを通じたチームの課題解決を体験してみましょう。このワークショップはBall Point Gameといって、スクラムでは定番のワークショップの一つです。ぜひ持って帰って自社でやってみてください。

  • Atsumi Kawashima
    keyboard_arrow_down

    Atsumi Kawashima - プロダクトマネージャーは、エンジニアリングマネージャーになれるのか

    20 Mins
    Talk
    Beginner

    私はプロジェクトマネージャーやプロダクトマネージャー経験が社会人生活18年の大半を占めており、エンジニアだったのは新卒入社の会社での1年程しかありません(もっと言うとホントにプログラム書いたのは半年で言語はPL/I…)。

    そんな私がスクラムを全く知らない状態でプロダクトマネージャーをやるようになり、さらに4年程前にプロダクトマネージャーをやりながらエンジニアリングマネージャーをやることになりました。

    当時はそんな言葉すら知らなかったので、本当に手探りの毎日でしたが、だんだん各ロールでやることというのがわかってきて、エンジニアリングマネージャーの仕事は「メンバーのお給料を上げるために尽力するのが仕事」だと2017年のRakuten Technology Conferenceでプレゼンさせていただきました。

    そこからさらに1年経過し、未だに時折プロダクトマネージャーを兼任しながらエンジニアリングマネージャーをやることもあり、より強くこの2ロールの違いを意識しながら動くことが増えました。

    ということで、2017年に述べたことよりもさらに気づいたこと、強く意識するようになったことを、両方のロールの面からお伝えできればと思います。

  • bleis-tift
    keyboard_arrow_down

    bleis-tift - 感謝のKPT 5000枚 -基盤チームのレトロスペクティブ-

    bleis-tift
    bleis-tift
    architect
    on the road
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    レトロスペクティブのツールであるKPTは実に多様な進め方があります。徐々に短い期間のスプリントに挑戦してきた基盤チームではこの1年でKPTの付箋が5000枚になりました。

    今回はそのKPTの具体例をチームメンバーであるbleis-tift, dico_lequeの二人それぞれ別の視座から紹介します。KPTの壁が狭くなるたびに引越しをかさねてきた基盤チームの実際のレトロスペクティブとはどんな会話がくりひろげられているのか。

    よいチームになるためにKPT活用法の事例として、みなさんのレトロスペクティブにすこし違う視点を提供します。

  • 20 Mins
    Talk
    Intermediate

    かれこれ20年以上、鳥取県にある株式会社リコーの子会社(何度か名前は代わって今はリコーITソリューションズ株式会社の鳥取事業所です)で働いていて、21世紀に入ってからポツポツと、気がつくと10年以上アジャイルとかスクラムとかやってきました。長い。華々しい成果とかはないのですが、長いと色々経験できるので、その経験のお裾分けをさせてください。

    特に、大きな組織や親会社子会社の関係性の中で、希望に燃えてスクラムを組もうとすると起きること、それを乗り越えるためにできること、に興味がある方にピッタリの内容です。最近始めた方、三年続けてみたぞという方、もう少し先の未来を覗けるかも?

  • Kazuhito Miura
    keyboard_arrow_down

    Kazuhito Miura - 「アジャイルやりたい!」って言うてるニワカ(おっさん)が足掻いた結果

    20 Mins
    Talk
    Beginner

    SIerにあって「30台、取り柄無いプログラマー」だった自分が「このままでええんやろか…」でアジャイルに入門…

    そうやって「やってみたいから足掻いてみる」ってスライドを書いてから数年。

    「アジャイルってなんや?」から始まり、「スクラムとの出会い」を経て、「スクラムのプロジェクトに関われない…」というボーダーを超え「スクラム・プレイヤー」となり、今サービスを作ってる。

    その間にあった「とまどい」「ジレンマ」「あるある」「踏み抜いた地雷 や 踏まなかった地雷(は、今から調べますが)」などなど。

    そんな「生存戦略としてスクラムを選んだ壮年プログラマー」の経験を「チームを眺める側」ではなく「メンバー視点」「プログラマー視点」から話したいと思います。

  • sakagawa mai
    keyboard_arrow_down

    sakagawa mai / Kogasan / Mori Keita / Nakamura Tatsuki - お堅い企業でスクラムチームを一から作った話

    20 Mins
    Talk
    Beginner

    こんにちは。

    私たちは、大手電機メーカーの中で全社を横断したシステム/ソフトウェア開発のコンサルティング及び技術導入を推進するグループです。

    今回の発表では、私たちが三年前にスクラム型開発方式を導入し、過去三年間に渡って開発を手掛ける傍ら、新しい文化の定着とプロセス・開発インフラの改良を実施してきた活動について紹介します。

    活動の初期段階では、担当者間で情報を共有する文化がなく、個々の担当者が自分の職務を淡々とこなしていました。こうした状況下でスクラム型開発を導入する先導役になったのは、入社1~3年の若手メンバーです。

    カンバンを使ったタスクの共有、基本的な開発インフラの構築、及び、開発プラクティスの導入と定着を経て、現在は、数多くのプロジェクトを並行して実行するスクラムチームとして活動しています。

    一方で現在の組織・体制の枠組みでは、チームに閉じたプロセスと開発環境の改善に限界も見え始めています。今年度は、自チームを対象に匠メソッドによるチームデザインを実施しました。5年後の姿を見据えた上で、直近のスクラム開発にどのような活動を落とし込むか?の取り組みも簡単にご紹介したいと思います。

    本発表を通して私たちのようなメーカー系企業とIT企業との間で活発な意見交換ができれば幸いです。

    About Us

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - スクラムチームは改善する問題を正しく選んでいますか?

    45 Mins
    Talk
    Beginner

    デマルコの名著『ピープルウェア』では、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と言っています。

    アジャイルやスクラム界隈でも、心理的安全性をどう醸成するのかといった話題やレトロスペクティブでいかにアイデアを引き出していくか、といったテーマに関心が集まっているようです。

    しかし、これは本当に今あなたのチームがフォーカスすべき問題なのでしょうか?

    スクラムで成果を出すためには、以下の3つの要素が必要です。

    • 適切な課題を設定する力(プロダクトビジョン、ミッション、ゴール)
    • 課題を解決するソリューションを構築する力(言い換えれば技術力)
    • これらを上手く進める力(プロセスやチームの関係性など)

    心理的安全性だけでは成果は出ません。ダメなビジョンをいくら良いチームで実現しても何の価値もありません。良いビジョンでも技術力がなければ時間がかかってマーケットに出せないこともあるでしょう。

    このセッションでは、あなたのスクラムチームが改善すべき問題にはどのようなものがあるのか、それらの問題の中から取り組むべきものをどのように選ぶべきか、説明します。

  • Mitsuyuki Shiiba
    keyboard_arrow_down

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

    20 Mins
    Talk
    Intermediate

    こんにちは。椎葉です。

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

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

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

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

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

  • 45 Mins
    Talk
    Beginner

    みなさんは、ふりかえり(レトロスペクティブ)を楽しんでいますか?

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

    ふりかえりは、皆で成長を祝いあい、前向きに未来のことを考える、とても楽しい活動です。
    そんな楽しいふりかえりを、これからふりかえりをはじめようとしている方、
    ふりかえりでモヤモヤしている方に体感いただきたいと考えています。

    45分のワークショップのなかで、チームを作り、実際にふりかえりを行います。
    そして、最後にワークショップをふりかえり、気づきを現場に持ち帰ることで、
    現場で楽しくふりかえりをはじめるためのきっかけしていただければ幸いです。

  • Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato / Miho Nagase - 出張!とにかく明るいセッション✌️(^o^)

    20 Mins
    Talk
    Beginner

    え、え、え、ちょっと待ってちょっと待ってーや?

    このセッション、めっちゃ明るくなーい!???

  • Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - 組織全体がアジャイルに変革した改善ストーリー

    Narichika Kajihara
    Narichika Kajihara
    Agile Coach
    Yappli,Inc.
    schedule 2 years ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    エウレカでは2017年1月から、本格的に アジャイル、スクラムの導入を開始しました。それは、自己組織化された開発チームが、ユーザに最も早く価値を届けることができ、開発チームが主体的にプロダクトに関わっていけるようになると考えたからです。
    最初は開発チームを強くするための取り組みでしたが、ステークホルダーが「アジャイル宣言の背後にある原則」を徐々に理解していくにつれて、変革していった組織全体の意識の変化についてお話させていただきます。

    始め方、ムーブメントを起こして組織を巻き込んでいった様子について、お話出来たら幸いです!

  • Masahiro Taguchi
    keyboard_arrow_down

    Masahiro Taguchi - 失敗しない男が大失敗した話

    20 Mins
    Talk
    Beginner

    スクラムは「失敗をマネジメントするプロセス」とも言われています。

    「私、失敗しないので!」が口癖のたぐちさんが、大失敗したこと赤裸々に話した上で、何故そうなったのか、どうしたら良かったのか、ポストモーテムします。

  • Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - 新米スクラムマスターのファシリテーション術

    20 Mins
    Talk
    Beginner

    2018年1月にCoplien氏の研修を受けて認定スクラムマスターになりスクラムの文脈でのファシリテーションもするようになりました。現場に接するようになって見えてきたファシリテーションのポイントについてお話しできればと思います。

    「スクラムセレモニーの時、スクラムマスターはファシリテーターのメガネをかける」そんな感覚で、ファシリテーターの目線から見たスクラムマスターについて語ります。

    ファシリテーションについての質問も少し受けれたらと思います。

  • Daisuke Kasuya
    keyboard_arrow_down

    Daisuke Kasuya - 魂の1on1 100連発

    20 Mins
    Talk
    Beginner

    チームをマネジメントしていくにあたって、メンバーとのコミュニケーションは欠かせません。マネージャとして、メンバーと親密になりたい、しかし、このご時世では飲みニケーションなんて言ってられない。

    そこでぼくは今年、これまで以上に1on1に力を入れる取り組みにチャレンジしてみました。

    1on1とは、会議とは違った業務を離れた気軽な対話の場です。30分ほどのマンツーマンの対話を繰り返し行うことで、お互いのことをよく知り、業務の内外のさまざまなことについて気軽に相談できる場の構築を目指します。メンバーから、仕事についてぼくにさまざまな相談をしてほしい。ぼくは、メンバーがリラックスして仕事をするにはどうすればいいか、彼らがどう成長したいかを知りたい。そういったことをお互いで探っていく場です。

    魂を込めて挑む1on1チャレンジ。

    どんなメリットがあって、どんなデメリットがあるか。うまくいく工夫や、うまくいなかったパターンなど、そのすべてをお話します。

  • Yoshitaka Fujii
    keyboard_arrow_down

    Yoshitaka Fujii - Managerを求められながら尖ったEngineerであるために自己組織化チームに挑む

    Yoshitaka Fujii
    Yoshitaka Fujii
    Engineer
    Chatwork Inc.
    schedule 2 years ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    エンジニア35歳定年説がどうとか実際にあるとか無いとかって話より、所属する組織の状況によっては、ある程度のキャリアを積んだエンジニアに一定のマネジメントを求めることは普通にある。

    またマネジメントの役職を与えることでしか、給与水準を上げられない仕組みの企業に所属することもぜんぜんある。

    その中で、自身の市場価値をエンジニア領域に置き続けるために、私が選択したことは、チームを自己組織化することで、自身のエンジニア領域の時間や役割を確保し続けることができるんじゃないかという光明だった。

    いかに自身のエンジニア領域を確保しつつ、チームの成果を上げ続けるマネジメント力を発揮し、成果にコミットするチームを作っていくのか、そのためにManagement 3.0のプラクティスや、スクラムのプラクティス、カンバンなど、チームがハピネスを持ちながら成果を発揮し、自身もハピネスであり続けるために、システムをどうやって構築したのか。

    Tryした経験を踏まえてふりかえってみたいと思います。

  • Tsuyoshi Miyamoto
    keyboard_arrow_down

    Tsuyoshi Miyamoto - サーバントリーダーシップが起こす組織の"覚醒"

    Tsuyoshi Miyamoto
    Tsuyoshi Miyamoto
    Manager
    Rakuten, Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    私は2010年にエンジニアとして楽天に入社し、いくつかのサービスの開発を経て3年前に今の開発グループにスクラムマスター的な立場でジョインし、その半年後にグループのマネージャになりました。

    エンジニアやプロデュース的なこと、スクラムマスター的なことを、よく言えば全部のいいとこどり、わるく言えば全部中途半端にこなしてきました。

    そんな私がジョインする前からグループが抱えていた課題の数々をマネージャという立場から四苦八苦しながら改善したお話を通じて、サーバントリーダーとして自身が"覚醒"するまでと、サーバントリーダーシップによってどのように組織の"覚醒"をお手伝いしてきたのか、具体例を通してお伝えできればと思います。