Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

アジャイルって言ってもふつうのコト

アジャイルの啓蒙として、以前、社内SNSに書いたことを転載。

#今あらためて読んでみても、
#この「ふつうのコト」がなかなかうまくできていないのだけどもね...。

-------------------------------------

吉羽さんのブログより。

 Scrumで失敗する7つの方法
 http://www.ryuzee.com/contents/blog/3224

#ジェフ氏の原文ページは認証付きで見れなかった。残念。

スクラムアジャイルの用語を含む文節を「素直に除去して」書きなおしてみた。

 失敗する7つの方法

・ビジョン、ビジネスプラン、リリースのロードマップを持っていない。
・適切な順番で優先順位付けされていない。
 技術的な問題を含む、全ての仕事が含まれていない。
 適切なサイズになっていない、正しく見積もられていない、
 詳細化できるようになっていない。

・はっきりと思いを伝えない。
・フィーチャーをブレークダウンしていない。
・信頼、透明性、真実がない。

・発言しない人がいる。
・意味ある情報が伝えられない。
 (タスクの開始、停止、完了、見積もり超過、個人的な問題を含むプロジェクトへの妨げ。)
・チームが自己組織化されていない。
 (聞いた情報を元に作業を再計画すべきだ。
  ミーティングで最も妨害となる事項の除去のために60秒ルールを使う。)
・酷いミーティング(15分以上、ファシリテーションが欠如した)をする。

・チームに奉仕、集中していない。
 (毎日妨害事項を解決する、毎日個人の問題を取り扱う。)
・良いヒューマンスキル、ファシリテーションスキルを持っていない。
・良いリーダーシップスキルを持っていない。
 (誠実でないことを黙って見過ごす、嘘や怠慢、情報の隠蔽。
 優先順位付けした妨害事項のリストを持たず、妨害を解決できない。
 個人の変化や問題に対応できない。)

・必要な技術や知識領域を持っていない。
・妨害を除去できない。
・記載されていない作業をしている。
・マルチタスク。
・過度な仕事量がある。
・テストを早期に実行することができない。
・エンジニアリングに関するプラクティスを改善できない。
・占有して自由に使えるリソースがない。

・チームが振り返りをしない。
 (チームは改善のための振り返りをしない。振り返りの提案をすることができない。)

・ビジネスモデルを持っていない。
・十分なリソースを用意しない。
・均一に出荷することができない。 -ムラ
・負荷がかかる構造を避けることができない。 -ムリ
・無駄を除去できない。 -ムダ
・チームが除去できない妨害を除去することができない。
・チームを平凡なチームから押し上げるようにチャレンジさせることができない。


こうやって読んでみると、あらためて
アジャイルって言ってもふつうのコトじゃん」と思えるはず。
ようは、名前をつけて、枠組み化して、「こうやってやろうよ」と言っているだけなのだ。

目指すところは同じなのである。