これはAdventCalender2022の一日目の記事です
別名チラ裏なので軽い気持ちで見てね♡
序文
タイトルは嫁のメシがまずいスレタイよりアレンジしました。
DXがコンサルの飯の種になって以降、猫も杓子もJTCもスクラムーアジャイルーと大変モダーンな開発手法が今までの組織体系ガン無視で叫ばれています。
大変意識が高くてよろしいことですが、大抵の場合はプロのスクラムマスターをチーム毎に雇う金や手続きに対する負担を支払う気が無いため現場のスクラムを一切知らない人間がなんちゃってスクラムっぽいことを今までの仕組みの中に無理矢理取り込んだ結果、意識高い系(笑)スクラムのような目も当てられない状況になっている場面を散見します。
よく見るのは「スクラムだとうちのやり方に当てはまらないからアレンジした」だとか「時間が取れないからセレモニーの一部を短縮・取りやめた」などくそ素人スクラムの経験が無いメンバーが独自にやり方を変えた結果、結局プロジェクトを管理出来ずに全く成果が出ない。 -> スクラムはうちに合わないし、成果がでない! -> スクラムは使えませんでした！もしくは成果が出ないままやり方を改善せずにずるずると今までやってきた中途半端なスクラムを続けて、いつまでも成果が出ないと言う状況です。
大抵こういう現場は、現場を仕切るリーダー格以上のメンバーにスクラムの知見が一切無い事が多く、アジャイル侍などのアジャイルの有名どころの本を一冊読んだは良い物の二度と見返さないしその本からのフィードバックもしないので最初のうちはそれっぽいフォーマットで回っていたもの、徐々に元のプロジェクトのやり方に戻ってしまい元のプロジェクトとスクラム(一部分)が悪魔合体を起こし台無しになるパターンが多いように感じました。それはまるでメシマズの嫁が味噌汁がしょっぱいから砂糖やチョコレートを入れて味見をしないかが如く。
と言うわけで、このドキュメントでは自分が今まで経験してきたスクラムのフレームワーク中で、なんでそうなってるの?という事案をフェイクを交えて紹介して、溜飲を下げる読んでいただいた方の他山の石になって頂こうかなという奴です。
状況によってはその案や施策は正しいよねーと言う物あるかと思います。一応そこら辺もちょこちょこ記載しながら話していきたいとは思いますが、もしいやこの手法は割と良く使われている方法でーみたいな施策があったらコメントいただけるとうれしいです。マジで。
序文の最後に、マジでメンバーに素人しかいないのであればきっちりフォーマットに従った方が良いと思っています。マジで。できないのであればプロにスクラムマスターをお願いしましょう。もし組織構造上スクラムでやれなさそうであれば変にアレンジせずに他のフレームワークを検討する事を個人的にはおすすめします。
スクラムは組織構造に非常に密接しているフレームワークです。そういう意味で結構トップダウンで、現場の人間では手が出ないよーという事がママある気がします。組織構造に対する決定変更に権限がある人がスクラムに理解がないのであれば別の方向に誘導するのも一つの手段と思いますので検討いただければ。
事例集
1スクラムチームのメンバーが多い
解説と起きうる弊害
スクラムのチームメンバーが10人(以上に)になってしまったとか言う奴です。
大体スクラムチームの規模は5 - 7人が最適と言われています。感覚的にも１０人以上で毎日のデイリースタンドアップミーティングをするともう自分が話すことで精一杯でろくに相手の進捗や質問などができない状態になったり、時間内(大体毎朝15分と言われている)に終わらなかったする事が多発します。
これはその他のセレモニーでも発生し、10人くらいの規模になると明確にMTGなげーなーと感じることが多くなっていないでしょうか?
解決方法
10人になる位をそれくらいをめどにチームを分けてLeSSなどの大規模スクラムの手法に移行できると良いです。
がチーム分けるのはそれなりにコストや難易度が高い作業になるためなんやかんやで10人チームのままで進む事が結構あり辛い気持ちになることが多いです。
MTGの効率化などで乗り切ろうと当初はしますが、中々難しい印象があります。その結果本来は話したいことを話すことに躊躇したりで良い影響はないと思います。
分割頑張りましょう。
え?30人でやってる?そう...(諦め)
リリースサイクルがスプリント期間と合っていない
解説と起きうる弊害
素直に考えると、スプリントレビュー -> 完了したタスクをリリースという流れを毎スプリント実施するが自然かなーと考えています。当然障害・脆弱性・商戦・イベントなど中々スプリントレビュー後だとタイミング合わないリリースも発生する事は当然なのですが、こういう例外的なリリースが多いと結構手間が掛かって面倒ですよねーと言う話。
解決方法
ここら辺結構チームにより体制に差があるかと思います。
例えば脆弱性・バグフィックス、リファクタリングなどは自動テストをクリアしていたらいつでもリリースして良いとか。
フューチャーフラグを利用してユーザーには見せないけど、内部には本番環境で確認できるようにしているとかあるかと思います。
ここら辺ができるとスクラムのフレームワークに従いつつ、リリースをコントロールできるのですが中々にレベルが高いなーと感じでいます。
デプロイ≒リリースだとどうしてもリリース頻度もコントロールも難しいですね。
ただスクラム・アジャイルでやる以上CI/CD・自動テスト・フューチャーフラグ辺りがあると大分自由度が増えて良いと思います。
リリース内容とタイミングの決定権限がチーム無い?マジかー...
チームを機能ではなく役割で分割している
解説と起きうる弊害
おれおれのやり方でやっていたチームが上から「これからはDXでアジャイルだ!」と上から言われて仕方なくスクラムを導入したチームによくあるやつです。
本来１機能を作れるようにチームメンバーを選定するのですが、スクラム以前のやり方のチーム分けがバックエンド/フロントエンド/インフラ/運用/モバイルみたいな体制になっておりスクラムに移行した後も結局そのままの単位でスクラムチームを分けてしまうという奴です。
これは本当にスクラムの無駄遣いだなーと思っていて、結局リリースするために各チームが既存のスクラムセレモニーとは別にセレモニーっぽいことをしないとリリースまでいけません。特にスクラムを始めたばかりだと各チームの成果物の責任分界点もあやふやなので最終的にふわっとしたところは他のチームに押しつけ合い、縄張りの主張、それを調整するためのミーティングなどが発生してろくなことになりません。...って友達が言ってました。
解決方法
チームを決めるときはユーザーやステークホルダーに見せられる機能を開発できるチームを作れるようにした方が良いです。まるで解決の助けになっていない解決方法で恐縮ですが、頑張って交渉して。
いまいち判断が付いていないのはモバイルチームのあり方です。Android/iPhone用アプリは個人的に技術領域が違うように感じるため、結構スクラムチームでも別チームでやる所が多いように感じています。(BFFとかそういう文脈もあるのかなって考えていました)誰か教えて。
検証しかタスクが無いような状態でスクラムを導入してしまう
解説と起きうる弊害
個人的にスクラムにすべきタスクはチーム内で見積もり可能なタスクがほぼほぼで、当然よくわかってない技術等は別途調査するタスクは発生するのですが、それはあくまでPBIの一部という認識を持っています。たまに実施する場合はスパイクみたくタイムボックスを決めてストーリーポイント(難易度)ではなく実時間で決めるという手法を使っていました。(スパイクはXPなのか...)
がスパイクばかり発生するようなプロジェクトの場合スクラムって有効なんでしょうかね。。。なんか結局見積もりもタスクもふわふわしているのでスプリント内で終わんないことが多いです。多分有効じゃないよなー
なんか良い方法があれば教えてください。
チームメンバーが頻繁に増減する
解説と起きうる弊害
上述したようにスクラム単体で見ると、メンバーの増減に弱いフレームワークなのかなーと思うような、思わないような。
なのでOnBorading対応やチームの自己組織化みたいな事ができていないとチームのベロシティの振れ幅が大きくなってしまい、見積もりの精度がめちゃくちゃになってしまいます。
ちゃんと自己組織化したチーム・チームメンバーに育てても、チームからそのメンバー離れてしまえば今まで提供していた安定的なベロシティと成果物は崩壊します。
自己組織化していないチームからメンバーが抜ければ更に悲惨です。それはすなわち属人化しているタスクが多いという事に他ならないので、その人が抜けてしまったら仕事が回らなくなるという事象が起きないとも限りません。
そうでなくてもスクラムが実施可能なチームは貴重なので、チームの増はまだしも減は慎重にお願いします。何でもしますから。
タスクのアサインをプランニング時に決めてしまう
解説と起きうる弊害
これもありががち
プランニングかリファインメント時、POとかスクラムマスターとか後チームのリーダー(POやらを兼務するケースが多い)がやたら最初のタスクのアサインを決めたがります。
これ俺が経験してきた、「POとスクラムマスターがずぶの素人」でなおかつスクラムに関するアドバイザー一切いない場合必ずやりたがる。
これをやると多分アサインした側としてはこのようなメリットがあると思っていると感じています
- 得意な人にやらせるので完了や見積もりが早い
- アサインしていない人というのがいなくなる
対してデメリットは以下の感じになると思います
- 大抵の場合得意な人にしかやらせない(特に難しい課題ほど顕著)のでチーム属人化を推し進め自己組織化を抑制する
- 一つの課題・PBIに対し必ず一人をつけてしまうケースの場合、すべてのタスクが優先度にかかわらず平行に少しづつ進み、最悪何一つタスクが終わらないという事態が発生する。
- 本来一つの課題に対して複数のタスクが作成して全員で取り組むため何も成果が得られませんでした！と言うことはあまりないのですが、このやり方だと普通にあり得えます
解決方法
バックログリファインメントをきちんと実施するというレベルでしかあまり解決案は思い浮かびませんでした。
ちゃんとPBIをタスクに分解してチームで実行できるレベルに落とし込むという作業ができると良いです。
またここで重要になってくるのはスクラムマスターで、バーンダウンチャートなどで進捗を確認しつつ遅れが出ている部分に関しては、ヒアリングを行う等は対面だと結構やっていた気がします。
コロナ禍になって対面での仕事が難しくなって来ているので、このタスクの分解はまだしも一つの課題に対して複数人数でアタックそしてそのケアの難易度が異常に上がっているという実感はあります。
あんまりにもこういう進め方をしたがる人が多いので、なんだかこういう手法もどっかであるのですかね？中期的に見ると、あの人しか知らないからあの人は異動できないねとか頻繁に元の部署に質問されるとか発生しててあんまり良い印象はありませんでした。
頼られるのが好き?あのチームは私がいないと駄目なんだから...?原因作っといて何言っとるねん。
ACを書いていない
解説と起きうる弊害
これは上の「タスクのアサインをプランニング時に決めてしまう」をやっているチームにありがちです。だって特定の個人しかそのタスクをやらないならACなんか他人に理解させる必要無いもんね。
PBIはチームメンバーであれば誰でも記載する権限がありますが、(たしか)
タイトル: linux対応
概要: ubuntuで使えるようにする
AC: (空欄)
じゃないんだよ。これで他人がやる内容理解できてたら、そいつお前の心読んでるかお前サトラレだからな。
Jiraはお前の落書き帳じゃないよ?
解決方法
PBIはスプリントにのせるタイミングで少なくともACはチームメンバーなら誰でも理解できるように書きましょう。
どういう書き方が良いかはチームの状況次第ですが、少なくとも主語・述語を明記、場合によっては参考資料のURLを貼って他人が見て理解できる物を書きましょう。
ちなみに主語と述語との関係性に重点を置いた文の構成は小学校1年と2年の学習内容らしいです。
そもそもPOがACをチェックしていない
解説と起きうる弊害
メンバーがACを書かないと次第にPOもACをチェックしなくなります。
個人しか理解できないPBIが乱舞し、誰も理解できないタスクが切られていきます。普通はどこかで歯止めがきくのですが、稀にPOが多忙とかだとかPOが複数いると発生する事があります。
解決方法
ACの合意を取らずに何をしたいのだろうなと思う一方、この状況が常態化しておりなおかつ普通に回っているのであれば、そのプロジェクトの今の段階ではスクラムは採用しない方が良いか、回っていると言う認識は当事者だけの幻覚である可能性が高いです。注意しましょう
まだまだあるんだけど、意外と分量が多くなってしまったので、2スプリント目に行こうと思います。