スクラムイベント外の振り返り会 体験コーナー 〜相互理解、コミュニケーション強化を目指して〜

振り返りはどんな頻度で、どのように実施されていますか?

私のチーム(複数プロダクトを持つ部署内のQAチーム)では、以下の課題がありました。

  • チームメイトはそれぞれの担当領域があり、業務上関わりが少ない。
  • さらにフルリモート化ということで、そもそも話す機会も少ない。

そんな時、チームメイトが「月次で振り返り会をやりませんか?」と提案してくれました。

この会がとっても楽しいので、他の方にもぜひ知っていただきたいと思い、体験コーナーをご用意します。

 

「初対面の人たちが集まってうまくいくのか?」ですって?ご心配なく!

  • 業務上関わりが少ない
  • 話す機会も少ない

という中で運用を開始しています。まさに、セッションに参加する私たちと似た状況ですね。

ワークショップを通して、スクラムイベント外での振り返りのメリットを実感していただくことを目指します。

そのまま自チームで実施してみるのもよし、カスタマイズして行うのもよし。チーム内外との相互理解、コミュニケーション強化のためのアクションのきっかけになる、チャッカマンのようなセッションを目指します!

 
 

Outline/Structure of the Workshop

  • 前提
  • ワークショップ
  • まとめ

Learning Outcome

振り返りのやり方を1つ実感することができる

初対面だけど似た悩み・課題感を持つ方のことをちょっぴり知ることができるかもしれません

Target Audience

メンバーがそれぞれ異なる業務を行っているチームの方、チーム内・チーム間の定期的なコミュニケーション方法を知りたい方、振り返りのやり方自体に興味がある方

schedule Submitted 5 months ago

  • Kazumasa Ebata
    keyboard_arrow_down

    Kazumasa Ebata - Various Scrum Teams

    Kazumasa Ebata
    Kazumasa Ebata
    CEO
    Odd-e Japan
    schedule 5 months ago
    Sold Out!
    60 Mins
    Keynote
    Advanced

    When you think of Scrum, you probably imagine its use in software development. I often hear these voices in many Japanese communities. However, my image is a little different.

    あなたのScrumといえば、ソフトウェア開発での活用をイメージするでしょう。多くの日本のコミュニティで、こうした声をよく聞きます。しかし、私のイメージは、少し異なります。

     

    This time, key staff members, especially Matsuura-san who made an enthusiastic love call to me, asked me to talk about examples and methods of utilization outside of software development.

    今回は主要なスタッフ、特に熱烈なラブコールされた松浦さんから「ソフトウェア開発以外での活用事例、活用方法を話して欲しい」との要望を受けました。

     

    In response to these requests, this session may change the image of Scrum a little, from examples of its use in projects other than software development and how it is used.

    こうした要望を受け、本セッションでは、ソフトウェア開発以外のプロジェクトでの活用事例、活用方法から、少し Scrum のイメージが変わるかもしれません。

  • Fujihara Dai
    keyboard_arrow_down

    Fujihara Dai - アジャイルになれない開発入門

    45 Mins
    Talk
    Beginner

    アジャイル開発の解説はたくさんあるので、逆に、アジャイル開発になれない方法をざっくり紹介します。
    成功する方法を見つけるのは難しいけど、失敗する方法を知るのは簡単だったり。

  • kyon _mm
    keyboard_arrow_down

    kyon _mm - スペシャリストになれなくても成長する方法 #5000dai

    45 Mins
    Talk
    Beginner

    ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。

    ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。

    ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。

  • Satoshi Harada
    keyboard_arrow_down

    Satoshi Harada - その心理的安全性は間違っている!心理的安全性で陥りやすい間違いとその対策

    20 Mins
    Talk
    Intermediate

    心理的安全性という言葉、皆様は聞いたことありますか?

    心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。

    あなたが所属するチームで、メンバーに「心理的安全性は重要だと思う?」と聞けば、恐らく殆どの場合「当然。心理的安全性は重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ!」という声が帰ってくると思います。

    しかし、そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか?心理的安全性という言葉がキャッチー(かつ、流行っている)こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。

    心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。

     

    このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。

    そして、そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase / Kazunori Otani / Mitsuo Hangai / Teppei YAMAGUCHI / Tsutomu Yasui / Yosuke Ota / Yudai Moriya - F1 仙台グランプリ'22

    45 Mins
    Talk
    Intermediate

    Regional Super GT 2022、もとい、Regional Scrum Gathering Tokyo 2022を皮切りにスタート、5月の新潟GP、6月の大阪GPに続き、フィードバック1グランプリ'22国内ツアー、好評につき第4弾は杜の都仙台で開催します!
    初回から3戦連続、王座を守るyattom帝国の牙城は突き崩されるのか!?

    開催年月 開催地 チャンピオン
    2022年6月 大阪 yattom
    2022年5月 新潟 yattom
    2022年1月 お茶の水 yattom

    F1のFはFeedbackのFです。
    アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

    この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

    アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
    ポイントの投票は回答者自身と、聴講者によっておこなわれます。
    高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
    最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。

    お題と回答の例その1
    お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか?」
    回答1「上司にベロシティについての理解を問うてみてはどうでしょうか?」
    回答2「ベロシティは顧客価値につながる指標なんでしょうか?」
    回答3「デプロイメント頻度は計測できていますか?」

    お題と回答の例その2
    お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
    回答1「テストをサボるとその足枷がどんどん重くなるのでは?」
    回答2「一度テストをまったくしないで進めてみてはどうでしょうか?」
    回答3「プロダクトオーナーを説得する役割の人はいないのですか?」

    出演者の情報です。
    実況:ながせ(miholovesq
    解説:もりや(yudmo
    ドライバー(回答者):よた(yota)、てやまぐ(teyamagu)、やっとむ(yattom)、かっちゃん(katzchang
    その他のドライバーにはこれから声をかけます。
    出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します!

    今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました!!!

    お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
    https://forms.gle/oFih3o1mk6P8gTGK8

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - プロダクトオーナーのための、ふりかえりが日常に溶けるチームのつくりかた

    45 Mins
    Talk
    Advanced

    毎日ふりかえりをして、毎週ふりかえりをして、自分たちのこと、チームのこと、プロダクトのことに向き合い続ける。

    毎回1つとて同じふりかえりはなく、その場に合わせて新しいふりかえりが自然発生し、チームによって生み出されていく。

    そういったふりかえりを全力で行い、プロダクトを全身全霊で作るうちに、ふりかえりが日常に溶けていく。

    そんなチームが出来上がるまでの2年間をふりかえると、ふりかえりだけでない、いろんな要素が絡み合っていました。

    • ふりかえりを楽しむということ。
    • チームの文化を作り続けるということ。
    • ひとりひとりのオーナーシップ。
    • メンバーそれぞれの価値観の共有。
    • みんなが大切にしている想い。
    • ゴールをともに作り上げ共有すること。

    このセッションでは、ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素をお伝えします。

    マネする必要は全くありませんが、少しでもふりかえりを身近に感じられたり、ふりかえりの周辺にある何かを感じ取っていただけたら嬉しいです。

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - ボードゲーム「チームで勝て!(仮称)」

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 5 months ago
    Sold Out!
    90 Mins
    Workshop
    Intermediate

    チームが一致団結して開発する日々の様子を、メンバーの立場から体験できるボードゲームを作りました(作っています)。以下のような和やかなやり取りをしながら進めるゲームです(予定です)。

    「ちょっとこのタスク誰がやるのよ」
    「いまリファクタリングしとかないとヤバ…」
    「依頼してよかったですよ、ありがとうございます。次のも楽勝ですよね?」
    「品質に問題があります」
    「これできる人いたっけ?」
    「グロース!!」
    「おれiOSしかやりたくないなあ」
    「楽しく仕事しましょうね、楽しくね」

    4人1グループで、90分~2時間くらいかけて遊ぶゲームになりそうです。仙台では、オンサイトで会場に集まってボードゲームを遊ぶ予定です。

    各プレイヤーは、開発チームのメンバーとして、自分のスキルを表す手札を持っています。ボード上にはタスクカードが並んでおり、自分のスキルでこなせるタスクを選び案件として実施すると、開発が進みます。開発を進めるとチームは3種類の報酬を得ます。

    • Growth - プロダクトや会社の成長と売上増
    • Impact - ユーザーや社会に対する貢献
    • Productivity - プロセス改善やリファクタリングによる作業効率化

    メンバーは一人ひとり異なった「勝利条件」を持っています。あるメンバーはひたすら成長にコミットしており、別のメンバーは自分のスキルにしか興味がなく、また別のメンバーはプロダクトがバランスよく成長しながら社会に貢献することをモチベーションにしている。自分の勝利条件に近づくようにタスクを選んで案件を実施ししましょう。

    しかし1人でできる仕事は僅かです。スポンサーの要求はどんどん高まっていき、チームが協力して開発しなくてはクビになってしまいます。チームとして案件を成功させながら、いかにして個々人の勝利条件を追求するのか。チームとしてのコミュニケーション、作戦、そして駆け引きがこのゲームの醍醐味です(予定)。

    ゲームの準備の都合で、参加者は最大12名の予定です。見学だけの参加も可能です。

     

  • Noriyuki Nemoto
    keyboard_arrow_down

    Noriyuki Nemoto - 品質レベル+1~品質を作りこむ独自のスリーアミーゴスサンド~

    Noriyuki Nemoto
    Noriyuki Nemoto
    senior engineer
    Agile Sapporo
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    「アジャイルチームで品質を作りこむ」
    色々やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。

    ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」(独自イベント)を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。

    ### リファインメント

    言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。

    • PBIのゴール
    • 設計方針
    • テストの方針+影響範囲

    POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。

     

    ### 受け入れ

    私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。
    POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。

    お気づきでしょうか?
    DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。
    良く見ると「実装」がスリーアミーゴスでサンドされています。
    自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。

    • スリーアミーゴス
    • 実装
    • スリーアミーゴス

    このスリーアミーゴスサンドにより、以下のことを防ぐことができます。

    • 作ってみたら変なモノができていた(修正)
    • テストが足りていない(追加)
    • お互いに期待値に達していなくてイライラする

    スリーアミーゴスサンドぜひお試しを!

  • Hiroyoshi Takahashi
    keyboard_arrow_down

    Hiroyoshi Takahashi - ど根性学生起業 CTO編 ~ソフトウェアの素晴らしさに目覚めた大学生が起業してみた...そして今~

    45 Mins
    Talk
    Beginner

    東京理科大発(理科大VC出資)ベンチャーShinonome(https://shinonome.io/)を学生創業してから、はや6年。

    現在では、全国の大学と提携をして大学生にIT実践教育の仕組みを提供できるようになり、500名以上のエンジニア・デザイナーを教育・輩出しています。

    しかし、創業期は...

    「金がないので、寸胴で炊き出し?!」「20時間/312日、開発体制!?」

    ソフトウェアとの出会いから、学生起業、今に至るまで赤裸々なストーリーをお話しします。 

  • Toshiyuki Ohtomo
    keyboard_arrow_down

    Toshiyuki Ohtomo - ダイナミックリチーミングから学ぶ、不確実な状況に適応し続けるためのチーム作り

    45 Mins
    Talk
    Intermediate

    J. Richard Hackman著の書籍Leading Teamsによると「安定したチームほど良いパフォーマンスを発揮する」とあります。

    まったく異論はありません。

    ただ、嬉しくもあり、残念でもあるのですが、チームでの活動がうまくいった結果、プロダクトが成長し、ビジネスが成長すると、どれだけ今のチームが素晴らしくても、チームを大きくする力がどうしても働き始めます。

    そうすると、いつまでも安定したチームで居続けられなくなるのもまた事実です。

    安定したチームがよいパフォーマンスを発揮するとはわかっていても、なかなか許してもらえない。

    そんな状況を受け身になげくのではなく、それを受け入れ、不確実な状況に適応するために、積極的にチームや組織をダイナミックにリチーミングすることはできないでしょうか?

     Heidi Helfand 著の書籍Dynamic Reteamingより、チームをダイナミックにリチーミングするための5つの方法を、実際に現場でチームと関わるなかででてきた事例とともにご紹介します。

    もうリチーミングは、怖くない!

     

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - 意志の弱い自分を許せるようになる(かもしれない)セッション

    Shinya Ogasawara
    Shinya Ogasawara
    -
    -
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner
    • 今日は本を読むぞと決めたけど、結局ゲームをやってしまった
    • 体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった

    • 貯金をしたいのに、欲しいものがあると思わず買ってしまう

    このような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか?私はあります。こうした経験をすると、自分の意志の弱さを感じて、嫌になったりもします。

    行動経済学などの文脈で、「意思決定理論」という考えがあります。私が知っている範囲では、「意思決定理論」において重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。

    例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。こうしたバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。

    このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。

    こうした非合理的な行動を説明する理論として「双曲割引」という考えがあります。

    私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。もちろん非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。

    このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。

    私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。

  • Koki Shimizu
    keyboard_arrow_down

    Koki Shimizu - Certified Team Coach(CTC) への道 〜スクラムマスター・アジャイルコーチのスキル探求〜

    Koki Shimizu
    Koki Shimizu
    Senior Architect
    RedHat K.K.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    みなさん、こんにちは!

    アジャイルコーチの清水弘毅です!
    日本在住だとおそらく3人ほどしかいない、CTC認定をスクラムアライアンスから受けています!

    本セッションでは、スクラムマスターやアジャイルコーチの方の、必要なスキルの探求をしていきます。

    私自身がどんな場面に遭遇し、どのように考え、どのような道を辿ってきたかお伝えしますので、スクラムマスターを極めたいと考えている方たちの一助になれば幸いです。

    CSM, A-CSM, CSP-SM, CTC, CECで求められるコンピテンシーに照らし合わせながらお話する予定です。

    スクラムマスターを極めたい方は集まってください!

  • amix edcolor
    keyboard_arrow_down

    amix edcolor - 週6時間でうまくいくスクラムのはじめかた

    amix edcolor
    amix edcolor
    Student
    University of Tsukuba
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    私は筑波大学の情報系の学生です。3年生の春から、enPiTを通してアジャイル、スクラムを学んでいます。

    3年生の秋に、新しくチームを組み開発を始めることになりました。ここで珍しかったのが、そのチームのチームメイトは全員スクラムを知らなかったということです。

    そんなチームで、私がスクラムマスターとなり、スクラムをはじめました。その過程から「スクラムのはじめかた」を紐解いていきたいと思います。

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) / Harada Kiro / Miho Nagase - パワポカラオケ「スプリントプランニング Deep Dive」

    45 Mins
    Talk
    Beginner

    当初講演予定のRyuzee不在につきプレゼンター変更でお届けします

    講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ(コーラス:haradakiro)でお送りします。
    いつの日か本物の「スプリントプランニング Deep Dive」が聴けることを期待しつつ……、それでは聴いてください。
    Attractor Inc.で、新曲「スプリントプランニング Deep Dive」

     


    ★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

    前回のプロダクトバックログ(https://slide.meguro.ryuzee.com/slides/107)に引き続き、今回はスプリントプランニングのすべてを完全解説!!


    スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

    ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

    一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

    以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

    • (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
    • (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
    • (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
    • (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
    • (e) スプリントプランニングの前に、先にタスクに分解しておく

    もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば(SCRUM BOOT CAMP THE BOOKも是非読んでみてください)、陥りがちな罠は避けられます。

    本セッションでは、スプリントプランニングをうまく行うための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。


    なお、望ましくないものは、(c)以外のすべてです。

     

  • Takeshi Kaise
    keyboard_arrow_down

    Takeshi Kaise / Ryota Saiga - [オンサイト開催] 初心者歓迎!DoD Cooking Studio

    90 Mins
    Workshop
    Beginner

    スクラムガイド2020年版において「完成の定義」のアイデンティティが明確になりましたが、活用イメージがついていない方もいらっしゃるのではないでしょうか。

    そういった方々に向けて、誰しも親しみのある「料理」を題材に、完成の定義(Definition of Done)の理解を助けるワークショップを作りました。

    スクラムチームにおける役割や職種、スクラムの経験年数に関係なく、どんな方でも参加いただけると思います。みんなでワイワイ楽しみましょう!

    ※基本的にオンラインで進行しますが、希望が多ければ、オンサイトでの同時進行も行うかもしれません。→ 直前のご案内で申し訳ありません。こちらのセッションは「オンサイト開催」となりました。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Kenta Sasa / Taku Iwamura / Tsutomu Yasui / Yosuke Ota / Yudai Moriya / Yuji Imagawa / Yukei Wachi / yumi kanehira - ワインバーグ先生の未訳本『フィードバック』のエッセンスと読書会の体験

    45 Mins
    Talk
    Beginner

    すべてがフィードバック、なんでもフィードバック - Feedback is Life

    フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

    しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない!と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

    そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

    • すべてがフィードバック、なんでもフィードバック。
    • テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
    • フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
    • フィードバックでは自分自身を大事にすることが大切です。
    • フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
    • 「フィードバックください!」とよく言ったり言われたりしますが、実は……

    みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

    本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

    ぜひ、楽しい時間を皆さんと分かち合いましょう!

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - The Best Agile Metrics – Everything Else Sucks!!!

    45 Mins
    Talk
    Beginner

    Look, you need metrics for your Agile organization, right? In the immortal words of Peter Drucker, If you can’t measure it, you can’t improve it.” So, you need to measure things, and measure them well. And you need to measure the right things too! 

    Metrics on employee happiness, theoretical value, and work not done are just plain dumb. I will reveal the metrics that you need. That mean something. And that get results. Join us as we discover THE BEST AGILE METRICS!

  • Shigeo Konno
    keyboard_arrow_down

    Shigeo Konno - 小さく始めるアジャイルコーチの提案

    Shigeo Konno
    Shigeo Konno
    Specialist Lead / Agile coach
    DTC
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    私は、悩んでいました。

    アジャイルコーチを名乗っているのですが、コーチングができているかわからないんです。
    もちろん学んでいますし、超優秀なコーチから継続的にコーチングも受けています。
    でも、現場で行っているコーチングが、コーチングになっているかどうかの判断がつかないのです。

    まわりを見ると、第一線でキラキラと輝くアジャイルコーチたちが活躍をしています。
    そして、自分はいつも、悩んでいました。

    そんなある日、コーチングセッションでコーチから提案を受けました。
    「小さなことでもいいので、現場で日々やっていることを書いて共有して!!」

    当初は、1ヶ月で20個、現場でやってみたことを書いてみる予定でした。
    やってみると、1週間で50個を超えました。
    今は、3週間で100個を超えました。

    「デイリーミーティングでは大きな声で挨拶する」のような、簡単なものもあります
    気づかず繰り返しでやっているものもあります。
    中には、やってみて、傷つくような失敗になったものもあります。
    思いがけずに、素敵な結果に結びついたものもあります。

    もしかすると、僕がやりたいことは
    こういったことが積み重なった先にある、小さく始めるアジャイルコーチの提案なのではないか、と思い始めています。

    発表では、私が日々現場でやってきたことを抜粋して紹介します。
    また、繰り返し現れたものや関係性があるものなど、パターンの抽出にも手をつけてみようと思います。

    それら、発表の中で紹介した中から、気に入ったものや使えそうなものを持ち帰っていただいて、
    明日から、皆さんの現場で、小さくな所からでもアジャイルコーチを始めてもらえれば嬉しいです!!
    そして、また、コミュニティの中で結果を共有できる日を楽しみにしています!!

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - チームの関係性をつくるインセプションデッキ

    45 Mins
    Talk
    Beginner

    あなたのチームのインセプションデッキは役に立ってますか?

    インセプションデッキは、書籍「アジャイルサムライ」の中で紹介されたツールです。

    "プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキ"

    インセプションデッキは10個の質問で構成されていて、質問に答えていくことでプロジェクト開始前に確認しておくべきことが明らかになるツールです。これだけ聞くと簡単そうに聞こえますが、実際に現場でインセプションデッキを作成して活用するまでにはさまざまなお悩みポイントにぶつかります。

    「デッキ作成にどれくらい時間を確保すればよいの?」  
    「デッキ作成するときは具体的にどう進めたらよいの?」  
    「デッキを作ったのはいいけれどそのあとどうしたらいいの?」

    本セッションでは、インセプションデッキの紹介からこれらの現場で実践する際のお悩みポイントを解決する方法までお話します。

    また、インセプションデッキは作成したデッキ以上にチームの関係性をつくることに価値があります。ただデッキを作成するだけでなく、チームの関係性をつくるためのインセプションデッキについてお話してみます。

  • 90 Mins
    Workshop
    Beginner

    "You better bring it!

    Oh, it's already been broughten!"

    The purpose of cheerleading is to support and encourage their team to achieve peak performance - they give the team the extra oomph to carry them over the goal line! The cheerleaders not only support and celebrate the wins, they also encourage the team when they need to push through their trials and tribulations. Cheerleaders build the hype of the team fans by creating infectious energy, just imagine your stakeholders hyped up because of your awesome team!

    In this session we will take lessons from professional cheerleading and apply them in an agile team context.

    We will cover the 3 pillars of agile cheerleading - chants, dances, and symbols and explore the fundamentals and benefits of an agile cheer so that you can super-charge your teams.

    BE! AGILE! BE! BE AGILE!

    AAWUweXUoYnrgigVUXlh_0HNtVC7juQixRk6xDwkQ8Gc5wqYbizgmm96lEN9c-pOQlc2KZtrPWnMBazOaix8zNrYM4xs2Y6fDSiP1WBfO917seR_ERlIQOnVYAfJ9YPELcjQfsJl4OTnE-NPR3TumOWPVHr8KvSLBJ3nQjbL3j_DEccrXhy_D3JKvXqqDB17OVaW5CCAZp_JCsVUNrkd32mykhnjm6SHh1o79vHJhjvk-BbO7rLTwusyWvmZ6E3WNnvifP_gGwBwUCXU3LnZqtSSyQlnSj3bAejFGK7CnXsLR8WZaTCRCL-kb2z24dZ0OFQkND5NU2IfTFFnxjQuwUc8Z950K3a2B8ncnVVvmZ8cTBAU2I3HwJSwSk8R8lvSYg2pckSpejoz_ckgzPNt2kInLsq9D05LsVCrhZE5FDbnhmDEqSyGjBShb4ywUaDOZFgymtXPI6kSXX1w9_t5G-ztZzj5l7HFpN2znvZcGl6YTLe0KUbjXV8kutDO0NBbmt4j8HEtXaOfkcOzrxPy8CeEBYjxlVlUWlhbCS570ktL7VEiEiVWSFG_Kj22F4vEYdOegp40aGNPfZvU-C6MTJTjwprCnSemO6Ezcq-HnFzk0LCu8fOeILoFAdo0q_PJq5LC0kpbyk3hxqsCCq7ZlIYJUf_sxBXwU8aSRqodRqv6FeZEz9QjCEVsverhEwCcwjr7IWk96X82JShijhhFalkskOz0_8gvUC-HEA=w1714-h533-ft

help