スクラムマスダーの日記

アジャイル、スクラムに関連した内容が多めです。

Regional Scrum Gathering Tokyo 2020のスライドまとめ #RSGT2020

2020/01/08から、Regional Scrum Gathering Tokyo 2020(以下、RSGT2020)が始まりました!

2020.scrumgatheringtokyo.org

本ブログでは、RSGT2020のセッションの発表資料をまとめています。
個人で発見した発表資料のみですので、掲載していないセッションの発表資料がありましたら、コメント欄などで教えていただけるとさいわいです。

現時点では、1日目のスライドのみです。
2日目まで追加しました!
3日目まで更新しました。

1日目(2020/01/08)

keynote

The Ten Bulls of the Scrum Patterns

Hall WEST

アジャイルコーチ活用術

slide.meguro.ryuzee.com

みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?

プロダクト生存戦略 : 大企業で新規事業を始めて成功させるには

note.com

特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 -

テックリードは未来の話をしよう (Tech Lead in Scrum)

Hall EAST

Afternoon Mingle

見積りしないスクラム / NoEstimates Scrum

モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education

日本語版

www.slideshare.net

英語版

www.slideshare.net

The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!

www.dropbox.com

A Scrum Bookの歩き方

Terrace Room

スクラムの理解を深めるスクラムショーワークショップ

qiita.com

リーン・チェンジマネジメント - チーム・組織に変化を起こす!オリジナルのチェンジ・フレームワークを構築する方法

2日目(2020/01/09)

keynote

Lost in Translation: The Manager’s Role in Agile

Hall WEST

日本にJoy,Incを創る!ぼくらのジョイインクジャーニー3年間の軌跡

組織変更して部長がいなくなってから起きたこと

大企業の縦割り組織の中でProduct Discovery Teamを作ってサービスをリリース出来た話

キャリアパス考察:開発者と動くQAテスターからチーム支援するスクラムマスターへ

アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り

10年たってやっとアジャイルがわかりかけてきた話

最高のScrumキメた後にスケールさせようとして混乱した(してる)話

Hall EAST

【完結編】総売り上げ:35,400円 ~ 受託エンジニアが自社サービスのPOをやって学んだこと Total sales: 35,400 yen ~ What the contract engineer learned from the experience of Product Owner

Sociocracy for Scrum teams

 ### Going Agile with Tools - たまにはツールの話もしようぜ

A newアジャイルTransformation: Immersive Learning Spaces

ORGANIC agility®: an evolutionary approach to organizational resilience

Terrace Room

チームの再定義 -進化論とアジャイル-

Team-Based TEAM - 会社を越えるチーム -

【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方

アジャイルUXリサーチLive! ~ 「即席」ユーザーテスト見学会

3日目(2020/01/10)

Terrace Room

Test-Driven Product Development (TDPD) - a better way of handling product development

keynote

NEXT→ACTION

講演中に「資料の公開は無し」とおっしゃっていました。

2019年のふりかえりをやってみた

2019年も、あと数日になりました。
年末でふりかえりブログも多く見かけるので、私も流れに乗って、2019年をふりかえってみます。

仕事に関すること

転職してRise UPに入社しました

人生初の転職をしました。8月から株式会社株式会社Rise UPで働いています。

業界、環境などが大きく変わりました。

業界としては、BtoB業界からBtoC業界に変わりました。

お金を儲ける仕組みとしては、顧客がソフトウェア自体に対してお金を払っていた仕組みから、ソフトウェアを通して届ける商品にお金を払う仕組みの環境に変わりました。
※もちろん、どちらも顧客は、自身が感じる価値にお金を払ってはいるのですが、会社の資産価値的な意味では異なる

配送部門やマーケティング部門が非常に重要だったりするなど、開発者と関連する部門も大きく異なります。

正直、まだまだ慣れない環境で働いている感じです。

エンジニアには非常に良い環境で、最新のMacが用意されていたり、研修(10月に和田卓人さんのTDD研修を受けました)が充実していたりと、成長できる機会は数多くあります。

関西系の企業で、これだけ充実している環境は、なかなかないと思います。

組織改善担当からエンジニアにロールチェンジしました

転職する際に、自身のエンジニアリングスキルをアップしたいと思い、エンジニア組織改善やスクラムマスターといったロールから、純粋に設計やコーディングをするエンジニアにロールチェンジしました。

日々コーディングをしていて、「エンジニアって難しいな・・・。」と毎日痛感しています。
自身のエンジニアリングスキルのなさに、日々悔しい思いをしています。

自身が今まで理解していたと思っていた内容を、いざ実践してみると、全然実現できないのが、圧倒的にしんどいです…。

ただ、僕が将来なりたい姿になるには、今の経験が非常に重要だと思い、取り組んでいます。
今は、踏ん張りどころ…。

コミュニティに関すること

スクラム道関西の運営を継続しました

スクラム道関西の運営として、いろいろなイベントを開催しました。

scrumdo-kansai.connpass.com

スクラム道関西のオープンジャム、ScrumBootCamp、アジャイルラジオなどを通して、30回以上の活動を行いました。 ※スクラム道関西全体としては、48回の模様

ほぼ週に一度は、何かしらの発信をするアジャイルのコミュニティは、僕の観測する限りでは日本にないので、一番何かしら活動しているコミュニティに関わることができていて、ホントに最高の活動をさせていただいていると思います。

ソフトウェアの世界は、東京と比べると、大阪は、まだまだ遅れている状況だと思っています。
コミュニティは、会社の垣根を超えて活動できるので、大阪という地域がより活性化して、東京に負けないよう、活動を継続できればと思います。

AgileJapan大阪サテライトを継続しました

2019年AgileJapanの大阪サテライトを開催することができました。
今年は、登壇ありの大型イベントを無事開催することができたので、ホッとしています。

agilejapan-osaka.connpass.com

詳しくは以下のブログにまとめています。

scrummasudar.hatenablog.com

昨年、今年は関西のサテライトは一つしか開催されていないので、来年も継続して、関西の地で、頑張りたいです。

Scrum Fest Osakaに参加できませんでした…

2月22日、23日に開催された、Scrum Fest Osakaに参加することができませんでした。

www.scrumosaka.org

RSGTのようなイベントを大阪で初めて開催したようなのですが、参加していないので、全くわかりません…。

きょんさんと及部さんの基調公演が素晴らしかったとのことで、アジャイルラジオにきょんさんにゲスト出演いただき、お話を聞かせていただきましたが、全然イメージできませんでした。 イメージできないことこそが、基調公演の素晴らしさかな、と思っています。

agileradio.github.io

agileradio.github.io

個人に関すること

結婚しました

2月に、結婚しました。
いろいろな方に結婚式・披露宴に出席いただくことができ、感謝するばかりです。

また、結婚を機に、30年近くすんでいた実家を離れ、妻と二人で暮らし始めました。
実家でも家事をすることはありましたが、毎日するって、大変ですね…。

『Design It!』の翻訳レビューに参加しました

11月に出版された『Design It!』 の翻訳レビューに携わることができました。
知人が書籍を出版したり、技術書展で同人誌を出版したりするのをみていて、2019年のはじめころから、「将来、技術書の出版に携わりたい」と考えるようになりました。

そして、ラッキーなことに、オライリーという数多くの素晴らしい技術書のシリーズの出版に携わることができました。

内容もホントに素晴らしいので、みなさん、ぜひ読んでください。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

その他

英語を頑張ろうと痛感しました

Rise UPでは、日本人以外のエンジニアも数多くいます。あるチームは英語を標準言語としています。 彼、彼女らと会話する際には、英語である必要があるため、自身の英語の話せなさを痛感することが多くあります。

2020年は英語に関する具体的な目標をもって、取り組みたいです。

AmazonのPrime会員になりました

結婚して、実家を離れ、妻も働き出すと、ECで購入する際に、配送物が到着する時間って、めちゃくちゃ大事だなと痛感するようになりました。 ということで、ついにAmazonのPrime会員になりました。

今は、エンジニアは必ず見たほうが良いらしいシリコンバレーを見ています。

amzn.to

海外の連続ドラマは、いままで見たことがなかったですが、かなり面白いなと感じています。

おわりに

2019年は、結婚、転職と激動の一年でした。
自分ができること、できないことが明確になった一年でもあります。

環境が変わったからこそ、新しく見えてきたことが数多くあります。

2020年は、腰を落ち着けて、新たなことに挑戦する年にしたいと思います。

ふりかえりで前回のふりかえりの改善策を確認する必要があるか?

こんにちは。スクラムマスダーです。

この記事は、 ふりかえりアドベントカレンダー9日目の記事です。

前日は、id:cobase16 さん

kobase16.hatenablog.com

翌日は、id:ikikko さん

ikikko.hatenablog.com

私は、スクラム道関西というスクラムについて参加者同士で話し合うことができるコミュニティの運営に携わっています。

scrumdo-kansai.connpass.com

参加者は話し合いたいトピックを出しあうのですが、ふりかえりは非常によく出るテーマの一つです。

そのふりかえりの中で、「ふりかえりを行う際に、前回のふりかえりで出たTry(改善策)の確認はするべきですか?」という話題が定期的にあがると、個人的に感じています。

この話題について、僕が、普段スクラム道関西でお話していることを、記してみます。

結論を言ってしまうと…

  • ふりかえりで、前回のふりかえりの改善策を確認する必要は、ない。
  • もちろん、話したい人がいれば、話題として出すべき。
  • 確認するタイミングは、別にある。

スクラムのスプリントレトロスペクティブを確認してみる

スクラムには、公式の型として『スクラムガイド』があります。

いわゆる「ふりかえり」に相当するスクラムのイベントは、「スプリントレトロスペクティブ」です。

スプリントレトロスペクティブでは、「前スプリントで出した改善策を確認する必要がある」旨の記載はありません。

そのため、「前回のふりかえりの改善策を確認する必要があるか?否か?」という問いに対しては、「必要はない」となります。

ふりかえりで前回の改善策を話したい!

ただ、『スクラムガイド』には、以下の内容も記載されています。

スプリントレトロスペクティブには、以下の目的がある。
(中略)
うまくいった項目や今後の改善が必要な項目を特定・整理する。

前回のふりかえりの改善策で、うまくいった場合や改善が必要で、その対応の優先順位が高ければ、話をする必要があるということです。

そのため、必ず話題に上げる必要はないが、前回の改善策について、話をする必要があると感じているメンバーがいれば、話題にあげるのがよいと思います。

スプリントバックログを確認してみると…

スクラムガイド』は、2010年に初版が発行され、現在は第5版の2017年版が最新です。

一つ前の2016年版から2017年版に更新された内容で、ふりかえりに関連する内容が以下です。

7.「スプリントバックログ」のセクションに以下を追加した。
継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく。

スプリントレトロスペクティブの章ではなく、スプリントバックログの章に、スプリントレトロスペクティブで特定された改善策についての内容が、追加されました。

最新の『スクラムガイド』では、スプリントレトロスペクティブで特定された改善策を、スプリントバックログ(開発チームがスプリントゴールを達成するための作業項目)として、明確にする必要があります。

スプリントバックログとして明確にするということは、デイリースクラム(いわゆる朝会)で、進捗を確認する必要があります。

開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。

つまり、スクラムを利用している場合、スプリントレトロスペクティブで特定した改善策は、デイリースクラムで日々進捗を確認する必要があるということです。

改めてまとめると

  • ふりかえりで、前回のふりかえりの改善策を確認する必要は、ない。
  • もちろん、話したい人がいれば、話題として出すべき。
  • 確認するタイミングは、『スクラムガイド』に則ると、デイリースクラム

おわりに

今回は、スクラムに沿って、ふりかえりについて書きました。
もちろん、ふりかえりの頻度が毎日だったり、デイリースクラムに相当するイベントを実施していない場合もあるので、あらゆるパターンに当てはまるということではないと思います。

そういうことも含めて、ふりかえりでの改善だと思いますので、ぜひ、もやもやした気持ちを、ふりかえりで、チームのみなさんに共有すれば、よいと思います!

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

エッセンシャル スクラム

エッセンシャル スクラム