スクラムチーム

この質問は言い換えると、マネージャー兼プロダクトオーナー、マネージャー兼スクラムマスター、マネージャー兼開発者のありなしです。 スクラムガイド2020では、スクラムチームの構造や説明責任に関する記述は以下のようになっています。 スクラムチーム内には、サブチームや階層は存在しない。 自己管理型であり、誰が何を、いつ

みなさんこんにちは。@ryuzeeです。 スクラムチームのパフォーマンスを測定したいとステークホルダーに言われて悩んでいるスクラムマスターは多いと思います。 今回は、スクラムチームのパフォーマンスはどうやって測ればいいのか、何を気をつけるといいのか考えてみましょう。 具体的なメトリクスについては、別の記事で触れる予定で

司会とファシリテーションの違いの境界線は必ずしも明確ではありませんが、司会は会議やイベントの全体的な進行をスムーズに行うことに重点を置く一方で、ファシリテーションは議論と意思決定のプロセスに重点を置きます。 ここでは両方をまとめて扱います。 スクラムガイド2020ではファシリテーションや司会という単語は登場しませんが、

開発者を社外から集めるというのは大きく分けると2つです。 開発をまるごと別の会社にやってもらう（別の会社に発注する） さまざまな会社から派遣やSESで来てもらったりフリーランスの方にチームに入ってもらったりする どちらの形態なのかによって多少の違いはありますが、以下のような問題が起こりやすいです。 開発のノウハウ

スクラムガイド2017では自己組織化という単語が使われていて、以下のような記述がありました。 自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。 一方で、スクラムガイド2020では、自己管理という単語が使われ、表現も変わりました。 また、自己管理型であり、誰が何

スクラムチームは10人程度までがよいとされています。 これは人数の増加に伴ってコミュニケーションのオーバーヘッドが大きくなることが大きな理由です。 したがって、10人を超える場合はスクラムチームの分割を検討することが一般的です。 また、人数が10人を超えなくても、認知負荷の観点からスクラムチームを分割することもあります

組織によっては、スクラムチームの開発者が複数チームを兼務することがあります。たとえばAのプロダクトに半分、Bのプロダクトに半分といった具合です。 スクラムではこのような兼務を明示的には禁止していません。 ただしスクラムガイドは「やってはいけないこと」をすべて定めるようなものではなく、最低限の原則と守るべきことを述べたも

スクラム未経験者が新たにチームに加わるときは、その人の経験や力量にあわせて受け入れをすることをお勧めします。 いきなり、各種イベントに参加して、意見を言ったり、作業をセルフアサインしたりするのは難しいことが多いですし、価値観や原則、チームの作業の仕方や完成の定義を理解していないうちに作業をしてしまうとチームにも影響を与

誤解のないようにいっておくと、個人としてインフラやアプリを始めとするさまざまな領域の設計や実装を全部できないといけないわけではありません。 開発チーム全体を見た時に必要なスキルを網羅していることがだいじです。 外部のチームへの受渡しや依存が増えれば増えるほどリードタイムは長くなり、計画作りも難しくなります。 また、いま

まずは、チームが作成しているプロダクトの売り上げ、利益、キャッシュフローの計測が基本です。 つまり、生み出した価値を基準にします。 これらは短期的に達成すれば良いわけではなく、継続的に達成していく必要があります。 その上で、これらの指標に結びつく内部の指標に何があるのかを考えてみてください。 成果との関連を確認せずに一

実行責任や説明責任、結果責任については、従来どおりマネージャーが一端を担うはずです。 つまり実行そのものについてはスクラムチームに委ねたとしても、マネージャー自身はプロダクトオーナーやスクラムマスターと協働する必要はありますし（この場合マネージャーはステークホルダーになります）、マネージャーの責任が担保できないような場

評価の目的は何ですか？ チームメンバーとして、チームの業績に貢献するための能力、やり方の改善のための評価でしょうか？それとも給与を決めるための評価でしょうか？ それらは、全く違うものですので、まずはそこを分けて考えると良いと思います。 つまり仕事がうまくなるようにするためのフィードバックは頻繁に行う必要がありますし、期