「決まっているから変えられない」「変えるのは大変だから」という思い込みで、現状の制約の中で仕事をしようとすれば、何か問題が発生するたびに、「すべきこと」はどんどん増えてしまう。
たとえば日本では本番のリリースも、「失敗しないように慎重にテストしないといけないから、たくさんの仕様書を書いてマニュアルテストをします。そうでないと本番にはリリースできません」と現場の方は言う。ところが、社長さんを連れてきてプロセスを見える化して一緒にディスカッションをすると、「この承認は無駄だね。カットしよう」「別に品質にそこまでこだわらなくていいから、早くリリースできるように前倒ししようよ」「そこは現場で判断していいよ」等、一気に話が進む場面をよく見てきた。
「すべきこと」と思い込んでいるだけで、実際省ける要素は本当はもっと多いのだ。

もっとも、仕事の案件の中には納期が絶対のものも存在する。オリンピック用のアプリの納期に遅れてしまったら、仕事そのものの意味を失ってしまうだろう。絶対にデッドラインを割りたくない案件だったら、シンプルに「早く始める」しかない。
あるいは、既に動いているものを「リリースする」と約束すればいい。今では、フィーチャーフラグというテクニックがあり、実際の機能がすでに盛り込まれているが、公開するスイッチをもっており、そのスイッチをオンにしたら特定のユーザのみに公開されたり、全体に公開することができる。先に実装しておき、一部のユーザに使ってもらって、実際に動くし価値もあると判断してから、スイッチして本当の「公開」をすることもできる。これは、Azureや、windowsなどでも広く使われている方法だ。
前述のように、納期は固定して、スコープを変動させるやり方もある。納期に何らかのリリースをするが、実装できたものだけにする。含まれる機能が増減しても、ユーザーにとって価値あるものがリリースできるようにしておく。
機能Ａ、機能Ｂ、機能Ｃがリリースされないと意味がない・・・と言う場面では、機能Ａ、機能Ｂ、機能Ｃを順に作るのではなく、三つ同時につくるが想定よりずっとシンプルなものにする。連携しつつ価値を提供できる単位でつくると、常にリリース可能な状態ができあがる。そうすれば、機能の増減に関係なく「いつでもリリース可能」というわけだ。