Karl Scotland氏(リンク)は、かんばん(参考記事・英語) システムにおけるワークフローあるいは段階が、クロスファンクショナルで協力的なチームというアジャイルの理想と反対のものであるかを検討する議論(リンク)を始めた。彼はまず、かんばんボード(参考記事)の各段階はウォーターフォールのフェーズに非常によく似ている、と発言した。次に起きた議論は、段階は必ずしも引き継ぎではないことを明らかにし、その他の洞察ももたらした。
Karl氏はかんばんシステムの検討から始めたが、これはウォーターフォールのプロセスに非常によく似て見える：
分析 -> 構築 -> テスト -> リリース
次に彼は典型的なスクラムのタスクボードを考察したが、これは次のようなものである：
未着手 -> 作業中 -> 完了
Karl氏はその次に、システムを通してどのように作業が進んでいるかについて、このタスクボードでもっと情報を明らかにする方法を探した。多くの環境では、「完了」とマークされた機能（ストーリー）がすぐにリリースされたり、製品の環境に置かれることは無い。こうした状況では、「製品に導入可能である」ことと「製品に導入されている」ことの区別をボード上でマークして明確にすることが出来る。たとえば、もし作業中のものがリリース待ちの山を作っていることがボードによって明らかになれば、ビジネスは継続的デプロイ(参考記事)の採用によってプロセスを最適化することを決断するかもしれない。
Karl氏は続けて、タスクボードの段階を細分化する方法を見出している。彼はまた、段階毎の作業をもっと示唆していると思う名前を提案しており、最終的には次のフローにたどり着いている：
計画を練る -> 説明する -> インスタンスを作成する -> デモをする -> 清算する
次に起きた議論は、単にラベルを変えても振る舞いは変わりそうにはないが、もっと大きなソリューションの一部となるかもしれない、とRobin Dymond氏(リンク)が述べたことから始まった。：
よりすぐれたアプローチは、同じ場所にいるクロスファンクショナルなチームを使うことによってプロセスを単純化し、テストをプロセスの前面に引き出し、顧客も含めた全員が品質に責任を持つようにすることです。この場合、私は違う言葉を使うでしょう。なぜならプロセスの各段階は、機能をデリバリするためにチームがどのように一緒に作業をするかということよりも、ずっと重要ではないからです。
Keith Braitwaite氏(リンク)は次のような意見をもった：
かんばんのようなプロセスを、リニアな、ゲートで受け付けて引継ぎを行う、やり直しが予定されていない解釈を可能にするだけではなく確実に提供する、と言葉（や絵）で説明する限り、多くの人々が抵抗するだろうと思います。
この意見はアジャイル主義の大部分と一致する。より密接なフィードバックのループを促進するために、引継ぎを避けてシーケンスを排除するか短くしようと努めるのである。たとえば、アジャイルのテスト駆動開発(参考記事) のプラクティスには次の段階がある：
テスト -> コーディング -> リファクタリング
実際には、開発者はこれらを短期間で繰り返すので、タスクボードでそれを追跡するのはうんざりするだろう。
リーンの観点からは、重要なことは機能がシステム（継続的なフロー）を通して継続的にプルされることであり、これは作業をキューに入れてバッチで仕上げるのとは対照的である。従来のウォーターフォールのプロセスは、バッチ・アンド・キューのアプローチの一例である。全ての要件を集める作業がまとめて行われ、キューに入れられた要件は設計作業が始まるのを待つのである。同様に、設計作業はまとめて行われ、その成果物はコーディング等のためキューに入れられる。
継続的なフローのシステムでは、機能をバックログから取り出し完了するまで継続して作業する。もし開発中に特定可能な段階があれば、かんばんボードを利用して仕掛かり中の作業が止まっている個所を特定することが出来る。これらのボトルネックはプロセス改善の対象となるが、それは作業がシステムを通して効果的に流れるのを保つためである。
David Draper氏(リンク)は次のように述べている(リンク)：
機能のワークフローはまさしくそれです。機能は、ひらめきの瞬間からデプロイして使用され、価値を生み出すまで、いくつもの状態を経ます。かんばんにおけるワークフローは、個人間の引継ぎを命じるものではありません。同様に、機能が確実に各状態をスムーズに素早く進むようにして、チームはその機能に群がらないという要求はありません。
Vasco Duarte氏(リンク)は、この議論はプロセスやツールに集中しすぎており、仕掛かり中の作業を減らすという、かんばんの大事な点を外していると感じた。
なぜ気にするのでしょうか？実際のところ、かんばんのシーケンス（リリースするためにバックログから取り出した１機能）はとても短い期間（１日、もしかすると2/3？）に関するもので、このシーケンスは、分析、設計、実装、テスト、実装と非常によく似たものになるでしょう。もちろんリニアではありません。なぜ議論するのでしょうか？機能は今では少人数のグループに割り当てられますので、もしそれが「シーケンスを中断すること」を意味していても、彼らは何をすべきか知っているでしょう。
確かに、もしもかんばんボードが必要とされる各作業が生じたことを確認するために使用されていたら、それはチームの完了の定義(参考記事)を実施するために使用されているが、その役目は簡単なチェックリストのほうが適している。
みなさんは、かんばんボード上の状態はウォーターフォール・プロセスの各段階のようだと思われるだろうか？もしそうであれば、その類似点は表面的なものだろうか、それとも重要なものだろうか？コメントを残し、みなさんの考え方を共有して欲しい。