新しいことではないが、カンバンへの認識がアジャイルソフトウェア手法のユーザたちの間で広がっている。講演やワークショップ、カンバンのカンファレンスが現れ、アジャイルトレーナーたちは、コースにカンバンを組み合わせている。アジャイル実践者たちは、リーンから適用されたこの手法がチームに提供するものを調査している。ボトルネックを明らかにすることからより速く進歩し、より多くの "動き"を経験するチームがより満足することまで魅力的な利点を挙げる。このエコシステムの中で、Simon Bennett氏の The Philosophy of Kanban is Kryptonite to Scrum(カンバンの哲学はスクラムにとってクリプトナイトだ)において、スクラムのプロセスにカンバンを取り入れようと考えている人たちに警告を与えている。カンバンの提案者たちがBennett氏に同意するのは、カンバンの障害に対して攻撃的ではないアプローチが、直ちに障害を取り除くというスクラムの呼び掛けと対立する点だ。
Bennett氏は、ブログでカンバンに反対する暴言でも、スクラムを純粋に守るためでもないと明言して、以下のように述べた。
スクラムを使うつもりで、障害を無視したり、隠したりする場合(または、そもそもそれらの障害を取り上げない場合)、苦痛にあふれた世界で進歩しないことを求めているようなものです。これは、Ken Schwaber氏 と Martin Fowler氏が、だらけたスクラムについて話している時に言っていたことです。(少なくとも技術的負債の観点から)
スクラムもカンバンも透明性を重視しますが、それぞれ異なる方法で扱います。スクラムは明確な実施要請が組み込まれています。この実施要請は、スクラムを成功させるために対応する必要があります。
カンバンによって、チームは障害を“受け入れ”、その影響を測定できます。
Bennett氏によると、スクラムとカンバンは哲学が対立する。「スクラムプロジェクトは、カンバンの哲学が近くにある限り、弱くなる。」 しかし、純粋な哲学を適応することが目的ではない。目的は、品質の高いソフトウェアを頻繁にリリースすることだ。この目的のために、Bennett氏は、実践者たちがどのようなプロジェクトを持っていて、スクラムを使ってどのくらい成功しているかを調査するように奨励する。Bennett氏はどちらを使うのかを決める方法に関してガイドラインを示す。
Corey Ladas氏の2008年の論文「Scrum-ban」において、スクラムをほとんど置き換えるようなカンバンに対する進化的なプロセスを述べた。Ladas氏のアプローチによって、デイリースタンドアップやバーンダウンチャートのような従来のスクラムプラクティスの多くは、修正されたり、置き換えられたりするだろう。興味深いことに、Agile2007で大評判となったCorbis社のカンバンの体験談を発表したAnderson氏は、今ではカンバンの導入に大いに注目している。Anderson氏のもともとのねらいを、Scrumから人々を転換するのではなく、アジャイルの導入に苦労している人たちを助けることだと述べた。Bennett氏のブログは、カンバンを取り入れる前に、チームで注意深く検討することを提案する。チームはスクラムから十分な価値を得ているか? Bennett氏は、続けて述べた。「最前線で本当に活躍しているならば、スクラムに頼るようになると想像します。」
Bennet氏は、「ソフトウェア開発コミュニティのカンバンの本部」となることを目的とする Limited WIP Societyの今後の方向性を示すリーダーではないが、リーダーである多くの人たちがブログに支援するコメントを寄せている。このリーダーには、Karl Scotland 氏やDavid J. Anderson氏が含まれる。Anderson氏は次のように同意する。
えぇ、カンバンは進化であり、スクラムは革新です。私は、この位置付けに十分満足しています。
もちろん、どのツールも間違って使われる可能性がある。Chris Sims氏の記事、 Are Kanban Workflows Agile? (かんばんワークフローはアジャイルか？)は、必要な活動がそれぞれ行われたことを確認するためにカンバンを使う場合、チームの完了の定義を強いるために使われていることを読者に思い出させる。これは、単純なチェックリストのほうがふさわしい仕事だ。そして、 Mitch Lacey氏が、私たちに思い出させることを最近言った。「一日の終わりに魔法の答えがあるのではない。人が他の問題ではなく人々の問題を解決するということが魔法の力なのだ。」