Empathy Boxというカードゲームを体験する会です。グループでのコミュニケーションを改善するツールとして、自分自身の深いところから湧き出す物語りの場として、全力で人の話を聞くという心躍る体験として、ユニークなEmpathy Boxを体験してください。

Empathy Boxでは「話したいことを気兼ねなく話せる場」を作ります。話者はStorytellerと呼ばれ、自分が語りたい話をします。好きな話をしていいのですが、「大事なこと、印象的なこと、自分のこと(meaningful, memorable, and about me)」という指針があります。

そして話者以外の人は、発話禁止です。聴き手は反応カードをそっと押しやることでなんらかの表明ができ、話者から聞かれて初めて感想や意見を言えます。反応カードは5種類あり、反応の種類をカテゴリ分けしたものです。

  • show some LOVE (ありがたい)
  • help me UNDERSTAND (わかりたい)
  • share an OBSERVATION (返したい)
  • offer alternative PERSPECTIVE (教えたい)
  • WILD CARD (好きにしたい)

Empathy BoxはTribeless PLT(マレーシア)の製品です。最近このカードを手に入れて、これはすごいのではないかと思い、体験会を何回か開催しています。本プロポーザルが通れば北海道で初の体験会となります。

 
 

Outline/Structure of the Workshop

  1. Empathy Boxの体験(65分)
    • 3人ずつのグループに分かれます
    • 説明しながら進行します
  2. ふりかえり(10分)

Learning Outcome

  • 話したいことを話せる体験
  • 話者のために全力で聞くという体験
  • 現場のコミュニケーションを改善できるツールの使い方

Target Audience

コミュニケーション改善のツールを探している人、コミュニケーションを体験したい人

Prerequisites for Attendees

カードは英語ですが、説明は日本語でします。カード1枚に1単語書いてある程度なので、英語力は必要ありません。必要に応じて翻訳アプリを使えます。

schedule Submitted 1 year ago

  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - もりあがるスプリントレビューをしよう

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    あなたのスプリントレビューは盛り上がっていますか?

    アジャイル開発を始めて4年になりますが、意義のある・活気のあるスプリントレビューができることもあれば、お通夜のような・審議のような・辛いスプリントレビューをしてしまうことが今でもあります。皆で褒め合うだけでなく、皆で責め合うだけでなく、「またやりたい」と誰もが感じられるスプリントレビューを開催する秘訣はないのでしょうか。

    Regional Scrum Gathering Tokyo 2020でこの悩みを共有したところ様々な方からアドバイスをいただけました。このセッションではその内容を整理し、実際に自分たちで実践した感想を加え、よりよいスプリントレビューをするための知見を共有したいと思っております。

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - 本当に強いプロダクトを作るためのプロダクトオーナー支援のはじめかた

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    みなさんの現場ではすでにスクラムを導入済みでしょうか。

    最初は仕事が終わらない、品質が低い、改善が進まないといった問題が沢山出ていたチームも、スクラムを始めると少しずつ安定して開発ができるようになってきます。ある程度のベロシティが出て、不具合の数もそれほど多くなく、割り込みタスクも大きい問題にはならなくなるでしょう。しかし、チームは魅力的で顧客の問題を解決する本当に強いプロダクトを作ることができているでしょうか。

    本当に強いプロダクトを作るためには、プロダクトオーナーの支援が欠かせません。プロダクトオーナーが不確実性と向き合い、素早い仮説検証を繰り返して、価値の高いアイデアを見つけられるようになる必要があります。開発チームはプロダクトオーナーの活動に参加・協力し、スクラムマスターはその取り組みを様々な方法で支援することができます。

    このセッションでは、自分がスクラムマスター/アジャイルコーチとして複数の現場で取り組んできたプロダクトオーナー支援の活動と、そこから学んだことについて紹介したいと思います。

  • Tomonori Fukuta
    keyboard_arrow_down

    Tomonori Fukuta - Scrum for people who working remotely

    20 Mins
    Talk
    Intermediate

    (作成中)

    ひょんなことから委託元はおろか開発チームのメンバー全員別々の場所で働いているチームに関わることになりました。

    別拠点、別組織、別会社、SIer、ベンチャー、フリーランス、リモートワーカー...どうやってチームになっていくのか、その過程において、自らもその1ノードでしかない人間に何ができるものなのか。

    「場」の無いところに「場」をつくる、そんな仕事の様子をお伝えできればと思っております。

  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - Happy Lucky XP ― ケント・ベックに教わったこと

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    “I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.”

    ― J.R.R. Tolkien, The Two Towers

    スクラムのイベントなので、エクストリームプログラミングの話をしたいなと思いました。

    私が最初にアジャイルに触れたのは、2000年頃、XPの記事や書籍、さらにXPを導入したプロジェクトにプログラマーとして参画したときでした。まだアジャイルという言葉はありませんでした。ペーペーのSIerプログラマーだった私はXPと遭遇して、プログラマーがさらに大好きになり、同時にただプログラミングが好きなプログラマーではいられなくなりました。プログラミングは趣味も含めて10年以上、フルタイムジョブとしては2年目くらいという、XPに触れたタイミングは幸運でした。

    XPはプログラマーの仕事を楽しくし、人生を幸せにします。プログラマーは指示通りに手を動かす歯車ではなく、創造性と専門知識を持った一個の人間です。同時に、プログラマーは安穏としてプログラムを書いてるだけでは済まず、顧客やその他すべての職種の人とコミュニケーションし、協力して、やるべきことをしなければなりません。プログラマーはプログラマーだから愛されるのではなく、生み出す価値が故に愛されます。XPは究極(エクストリーム)なので、プログラマーは究極的に最高の仕事をします。時間不足やスキル不足に追われる代わりに、ユーザーの期待と品質のバーを最高に設定して越えていく仕事が楽しくないわけがありません。プログラミング、ものづくりという仕事の意味をXPに塗り替えられた私は幸運でした。

    2000年に発行された『XP エクストリーム・プログラミング入門』(第1版)を見返すと、XPのユニークなプラクティスとして紹介されているものがいかに当たり前になっているかに驚かされます。テスト自動化、リファクタリング、コードの共同所有、継続的結合、シンプルな設計。当時の私にとっては、XP、Java、オブジェクト指向設計は不可分なものでした(時代背景的にも多くの人が似た状況だったのではないかと思います)。アジャイルなソフトウェア開発が発達するのと、並行して進歩する開発技術は表裏一体でした。将来当然となるプラクティスに早く触れられたのは幸運でした。

    XPは日本において(だいたい世界でも)現在に続くアジャイルのムーブメントを引き起こした先鋒であり第一の波でした。私はXPに心酔するのと同時にコミュニティに熱狂しました。アーリーアダプターの人たちがたくさん引き寄せられました(一過性ではなく、いまでもずっと活動されている方もたくさんいます)。そうした中で、コミュニティに参加したり、登壇の機会をもらったり、運営側を経験することにもなりました。人前で話をするなんてまっぴら御免と思っていた私にとって、幸運な機会がたくさんありました。

    XPはソフトウェアの作り手と使い手とを引き裂いた人工的な傷口を癒やし、全体性を取り戻す試みです。私は最初にXPに触れられて幸運でした。XPはプログラマーとして守るべき規律を示しながら、プログラマーの本来の役割は顧客やユーザーに歩み寄り、価値を生み出し続けるために一緒に働くことであるという、長く続く道にそうと知らずして進み始められたからです。オブジェクト指向設計やJavaといった技術だけを追求していたら、もしかしたら一生見つけられなかった道です。幸運だったとしか言えません。

    (上記はプロポーザル時点で考えている概要で、今後おおきく変化する可能性があります。4月になったら「XP: An East Asian smiley emoticon representing a happy face sticking out its tongue.」みたいな話になってる可能性もあります。悪しからずご了承ください)

  • Mizuki Kusakabe
    keyboard_arrow_down

    Mizuki Kusakabe - ゼロからつくったリモートスクラムチームはスクラムに挫折し解散しました

    20 Mins
    Talk
    Beginner

    「ゼロからつくる!リモートスクラムチーム」からタイトルを変更しました。

    プロポーザルを出した時点では以下のようなことをお話しするつもりでした。

    小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。

    会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。

    その状況から、

    • いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
    • 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
    • リモートでもチームとしてワークするために試行錯誤している話

    をお伝えしたいです。

    それから半年ほど経った今、このチームはすでに解散しています。目指していたマイルストンは達成できませんでした。

    でも、一部メンバーによってプロジェクトは推進されています。

    チームを立ち上げ、スクラムマスターとしてスクラムを実践してみたこと、スクラムに挫折したこと、チームの解散、その後のメンバーの頑張り、私たちにできたこととできなかったことを、ひとつの経験としてお話しします。

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴

    20 Mins
    Talk
    Beginner

    これまでのやり方に比べて、よりよさそうなやり方に変えてみるには知識と勇気、そして作戦が必要です。
    またそのようなことを進める中で様々な壁にぶつかります。

    このセッションでは自分がこれまでの様々な状況(※)で自分がどのように考え、やってみたこと、その時には越えることができなかった壁のこと、そこから得たことなどをお話します。

    ※様々な状況

    • SIerの客先常駐の現場
    • SIerのチームリーダー
    • 事業会社のマネージャー
    • アジャイルコーチ
  • Tsukasa Yokoyama
    keyboard_arrow_down

    Tsukasa Yokoyama - 突破力 - 大企業の札幌支社に中途入社して直面したこと

    Tsukasa Yokoyama
    Tsukasa Yokoyama
    Producer
    Rakuten
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    まるで自分たち4人だけ隣のグランドでサッカーをやらされているようだ
    と私は思いました。2012年ごろのことです。

    約10年前に、まだ設立間もない楽天の札幌支社に中途入社し、
    しばらくは社内システムを担当していました。

    組織移動により、一般ユーザ向けサービスの担当になり、
    最初のBigプロジェクトが楽天のデータセンター移行でした。
    全サーバを、物理サーバからVMに変換しつつ旧DCから新DCに移行するというものです。

    担当サービスのこともまだ良くわかっていないのに
    関係者がどこの誰だかわからない、やらばければいけないことさえわからない。
    わかっているのは期限だけ。

    自分たちには相手の協力が必要なのに、相手からは必要とされていない。
    圧倒的格差。
    無理もありません、だって知られてないわけですから。
    相手も手一杯の仕事を抱えているなか、なんで自分たちをケアしてくれないんだ
    と憤ってみても始まりません。当時は気付けませんでしたが。


    本社や発注元企業がリモートになりがちな地方都市では、このような状況に陥りやすいのではないでしょうか?
    自分のやり方が正解なんて思っていませんが、札幌で働く皆様の気づきの一助になれば幸いと思い自分がどのようにこの状況を突破したかお伝えさせて頂きたいと思います。

  • Atsushi Nagata
    keyboard_arrow_down

    Atsushi Nagata - ここがすごい!モブプログラミング

    Atsushi Nagata
    Atsushi Nagata
    Agile Coach
    Cybozu
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    モブプログラミングは、いますごく話題になっています。モブはいいという話が多くされてはいますが、どういうことでいいのでしょうか。そして、モブプログラミングでは何が起こっているのでしょうか。モブで、チームメンバーはお互いにどんなやりとりをしているでしょうか。それがそれぞれにどのように働きかけているでしょうか、その結果、どんな効果が生まれているでしょうか。

    サイボウズでは、日本の開発は全てモブでやっています。そこから戻ることはありません。何が彼らをひきつけているのでしょうか

    私は、そのモブに接した時、衝撃を受けました。そしてその魅力に取り憑かれました。何が起こっているのか、もっと調べたくなりました。そこで、モブのやりとりを徹底的に取っていきました。そこからモブメトリクスというものができて来ました。そのメトリクスを改善していくうちに、虜にさせるモブのメカニズムが見えてきました。そこには、チームが不確実な問題に取り組む際のメンタリティーを高める効果ばかりでなく、高い品質をはじめから組み込んでいく仕組みを支える効果もありました。

    このセッションでは、その膨大な情報から見えて来たモブの活動の何がすごいかをご紹介したいと思います。

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - It dependsから脱却するスクラム

    50 Mins
    Talk
    Intermediate

    チーム、組織、会社、役割、契約、業種・・・
    私たちの仕事にはいろんな状況があるので、つい、
    「It depends(ケースバイケースだね)」
    と言いたくなってしまうときがあります。

    しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

    こんにちは!

    こんにちは、及部です。

    私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

    組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

    伝えたいこと

    教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

    つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ?」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

    それでは、スクラムフェス札幌大会でお会いしましょう。アディオス!

  • Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 日本にJoy,Incを創る!どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡 Scrum Fest Sapporo特別編

    Tadahiro Yasuda
    Tadahiro Yasuda
    CEO
    Creationline,Inc.
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    会社の文化(カルチャー)変革の7年間の軌跡。

    2013年ごろ、色々な問題が噴出し、会社としても個人(経営者)としてもどん底の状態でした。
    そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化(カルチャー)が形成されるようになりました。

    その過程のなかで2017年8月「Joy,Inc.」に出会いました。
    「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
    この本に共感しぼくらもこんな会社に成りたい!と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

    会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

    今回はScrum Fest Sapporo特別編として
    1.コロナ禍によって全社リモートワークになり発生したメンバー間のコミュニケーションの減少という課題とそれを解決するために行っていること
    2.Menlo Innovations の現在の状況
    についてもお話したいと思います。

    https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Ayumi HOSOZAWA / Toshiharu Akimoto - プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ

    30 Mins
    Talk
    Advanced

    なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。

    実行委員やスタッフで参加される方、共同登壇者に名前を連ねませんか?2-3人でできればと思います。実行委員で東京のスタッフをされた方にも声掛けしたいです。

  • Ikuo Suyama
    keyboard_arrow_down

    Ikuo Suyama - 続・見積りしないスクラム / #NoEstimates Scrum Season2

    Ikuo Suyama
    Ikuo Suyama
    Engineer
    CyberAgent
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Advanced

    はじめに

    本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

    見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
    本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
    見積りをやめてから起こった問題やその対処についてもご紹介します。

    また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
    以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
    この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

    Introduction

    本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
    アジャイル開発における見積りについては「アジャイルな見積りと計画づくり(AEP)」という素晴らしい書籍でその有用性や有効な実践方法が示されており、私自身もその有用性について同意しています。

    しかしながら、見積りには負の側面があることもまた事実であるように思われます。
    RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

    そもそも、なぜ見積りが必要なのでしょうか?

    そして、本当に必要なものは見積りなのでしょうか。

    この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか?」という仮説にたどり着きました。
    それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
    以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

    この私達のプロセスでは、モブプログラミングが鍵となっています。

    本セッションでは、私達がどのように見積りをせず開発をしているのか、その方法論を紹介するとともに、
    見積りをやめたチームの事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

    見積りの負の側面と価値

    見積りの負の側面について、私達の考えをまとめます。
    私達が考える見積りの負の側面は、以下の「3M」に集約されます。

    • 数値化による「コミット圧力」… 納期の「ムリ」
    • 数値化による「仕事量の最大化」 … 仕事の「ムダ」
    • 数値化による「正確であるという錯覚」 … 精度の「ムラ」

    そしてこれらは、見積りを「数値化すること」により発生すると考えています。

    もちろん、見積りは負の側面ばかりではありません。
    見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

    見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
    計画づくりとは価値の探求なのだ。
    – アジャイルな見積りと計画づくり

    見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
    見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

    これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

    見積りの負の側面の根源である「数値化」を行わず、
    見積りから取り出したい「価値」を抽出する手法

    と定義づけています。

    スクラムと見積り

    私達はスクラムを実践しています。

    見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
    見積りをやめて以来、ずっと問い続けてきました。

    スクラムガイドには「見積り」という言葉が9回登場します。
    それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

    • リリース計画づくり … PBIの優先順位付け
    • スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
    • 進捗管理 … 残作業を確認し、計画を更新する

    見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
    これが私達のたどり着いた答えです。

    我々は、以下の方法でこの意思決定を行っています。

    • 優先順位付け / バックログリファインメント
      • PBIのサイジング … 直近のPBIを 1スプリント以下のサイズ に調整
      • C3D(Cost of Delay Divided by Duration)
    • キャパシティ / スプリントプランニング
      • PBIのスループット
      • スプリントゴール
    • 進捗管理 / デイリースクラム
      • SBIのスループット
      • モンテカルロ法 … 過去データからの ‘予測’
    • スプリント(開発作業)
      • モブプロ
        • WIP制限 … 安定性・予測可能性の向上

    「見積しない」 開発と現実

    このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
    通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

    • 「見積りしない」の始め方
      • どのように上司を、ビジネスを巻き込むのか?
    • 「見積りしない」計画づくり
      • どのように先の見通しを立てるのか?
    • 「見積りしない」開発の課題
      • 見積りをやめてから、チームに降りかかる課題と対応
    • 「見積りしない」で納期を守る
      • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには?

    まとめ

    Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
    見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

    私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

    AEPから10年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念なのかもしれません。
    我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - Dammit Jim, I’m an Agile Coach, not a Doctor!

    50 Mins
    Talk
    Beginner

    Just what exactly does an Agile Coach do? Coaches may vary in their response to this question. I would like to think that most Agile Coaches, with some variation, would be fairly consistent in how we perceive our role. However, some companies or orgs or people probably interpret the role of the Agile Coach in ways that coaches never intended.

    Let’s explore some of the things that Agile Coaches have been asked to do! Are these antipatterns? Doing what needs to be done? This session will delve into the topic of the role of the Agile Coach and highlight potential challenges and possible solutions.

  • Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    75 Mins
    Workshop
    Beginner

    昨年のRSGT2019などでも好評だった、心理的安全性ゲームを体験するワークショップです。

    • 心理的安全とは、気兼ねなく話せると全員が信じている状態である
    • 心理的安全がないと組織やチームとしての学びや成長が得られない
    • 心理的安全がある状態で困難な仕事に取り組んで初めて効果が上がる。ぬるま湯や仲良ししクラブが好ましいわけではない
    • 心理的安全を高めるコミュニケーションのやり方を自分たちで発見する

    こうしたことを、ゲームを遊び、ふりかえりをし、解説を聞きながら理解していきます。ゲームは簡単に遊べ、時間も短く、自分の現場でやってみることもできます。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Takahiro Kaneyama - #ふりかえりam 出張版 in 札幌

    50 Mins
    Talk
    Intermediate

    Podcast : ふりかえりam の出張収録です。

    #ふりかえりam は、ふりかえりの手法の紹介や、ふりかえりの悩みの解消などを行いながら、ふりかえりの楽しさ、奥深さを色んな人に届けるためのPodcastです。

    「出張版 #ふりかえりam」では、その場でリスナー(参加者)の皆様から「紹介してほしい手法」「相談したい悩み」を募集しながら、参加者たちと一緒に1つのセッションを作っていきます。

  • Sally Sloley
    Sally Sloley
    Agile Coach
    Sally Sloley
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    You are a Scrum Master, but you find yourself in between jobs. You begin your search. How do you choose the company that will be a great fit for you? How do you know which company will understand and respect your specific skill set? This talk is a fresh way to look at the companies that may be trying to hire for a role they don’t understand and don’t want to pay for. This talk with raise the red flags you need to understand before you go in for an interview.

  • Keita Watanabe
    keyboard_arrow_down

    Keita Watanabe / Kazuki Mori - チームビルディングワークショップ

    75 Mins
    Workshop
    Beginner

    最近チームで笑えていますか?

    プロジェクトが始まってからチームビルディングを全くせずにいきなり開発が始まって、チームのコミュニケーションがうまく取れない。チームに新しいメンバーが入ったものの、誰も相手をせず、悲しい目をしてこちらを見ている。 そんな現場、ありませんか?


    このワークショップでは、忙しい中でもできる、よいチームを作り上げるための様々な手法を体験できます。 こんな人におすすめです

    • いいチームを作りたい人
    • チームのコミュニケーションがうまくとれていないともやもやしている人
    • どうやってチームをよくすればよいかわからない人

    ワークショップの中で、チームビルディングのノウハウを知り、実際の現場に戻ってから使える様々なアクティビティを実践します。

    添付したスライドはXP祭り2019にて開催したものです。

    こちらの拡張版を行います。

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima - 【特別編】総売り上げ35,400円だったPOが挽回するためにやったこと

    20 Mins
    Talk
    Intermediate

    永和システムマネジメントはソフトウェアの受託開発を生業にしていて、私もその最前線で25年やってきました。 そんな私が企画し、プロダクトオーナーとして関わった自社Webサービスが、数か月前にひっそりと終了しました。

    その後、ビジネスのオーナーがすべきことは何なんだろう?個人と組織のより良い関係性は?といったことを徹底的に考えて行動を改善し、結果的に「Agile Studio Fukui」というアジャイル専門組織のオーナーへとピボットしました。

    その過程では、RSGT2020でお話させてもらったようなメンタルモデルの変革も行いましたが、もちろん、それだけではありません。今回の【特別編】では、挽回に向けて取った戦略と具体的な行動、またそれらに影響を与えてくれた考え方についてお話をさせてください。

  • Hiroki Hachisuka
    keyboard_arrow_down

    Hiroki Hachisuka - 話題の「価値観ババ抜き」をやってみよう!

    Hiroki Hachisuka
    Hiroki Hachisuka
    parallel PdM
    -
    schedule 1 year ago
    Sold Out!
    75 Mins
    Workshop
    Beginner

    近年、類似品が出回るほど、話題となっている「価値観ババ抜き」。

    チームにおいてのチームビルディングの観点で多くの方法がとられていると思います。特段スクラムにおけるチームには継続してプロダクトならびにプロジェクトに立ち向かう必要があり、そのチーム内の本質を理解することで、残念な衝突や顔色を伺っているだけの誤った心理的安全性の担保を回避できます。

    その要素の一つとして各人がもともと持っている「価値観」にフォーカスして向き合う手法としてご紹介できればと思っています。

    特にチームが組成した一番最初にやることをお勧めしています。

    普段は有料でのワークショップが義務付けられているこのワークショップをエンジニア、Agile界隈に広めた認定インストラクターの私がご提供します。

    価値観ババ抜きとは

    本来の自分を発見するカードワーク、それが「価値観ババ抜き」です。

    どんな人でも時に自分の人生や自分自身に迷いを感じたり、悩んだり、自信や元気をなくすことがあります。
    そんな時、「本来の自分」を、より深くわかっていたならば、そこに立ち返ることで、迷いや悩みを乗り越え、自信や元気を取り戻すことができるのではないでしょうか?
    私たちは、本来の自分を発見するための重要な要素が「価値観」ではないか?と考えています。

    価値観ババ抜きは、子供の頃に誰もが遊んだトランプゲームのババ抜きをモチーフとし、お互いのカードを取ったり・取られたり・場(フィールド)に捨てたり・拾ったりを繰り返すことにより、自分の価値観に触れてもらい、見える化するカードワークです。

    本来の自分を発見することで、自分自身が楽になり、もっと自分を好きになり、より豊かな人生を歩んでいただけるツール、それが価値観ババ抜きです。

    http://myvaluecard.com/?page_id=22 より

  • Etsuo Yamada
    keyboard_arrow_down

    Etsuo Yamada / Takahiro Hisasue - どのアジャイル開発チームでも起こりえる課題を事例を通して学ぼう!

    50 Mins
    Talk
    Beginner

    「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」
    「このエピソードは、どこでも起きうる話なのだろうか?」
    「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか?」

    事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか?

    レッドハットには、現場を支援しているアジャイルコーチが複数人います。このセッションでは、同じ会社だから話せる“場”のなかで、アジャイルコーチ同士で深く共有した事例を通し、チームの成長に伴い起きる課題について、実際に現場で起きた内容とどの現場でも共通でチームにみられる事象を紐づけて話せたらと思います。

    今、現場で起きている課題の先に光があるのだろうか?そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。

    ※本セッションは、「アジャイルチーム成長の過程ってどんな感じ?(20min)」と「アジャイル開発導入事例から分る組織・チーム・個人の課題(20min)」を1つにまとめて再構成するものになります。

help