デイリースクラムいらなくなくなくなーい!?
「え、それデイリースクラムで言ってよ。」
「いやいや、その話は、デイリースクラムで話さないでよ。」
気づけば、いつのまにかこんな状態に。。。私は開発者の一人として、携わるこのチームの状況をなんとかせねばと思い始めた。
デイリースクラムとは、
スクラムのイベントの中でも一番多く開催されるイベント。
毎日やっているからこそ、慣れ親しんだイベント。
いつもの流れ作業でこなしがちなイベント。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
~スクラムガイド2020より~
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
現実を見てみると、
・進捗報告だけの場
・ファシリテーターと参加メンバの1対Nのコミュニケーションパス
・課題についてどうするかを議論しだす
・今じゃない話題が出てくる
・今いってほしい話題が出てこない
・15分じゃ収まらない
こんなデイリースクラムは、いるのか?いらないのか?どっちなんだ!?
このセッションでは、形骸化してきたデイリースクラムに対しての、私達チームの課題や悩み、それらを生み出していた根本原因、そして、課題解決と改善に向けた取り組みについて、お話します。
「デイリースクラムが形骸化する」「デイリースクラムいるの?」「デイリースクラムで何すればいいのかわからん」という同じ悩みを抱える方々のご参考になれば幸いです。
Outline/Structure of the Talk
- デイリースクラムとは?
- なぜ形骸化してしまうのか?
- デイリースクラムいるの・いらないの
- 背後にあった根本原因
- 今のチームにあったデイリースクラムを本気出して考えてみた
- デイリースクラムのその先へ
Learning Outcome
- デイリースクラムを形骸化させないためのヒント
- デイリースクラムでわかるチームの現状把握
- 必要性を腹落ちするためには
- タイムボックスの守り方
- チーミング
Target Audience
「デイリースクラムが形骸化する」「デイリースクラムいるの?」「デイリースクラムで何すればいいのかわからん」という方々
Prerequisites for Attendees
特になし
Links
Scrum Fest Osaka2022での発表資料
schedule Submitted 8 months ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Satoshi Harada - Whyから始めよう!スクラムチームが力強く前に進むための「なぜやるのか」を考える
45 Mins
Talk
Beginner
皆様は、スクラムチームが走り始めるときにまずは何から始めますか?
プロダクトバックログを作る?
エレベーターピッチを作る?
インセプションデッキを作る?
とりあえず開発環境作ってみる?
えーい!そんな暇はない!開発着手だ!!!
あるあるーと思った皆様。
そんな皆様に私がおすすめしたいのは、スクラムチームのメンバーは今なぜここに集まっているのか?を問うことです。
ゴールデン・サークル理論という言葉を聞いたことはありますか?
TEDの人気プレゼンテーション「優れたリーダーはどうやって行動を促すか」でサイモン・シネックが解説した理論です。
端的に言うと、人が真に突き動かされるのはWhat(何をやるのか)ではなくWhy(なぜやるのか)であるという内容です。
詳細はTEDの動画を見ていただきたいのですが、このWhy(なぜやるのか)こそ、スクラムチームが走り始めるときに最初にやるべきことなのではないかと思うのです。
実は、インセプションデッキの10の設問にも「我々はなぜここにいるのか?」という設問があるので、インセプションデッキを丁寧に作成したチームならWhy(なぜやるのか)を考える機会があるはずです。
しかし実際のところ、インセプションデッキをちゃんと作ったことがあるというチームはそれほど多くないのではないでしょうか?
インセプションデッキを作らない理由は様々ですが、そのようなことにかける時間が無いという理由が大きいのではないかと考えています。
そこで、時間が無い!という皆様にはWhyから始めることを私は提案します。
10の設問があるフルセットのインセプションデッキに比べれば、チームのWhyを決めることは時間はかかりません。
ですが、Whyを設定しないままチームが走り出すよりも、Whyがある方が間違いなくチームが力強く前に進むはずです。
このセッションでは、実際にチームのWhy / How / Whatをゴールデン・サークルに当てはめて設定した私の経験をもとに、Whyから始める際のポイント・Whyを訴求し続けるためにリーダーが取るべき行動・HowやWhatに陥りやすいケースとその対策について私の経験ベースでお話します。
このセッションを見ていただいた方に、「私もチームのWhyを考えてみよう!」と思っていただけるような内容にしたいと思います。
そして、実際にチームのWhyを設定して訴求・改善し続けることで、あなたのチームはなぜやるのかに基づいた力強い推進力を得ることができると、私は考えています。
-
keyboard_arrow_down
Ikuo Odanaka - OKRはツリーではない
45 Mins
Talk
Advanced
対話しながらチャレンジングな目標の達成に向けてドリブンしていくOKRと、検査と適応を繰り返していくスクラムチームは相性が良いものだ、と私は考えています。過去には「OKR-based Scrum Team」と題して話したこともあります。ここではOKRのツリー構造を使って組織と個人の意思をいかに伝搬させてゆくか、特に「納得」をいかに醸成していくかという点に重きを置いて話しています。
ですが、実際に自分自身がOKRを運用している現場では、OKRを採用した2年目あたりから厳密なツリー構造というものからは脱却しています。ツリー構造にすることを重視すると、どうしても間に落ちてしまう部分が生まれてしまうというのがツリー構造をみなおすきっかけでした。同時期に「クリストファー・アレグザンダーの思考の軌跡」を読んでいたことも、ツリーを脱却しセミラティス構造に向かう直接の要因だったように思います。(本プロポーザルのタイトルは同氏による「都市はツリーではない」のオマージュになっているので、インスピレーション元がアレグザンダーであることにお気づきの方もいらっしゃることと存じます)
話は変わり、5月に開催された品川アジャイルのイベント「OKRってどういうのが正解なんだろう?」において、名著「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を題材にOKRとはそもそも何なのか、ということを川口さんとたっぷり話す機会がありました。ここで衝撃を受けたのが、あらためてこの本を読み解いてみると「OKRはツリー構造だよ」なんてことは一言も書いていない、ということでした。それどころか、私が自ら切り開いたと思い込んでいた「ツリーではない構造のOKR」は、しっかりとここで提示されていたのです。なんということだ。
気を取り直して。そう、OKRの分野の名著では「ツリーだ」なんていっていないわけです。けれども多くの現場はツリー構造に向かっているように思えます。
そして「ツリー構造に落とし込むのが難しい」といった、本来悩まなくてもよい悩みを抱えてしまうことになったりする…あなたの現場はどうでしょうか。私自身、最初はツリー構造から出発しました。そこに窮屈さを感じセミラティス構造への転換を試み、メンバーからの意見をOKRに取り入れるよう工夫をし・・・今では、自己評価としてはうまくOKRと向き合うことができている、といえるくらいにはなりました。
このセッションでは私自身がどのようにツリーから脱却していったのかという話と、そもそも人はなぜツリー構造に向かってしまうのかという謎を解明する試みについて話せればなと考えています。
-
keyboard_arrow_down
Jumpei Ito / Aiz ack / Chizuru Yoshida / Hideki Takahashi / Kentaro Arakawa / Masakazu Kichima - 現場の泥臭い話を「QAマネジメント」という言葉で定義してみかわ
Jumpei ItoQA Engineer / QA ManagerWingArc1st Inc.Aiz ackSupport EngineerWingArc1st Inc.Chizuru YoshidaQA EngineerWingArc1st Inc.Hideki TakahashiSoftware EngineerWingarc1st Inc.Kentaro ArakawaSoftware EngineerWingarc1st Inc.Masakazu KichimaSoftware EngineerWingArc1st Inc.schedule 9 months ago
45 Mins
Talk
Beginner
昨年のスクラムフェス三河2021では、「新米QA部門長がアジャイルな組織作りを実践してみかわ」というタイトルで、新米マネージャーのストーリーと意気込みを発表させていただきました。
今年のスクラムフェス三河2022ではその後のマネージャーとしての取り組みについてお話ししたいと思います。
まだまだ先は長いものの、QA部門長として色々見えてきたものや、様々なことにチャレンジして、失敗して、学んだことがあります。そして、もしかしてこれがQAマネジメント?と感じるものを、ここで一旦まとめます。
(この一旦まとめてみるのがスクフェス三河の良さw)
以下のような内容を話したいです。
「ラインマネージャーとQAマネジメントは別物!?」
「突然動かなくなる3rd Party。情報集めと定期的な配信」
「自動テストにできない、定期的な手動リグレッションテストはアウトソースしよう」
「ねぇねぇ。QAにスクラムマスターいる?もちろんいるよ!」
「大変です!テストケース数が多すぎて自動テストが終わりません。。。」
「来週リリースするので出荷承認お願いしますー え?」
「POも開発エンジニアもテクニカルライターも。みんな集まれ。社内専用Janet研修」
「QAもエンジニア。QMファンネルを使って自身のキャリアをイメージしよう」
「社内チリング会でスクフェス視聴してYYしよう」
「ハイヤリング×ハイヤリング」
-
keyboard_arrow_down
Yasunobu Kawaguchi - よなよな Fortnite プレイで学んだ、チームのスウォーミングと心理的安全性
45 Mins
Talk
Beginner
「私の会社ではなかなかスクラムができないんです。上司が許してくれなくて。仲間もいません」....大丈夫です。Fortniteがあります。パソコン、Switch、PS4/PS5、XBox としっかりしたネットワークがあれば無料で参加できます。在宅ワークのために投資した自宅のワーキング環境を活かして、オンラインリアルタイムコラボレーションの世界に参加できます(注: 本セッションは、ゲームへの参加を勧誘するものではありません)。
品川アジャイルでは、モブプログラミングの勉強の一環として Fortnite を始めてみたんですが、それ以来、配信環境を強化したり、自宅ネット環境やPCを買い替え、徐々にのめりこんでしまい、一部メンバーによるよなよな Fortnite が2年以上続いています。その中で学んだスクラムやチーム開発との共通性をこちらで話したいと思います。
- スウォーミング
- 発話での状況表現
- 少人数のチームでのコラボレーション
- 自律的な参加、自己組織化
- 限られた資源を協調的に使う
- サーバントリーダーシップ
- イテレーションを通じてだんだん上手になる
- 変化する状況に対応する、変化の先を読む
- 序盤は生き残り、中盤で余力を溜め、終盤で勝利する戦術を組み立てる
- システム側に組み込まれたご褒美回路
- 世代を超えて楽しめる多様性