はじめに
この記事は、2019/12/09に開催されたAgile Talks vol.1をふりかえるものです。
得られたものや、そこからの考察を行います。
Agile Talks vol.1では、Regional Scrum Gathering Tokyo 2020で落選となったプロポーザルの中から、イベント主催者である山口さん(@teyamagu) の「聞きたい」ネタを集めたものです。
普段のRSGTとはまた違った雰囲気で、のんびりと発表を聞くことのできる、非常にいいイベントでした。
今回は2つのテーマが話されたため、それぞれについてふりかえっていきます。
アジャイルコーチから見たScaled Agile Method.. ～SAFe and LeSSから学ぶ勘所～
メモ
ちゃんと勉強しなきゃなぁ #AgileTalksJP pic.twitter.com/f1JWZft443
— びば（森のフレンズ）ふりかえり読本シリーズ (@viva_tweet_x) December 9, 2019
学び
実は、SAFe, Lessも以前に本を流し読みしただけで、しっかり学んでなかったので、実践者から話を聞けて嬉しかったです。
内容は恐らくSAFe, Lessの触りの部分だけだと思うのですが、要点を抑えてそれぞれの対比をしながらお話していただけました。
「システムを変えられるのはマネジメントです」という考え方のSAFeと、「文化は構造に従うため、組織構造から変える」というLess。どちらも、アプローチは異なりますが、組織そのものの変革が必要となるのはどちらも同じでした。
Lessはスクラムの延長線上であり、原理原則なども、XP, Leanなど様々なところから吸収していることが伺える内容で、すんなりと入ってきました。今、本を読み直すと理解が捗りそうです。
私がチームをスケールするときに考える基本姿勢も、Lessにかなり近いものがあったため、これを機に勉強を深めようかと思いました。
SAFeの「Program Increment計画」という考え方と、SAFeのロードマップ
SAFeで特徴的だと思ったのが、「Program Increment」と「Program Increment計画」と呼ばれるもの。
SAFeでは1チーム10人の5〜12チーム構成が基本であり、大人数で1つのプロダクトを開発していきます。
その際、どうやって足並みを揃えてやっていくか、というのがProgram Increment。
Program Incrementは複数のフィーチャーチームが、それぞれが開発した作成物を結合したものと認識しています。
その結合するタイミングやリリースのタイミングなどの戦略を立てるのがProgram Increment計画。
凄いとも、恐ろしいとも感じたのが、この計画でした。
2日間かけ、フィーチャーチームのみならず、経営層レベルのトップからボトムまで集まり、Program Incrementの計画を話し合います。
話し合う流れも決まっています。
- 現状の経営状況などを語るBusiness Context
- プロダクトの状況や今後を話すProduct Vision
- 全体構成を話し合うArchitecture Vision
- and more
ととてつもない量のイベントで埋め尽くされています。
それを全員で計画しきり、実施できるという確証が持てなかったらやりなおします。
この計画は10週間に一度行われるのですが、計画自体の改善ももちろん行うとのこと。
改善のライフサイクルが最低10週間になるため、果たしてその改善がうまくいくのか、というのに疑問が残りました。
とはいえ私もSAFeを経験しているわけではないので、腰を据えて学び、実践してみてから考え直すとよさそうだと思いました。
SAFeの特徴としては、企業導入へのロードマップがあることで、ロードマップの部分部分で資格がたくさんあります。企業全体を巻き込み、計画的に育成していくという考え方は素敵だなぁと感じました。
Lessのシンプルさ
スクラム学びたてのころにLessを読んだときは「正直よくわからん」状態だったのですが、木村さんの話を聞いて結構しっくりきた自分がいて、成長を感じました。
スクラムをそのままスケールするようなイメージで、「そぎ落としではなくスケールアップ」という考え方にとても同意できました。
チームをスケールするときには、ロールを増やしたり、会議体を増やしたり、と「必要そうに見えるもの」を増やしてしまいがちですが、多くの場合コミュニケーションのための障壁が多くなり、うまく機能しません。Management 3.0のスケールの考え方も、何かの枠に当てはめようとするのではなく、必要なものは何かを自分たちで考えるものであり、近いものを感じました。
出来る限りシンプルに、というのはきっとXPから来ているのかなぁと感じます。
SAFe, Less, Scrum@scale, Nexusなど、スクラムのスケール手法は多々ありますが、まだまだ日本では実践者が少なく、これからの分野だと思います。
私自身も経験をたくさん積まねば、と決意できたよいセッションでした。
レトロ・オブ・ザ・デッド ～ゾンビレトロしてたチームを2年間観察していたら、良い振り返りをするようになったので、その活動報告～
メモ
最高じゃった #AgileTalksjp pic.twitter.com/gcIudPthCl
— びば（森のフレンズ）ふりかえり読本シリーズ (@viva_tweet_x) December 9, 2019
学び
田中さんに合わせて、この記事ではふりかえりを「レトロ」と表記します。
良いレトロとは「自己肯定的」であること。
私は「自己効力感」としてふりかえりの1つの要素にいれていましたが、その類似概念のようです。
自己肯定感 - Wikipedia
英語圏では自己肯定が伝わりやすいとのことで、バイリンガルで活動される田中さんならではの観点だと感じました。
今回、randamretros.comを教えてもらえたのは僥倖です。このサイトは知りませんでした。作りもしっかりしていて、ランダム洗濯したふりかえりのそれぞれのステップ を紹介してくれます。
紹介されていたレトロは以下。
checkout/amazon rating
レトロを5段階評価する。
帆船(Sailboat)
自分たちを帆船に見立て、追い風、錨、遠くに見える島でそれぞれ「加速させるもの」「減速させるもの」「ゴール」を話し合う
ヘルスチェック
独自？覚えていません
免疫マップ
http://makonari.com/?p=348 に載ってます。
パックマン
名前負けしている感じ。
blockerを話し合う？
星座
アジャイルふりかえりから価値を生み出す - ふりかえりエクササイズのツールボックスで紹介されています。
色々なふりかえりの手法が紹介されていました。重要なのは、楽しむこと。
上記の手法も1つの例や型でしかなく、作ろうと思えばいくらでも新しいものを作れます。自分たちにあったふりかえりの手法を探すことのほうが大事です。
このセッションでの気づきは、「私と同じ思想でレトロをしている人がいる」ということに気づけたことです。自分のふりかえりエバンジェリスト活動が肯定された、そんな気持ちになれたセッションでした。
また、別途考えてみたいのは、**「チームは問題解決を見てはいけない」**という話。私もこの意見に賛成で、自分なりの答えを出せそうですので、それは別の記事で書いてみたいと思います。
次回のAgile Talks vol.2
1/27(月)に開催されます。
お楽しみに。