ウォーターフォールとアジャイルにおけるマインドセット

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

Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。

以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。

第1世代アジャイルと第2世代アジャイルの類似点
	ウォーターフォール	第１世代アジャイル	第2世代アジャイル
要求	要求はそれらの実装を始める前に前もって詳細化されるべき	顧客は自分たち自身の要求を完全には理解していない。もし顧客が理解していたとしても開発者たちが完璧に理解することはできないだろう。システムの一部分を作りそこから学ぶことでインクリメンタルに要求を見つけていくほうがよい。	第1世代と同じ
価値のデリバリ	全てを完全に揃った状態でデリバリするのがベスト	価値をインクリメンタルに届ける	第1世代と同じ。.リーンやKanban、リーンスタートアップは、最小のマーケット出荷可能フィーチャーやMVP等をさらに重視している。
主要領域における第1世代と第2世代の手法の違い
どうやってウォーターフォールからの移行を開始するか	無し	チームから開始する。組織の残りの部分を改善するのに問題となっている障害を明らかにする。必要なら新しいロールやプラクティスを定義し、チームに根付くまでそれらに従う。そしてそれらのプラクティスを行う上での障害を取り除く。	全体のバリューストリームに対する総体的な視点を持つ。フローやそれに従った作業における障害事項の根本原因を見る。いま取り組んでいることから開始し、現在のロールや責任や肩書きを尊重する。見える化することで理解を促進する。
どうやって文化を変えるか	なし	いくつかのプラクティスをチームがより良くなるまで繰り返し使い続けることで文化を変える。これはXPの12個の原則すべてを行ってなくても止まってしまうことはないよと言われているような初期のXPチームによくあてはまる。スクラムではスクラムをよりよいスクラムになるように適切に取り組んでいない人を非難することでこれを継続的に行う。この取り組みは、プラクティスにしたがって(プラクティスにしたがっていない組織の他の部門による妨害事項に遭遇したときでも)つまることがなくなるまで続けられる。	いまいるところから文化を変え、理解を促進し、継続的な改善ができる文化を作ろうとする。注: 最初から大きい変化を指し示せず、どれだけ成功したかを言えないという点においては最初は満足行くものではないかもしれないが、数年後になっても成長し改善し続けているようになるだろう。
人をリスペクトする	個人的にはチームの他の人をリスペクトはするが、プロフェショナルとしてのリスペクトは行わない。チームに何をすべきか指示するマネジメントがいる	リスペクトとはプロフェショナルとして、人として尊重することを意味する。どうやって仕事を自己組織化して行うかについて理解させる。	第1世代のアジャイルと同じようにリスペクトする。そしてさらに人の状況についてもリスペクトする。すなわち、人は多すぎる変化は好まないということだ。人の学び方を受け入れ、人が成長できるような環境をつくろう。ただやれと言ってもやられることはない。技術的な問題ではなく人間的な問題であることを認めること。
アジャイルとは何か？何に基づいているか？	なし	アジャイルは価値と原則に基づいている	アジャイルは価値と原則と人間の振る舞いと製品開発フローに基づいている。
学習のアプローチ	するべきことを言い渡され、必要な基礎スキルのトレーニングを施される。	やりながら最良の方法を学ぶ。理解はしばらくの間仕事を完了させたあとで得られる。イテレーションの最後でのふりかえりはプロセスを再考し改善するのに十分な頻度で行う。	なぜ提案されたプラクティスがうまくいくのかについての理論もある状況で仕事をすることで最大限に学習することができる。何を行うべきであるか学習することは複雑になるかもしれないし、人を複雑の中に送り込むことになるかもしれない。しかし、プラクティスと理論の組み合わせは不可欠だ。Rother's Toyota Kata のような継続的学習モデルが理想的だ。
組織と要求へのフォーカス	詳細を提供しトップダウン式に行う	要求は顧客にフォーカスする。要求はストーリーの形式で集められ、管理可能な単位に分解される。ストーリーはいくつかまとめてリリースされる。	要求はビジネスの必要条件としての価値を踏まえて顧客にフォーカスする。第2世代の手法における製品ポートフォリオの見方によって、単に顧客価値にフォーカスしてしまうことは、他の顧客群に対しての価値を作ることに切り替えなければならないときに、この顧客への価値を作りつづけてしまうかもしれないということが分かる。要求は、どのストーリーを開発しリリース計画に含めるのかを決めるために、最小の市場投入可能フィーチャーやMVPといった考え方を使ってビジネス上の可能性の側面から作られる。
どうやってカイゼンを成し遂げるか	労働者に対して一番良い仕事のやり方を指示するマネジメントにフォーカスする	仕事の中でもっとも良いやり方を理解しようとしたり、マネジメントに対してマネジメントがどのようにチームを助けることができるかを言う人にフォーカスする。	マネジメントに仕事で最善を尽くせるような環境を作らせたり、人々がその環境の中で自己組織化できるようにする。
人とプロセスの関係	プロセスを人がやるべきことを伝えるために使う	プロセスよりも人を重視する	人とプロセスをともに重視する(例えば、プロセスは重要だが、プロセスはそれを使う人によって作られるべきだ。)
マネジメント	マネジメントがチームにプロセスの利用を命令する	明確なマネジメントを行うこと以外の初期に忘れられている何かによってチームが邪魔されるべきではない。チームはイテレーション中もイテレーションの最後でもチームに対して仕事の進捗や結果の可視性を提供する。多くのスクラムコミュニティにおいて、最終的には鶏と豚のたとえ話を捨ててしまっている一方で、マネジメントの態度の変化も指し示している。マネジメントとチームが同じ信条をもって近い場所で働いていればそのような話が起こるというのは信じがたいことでもある。	チームはマネジメントが価値あるソフトウェアを作るためには不可欠であると認識する。第1世代のアジャイルによって提供される可視性に加えて第2世代の手法ではワークフローも可視化する。これはチームのワークフローの厳密なポリシーによって得ることができる。
ワークフロー定義のレベル	ワークフローは定義されており固定である。チームはワークフローに従おうとする	チームのワークフローに入るときと出るとき以外にはワークフローを明確に定めることはできない。	ワークフローはチームのキューに入るところからデリバリされるところまで定められている。
手法のスコープ	全体のバリューストリームを見る	チームにフォーカスする	全体のバリューストリームを見る
チーム構造	チームは交換可能であり、稼働率の向上のためにまとめられる。	人々をクロスファンクショナルチームとして組織化し、固定する。	クロスファンクショナルチームはより効果的だが、必須ではない。
ワークロード	計画は先に完全に作られ、チームに渡される	バッチサイズにまとめてチームによってプルされる。イテレーションと呼ばれるタイムボックスによって暗黙的に管理される。	チームによって小さい単位でプルされる。WIPの制限によってワークロードは厳密に制限される。
他の領域における第1世代と第2世代の手法の違い
タイムボックス	使われない	イテレーションを管理するためにタイムボックスが使われる。	フローを管理するためにタイムボックスを使うことは推奨されないが可能ではある。ケイデンスがアクティビティやレビューやデータ収集の調整のために使われる
適合性	仕様書に適合していることが重要	適合性に対して奮闘するようなものではない	あなたが知っている最良のワークフロー（学習すると変わる）に適合していくことは良いことだ
技術的な設計	前もってシステムを設計する	設計はほとんど必要でない。全体の設計は出現した設計によって可能となる。