起源
精益軟體開發一詞起源於Mary Poppendieck 和Tom Poppendieck寫的一本同名書籍。這本書將傳統的精益原則以一種新的方式呈現---作為22種敏捷開發實踐工具之一，並且和其他工具進行了比較。
Mary 和 Tom's 在敏捷軟體開發社區中提出的改進，包括在敏捷開發會議上的幾次演講，已經形成了被敏捷開發社區廣泛接受的概念。 例如：諮詢公司NetObjectives 和C.C. Pace 就使用了“精益-敏捷”以及其他一些列入的概念。
精益原則
和精益製造原則的概念相近，精益開發也可以總結為如下七條原則：
尊重一線人員 工作在一線的人最了解實際情況，他們知道現在發生了什麼，知道當前情況下的最佳應對方法；
他們熟知每天使用的工具、流程、規則，因而完全具備足夠的知識提出改進意見；
要充分尊重一線人員的意見；
消除浪費（或者叫Muda,是豐田管理詞典中的一種特殊的浪費）原則，最初是由Taiichi Ohno（豐田生產方式之父）的理念所採用的。他將如下行為視為浪費：
儲存的等著被使用的汽車零配件生產任何不是馬上就需要的產品不必要的配件移動等待其他配件被生產製造過程中多餘的處理步驟缺陷（質量差） 換句話說，按照精益思維，任何不能為客戶增加價值的行為即是浪費。包括：
不必要的功能和代碼軟體開發過程的延遲不明確的需求繁文縟節低效的內部溝通 為了消除浪費，首先必須能夠識別、認識到浪費。如果某項活動可以被跳過或者沒有這些活動也能達成最終的結果，那它就是浪費。在開發過程中作成但最終被廢棄的代碼是浪費。客戶不經常使用的額外的處理和特性是浪費。等待其他活動、團隊、處理是浪費。缺陷和低品質是浪費。不產生實際價值的、過度的管理也是浪費。以價值流來區分的方法被用來區分識別浪費。第二步就是指出浪費的根源並消滅它。持續不斷的消除浪費直到一些甚至看起來必不可少的過程和步驟被清除。
面對開發團隊以及最終的產品大小的額外挑戰，可以說軟體開發是個持續學習的過程。最佳的改善軟體開發環境的做法就是增強學習。在代碼完成後馬上進行測試可以避免缺陷的累積。不是去做成更多的文檔或詳細設計，而是對各種各樣的想法進行實際的編碼嘗試。用戶需求的收集過程可以簡單地通過給最終客戶演示，並聽取他們的反饋來完成。
使用短周期的疊代（每個疊代都應包括重構和集成測試）可以加速學習過程。在決定當前階段的開發內容並對未來改善的努力方向進行調整時，在客戶端幫助下通過簡短的反饋會議來增強反饋。通過這些簡短的反饋會議，客戶代表和開發團隊會更多地發現在進一步開發時會遇到的主要問題及可能的解決方案。從而，基於已開發出的原型，客戶可以更好地理解自己的需求，開發者也能了解到如何才能更好地滿足客戶的需求。另一個關於和客戶溝通、學習的想法是“基於組的開發”，這種方法聚焦於未來解決方案的約束限定而不是各種可能的解決方案，因此通過和客戶的對話加速了解決方案的產生。
因為軟體開發通常具有一定的不確定性，基於多種選擇的方法能夠達成更好的結果，儘可能的延遲決定，直到能夠基於事實而不是不確定的假定和預測來做出決定。系統越複雜，那么這個系統容納變化的能力就應該越強，使其能夠具備推遲重要以及關鍵的決定的能力。
嵌入質量 質量是在過程中產生的；
如果在開發流程的每一個階段，都能保證產出物的質量，最終產品的質量就能以最低的代價實現；
過程中保證質量能大量減少浪費，質量是過程的一部分；
快速交付的好處數不勝數，譬如能夠使客戶更早地得到產品價值，能使產品更快地投入市場；
整體最佳化 局部的最佳化，若不能帶來整體的改善，將是沒有價值的；
構造一個完整的產品
