Agustin Villena氏は、カンバンの制限を受け入れるように、管理者側を説得するのに苦労している。 彼は、次のように書いている。
私は、今コンサルタントとして働いているのですが、管理者側とうまくいってません。カンバンボードは、明らかに開発者にとって、完全なオーバーワークになっていることを示しているのに、彼らは、効率とストレスにおけるそのマイナス面を認識していないのです。
今の課題は、チームに割り当てられるプロジェクトのトータル量を制限することです。しかし、チームのマネージャは、入ってくるプロジェクトをフィルターするように、説得できない人です。そしてまた、余裕は無駄だ、と考えています。
なぜ我々は、余裕を無駄、と考えるべきでないのでしょうか？ Tom DeMarcoによれば、余裕は、「変化をもたらすのに必要な自由度」である。ということは、余裕は、動いているものが一緒に固まってしまわないようにする、組織に必要な潤滑油と考えることができる。
Mary と Tom Poppendieck氏は、彼らの本、リーン ソフトウェア開発：アジャイル ツールキットの中で、キューイング理論の見地から見れば、余裕は、ずっと基本的な意味を持っている。「高速道路のように、容量に幾らかの余裕がなければ、満足できるサービスを提供することはできない。あなたの組織に余裕がなければ、あなたは、おそらく顧客に最高レベルのサービスを提供していないでしょう。」と言っている。
Amir Kolsky氏は、余裕は無駄である、という非難に簡潔な反論を述べている。
余裕は、人々がダラダラしている、ということではない。余裕は、ボトルネックにドンドンものを詰め込むようなことをしない、ことです。
人々を忙しく他のことをするようにできます。
では、カンバンの制限に対する抵抗の問題原因となるものは、何なのか？ Nader Talai氏が考える のは、カンバンの制限に対する管理者側の抵抗は、おそらく部分的には、チームのパフォーマンスをどのように測るかによって、動機づけられているかもしれない、ということである。
管理者側は、何を重要視しているのか、すなわち何に基づいて、彼らは、評価されているのかを知っていますか？ボードは、彼らが重要視しているものを示していますか？[...]
例えば、管理者は、欠陥無しでリリースされた、とは対照的に、開発終了によって評価されているかもしれない。私は、12ヶ月前に見積もられた日程を基に、時間通りプロジェクトを終了したかどうかで、ITチームを評価している組織で働いたことがあります。この組織では、時間通りにリリースしたかどうかが重要で、何をリリースしたかや品質は、どうでもよかったのです。
Tomo Lennox氏によると、もっと教育が必要かもしれない。
管理者側がたくさん仕事を与えれば、それだけ多くの仕事ができあがる、という単純な考えを持っているなら、彼らに何かを教えてやらない限り、彼らは、変わらないでしょう。
しかし、あなたの真意を理解させるために、ジョークの力を過小評価してはいけない。「人々は、ジョークの後は、よく聞く」。Lennox氏は、次のように書いている。
警察官が自転車を引いて走っている少年を見たので、手を貸そうとして車を止めた。「パンクしたのかい？」と警察官は聞いた。「いいえ」と答えて少年は、その自転車を引いて走っている。警察官は、車で追いかけて少年にまた話した。「じゃ、君の自転車のどこが悪いんだい？」「どこも悪くないよ」と少年は言って、走り去った。警官は、また車で追いかけて、もう一度聞いた。「じゃ、どうして自分の自転車に乗らないんだ？」「学校にすごく遅れたので、自転車に乗る時間がないのさ」。そして彼は走り去った。