私たちは約3年に渡りスクラムチームによる開発を行い、その中でスクラムチームの”生産性”の向上が自分たちの出来る事業貢献と考え改善を繰り返してきました。

しかしある時、場合によっては「生産性!=事業KPI」である事に気がつきました。

チームとしてモチベーションを維持しつつ、事業にインパクトを与える方法になる可能性を感じていたモブプログラミングを導入しました。

導入するにあたりぶつかった壁、その突破方法、そして成果についてお話ができればと思います

 
 

Outline/Structure of the Talk

私たちについて

私たちは1スプリント1週間で約3年、120スプリントを継続スクラムチームです。

その中でスクラムチームのKPIとしては、、生産性の向上を目指し改善を繰り返してきました。

しかし、開発の生産性があがっても外的要因により事業KPIへの貢献ができないケースがあるジレンマに悩んでいました。

その課題解決の手段としてモブプログラミングの導入を決めました。

私たちの抱えていた課題とモブプログラミング導入障壁、その解決方法についてお話します。

課題

  • デバッグ・バグ対応などの外部に流れるコストを抑制したい
  • 人により技術的、プロダクト仕様的な知識にばらつきがある
  • モチベーション維持・向上の為に新たなチャレンジを行いたい

モブプログラミングの導入障壁

  • 実装した成果物のマージやドライバー交代のコストが大きい
  • モブプログラミングを実施する物理的な場所の問題
  • スクラムの中で実施するメリット・デメリット

導入障壁の解決方法

  • モブプログラミング用の開発環境の用意
  • 個人の開発環境(エディタなど)を利用できるよう、Dockerによる環境構築
  • 会議室、個人のデスク、デスクトップシェアなど画面共有方法の模索

Learning Outcome

実際にモブプログラミングを導入による成果と、無くなったもの・増えたものについてお話します。

成果

  • バグ件数、デバッグ費用の大幅な削減
  • 日々の共同作業により知識レベル(技術・仕様)の標準化
  • 新たな試みから成果に繋がった事がチームのモチベーション向上に寄与

モブプログラミングを実施して、無くなったもの増えたもの

無くなったもの
  • 個人への依存
  • レビューなどの同期コスト
  • 過度な残業
  • バグ削減
  • セレモニーの削減
増えたもの
  • 技術力
  • 共通体験
  • 疲労

Target Audience

チームが抱える課題を分析し、その解決手段を模索することができる方にお勧めします。

schedule Submitted 10 months ago

  • Arissa Nakamura
    keyboard_arrow_down

    Arissa Nakamura - プランニング会議は実験室 !チームと顧客に支えられるスクラムマスターの日々の試み

    Arissa Nakamura
    Arissa Nakamura
    Scrum Master
    CI&T
    schedule 11 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate


    CI&Tに入社して4年目、スクラムマスターになって1年半、今までは教えられた通りにプロセスを回していました。
    しかし、プロセスは私たちを目的地までたどり着かせるツールであり、全てを解決してくれるわけではありません。

    プランニングではいつもスプリントバックログを細かいタスクに分けて、それらを時間で見積もっていました。
    その見積もりを時間ではなく、日にち単位で見積もったらどうなるのか?
    それについて考えて、お客様とより良い関係を築けるように、チームと新しい方法に挑戦してみました。

    新しいことに挑戦させてくれる会社、一緒についてきてくれるチーム、その経験について話したいと思っています。


    It has been 4 years since I joined CI&T, and 1 year and half since I became a Scrum Master.
    When I joined, I learned CI&T process and all these years I've been running it exactly the way I was taught.
    Along the time, I also learned that the processes exist to lead us to a certain Goal, they are not a magical solution to all our problems.

    On our planning, we used to split the Sprint Backlog into smaller tasks and estimate every one of them in hours. However, what would happen if we changed the estimation from hours to days?
    This question was made to me when I was looking for a way to improve the team relationship with the customer. Not accurate estimations was one of our struggles at the time.
    Finally, I decided to talk with my team and make an experiment: try a new methodology with my team that could also help us to get more trust from the client.

    In this short talk, I'd like to share my experience of new trials, learnings with my team members and how CI&T supported us on this trial.

  • Kazuyoshi Takahashi
    keyboard_arrow_down

    Kazuyoshi Takahashi - アジャイルコーチとVPoE、あるいはEMの間にあるもの

    20 Mins
    Talk
    Executive

    10年前から5年前まで、アジャイルコーチとして2,000人以上の開発組織を抱える企業のアジャイルトランスフォーメーションに挑戦していました。
    現在はその立場を離れ、事業会社のVPoEとして開発組織の運営をしています。

    アジャイルコーチとVPoE、両方の経験からチームを見る視点にどのような違いがあるのか、アジャイルコーチの先にどのようなキャリアがあるのか、個人的な経験を交えながらお話します。

    RSGT2020 Closing Keynote「NEXT→ACTION」の後日談でもあります。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Takahiro Kaneyama - ふりかえり手法のおもちゃばこ

    45 Mins
    Panel
    Intermediate

    ふりかえり/スプリントレトロスペクティブで、みなさんはどんな手法を使っていますか?

    「KPT・YWT・Fun/Done/Learn あたりは試してみたものの、他の手法は知らない」という人も多いはず。

    色々な手法を試してみると、「あぁ、ふりかえりってこういうものなのね」とあらためて見えてくるものがあるんです。

    だから、色んな手法を試してみてほしい!楽しんでほしい!

    そんな想いで、このセッションを実施します。

     

    このセッションでは、トコトンHowを追求します。

    目的の話は一切しません(目的の話は関連リンクをご参照ください)

    とにかく色んな手法を、手法の進め方、実施イメージ、ポイントなどに絞ってお話します。

    1手法1分~2分くらいで、とにかくたくさん、面白い手法を話します。

    メジャーなものからマイナーなものまで、色々話したいと思います。

    きっと、「あ!これ楽しそう!私もやってみよう!」という手法が見つかるはずです。

     

    話せるとよいなと考えている手法

    • DPA
    • 3Dots
    • 連想ゲーム
    • Timeline
    • Story of a Story
    • 象、死んだ魚、嘔吐
    • 斜に構える/構えないを切り替える
    • Starfish / Small Starfish
    • Following up on Action Items
    • Celebration Grid
    • 質問の輪
    • Sailboat / 熱気球 / スピードカー / ロケット
    • ORID
    • 4Ls
    • Repeat / Avoid
    • Effort & Pain
    • SMART Goals
    • 360度感謝
    • Hapiness Door

    このセッションは、参加者との双方向で作り上げていきます。

    KANEが参加者からのコメントを拾い、森が解説する。

    気になる手法を、この場で明らかにし、楽しいふりかえりを作り上げていきましょう!

  • Rie Chonan
    keyboard_arrow_down

    Rie Chonan / Toshiharu Akimoto - 本当に大切なものは余白から生み出される。ゆるい1on1のススメ

    45 Mins
    Talk
    Beginner
    • コーチやSMは特に横の繋がりをうまく作らないと知識の幅や、学習の幅が狭まりませんか?また悩み事やこんな時にどうしたらいいの?みたいな具体的な話も、オープンな相談会ではしにくいことがあると思います。
    • 一方で、勉強会などのイベントだと自分の興味範囲を必ずしも話題にできるとは限らず、その時々の状況に応じたトピックを話す場合が多いのではないでしょうか?
    • そんな人たちに、このゆるい1on1を提案し、ゆるい紐帯(つながり)だからこその新しい気付きやアイディアの源泉となっている事例をご紹介します。
    • この考え方はふりかえりやチーム内での対話にも有効です。
  • Yosuke Matsuura
    keyboard_arrow_down

    Yosuke Matsuura / Ken Matsumoto / Yasunobu Kawaguchi - アジャイル戦略論 「チーム作りの巻」~すべての基礎はチーム作りにあり。

    45 Mins
    Talk
    Intermediate

    「ボトムアップでのアジャイルチームづくりは、どうしたらよいか?」
    「アジャイルチームを作ったものの、なかなかその先に進まない」
    「顧客要望やトップダウン指示で、アジャイルチームを早急に作り成果を求められているが何から始めたらよいか、わからない」
    こうしたご質問を数多くいただくようになりました。日本企業の経営層から開発エンジニアまで、みんな悩んでいるみたいです。

    みなさんご存じの通り、アジャイルにおけるマネジメントの基礎は、チームにあります。チームがなければ、ベロシティも測れないし、見積もりもできないし、デリバリーできません。しかし、いまだに、作るものが決まって、予算が取れてから人をかき集めるプロジェクトが後を絶ちません。どうやって調達・開発するのかが決まっていないのに、なぜか金額や期間は決まってしまう。

    まあ日本人、子供のころからチームチーム刷り込まれてますし、集まれば仲良くやることには長けてます。なんとかしますよ。大人ですし。

    「うちの会社にいる人間はまじめな奴が多いから、
     チームというのは勝手に集まればできるもので、
     まあ、よいチームを作るためにワークショップでもして、親睦を深めたらいい」
    ....などと、簡単に思っているマネージャーも結構多いのではないかと思います。

    ち・がーーーーーーう。

    そんな風にしたって、簡単にはうまくいかないこと、みんな体験してますよね?
    小学校の掃除の班でケンカが絶えない。遠足のグループ活動が楽しくない。
    あいつの言うことが納得できない。一人でやった方が仕事が早い。
    特定の人が仕事のほとんどを背負って周りは動けてない。
    うまくできない人がいるけど十分に教える余裕がない。

    私たちのチーム作りは失敗の連続。
    でも仕方ない。人間関係って難しいから。
    私一人が我慢すればよいのだ。
    ...いつもそうやって、うまくいかないことに蓋をして、めんどくさいことを先送りしようとします。

    じゃあ、どうやってチームを作るのか?
    本セッションでは、ここに答えていこうと思います。

    大企業から中小企業まで経験を持つ、アジャイルコーチ三人衆が、それぞれの経験から話をしていきます。
    チーム作りの各段階で、どんなことを考えながら作っていくのか、参考になる話もならない話もあると思いますが、
    参考になるところだけ持って帰っていただければと思います。


    チーム作りのプロセス

    1. 一人目の仲間を作る
    2. 話し合いながらアウトプットする
    3. ものの置き場を確保する
    4. 成果をアピールする
    5. やったことをふりかえる
    6. 技術的負債を解消する

     

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - [Online Interpretation] 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Akihiro Kosako
    keyboard_arrow_down

    Akihiro Kosako / Hiroki Noguchi / Masataka Mizuno - 「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます

    45 Mins
    Panel
    Intermediate

    大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が刊行されもうすぐ2年が経ちます。導入事例が少しずつ広まってきたものの、本だけ・成功事例の話だけを元に自分の組織で大規模スクラムを導入していくのはまだまだ難しいのではないでしょうか?

    Rettyでは2019年10月に全社でLeSSを導入・推進することを決定し、1年をかけてtoC向けのWeb/アプリ開発、toB向けWeb開発が合流しました。導入過程で問題もありましたが、一つずつ改善を行い、導入して効果があったと言える程に成功を収めています。

    本セッションでは大規模スクラム本の翻訳者の水野さんをモデレーターに迎え、Product Ownerを務めるプロダクト部門担当執行役員 野口、VPoEを務めるエンジニアリング部門担当執行役員 小迫の2名が、成功事例の紹介だけでなく、導入過程の悩みや苦しみ、失敗事例なども包み隠さずお話しします。皆様の大規模スクラムの導入に少しでも参考になる情報が提供できればと考えております

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - スクラムにおける「完成」とはなにか?

    20 Mins
    Talk
    Intermediate

    スクラムガイドには「完成」という単語が36回、「完成の定義」が12回登場します(弊社調べ)。ほかの代表的な単語を調べてみると、スプリントバックログは16回、スプリントレトロスペクティブは12回です。
    つまり、スクラムにおいて「完成」は非常に重要な意味を持つことは明らかです。

    しかし、「完成」に対する認識がスクラムチームのなかで違ったり、組織での品質の基準をまったく考慮せずに開発を進めていった結果、リリース直前に品質上の大きな問題が起こったといった話もよく聞きます。

    sgt01.jpeg

    ネット上の記事を調べても、「完成」が重要な意味を持つ割に「完成」とは何なのか、どのように「完成」を定義し、どうやって「それを守っていくのか」というノウハウはあまり出回っていません(と認識しています。プロダクトバックログの話なんかは山のように見かけるんですが)。

    そこで、本セッションでは、「完成の定義」をできる限り深堀りし、今後みなさまが「完成」を守っていく上でのヒントを共有します。

  • Minoru Yokomichi
    keyboard_arrow_down

    Minoru Yokomichi - アジャイルつまみ食いしたい人向けの「アジャイルから学べること(私が学んだこと)」〜アジャイルに興味をもってもらう方法を添えて

    20 Mins
    Talk
    Beginner

    私が最初に本格的にアジャイルと出会ったのは 2012年の Developer Summit でした。その後、書籍や記事、アジャイルコミュニティにいる実践者、研修トレーナー、同僚などから様々なことを学びました。

    その本質が理解できていた(る)かはさておいても、その中には、次の日から意識や行動が変容するような、私の中でそれまでの考え方が大きくかわった考え方もたくさんありました。

    ここ数年、「アジャイル」という言葉にはこだわることなく、これらのアジャイルから学んだことを、部分的であったとしても、様々なロールの人と働く中で実践しその考え方をおすそ分けしてきました。それがアジャイルから学んだことであることを明かすことで、結果としてアジャイルに興味を持って頂くシーンもとても増えてきました

    このセッションでは、私自身が初学者だった頃にさかのぼって、今でも印象深いことを広く浅くごった煮駆け足でお伝えできればとおもいます。(なるべくその後その知識を深められるように、参照元を紹介する予定です)

    さまざまなロールの方が、その中から一つでもひっかかり、つまみ食いでも良いのでアジャイルに興味を持つきっかけになればと思います。
    または、アジャイル実践者の方は、まわりでアジャイルのファンを増やす活動のヒントや材料にしていただければと思います。

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - A ScrumMaster Way - #ScrumMasterWay の歩き方

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

    スクラムを成功させるためには、スクラムマスターの活躍が欠かせません。自身がサーバントリーダーとしてチームを支援する立場でありながら、スクラムマスターも日々の実践を通じて成長することが求められます。

    キーノートスピーカーのZuzana 'Zuzi' Šochováが著書「The Great ScrumMaster(日本語版: SCRUMMASTER THE BOOK)」の中で提唱している #ScrumMasterWay は、スクラムマスターの成長過程の理解の助けになる概念です。

    本セッションでは #ScrumMasterWay の各レベルを参照しながら、実際に私がスクラムマスターとして取り組んできた活動をふりかえり、スクラムマスターの成長について考えたいと思います。

  • Koki Shimizu
    keyboard_arrow_down

    Koki Shimizu - Six trumps for Scrum with Terrific Tips -スクラムのセレモニーを最大限楽しくする原則とその実践のヒント-

    Koki Shimizu
    Koki Shimizu
    Scrum Master
    N/A
    schedule 11 months ago
    Sold Out!
    100 Mins
    Workshop
    Intermediate

    スクラムのセレモニー(イベント)が長い、退屈だ、誰か一人だけ話している、お通夜・・・
    なんてことありませんか?

    学習熱心なスクラムマスターに相談しましょう!
    ・・・でもスクラムマスターも困っています。

    スクラムのセレモニーを効率的に効果的に楽しく、みんなの学習効果を最大化できる方法なんてどこにも載ってないんです!

    そこで、Six trumpsをご紹介します。

    この原則を元にスクラムのセレモニーのみならず、ワークショップ、カンファレンス、エグゼクティブミーティング、全社会議、株主総会、国会審議をアレンジしてみてください!!
    ものすごい良いミーティングになると思います!
    人が集まるところにおいて、人と人との関係性、学習効果を高めるために、すべてに応用できます!

    このワークショップは、
    Six trumpsの概要をお伝えし、スクラムのセレモニーにどのように応用するかを参加者同士深くディスカッションする形式
    となります。

    加えて、清水自身がScrumにSix Trumpsをどのように適応しているかお伝えします!

  • Daisuke Watanabe
    keyboard_arrow_down

    Daisuke Watanabe - 実践知リーダーシップ / 新型コロナウイルス感染症まとめ における非秩序系ソフトウェアデベロップメント

    20 Mins
    Talk
    Beginner

    ヤフーは、新型コロナウイルス感染拡大に伴う社会課題に対し、さまざまな取り組みをおこなっています。

    今回はその中の一つ「新型コロナウイルス感染症まとめ」に関して、私たちヤフーのメディア開発チームがどのようにしてフルリモートの環境下で信頼できる情報を集約し迅速に情報提供を行っているかについてプロダクト開発事例を紹介します。

    そして、私たちの取り組みを通じて「複雑で不確実な状況におかれたソフトウェア開発チームが、どうすれば世界を変えていく実践に移行していけるか」、それを実現するための「実践知リーダーシップ」の具体例についてお話しします。

  • FORTE
    keyboard_arrow_down

    FORTE - 一人からでもできる越境していくモブプロ・ワーク

    FORTE
    FORTE
    Engneer
    mazrica inc.
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    モブプログラミング(以下モブプロ)のやりかたや効果についてはよく聞くようになりましたが、
    実際の開発現場にどうやって導入したか?
    とくに「お試し」だけでなく、どうやってプロダクトコードをモブプロで書いたのか?について聞くことは多くありません。
    またモブの対象をプログラミングだけでなくワークに広げることによって、
    ITエンジニアが一人しか所属していない、いわゆる一人チームでもモブワークを実践することができました。
    さらにそれを自チーム以外にも越境して伝えることができました。

    このセッションでは実際の開発現場でいかにモブプロを導入していったかの工夫の紹介、
    ならびにモブがプログラミング以外の価値を見出し、チームを越境していったかの事例紹介です。

    以下についてお伝えします。

    ・モブプロ、モブワークについて
    ・開発現場への導入にあたってのポイント
    ・実際の開発現場での効果
    ・一人チームでモブワークを行う
    ・越境するモブワーク

  • Asumi Ametani
    keyboard_arrow_down

    Asumi Ametani / Takamitsu Nakamura - スクラム導入支援やコーチ業の成果をメトリクスで確認しようとした話

    20 Mins
    Talk
    Beginner

    ★スクラムの導入支援・コーチをすることで成果が上がっているということをメトリクスで確認できるか??

    2019年10月から、組織内でスクラムを促進(支援)する活動が始まりました。

    組織の中で導入支援やコーチをしている中で、成果を見える形で確認したいというマネジメントからの期待がありました。(マネジメントにとって導入支援やコーチをつけることによる成果=組織のアジリティ向上)

    スクラム支援活動が組織のアジリティ向上に寄与していることをどうやって測れるのか?

    どんな風にメトリクス化出来れば導入支援やコーチの活動を評価できるのか?

    未知だけど、小さく動きながらメトリクス化できるようにやってみた、そんな私たちの実験結果をお話しします。

  • Takeshi Kaise
    keyboard_arrow_down

    Takeshi Kaise / Keita Sugawara - 戦略人事チームにおけるスクラムの戦略的活用と成長

    45 Mins
    Panel
    Intermediate

    DeNAの戦略人事を牽引するHRビジネスパートーナー(HRBP)組織では、数年前からスクラムを導入しています。プロダクトオーナー、アジャイルコーチそれぞれの視点から、非開発組織でスクラムを活用して得られた学びや要諦を共有します。

  • Akihito Enomoto
    keyboard_arrow_down

    Akihito Enomoto / Shigehisa Saito / Shun Kamiya - ラボ組織 〜イノベーションは実験からうまれる

    45 Mins
    Talk
    Executive

    プロダクトと組織を実験的に作りあげて来たGrooveXが如何にイノベーティブな環境を作ってきたのかを人事担当が中の人の視点で、エスノグラファーが外部から分析をし、組織と併走してきたアジャイルコーチがそれぞれの視点で共有します。

  • Toshiyuki Ohtomo
    keyboard_arrow_down

    Toshiyuki Ohtomo / Ayumi HOSOZAWA / Etsuo Yamada / KazuhideInano / Ken Matsumoto / Narichika Kajihara / Toshiharu Akimoto / Tomonari Nakamura ( ikikko ) / Yasunobu Kawaguchi - SCRUMMASTER THE BOOKの訳者陣とお送りする、優れたスクラムマスターになるためのエクササイズ

    100 Mins
    Workshop
    Intermediate

    SCRUMMASTER THE BOOKの中には、たくさんのエクササイズが載っています。

    書籍に載っているエクササイズってなかなか一人ではできなかったりしますよね?

    でも実際に、現場でエクササイズを導入する前には、試しておきたいですよね。

    そんな、あなたにSCRUMMASTER THE BOOKの訳者陣と一緒にエクササイズを試してみませんか?

     

     

  • 20 Mins
    Talk
    Beginner

    私達は、約1年前より新規プロダクトの開発を行っているスクラムチームです。

    プロダクトの最初のリリースを目前に控えたある日、在宅勤務による開発を取り組む必要に迫られました。

    セレモニーはどうするのか...スクラムを継続できるのか...

    様々な不安がよぎりましたが、私達はスクラムを継続する選択をしました。

    物理的に距離を乗り越えスクラムを継続した中での成果や気付き、そして失敗をお伝えできればと思います。

  • YUMA ISHIKAWA
    keyboard_arrow_down

    YUMA ISHIKAWA / Nakato Arase - 初めてプロダクトオーナーを担当したら大規模アジャイル開発だった件

    45 Mins
    Talk
    Beginner

    プロダクトオーナーを担っててこんな思いしたことありませんか?
    ・権限が委譲されず意思決定できない
    ・意思決定の判断基準が決められない
    ・ステークホルダーが多すぎて合意できない
    ・ステークホルダーがアジャイル開発を理解しようとしない
    ・スクラムチームとのコミュニケーションがうまくいかない
    ・プロダクトオーナーが呼ばれるミーティング多すぎる
    まさに私がそうでした。
    ヤフーとイーブックジャパンを統合しwebサイトのリニューアルを大規模アジャイル開発で実施し2017年に掲げた2020年に取扱高200億円の目標を達成するまでの日々の奮闘をお話します。 

help