ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

こんなスクラムには気をつけろ!?

こんにちは。@ryuzeeです。

支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。

なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。

  • 全体
  • なんでもアジャイルでやろうとする
  • そもそもアジャイルを採用することが目的化している
  • プロジェクト初期にマイルストーンやスケジュールを決めていない
  • 十分にトレーニングを受けていない
  • 認定資格をとればそれで十分だと思っている
  • 全体の要件やアーキテクチャを考えずいきなりコードを書く
  • 予定できることなのに、「アジャイルだから」と予定しない
  • ドキュメントを書かない
  • 文化や考え方を変える必要があるのを理解しない
  • 形式にこだわりすぎる
  • 基本に従わずいきなり現状の制約にあわせて変形しようとする
  • 会社のルールを交渉なしに無視する
  • カイゼンしていない
  • 標準化に従うよう求められる
  • 権限が委譲されていない
  • スクラムチーム
  • いきなり分散型をやろうとする
  • チームのやり方を決めていない
  • チームのやり方を守らない人を放置している
  • そもそもチームに必要なスキルがない
  • 自分の立場を守ろうとして情報を隠す
  • 困っている人がいるのに助けない
  • チームのやり方がずっと同じ
  • 面倒くさそうな仕事がいつも後回しになる
  • スクラムマスター
  • スクラムマスターがタスクをアサインする
  • スクラムマスターがプロダクトオーナーの言いなり
  • スクラムマスターがチームに対する妨害を排除しない
  • スクラムマスターが忙しすぎる
  • スクラムマスターが遠い場所にいる
  • プロダクトオーナー
  • プロダクトオーナーがプロダクトに必要な知識を持っていない
  • プロダクトオーナーが忙しすぎて捕まらない
  • プロダクトオーナーがステークホルダーの言いなり
  • プロダクトオーナーがステークホルダーに会わない
  • プロダクトオーナーがステークホルダーの意見を想像する
  • スプリント
  • スプリントが外部から妨害される
  • スプリントレビューがない
  • ふりかえりがない
  • スプリントの長さが可変
  • スプリントの長さが足りないといって途中で長さを変える
  • スプリントレビューで動作するソフトウェアをレビューしていない
  • 同時にたくさんのプロダクトバックログアイテムに手をつける(のでスプリントの最後の方まで完了しているものがない。いつもギリギリ)
  • デイリースクラム
  • デイリースクラムがタイムボックスに収まっていない
  • デイリースクラムが同じ時間に行われていない
  • デイリースクラムを報告メールで代用する
  • デイリースクラムが単なる報告会になっている
  • ふりかえり
  • いつも同じ問題がでる
  • 取るべきアクションを決めるが結局誰もやらない
  • ふりかえりの場で個人を責める
  • プロダクトバックログ
  • そもそも固定スコープ
  • プロダクトバックログが大きすぎる
  • プロダクトバックログの受け入れ基準があいまい
  • スプリントに入ってから、そのプロダクトバックログがReadyじゃないと分かることが多い
  • プロダクトバックログのメンテナンスをしていない
  • プロダクトバックログの供給が間に合わない
  • 機能でなく、実装レイヤーで分割してしまう
  • 優先順位がついていない
  • プロダクトバックログがなぜかタスクのバックログになっている
  • 完成の定義
  • 完成の定義があいまい、または存在しない
  • 完成の定義を満たさないものを完了にしてしまう
  • 完成の定義を途中で下げる
  • 自動で検証できるものを手作業で検証する
  • 見積り
  • 毎回オーバーコミットして、それが守れない
  • 見積りが毎回はずれている
  • 外部からオーバーコミットを求められる
  • いつも残業してコミットメントを守ろうとする
  • 最初から残業をあてにしている
  • 進捗管理
  • フィーチャーではなく、行動がモニタリングされている
  • 他のプロジェクトやチームとベロシティを比較する
  • メトリクスが見えないところにおいてある
  • 外部への報告用に大量のメトリクスを要求される
  • コーディング
  • コードが特定の個人に紐付いている
  • テストを書いていない
  • テストで異常なカバレッジを求める
  • リファクタリングしていない
  • CIしていない
  • CIが落ちても気にしない

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 見積りってなんだろう?
次の記事 AzureのBlobサービスにブラウザから直接ファイルをアップロードする

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World