2020年6月、新しいプロダクトを開発するために、1つのスクラムチームが生まれました。

このスクラムチームは、PO・SM・Devの3人からなる小さいチームです。
そのうち2人はアジャイル・スクラムの未経験者でした。

最初はプロダクトの掛け持ちにより、全員が1週間のうち2日しかプロダクトの活動が出来ない
という状態からこのチームははじまりました。
このチームの周辺では、掛け持ちが当たり前の世界観であり、どのチームも成長・変化はゆるやかなものでした。
きっと、他のチームと同様、このチームも成長していくには、時間がかかると思われていました。

このチームがはじめにやったことは、アジャイル・スクラムの世界を広げることでした。
経験者に連れられて、コミュニティに参加して、様々な本を読んで、チームで語り合って。
プロダクト開発に必要な業務の傍らで、自分たちの世界を広げよう、と手を伸ばし続けてきました。

そして、チームに転機が訪れます。
それが、「Scrum Fest Osaka 2020」です。

チーム全員で、このフェスへ参加したことがきっかけで、私たちの変化のスピードにブーストがかかりました。

永瀬美穂さんのキーノート、「今あえてのスクラム」。
kyon_mmさんと及部さんのキーノート、「Agile Wars − アジャイルチームの夜明け −」。

これらのセッションに参加したり、登壇者・参加者たちの話を聞いたり、ワークに参加したり、参加者同士で語り合ったり。
セッションの合間では、チームで「明日からこうしたいよね」「これは試したい」など感想戦を行っていました。

きっと、一人でフェスに参加するだけでは、
　「こうしたいなぁ」
　「でも難しいだろうなぁ」
という願望で終わってしまっていたでしょう。
熱量を心に秘めたまま、発露できずに終わっていたでしょう。

でも、チーム全員で参加することで、フェスで得た熱い想いが霧散することなく、
　「こうしよう」
　「やってみよう」
という実験をする勇気が湧いてきました。

そして、フェスの夜が明けて。
次のスプリントから、私たちの実験が始まりました。

手始めに行ったのは、フラクタルスプリント。
1週間だったスプリントを3時間単位に区切り、3時間ごとにインクリメントを作り上げるようにしました。

そして、モブプログラミング。
モブ・ペアでのワークをチームの文化として積極的に取り入れ、
チームが「チームである」ということをより実感できる動き方を実現しようとしてきました。

このプロポーザルを書いている今、まだSprint#8の途中です。
でも、フラクタルスプリントを取り込んでからは、変化のスピードが劇的に加速しているのを感じています。

Scrum Fest Mikawaでは、きっと、
　大きく変化した私たちの姿と、
　それまでたどってきた変化の軌跡（奇跡）
を見せることができるでしょう。

今まで、コミュニティに参加したこともなかった、登壇もしたこともなかった、
ブログなどへのアウトプットもしたことがなかった。
そんなチームメンバーが、どのように変化していったのか、を皆さんにお見せします。

そうすることで、私たちがそうだったように、
次の新しいチームへ、この勇気のバトンを渡せると信じています。

7月に漫画最終回を迎えた「ハイキュー!! がアジャイル方面のコミュニティでもじわじわと盛り上がってきています。チームの成長の物語であり、個人がチームや自分の実力・振る舞いとどのように対峙するかを丁寧に描く作品に、多くの人が共感と学びを感じています。バレーボールのルールを知らなくても大丈夫。6人で強い方が強い。ハイキュー!! の物語を通じて、チームで業績を上げる方法について考えてみましょう。

田原の出身なのですが高校は豊橋に通ってまして、バレーボール部の部員でした。といっても、大した運動能力もなくずっと補欠で楽しくやっていたのですが、先輩方から様々なことを学ばせていただいた気がします。出場選手6人だけでない周りを含めたチームの動き方は、そこで学んだんじゃないかと思います。そのあと、企業ITの道に進んだり、スクラムに出会ったりする中で、Production IG制作であるところのアニメ「ハイキュー!!」、そして原作の漫画に出会うわけです。

約一年前、他社向けアジャイルコーチとして転職し、10チーム以上でのスクラム導入を支援してきました。

3人の小さなスクラムチームで、とあるプロダクトの新規開発、リリース、運用をしています。

スクラムはフレームワークであり、スクラムのスキルを身につけた上で、実際のプロジェクトではプロダクトの特性、開発フェーズ、組織フェーズなど、その状況に応じてプラクティスやツールを取捨選択していく必要があると感じています。

本セッションでは、8ヶ月間スクラムチームで開発をしながら、開発チームの1メンバーとして考え、実践したこことについてお話します。

スクラム開発を1年くらい経験しています。

日々リファインメントを行っていますが、気の赴くままに会話を重ねてその結果を転記している感じでした。

そんな時に出会った Scrum Fest Osaka 2020 ！

そこでの学びをプロジェクトに活かしたお話をします。

入社４年目の若手SEです。

配属から２年間、開発PJに携わりたい！と訴え続け、待ちに待った開発PJへの参画。

アジャイルやるよ！って始まった新規チームの軌跡。

涙なくして語れない大失敗からの学びをお伝えします。

始めてのスクラムは難しい。今回の学びが少しでも皆さんの助けになれば幸いです

大学生と院生が対象のアジャイル開発プロジェクト（enPiT）の
担当教員になって7年目になります。

授業には、受講生、メンター（この授業の修了生）、教員がいます。
その間には「教える」「教わる」という縦の関係があり、
講義・演習系の授業に比べると近くはあるものの確かに縦の関係は存在していました。

それが、去年あたりから研究活動をアジャイルに進める試みを有志で始めたのをきっかけに、
教員、メンター、受講生の関係がフラットになり始めたと感じています。

教員とメンターが研究という共通の「複雑で不確実なもの」に対峙することで同じ視点に立つことになり、アジャイルに研究する方法を作り上げていく同志となりました。

さらにその活動を受講生のDiscordやSlackで公開して進めていくことで興味を持った受講生もそこに混じりはじめ、ともにアジャイルに模索をする戦友という関係が生まれ始めました。

そんな話をしようと思います。

デンソーのデジタルイノベーション室は、自社サービスを立ち上げるために新規に作った組織です。

開発スタイルとしてスクラムを取り入れて素早く市場のフィードバックをプロダクトに取り込んでいます。

一般的にスクラムでのエンジニアは多能工と言われていてチーム内ですべての必要なスキルを持つべきと言われていますが、商用サービスを開発していくうえで"性能"、”信頼性”、"クラウドの知識"、"セキュリティ"といった特に専門性が求められる領域で技術的な課題がでてきました。

これら特に専門性が求められる領域のスキルを持つエンジニアは限られており、かつどのプロダクトでも考慮しなければいけない共通の課題でした。

デンソーではこれらの課題を解決するべく、チーム横断のSite Reliability Engineering(以下SRE)チームを立ち上げてチーム共通の課題に日々向き合っています。

本プレゼンではSREチームの活動について

1. 技術的課題の解決のための取り組み
2. コミュニケーション改善のための取り組み

についてお話します。

このセッションでは、元々SIerでアジャイル開発をやったりアジャイルコーチをやったりしていた人間が、全く環境の違うスタートアップでどういう価値発揮をしたかに関して話します。

SIerでずっとアジャイル？なにそれ？というプロジェクトに赴き、アジャイル、スクラムの概要を説明して、ちょっとイベントのファシリテートして、そして帰ってくるということをずっと繰り返していました。
このままではアジャイルにだけ詳しい何も出来ない人になってしまうと焦っていたときに、なんとなく憧れていたスタートアップ。

自分が理想郷を夢見ていったスタートアップで出会った現実、そしてやったことなどをユーモアを交えつつ話せればと思います。

また、SIerで培った自分のアジャイルコーチとしての能力はスタートアップで役に立つのか、スタートアップでどんなことをしているのか、今スタートアップで働いていてどうなのかとかなども話す予定です。

Rettyには７つのスクラムチームがあります。
これまではホワイトボードと付箋を使って物理的なカンバンを使っていましたが、リモートワーク主体の働き方へと移行するにあたり、電子ツールの利用を開始しました。

実際に各チームで使っているカンバンを通して、リモートワークでの運用事例をご紹介します。

小学校の先生であるIKUにmiroを教えて、歴史の授業を小さくmiroで始めた話です。
制約が多い学校の中で新しいことにトライするには色々な障害がありましたが、IKUは心が折れかけながらも一歩ずつ頑張りました。
何よりも子供たちが一生懸命に、そして楽しそうに勉強している姿はとてもうれしいものです。
あっ 最近は歴史だけじゃなくて、理科の授業でも使いたいと子供たちから提案がありました！

当日はnemorineとIKUの二人でお話する予定です。

このセッションでは、スクラムの導入から、スクラムチームをスケーリングして複数のフィーチャーチームに拡大するまでの取り組みについて、取り組み内容とその気づきをお話しします。

私たちは約2年前にスクラムチームを立ち上げ、当時は10名程度だったスクラムチームも、現在では5チームになり約40名を数えるまでに拡大しました。

最初は、アプリ(iOS/Android)チームにスクラムを導入しました。当時はバックログはサーバーチームと別々に存在し、POはそれぞれのチームに仕様を説明していました。また、仕様はPOが作成し、開発チームは決まった仕様を作る・・・そんな状態でした。

現在は、アプリとサーバーが同じチームになり、フィーチャーチームとして最優先のバックログに取り組むことができるようになりました。

ここに至るまでに様々取り組んだことや、苦労した(している)ことなどを是非シェアできればと思います。

人事部に所属しながら、社内スクラムマスターをやっています。
エンジニアではないので非エンジニアチームにアジャイルを広める活動をしています。

今回は「サイボウズ式」というメディア運営をしているチームをスクラムマスターとして支援する中で学んだ
非エンジニアチームでも使える「アジャイル」の考え方をお伝えしたいと思います。

JIRAというツールはいろいろできる。しかしそれゆえにどこから手を付けていけば分からない。

複数のチームをJIRAというツールでAgileにプロセスを進化させた過程を話します。