1. WIP(仕掛り中)の同時許容個数を減らす
個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。
2. タスクの切り替えが減る
一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬のムダに該当します。 WIPを制限すればタスクの切り替えが減ります。
3. サイクルタイムが短くなる
サイクルタイムとは、繰り返し行われるプロセス（仕事、タスク、ジョブなど）においてその1回に要する時間のことです。 WIPの制限によってタスクの切り替えが減り、同時に多くのことを行わずに限られたことに集中して取り組むので早く完了します。 早く終わるということは早期に終わったものから価値を得ることが可能であるとともに、長い時間をかけてしまうことによって変更が入ってしまう余地が少ないということでもあります。
4. フィードバックが増える
サイクルタイムが長い場合フィードバックを得ようとしても、タスクの開始時点で何を考えていたのか覚えていないこともあるし、そもそも何のためにそのタスクが必要だったのかすら分からなくなってしまっていることもあります。 ウォーターフォールにおける大きな問題の1つは、要件を決めてから納品されるまでのサイクルタイムが長すぎて、効果的なフィードバックが得られないことにあります（フィードバックを得た場合でも既に対応できなくなってしまっている場合も多く、フィードバックのインセンティブも働きません）。 サイクルタイムが短くなるとフィードバックの頻度が増えます。
5. 品質が向上する
万が一誤りがあったとしても小さい単位で完了していくので、早い段階で誤りを検知できます。 誤りの検知は早期ほど修正のコストが低く、遅くなればなるほど修正のコストが高くなります。
6. チームの成熟度があがる
チームの成熟度はチーム自身によって継続的に自分たちのプロセスを改善することによってのみ向上します。 WIPの制限値を適切に制限していくのも改善のひとつです。
しかし、運用と開発を同じチームでやっている場合、割り込みは発生するものだし、そういうのはどうしたらいいのだろうか。