スクラムマスターは孤独、と言われますが、どう思われているでしょうか？

前職で、（外部コーチの方はいたものの）社内にアジャイル・スクラムの導入を進め、スクラムマスターとして、チームと伴走を続けていました。

スクラムマスターが自分1人という状況で、頼られることは、嬉しいことでしたし、貴重な経験とレベルアップにつながったと思っています。

一方で、僕自身がアジャイル・スクラムについて壁打ちしたい、スクラムフェスやコミュニティから持ち帰ったものを議論したい、というときに、社内ではそれができず、少し物足りなさを感じていました。（今、客観的に思えば、自分のマインド・巻き込み力のなさゆえで、立ち回りようはいくらであったと思いますが…）

その後、色々と事情があり、現職に転職することになるのですが、配属先以外にもスクラムで開発しているチームがいる、と聞いた私は一人、「他のスクラムマスターやアジャイル実践者と、相談や情報交換を気軽にできる場を社内に作れたら、めっちゃ楽しいんじゃね？」と思うのでした。

始動から約1年半、ちょっとずつ参加してくれる人も増え、コミュニティ内の相談や情報交換だけでなく、スクラムマスター不在のチームが外から相談に来てくれたり、会社的にスクラムマスターの立ち位置を作る運動がおきたり、想定外の効果も発生しだしているのを、わくわくしながら眺めています。

このセッションでは、私が社内アジャイルコミュニティをどう立ち上げ、運営を続けるために何をしてきたか、コミュニティがあることでどんな嬉しいことがあったかをご紹介します。

かつての私と同じように、もっと会社でアジャイル・スクラムの話をしたい、社内でアジャイルコミュニティを作りたい、と思っている方に、実際にやってみた一例を伝えると共に、行動のきっかけになれるようなセッションにしたいと思っています。

私達は、かつては、単一チームのスクラムでプロダクト開発を行っていました。しかし、プロダクトの成長に伴い発生した課題に対応するため、大規模スクラムのフレームワークであるLeSSを参考に、体制・プロセスを変化させていきました。

その中でも、リファインメントにおいては、各チームやメンバーが同じ情報を共有し一体感を保つため、単一チームのときと同様、全員が同じ場所に集まり、一緒に行う方法をとり続けました。

しかし、時間とともに、リファインメントに対して、コミュニケーションやコストなどの問題が顕在化するように。

この問題に対処するため、私達は、LeSSのガイドに記載されるマルチチーム（複数チーム）プロダクトバックログリファインメントという手法に着目しました。

最初は、アジャイルコーチに教えを請い、書籍を調べ、手探り状態で実践することになったのですが、うまくはいかず、スクラムマスター自身も含め、チームを混乱させました。

それでも、効果的なリファインメントの場を求め、フィードバックを集め、試行錯誤を繰り返す、という、検査と適応のサイクルを続けることで、やがてチームに適した形になってきたのです。

このセッションでは、私たちが経験した具体的な問題・課題や、それらを解決するために何をしたか共有します。さらに、マルチチームプロダクトバックログリファインメントの導入によってもたらされた効果についてもご紹介できればと思います。

弊社には、多くのプロダクトチームがあります。その中で、スクラムを選択するチームもたくさんありますし、スクラムを選択してもスクラムマスターがいない、もしくは兼任である、というチームも存在します。（それがスクラムなのかの議論は置いておき）

しかし、この1年くらいで、スクラムマスターを採用するチームが増えてきました。外部からの採用だけでなく、チームの中から手を挙げて、スクラムマスターになる人も出てきています。観測しているだけでも、スクラムマスターの数は倍以上になっています。

このセッションでは、そんなスクラムマスターたちをケーススタディとし、スクラムマスターの採用に至る背景とその結果についてお話したいと思います。

具体的には

• チームはどんな課題を持ち、どんな期待を持ってスクラムマスターの採用に踏み出したのか
• スクラムマスターは、どんな魅力や使命感を持って、名乗りを挙げたのか
• スクラムマスターがジョインした結果、チームに何が起こったのか

といった辺りをご紹介したいと思っています。

昨年のスクラムフェス大阪で、弊社の大倉から、Epic大臣という取組で、エンジニアからプロダクトオーナーの領域への越境を行ったチームの話をさせてもらいました。（Epicとは複数のユーザーストーリーを束ねたユーザー価値の最大の単位を意図しています）

今回は、このチームのその後になります。

プロダクトオーナーを助けたいという思いからエンジニアが越境し、Epic大臣としてプロダクトオーナーの責務の一部を担うことにより、プロダクトオーナーはもっと解決すべき問題へと注力できるようになりました。

時間が経ち、メンバーの異動・Epic大臣の知見の分断・プロダクトの成長に伴いPOが更に多忙になる、など、状況は大きく変わりました。

結果として、Epicはうまく進まず、チームの雰囲気もちょっと悪くなっていく…

しかし、今は、状況は改善し、更にロール間の距離が縮まってきています。

どうやって乗り越えたのか、さらにどんなチャレンジを考えているのか、をお話できればと思います。

スクラムチームをスケールさせたいとき、どう進めているでしょうか？

一般的に、できる限りメンバーは固定しスケールさせない、スケールさせるにしても急激に増員しない、みたいなことがセオリーかと思います。しかし、様々な理由で、セオリー通りではない方法でスクラムチームをスケールさせざるを得なくなっている組織も多いのではないでしょうか？

私が昨年11月にジョインしたチームが開発するプロダクトは、今年の2月に、リリースして2周年を迎えました。

現在、チームの中でリリース当時を知っているのは、POとデザイナーの2名しかいません。そして、当時は1チーム体制でしたが、20名近い人数になり、LeSSのプラクティスを取り入れた体制に変わってきています。

急激な変化できつい時期もありましたが、それでもユーザーに価値を届けたいとスクラムを続けています。

そんな変遷と改善の歴史をお話できればと思います。

アジャイルやスクラムなどについて悩んでいる時、みなさんはどうしますか？
インターネットなどで似たような悩みを解決した話がないか調べてみたり、SNSでつぶやいてみたり、同僚に相談したりする人もいます。

みなさんの現場にアジャイルコーチがいるなら話してみるのもいいかもしれません。多くのアジャイルコーチはアジャイルなマインドセットや幅広い知見を持っています。しかしそんなアジャイルコーチがすべての現場にいるわけではありません。

先日のRegional Scrum Gathering Tokyo 2020では Coaches Clinic という、アジャイルコーチに(基本)1対1で相談できる場がありました。

この時間では、その Coaches Clinic の紹介をし、実際にどのような感じで行われるのかを見ていただこうと思います。このセッションを終わった後には、ScrumFestOsakaでも Coaches Clinic の場ができるといいと考えています。

※Workshop(90分)を選択していますが、30〜45分の想定です。

2019年4月からスクラムで開発をしています。

チームには「他部署からの要望」や「経営判断による最優先事項」が集中しやすく、

プロダクトバックログは、自分たちでコントロールすることができないほどのアイテム数に肥大化していました。

結果、

「あのチームは、依頼してもやってくれない」

「自分たちは、本当に価値のあるものを提供できているのだろうか」

そんな声が聞こえるようになってしまいました。

現在、この状況を打破すべく、一度プロダクトバックログを捨て、部署横断で１から再構築しています。

プロダクトバックログの作り方を変えたことで、開発のプロセス自体も変化しました。

このプロポーザルを書いている時点では、再構築したプロダクトバックログを使い、1スプリント終わったところです。

一度もらった要望を捨てるという判断にも関わらず、どうやって他部署から協力を得ることができたのか、

このチャレンジにより、どんな変化が起き、どんなことを学んだのか

といったことをご紹介できれば、と思っています。

とあるECサイトを運営する前職での話です。

新システムプロジェクトに失敗。1からの再スタート。急いでシステムリプレースを進めねばならない。

そんな時にもたらされた一言。

「”スクラム”って知ってますか？」

そこから始まる阿鼻叫喚・悲喜こもごもの日々。

• 実はスクラムがどんなものか誰も知らない
• ふりかえらない
• プランニングしない
• プロダクトオーナー不在

ベテランの方々から見れば、鼻で笑ってしまうような出来事でも、同じような体験をした方、絶賛体験中の方いるんではないかと思います。

いきなり上手く出来なくてもいい。でもちゃんとスクラムできるチームになるためには？

未だ学習中の身なので偉そうなことは言えませんが、面白おかしい失敗談から、感じ取ってもらえればと思います。