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.
Kanban discussion
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"…