組織の慣習から旅立つチーム
「問題がないことが問題だ」
朝会で問題が報告されないにもかかわらずピンチな状況が生まれてしまう、皆さんはこんな経験ありませんか?
チームでは日々の仕事の中で暗黙知から醸成された慣習が出来上がっています。
私達の場合は朝会の進捗共有で「作業が予定に間に合わなさそうなら報告する」「問題を報告すれば迷惑をかけてしまうかもしれない」「言ってもいいんだろうか」という雰囲気の(形骸化した)慣習が存在していました。
こういった慣習がチームの不安要因を表明することを邪魔して来たのかもしれません。
そんな慣習から旅立ってチームは自分たちの価値観に基づき新たな慣習を獲得することはできるのか。
このセッションでは組織の慣習から脱却した小さな成功体験から学んだことをお伝えします。
Outline/Structure of the Talk
- チームの成功体験エピソード(形骸化した朝会からの脱却)
- 問いかけを少し変えると結果が変わる!?
- 成功体験はどうして続かないの?
Learning Outcome
- 異なる問いかけがもたらす、結果の違い
- 自己組織化が必要になる理由
Target Audience
組織のあり方を変えたいと思う方
Prerequisites for Attendees
- チームのリーダーの方
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yuichi Tsunematsu - もりあがるスプリントレビューをしよう
20 Mins
Talk
Intermediate
あなたのスプリントレビューは盛り上がっていますか?
アジャイル開発を始めて4年になりますが、意義のある・活気のあるスプリントレビューができることもあれば、お通夜のような・審議のような・辛いスプリントレビューをしてしまうことが今でもあります。皆で褒め合うだけでなく、皆で責め合うだけでなく、「またやりたい」と誰もが感じられるスプリントレビューを開催する秘訣はないのでしょうか。
Regional Scrum Gathering Tokyo 2020でこの悩みを共有したところ様々な方からアドバイスをいただけました。このセッションではその内容を整理し、実際に自分たちで実践した感想を加え、よりよいスプリントレビューをするための知見を共有したいと思っております。
-
keyboard_arrow_down
Kazuki Mori - さあ、楽しいふりかえりを始めよう
50 Mins
Talk
Intermediate
大事な活動である「ふりかえり」。だが、難しい活動でもある。
スクラムの重要なイベントの一つである「スプリントレトロスペクティブ/ふりかえり」。
チームを自己組織化へと導く大事なステップでもあり、スクラムの中でも一番「チームによるチームのための活動」だと言えると考えています。スクラムを始めたとき、多くの人が直面するのは、「ふりかえりがうまく機能しない」ということです。
ふりかえりが反省会のようなムードになってしまう。
チームのためのアクションが出ず、なかなかチームがまとまらない。
アクションは出たものの、なかなかカイゼンされているように思えない。
こういった悩みを持つ多くの現場を見てきました。ふりかえりは、難しい活動の一つとして考えられがちです。
時間対費用効果が出ているのか、なかなか計測がしづらいですし、効果がすぐに現れない場合もあります。
他のイベントと違い、ふりかえりがうまくいかなかったときに、「この活動は価値がないものだ」と感じ取られてしまいがちなのです。
そのまま、ふりかえりが行われなくなってしまうのは、とても悲しいことです。ふりかえりとファシリテーション
ですが、ふりかえりにはチームが成長するために大事な要素がたくさん詰まっています。
そのうちの一つが「ファシリテーション」という考え方です。進行役としての「ファシリテーション」ではなく、促す者としてのファシリテーション。
スクラムマスター一人がファシリテーターなのではなく、チーム全員がファシリテーター。
チームが「ファシリテーション」を意識したとき、あなたたちのふりかえりはきっと良い方向へと変わります。ファシリテーションというものをあなたがどうとらえるか。
そのとらえかたが変わると、きっと新しく見えてくるものがあるでしょう。COVID-19とふりかえり
COVID-19の影響を受け、チームの姿は大きく変容しました。
ふりかえりも、著しい影響を受けたイベントの一つです。
ニューノーマルな世界が形成されていく中、ふりかえりはどのような姿を見せるのでしょうか。
これまでの先人の知恵や、私たちが培ってきた経験は使えないのでしょうか?そこまで悲観することはありません。
このセッションでは、昨今のオンライン環境におけるふりかえりの新しい姿と、私たちが考えるべきこともお伝えできると思います。このセッションについて
このセッションでは、あなたがふりかえりの中で行うファシリテーションを考えるときの気付きを提供します。
COVID-19で変わったチームの姿。そして、この環境下でふりかえりにおいて変わるもの、変わらないもの。
チームの形成、そしてチームの成長。チームのグラデーション。
ふりかえりのファシリテーションと、マインドセット。「自分のチームでは今どんなことを意識しながらファシリテーションしているだろうか」
「自分のチームのふりかえりの現状はどんなものか」をイメージしながら、セッションに参加していただければ幸いです。 -
keyboard_arrow_down
Yusuke Amano - 本当に強いプロダクトを作るためのプロダクトオーナー支援のはじめかた
50 Mins
Talk
Beginner
みなさんの現場ではすでにスクラムを導入済みでしょうか。
最初は仕事が終わらない、品質が低い、改善が進まないといった問題が沢山出ていたチームも、スクラムを始めると少しずつ安定して開発ができるようになってきます。ある程度のベロシティが出て、不具合の数もそれほど多くなく、割り込みタスクも大きい問題にはならなくなるでしょう。しかし、チームは魅力的で顧客の問題を解決する本当に強いプロダクトを作ることができているでしょうか。
本当に強いプロダクトを作るためには、プロダクトオーナーの支援が欠かせません。プロダクトオーナーが不確実性と向き合い、素早い仮説検証を繰り返して、価値の高いアイデアを見つけられるようになる必要があります。開発チームはプロダクトオーナーの活動に参加・協力し、スクラムマスターはその取り組みを様々な方法で支援することができます。
このセッションでは、自分がスクラムマスター/アジャイルコーチとして複数の現場で取り組んできたプロダクトオーナー支援の活動と、そこから学んだことについて紹介したいと思います。
-
keyboard_arrow_down
Jun Yamamoto - (自称)エバッキーの愛弟子!が札幌でエンタープライズシステム開発のスクラムマスターをしてみたお話
20 Mins
Talk
Beginner
基幹系システム開発は、ウォーターフォールで着実に品質を積み重ねて行うべきもの。
そういった固定観念が社内外充満している中、
SoEな領域だけでなくSoRにもスクラムが適用されたプロジェクトメンバー約200名のエンタープライズ・アジャイルSIプロジェクトに
札幌からスクラムマスターとして参画してみた顛末をセッションで共有いたします。特段教訓めいた話に帰結するわけでもなく、発生したさまざまな出来事を通し、
札幌のエンジニア達がLeSSに近しい姿をトライ&エラーしていく
天竺への道程(現在進行形)を等身大で聞いていただければと思います。- アジャイルやスクラムも知らずに集められたメンバーの戸惑い。
- 複数拠点横断スタッフとのリモートワークによるチーミング。
- クライアントとのカルチャーギャップ。
- 自分自身含めたメンバーのマインドセットの成長。
- などなど・・・
-
keyboard_arrow_down
Tsutomu Yasui - Happy Lucky XP ― ケント・ベックに教わったこと
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.」みたいな話になってる可能性もあります。悪しからずご了承ください)
-
keyboard_arrow_down
Mizuki Kusakabe - ゼロからつくったリモートスクラムチームはスクラムに挫折し解散しました
20 Mins
Talk
Beginner
「ゼロからつくる!リモートスクラムチーム」からタイトルを変更しました。
プロポーザルを出した時点では以下のようなことをお話しするつもりでした。
小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。
会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。
その状況から、
- いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
- 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
- リモートでもチームとしてワークするために試行錯誤している話
をお伝えしたいです。
それから半年ほど経った今、このチームはすでに解散しています。目指していたマイルストンは達成できませんでした。
でも、一部メンバーによってプロジェクトは推進されています。
チームを立ち上げ、スクラムマスターとしてスクラムを実践してみたこと、スクラムに挫折したこと、チームの解散、その後のメンバーの頑張り、私たちにできたこととできなかったことを、ひとつの経験としてお話しします。
-
keyboard_arrow_down
Noriyuki Nemoto / Kohei Shoda - 紙粘土スクラムから得たアンチパターン
Noriyuki Nemotosenior engineerAgile SapporoKohei ShodaEngineerAgile Sapporoschedule 1 year ago
20 Mins
Talk
Beginner
アジャイル札幌で人気のコンテンツ「紙粘土スクラム」。
紙粘土と侮るなかれ、毎回リアルな現場のようなドラマがあります。
その中の失敗をアンチパターンとして紹介します。紙粘土スクラムに特化したアンチパターンではなく、例えば下記のような実際の現場でもあるあるのアンチパターンになっています。
アンチパターン:チャラオーナー
対象:PO
プロダクトオーナーが開発者に対してイメージトークしかしない。例えば「もっとカッコよく」「いい感じで可愛く」「品質をあげよう」など。
改善ポイント:開発者とPOで具体的な例を挙げて認識合わせをする。事前に画像でイメージを共有する。アンチパターン:妄想の暴走
対象:DEV
ステークホルダーが近くにいるのに、まったく聞かず仮定を積み上げて難しい仕様や不要なものまで作りすぎてしまう。POまで妄想に加わるとチームとして完全にアウト。
改善ポイント:仮説という認識を持って、ステークホルダーと対話する。 -
keyboard_arrow_down
YAMAKAWA, Hiroto - 学生に「チーム活動」を再認識させる!ある大学の情報系カリキュラムでの試み
20 Mins
Talk
Beginner
チームのあり方・チームでの成長の仕方が着目される昨今、IT業界を目指す若者たちも、いち早くそういったノウハウ・方法・ツールに触れ、体験的に学ぶことが肝要でしょう。
アクティブラーニングの活用などで学生が主体的・対話的な活動を求められる近年の学生達は、けれどもチームを組むとなると、ゴールにむけて役割・立場・責任を当てはめる分担的チームワークを求めがちです。
チームを形作り成長させるためのノウハウは、教育現場でも彼らに新たなチームのあり方・チームでの成長の仕方への気づきを促し、「チーム活動」を再認識させることは可能なのでしょうか?
大学教育の情報系カリキュラムにおける個別の試行事例から検討してみます。
-
keyboard_arrow_down
Tsuyoshi Maehana - 遠くにいるチームメンバーと、空間を超えて会える場を作った話
20 Mins
Talk
Beginner
遠隔のチームメンバーとのミーティングやスクラムイベント、どうしていますか?
チャット、TV会議、ホワイトボード共有ツールなどがありますが、うちのチームではどれも満足できませんでした。
バーチャルでメンバーとあって、付箋やボードを無限に広げて使える場、チームで占有できるプロジェクトルーム、欲しくないですか。
まだ、機材や制約もありますが「現実よりも便利に働ける場」を目指してバーチャルワークプレイスを作っています。
わたしたちのチームメンバー5名は、スクラムイベントを毎週そこで行っています。
少し未来の働き方を紹介させてください。
紹介動画: https://www.facebook.com/ricoh.jp/videos/808565413001238/
-
keyboard_arrow_down
Takao Oyobe - It dependsから脱却するスクラム
50 Mins
Talk
Intermediate
チーム、組織、会社、役割、契約、業種・・・
私たちの仕事にはいろんな状況があるので、つい、
「It depends(ケースバイケースだね)」
と言いたくなってしまうときがあります。しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。
こんにちは!
こんにちは、及部です。
私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。
組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。
伝えたいこと
教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。
つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ?」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。
それでは、スクラムフェス札幌大会でお会いしましょう。アディオス!
-
keyboard_arrow_down
Imai Takaaki - アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩
20 Mins
Talk
Beginner
去年、別のイベントで登壇したときの内容をアップデートしてお送りします!
社内へアジャイルを推進していく中で、いくつもの失敗や衝突がありました。
振り返ってみるとその原因は、アジャイルに対する期待値のギャップだったり、目的不明のプラクティス導入だったり、捨てきれないこれまでのやり方だったり。でもそこに「それはダメ!」「そうじゃない!」と迫っても、「”よくわからないアジャイルというもの”は随分と面倒なんだな。」と終わってしまうかもしれない。まずはアジャイルがどんなものかを正しく知ってもらうのが良いんじゃないだろうか。
そんな中で見えてきた、私の感じた「アジャイルを始めるにはこのあたりから取り組んでいくと良さそう」を紹介します。
-
keyboard_arrow_down
Yasunobu Kawaguchi / Ayumi HOSOZAWA / Toshiharu Akimoto - プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ
Yasunobu KawaguchiAgile CoachAgilergo ConsultingAyumi HOSOZAWAEngineerSelf employedToshiharu AkimotoCatalyst / Agile CoachKumu Incschedule 1 year ago
30 Mins
Talk
Advanced
なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。
実行委員やスタッフで参加される方、共同登壇者に名前を連ねませんか?2-3人でできればと思います。実行委員で東京のスタッフをされた方にも声掛けしたいです。
-
keyboard_arrow_down
Ikuo Suyama - 続・見積りしないスクラム / #NoEstimates Scrum Season2
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年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念なのかもしれません。
我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。 -
keyboard_arrow_down
kyon _mm / neno neno - 道産子が上京してからスクラムを2回はじめた話
50 Mins
Talk
Beginner
北海道でそだち上京、23歳で組織初のスクラム導入。転職してなんちゃってアジャイルだと数年たってから気付いてスクラムの再導入。どちらも期待と不安がいりまじった時間をすごしましたが、とても楽しい時間になりました。私が当時どのようにスクラムを導入したり、変化させていったのか。そしていまならどうやるのかという考察をお話します。
-
keyboard_arrow_down
Yasumasa WATANABE - ScrumMaster, 開発Teamの皆さん!Product Ownerの不安を聞いてください
20 Mins
Talk
Beginner
ScrumMasterや開発Teamの皆さん
「Product Ownerの責任は、Scrum TeamのROIを最大化なんで頑張ってください!」
「それでリターンいけるんですか!?納得感いまいちっすね」
とばっかり、Product Ownerに言ってませんか?それを言いたい気持ちは、わかりますよ。
そして、言われている意味も責任もわかってますよ。
でも、ですよ!何か、おかしくないですか?
ちょっと遠すぎやしませんか?よくよく考えてみました。
エンジニア、デザイナーの経験のあるPOやSMは多くいる。
一方で、PO経験のあるSMや開発Teamって少ない。
だからこそ、みんなPOことがわからないから、冒頭のようなコミュニケーションが発生したり、
また、冒頭のようなコミュニケーションで留まったりすることが多いのではないでしょうか。
(本当に多いかどうかは、あくまで仮説です)そこで、Product Backlogのネタを作っていくために、どんなことを考えたり、
いろいろなことを心配しながら、仕事に取り組んでいる日々の心の声を
皆さんと共有してみようと思います。僕の発表を踏み台にして、POの実務的な意味での理解を少しでも増していただいて、
より素晴らしいScrumチームが世に増えるための参考になればと願っています。 -
keyboard_arrow_down
Etsuo Yamada / Takahiro Hisasue - どのアジャイル開発チームでも起こりえる課題を事例を通して学ぼう!
50 Mins
Talk
Beginner
「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」
「このエピソードは、どこでも起きうる話なのだろうか?」
「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか?」事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか?
レッドハットには、現場を支援しているアジャイルコーチが複数人います。このセッションでは、同じ会社だから話せる“場”のなかで、アジャイルコーチ同士で深く共有した事例を通し、チームの成長に伴い起きる課題について、実際に現場で起きた内容とどの現場でも共通でチームにみられる事象を紐づけて話せたらと思います。
今、現場で起きている課題の先に光があるのだろうか?そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。
※本セッションは、「アジャイルチーム成長の過程ってどんな感じ?(20min)」と「アジャイル開発導入事例から分る組織・チーム・個人の課題(20min)」を1つにまとめて再構成するものになります。
-
keyboard_arrow_down
Tomonori Abe - 札幌の地でスクラムを実践して得た失敗そして改善
20 Mins
Talk
Beginner
数年前から札幌でスクラムを実プロジェクトにて実践してきました。
まわりではスクラムの事例が少なく、なかなか相談できる環境も多くはない状況でした。
その中での収穫は、自分たちで考え実践したことにより多くの失敗を経験することができたことです。
このセッションでは、これまでの経験から得た[失敗]そしてどのように[改善]していったかを紹介します。
スクラム視点での正解ではないかもしれないですが、これからスクラムに取り組む方や実践していてうまくいかない方の微力ながらヒントになればと思っています。
-
keyboard_arrow_down
きむら あゆみ / Junki Kosaka - Scrumですぐ使えるビジュアルコミニュケーション&『グラレコ』ワークショップ
75 Mins
Workshop
Beginner
初めまして、北のグラフィックレコーダー、木村あゆみと申します。
北海道&札幌のトークイベントを中心に、話を絵と文字でリアルタイムに可視化する「グラフィックレコーディング(=グラレコ)」を描いています。北海道・札幌で講演を描くというスタイルでは、第一人者として活動しています。
エンジニアさんの間でも、
・チーム内外の相互理解を深めるため
・より良い場をファシリテートするため
などを目的として、ホワイトボードを活用したり、グラレコを活用したりする機会が増えていると感じています。「絵が描けないと難しそう・・・」
と思われがちですが、ちょっとした道具や簡単なスキルを覚えるだけで、場をより良く可視化することができます!
現場で実践しているコサカさんの経験からも、
スクラムを通じて「現場をより良くしたい」と思っているみなさんにとって、グラレコのエッセンスは、即使える新しい武器になると考えています。私たちと一緒に簡単なワークをしながら、グラレコを体験してみませんか?
楽しい時間を通じて仲間も増える、素敵な時間を過ごしましょう!
-
keyboard_arrow_down
Takashi Maeda - アジャイルを知らずに8年間働いた後2年間スクラムに触れてみて得た学び
20 Mins
Talk
Beginner
システム受託開発を生業とする会社でエンジニアとして働き始めて10年、アジャイルという世界があることを知りつつも自分とは遠い世界のように感じて、勉強する気にはならなかったり、ちょっと書籍を読んでみても現実感がなくて自分には関係ないものと思いがちでした。
わたしがスクラムというやり方があるらしいぞ、と知って取り組み始めて2年が経ちました。
これまで、色々なことがしっくりこずにもやもやしながら悪戦苦闘を続け、本を読んでみたり、トレーニングにいってみたり、アジャイルコーチに来てもらったり、コミュニティーに参加してみたりしてやっと何かを掴みかけたと思いきや「なにもわからない」状態に突入した話などができればいいなと思っています。