スクラムを大人数で運用したところ💩な結果になった。スクラムを大人数で運用したところ💩な結果になった。2018-11-21スクラムを大人数で運用したところ💩な結果になった。国内にある地理的に離れた3拠点のオフィスで、大きな2つのプロダクトと無数なWeb、API群、データ生成などのサーバを持った部署がある。今まで、メンバーはそれぞれ持っているプロダクトに対して別チームや属人として対応していた。エンジニアのリソースを2つの大きなプロダクトに注力したいため、全員のリソース配分を可視化・最適化をするために大規模なスクラムのLeSSの要素を取り入れた体制を作り1年超運用した。いう振り返ると以下のメリット・デメリットがあるように思う。メリット今まで見なかった人、プロダクトに関われるのは面白いベロシティ(達成pt数)という形でチームの貢献度が表されて、みんなが働いている状況を数字で共有できるデメリット関係者が増えたおかげで、責任が不明瞭になり物事の決めごとに労力と時間がかかる。1週間のスプリントで、見たこともないプロダクトの見積もりと学習をし、数チームと合意し、複数のSMと合意するのは無理ある。スクラムに不慣れな人間がたくさんいる状況は仕方がないが、習熟と効率化が発揮されるのが遅い。人の入れ替え、組織変更を挟むと初期化される...ベロシティを重視するために、無理に計測期間で対応しようとしてプロダクトが壊れる。余裕があるときも、がんばると次のスプリントのベロシティ基準が高くなる力学が働くので、ほどほどにしようとしてしまう。注力以外のプロダクトから人を引き剥がすと愛着がなくなり、放置され壊れていく。プロダクトオーナーをアサインするだけでは運用できない。フリー写真素材ぱくたそ考えのまとめ2つの大きなプロダクトをグロースさせるために、トライアンドエラーとリリース速度をあげたかった。そのために、人的メンバーを増やしたかったはず。そのような背景もあって、トップダウンで案件が降ってくる形になり現場での改善活動ができなかった。エンジニアのみでスクラムチームで動いていたのは良くなかった。開発以外のノイズが増え、集中してプロダクトに向き合う環境がなくなっていたように思う。普通の話だけど、権限と責任の移譲をしっかりやって、コンパクトな組織を維持できるようにしたほう良いと思った。人間なので関係者が増えると、コストが調整コストが増えて、効率は下がる。ゆるい横のつながりは良いけど、チーム責任範囲を決めて落ち着いた状況をつくるのが大事だと思った。小さいチームで無理なく開発できるようにするのがいいんじゃないの?と、将来同じ轍を踏まないようにしようと思ってます。小さく始めず無配慮に大規模にスクラムやアジャイルを導入しようとする人間を警戒しようと思うようになった。12:00スクラムを大人数で運用したところ💩な結果になった。(1)月別アーカイブはてなブログをはじめよう!ctyoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。