People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy.
–or–
My team builds a component. Your team builds a component. I use your component. Don’t build features that your clients (like me) are not asking for. Don’t accept my requests if you can’t build them now.
Pretty simple to describe in theory. Some subtlety in practice. A kanban is a tool, and like any tool, it is meant to solve a problem. I think kanban solves this problem more efficiently than the known alternatives.
paranoiase's me2DAY | 29-Sep-08 at 9:55 pm | Permalink
강성희의 생각…
Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test….
Matthew Podwysocki | 23-Oct-08 at 3:44 pm | Permalink
DC ALT.NET 10/2008 Recap – A Look at Kanban Software Development…
Thanks to everyone who came out to the DC ALT.NET meeting on "A Look at Kanban Software Development"…
Learn Lean Software Development and Kanban Systems | 26-Aug-09 at 3:13 pm | Permalink
[...] Why Pull? Why Kanban?, Corey Ladas Posted by Ben Griswold Management, Presentations Subscribe to RSS feed [...]
Agile Australia 2009 Day 2 Review « CDS 43 | 23-Oct-09 at 5:52 am | Permalink
[...] Corey Ladas – Why Pull Why Kanban – JIT backlog – only do what you can do, lean has articulated what XP folk were talking about [...]