アジャイルコーチングで学んだ78のこと

みなさんこんにちは。@ryuzeeです。

78 Things I Have Learned in 6 Years of Agile Coachingの記事が素晴らしいので、78個の項目を意訳にてご紹介します。「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられています。

アジャイルについて説明させてくれるように頼む人の数＝アジャイルメンタルモデルの数±2
分散した開発では各サイトのチームごとに愛とスクラムマスターが必要だ
フットボールテーブルはあなたの最良のアジャイルなツールのうちの1つかもしれない
地理的分散はタイムゾーンの違い以上の問題がある。その場合はインフラのサポートが必要だ
ローカルのイベントやオンラインのメーリングリストやカンファレンスやカジュアルな集まり等を通じてアジャイルコミュニティに精力的に関わることには十分な価値がある。
プロダクトオーナーを持つことは譲れない
積み荷崇拝スクラムを回避しなさい！
アジャイルチームには楽しさが必要だ
最高のアジャイルチームと企業ができるかどうかは奉仕するリーダー次第だ
本当にアジャイルな文化を持つことは、チームが独力で作ることができる以上のことだ
アジャイルな開発は、あなたが喜んで時間と費用を費やす場合のみ、費用の削減につなげることができる
アジャイルの醸成と拡大のための素晴らしいアプローチはリーンの「Flow Pull innovate guidance」だ
バーンダウンチャートはチームの完了へのコミットメントに関係しており、個人のパフォーマンスやタイムトラッキングに関係しているわけではない
あなたのスプリントバックログが製品価値の提供を反映していることを保証しよう
エスカレーションは継続的なプラクティスの改善においては、アジャイルでもリーンでも役に立たない
成功のためには、あなたの上司から必要以上の小切手帳をもらってくる必要がある
他のチームに拡大を試みる前に、あなたのアジャイルチームのプラクティスを醸成しなさい
スタンドアップミーティングの明確な終わりの印を持たないことは、問題の発生につながりやすい
Flowのリーンの原則は、アジャイルチームが彼らのプラクティスをしっかりさせるためのガイドをする
リリースのビジョンについて本当にコミットしたいなら、リリース計画ミーティングに全員同席させよう
コマンドコントロールのスクラムマスターはチームの知力を減らしてしまう
同じ場所にいるチームは、分散しているチームに比べて、より簡単により早く、高いパフォーマンス、高い信頼を得られるようになる
開発場所への訪問、IM、Skype、Facebook,Yammer、ビデオ会議、その他の技術を使った頻繁なコミュニケーションは分散チームが仲良くし、愛を感じることを助ける
アジャイルチームでは、チームが素晴らしくなり永続するために、健全な摩擦が起こる
ベロシティはチームのもので個人のものではない
「かんばん」はチームが継続的に価値を流してることを測定する新しい指標となっているので、注意を払わなければならない
プロダクトオーナー不在もしくは多すぎるプロダクトオーナーは、アジャイル風になってしまう：優先順位や受け入れに際して定義可能な意思決定がない
プロダクト会議はステークホルダーを管理したり、バックログがひっかきまわされるのを最小化する効果的な方法だ
ストーリーポイントはチームがカレンダー時間やチームメンバー数とストーリーの複雑度、努力、疑問を分離するのを助ける
ストーリーはお互いに相対的なサイズを持っている。タスクだけが努力見積りを持っている
うまく書かれたストーリー（小さくて、役割に対する利点について書かれている）は嘘をつかない。要求は、内容がおおざっぱであるため、嘘をつくことがある
プロダクトバックログは常に優先順位付けする
プロダクトバックログはタスクリストではない。タスクはチームによる見積りと計画が終わって初めて登場する
アジャイルは、従業員のQOLを向上させる
素晴らしいチームは協力的なメンバーから成り立っている
アジャイルは放置されてしまうメッセージは作らない
ペアプログラミングはチームの気づきとコードの完全性を向上させる
チームの完全なコミットメントを取る際は、同意をとるようにし、強制的な約束やコマンドコントロールはしない
効果的なチームミーティングには仕組みと訓練が必要だ
アジャイルの価値と原則についてコミットしよう。あなたのプラクティスはそれに従うことになる
透明性はアジャイルの長所であり、懲罰のためではない。
アジャイルとはコミットメントに関することであり、ツールに関することではない。ツールはチームのコミットメントとそれらの可視化をサポートする
孤立状態で決定を下すプロダクトオーナーはアジャイルではない
アジャイルチームはストレス満載な場合でも敬意と思いやりを発揮する
ふりかえりをしないチームはアジャイルではない
ふりかえりは非難することではない
ふりかえりはプロセスとワーキングアグリーメントの継続的な改善をもたらす
もしチームのワーキングアグリーメントがないのであれば、すぐ作ろう
もしワーキングアグリーメントを壁に掲示してないなら、すぐ掲示しよう
ベロシティを知るまでは、あなたが使うキャパシティは積極的におさえるようにしなさい
アジャイルな経験をブログに投稿しなさい。あなたが思うより多くの人があなたの経験を聞きたがっています
テスト駆動開発は単によいコードを作るだけではない。よりうまく受け入れてもらうためのより良い会話の場を作ります
アジャイルアーキテクトとプロダクトオーナーはプロダクトバックログの順位付けのために、一緒に作業する
アジャイルチームにはリリーススケジュールのリズムに組み込んだ形で「hackathon」のようなブレイクを与えよう
キャパシティの利用状況が高いのは悪いことだ
品質はみんなの責任だ
素早く小さいインクリメントをすることは我々の作業について情報を与え、より早くフィーチャーのセットを生みだす
リーンは私のアジャイルランゲージに大きなインパクトをもたらした
「一番の人を雇用する」という言葉はアジャイルにおいては陳腐だ
賢く雇用し、安く雇用しない
新たなメンバーを雇用する時は、チームの同意が必須だ
5段階の計画を利用しよう。ビジョン、製品ロードマップ、リリース計画、イテレーション計画、そして日次計画だ。
リリース計画は私のお気に入りのアクティビティのひとつだ
チームと利害関係者は次のイテレーションを見通すためにリリースプランニングに出席する
FYI、よいブレインストーミングは大量のポストイットとノートと賢い人たちが必要だ
ファシリテーションスキルに注意を払え。あなたは意思決定を乗っ取ってはいけないし、他人にそうさせてもいけない
アジャイルミーティングを集中した、目的に沿った、タイムボックス化された状態に保ちなさい
アジャイルミーティングにおいては電子機器はOFFにしておこう。集中したミーティングは生産的で、時間通りに終わる。
アジャイルにおける最大のコストカットレバーは「優先順位付け」だ。
新しいプラクティスを試すことを恐れるな。あなたのベロシティと品質は新しいプラクティスを導入したあなたに感謝することになるかもしれない。
アジャイルはソフトウェア以外にも有効だ。組織の内外で活用しよう
古いツールは新しいトリックへの対応に立ちはだかっている。MS Projectはアジャイルへ進む道ではない。
チームのアイデンティティは重要だ。個人のヒーロー性は危険だ
ふりかえりにおける個人の感謝は、アジャイルチームの信頼を成長させる場を作るすばらしい方法だ
アジャイルへの成熟度は、CMMIのような成熟度モデルではない
アジャイルとウォーターフォールの論争は終わった。価値あるものを提供し続けることに注力しなさい
アジャイルはスピードをあげるために、スピードを落とすよう我々に要求する。
私はアジャイルが大好きだ