對於軟件開發來說，源於豐田生產管理系統中的“看板系統”是一種用於安排工作的非迭代方法。它並不使用固定時長的迭代和計劃會議的工作方式，而是完成先前的工作後才從backlog中取得新的故事來做的工作方式。
Dave Nicolette （Valtech公司的一個敏捷教練）說道：“在敏捷社區中，有一些人似乎變成了幹零活的人。他們僅掌握一種敏捷工作的方法，卻把它來遇到的解決所有問題．當你只會接管道時，那麼所有的事情在你眼裏就都都成了管道。”全面學習並擴展敏捷技能而不僅僅是那些SCRUM或XP的基礎是非常重要的，比如熟悉像看板等其它工具。
在軟件開發團隊中有各種各樣的方法來實現看板系統。James Shore（《敏捷開發的藝術》一書的作者）就寫過一種：“團隊從backlog中拿到一個故事後，實現它，一旦完成就交付它。然後再拿下一個故事，實現並交付它。他們的工作就是完成並儘快地交付它，團隊一次只做一個故事。”依James所說，讓看板真正發揮作用有幾個關鍵因素：
- 最小化可交付的特性（MMF）：一個MMF是最小粒度且有商業價值的特性。MMF被放在一個隊列中維護，（很像Scrum中的產品Backlog），但對隊列的大小有嚴格的限制（James認爲應該是兩到三個，最多七個）。
- 在線生產：團隊總是在做最重要的事，直到完成它，而且在一個時段內只做這件事，並把它分成很多小且離散的任務。
- 估算：放棄正式的計劃與評估，而假設所有的MMF都有相似的大小。通過記錄完成每個特性的平均時間，來估計隊列中剩餘的特性還需要多長時間。
- 緊急任務：偶爾也會有緊急任務。要爲緊急任務留有一個通道，這個通道會繞過了隊列，一旦緊急任務走上這個通道，那就要求團隊儘快地完成它．所以額外的緊急任務不受正常的backlog的限制。
- 缺陷：一旦出現缺陷，如果任務還沒有完成的話，就要立刻修復它，否則就被放入backlog中。
David Anderson（《敏捷管理》作者，而且是看板系統的力薦者）說道，他的成功密訣就是：“關注質量，減少在線產品，根據需求及優先級來平衡能力”。
Corey Ladas回答關於“爲什麼使用‘拉’的方式？爲什麼使用看板？”這樣的問題時，說道：
具有不同技能的人不得不在一起工作，來交付產品的特性。別做那些沒人要的特性；別寫那些你編程時不需要的規範；別寫你測試不了的代碼；別測試那些你不能部署的代碼；……我認爲看板比其它已知的工具更有效地解決了這一問題。
David Laribee爲其前任僱主Xclaim引入了看板，因爲在使用XP的兩年後，他還是面臨很多障礙和麻煩。另外，他感到，在計劃、回顧和演示上浪費了很多時間。而且最終每一個好的敏捷團隊都會有自己的工作流程，＂當然，我們不可能在第一天就找到這樣的流程．我們首先要根據已知且廣泛應用的實踐建立一個好的基線，這些實踐包括TDD，滾動式計劃等等。然而，好的敏捷團隊會持續調整他們的過程以適合他們的產品及客戶的需要。＂
加入看板的郵件列表，查看更多的關於看板的討論。
InfoQ中有關看板的文章：敏捷的未來方向， 使用看板讓敏捷項目可視化，Scrum-ban Paper Adds Kanban to Scrum。