IPA のまとめによれば、よいモノはよいチームから生まれるとされている。良い製品を作るにはチームを良い物に育てる必要があるとしている。
自律的なチームや自己組織化されたチームが複雑で変化の激しい問題に対応できるということは、Elastic Leader Ship でも語られていた。チームを自己組織化されたものとするために、バス因子の除去や知識の共有、作業のオープン化などが求められる。この原則もまた開発者だけではなく、開発に関わるチーム内のすべての人に対して求められる。誰かが誰かの作業に依存すること無く自分の作業をできるようになれば、開発される製品の品質やスケジュールの改善が見込まれるかもしれない。
IPA のまとめによれば「進捗も品質も現物で」ということ。つまり、現物じゃないもの、動いていないものは品質や進捗を測る目安にはならない。
ソフトウェアは実際に動かしてみるまで問題や課題に気がつくことができないため。この問題とはプログラム上のバグだけでなく、ビジネス的な観点からの見当違いや見落としなども含んでいる。
この原則はあくまでも顧客との対話の中での話である。顧客に対して進捗を報告する場合について動作するソフトウェアを提示するべきであって、開発者の中でのコミュニケーションを言っているわけではない。例えば顧客に対して進捗の報告を行う場では、全体の設計書とそれに対する完成度合いを報告するのではなく、動作をするソフトウェアを提示して動作する部分、しない部分、テストに合格している部分、していない部分を提示するべきである。
これらを実践するためには、顧客に対して説明をする場合だけではなく、スケジュールを作る段階から準備をしておく必要がある。また、同時にガントチャートへの否定でもある。ガントチャートはタスクの開始日付と完了日付を記入し、進捗度合いを埋めていくことになる。しかし、これはパーセンテージによる管理方法であるし、そもそもパーセンテージは担当者や管理者の主観である以上、正しい数値にはならない。さらに、パーセンテージは進捗や品質を保証するものではない。そこで、スケジュールは「終了日までにタスクを完了させる」というシンプルなものとなる。このとき、顧客に対して意味のある動作するものを提示できるように、適切な粒度で機能やスケジュールを分割する必要がある。
実際、アジャイルな開発を実現するためのプラクティスとして、ストーリーポイントの導入とイテレーションがあるわけだが、適切な粒度とストーリーポイントを割り振ったタスクを用意しておくことで、動作可能なソフトウェアを顧客に対して提示することができるようになる。
IPA のまとめによれば「一定のペースでプロジェクト」を進行するべきである、ということ。
この原則の背景には、ソフトウェア開発の中でプロジェクトのゴールを目指して過負荷な状態を求められるケースが存在しているということがある。タスクが詰まってしまって残業や休日出勤を開発者に要求することがある、ということだ。無理をして一時的に開発のペースを上げたとしても、長いスパンで考えるとトータルのパフォーマンスとしては低下している。
IPA の資料によれば、タスクの均一化や生産性の可視化、それらを行ってペースの設定を行うように提案をしている。資料には書かれていないが、実際にはこれらのタスクや可視化したペースを顧客と共有することが必要である。実際、この原則の原文では The sponsors, developers, and users と、製品開発に関わるすべての人がペースを維持することに貢献するべきとしている。