ソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人気を得た。Agile 方法論、特に Scrumの採用が増えている。しかし、すべてが Agileでうまく行っているか？ Kai Gilb 氏は、そう思っていない。彼は、 Agileには重大な欠陥があると言っている。
氏は、Agile の栄光にもかかわらず、 ある重大な欠陥があるという、
Agile に関する大部分の文書は、その栄光について語っていますが、私は、その欠陥について書きます：欠陥は、非常に深刻なので、もし修正されないと、あなたが好きなAgile手法は、去年の流行りだった、ということになります。
氏は、 AgileやScrumの焦点は、間違っている、と言う。これらは、ステークホルダーにビジネス価値を引き渡すことに焦点を合わせていない。 Agileマニフェスト にあるすべての考えは、「開発者にとって都合がいい」ものへのソリューションであると言っている。マニフェストは、ひどく開発者寄りである。ステークホルダーについて述べていない。氏は、 標準的なScrumのプロセス図 を取り上げて、ステークホルダーに与えられる価値が、図のどこにもない、と言う。
Kai氏は、Agileは、最高の優先度であると考えられているソフトウェアの開発に多く、焦点を当ているが、ステークホルダーにビジネス価値を与えることは、２ページ目の 原則のところ にあるだけだ、と言う。
このことは、他の原則といっしょにされました。それはすばらしいが、２ページ目にです。１ページ目にあるべきで、おそらく単独で、もっとはっきりと、述べられる必要があり、目標とソリューションをごちゃまぜにすべきでありません：「よって」は、ほのめかすべきです－他にもっといい方法もあり得ますから－時々は！
氏は次のことを強調した
ソフトウェアを開発することや、好みの開発プロセスやユーザストーリーのことでは、ありません。顧客あるいは、ユーザだけについてのことでもありません。
関係するステークホルダーに価値の改善を届けることがすべてです。それこそが、彼らの関心があることであり、同意できる、最小限のあるいは、予め決めた費用内で、彼らの世界をより良くするものです。
Kai氏の考えに、 pschwarz は、 XPは開発中に繰り返されるサークルによってビジネス価値を加えている、とコメントしている。彼によると、
ビジネス価値は、得たもの、いつ得たか、かかったコストに依存する。何をやるべきか、そしていつを決めるために、顧客は、自分が頼むものにかかるコストを知る必要がある。プログラマは、自分の経験に基づいて、この情報を提供する。それから、顧客は、何が欲しいかを選び、そしてプログラマは、それを作る。このようすは、以下のようになる
1. 顧客：価値を決める
2. プログラマ：コストを見積もる
3. 顧客：価値を選ぶ
4. プログラマ：価値を作る
5. 繰り返す
このサークル度に、我々は学ぶ。顧客は、彼らの提案したフィーチャが本当にどれだけ価値があるのかを学び、一方プログラマは、これらのフィーチャが本当にどれほど難しいかを学ぶ。
Kai氏は、反論して、これでさえも、ステークホルダーに価値を加えていない、これは、明らかにプログラマの視点である、と言っている。開発者が、開発している、そして目標としている、フィーチャではなく、定量的な価値に、焦点を当てない限り、 開発のサークルは、付加価値への単なるリップサービスになってしまうだろう、とKai氏は、述べている。
Kai氏は、更に Agileの「幼児語」が開発者の創造性を殺している、と言っている。Agileは、機能でなく、ソリューションにフォーカスするので、開発者に創造的になる余地を与えていない、と言うのである。更に、 Agileをやっている者は、競争力のある製品を作ることができない、と氏は言っている。
Scrumでは、巨大な、共同で行う やることリストを実行する。システムの重大な「どのくらい良く」という側面には、焦点を当てないで、Scrumは、ソフトウェア開発をタスクのレベルに落としているので、腕がよく、創造的で、知識豊かな開発者を必要としない。開発者は、何を作るべきかは言われるが、製品品質の要求を満足するための最高の方法については、問われない。いかに競争力のある製品を作るかについての理解がほとんど、あるいは全くない。むしろ、逆のことが起きてしまっている。（アーキテクトではなく、アマチュア（ユーザ）によって作られる）ソリューションが要求され、もっと競争力のある選択肢は、システム的に落とされてしまう。
この「幼児語」による要求プラクティスによって、競争力のあるシステムを作っている人たちや高価値を必要とするシステムを作っている人たち、そしてビジネスにとって、人気のあるAgile 手法は、役に立たなくなっている。
Kai氏は、多くのAgileプロジェクトがユーザストーリーとして使っている例を上げた。 購買者として、私は、ショッピングカートに本を入れたいと思う。彼が言うには、このユーザは、完全に間違っている。
何が間違っているのか？ すべて間違っています。さっとブレークダウンしてみましょう。
Kai氏によれば、このユーザストーリーによって、競争力のある製品を作ろうとする、開発者の創造性と熱意が奪われる、と言うのは、このユーザストーリーは、機能を提案するのではなく、ソリューションを実装するように言っているからである。
純粋な機能は、「本を注文すること」です。「ショッピングカート」のような、注文をさせる特定の方法は、開発者がソリューションを見出すのに、本来存在する選択肢や創造性の余地を奪うものです。そのソリューションの方が、機能である「本を注文すること」をもっと良い品質にし、パフォーマンスもよくなるでしょう。
彼が言うには、ユーザストーリーは、開発者にとって、「どのくらい良く」の部分が完全に落ちている。その機能は、ライバルよりも「どの程度」良くあるべきなのか、置き換えるシステムより「どのくらい良く」あるべきなのか、提案されているUIより、どのくらいもっとユーザフレンドリにできるのか、である。Kai氏は、現在の Agile や Scrumのアプローチでは、開発者は、何をすべきか言われている、単なるレンガ職人である、と言う。
強力な Scrumのフレームワークは、大きな共同の やるべきリストになってしまい、開発者に何をすべきかを告げ、開発者は、ただそれをやるだけなのです。
シリーズでは、Kai氏は、 近日、もっと重大な欠陥を明らかにする計画である。 Agile や Scrumのこれらの特定の欠陥について、あなたはどう考えるだろうか？