Limiting Work in Process… Are There Any Other Options?
by Mike Cottmeyer, 1 April 2011 | Lean Development
This post is from LeadingAgile by Mike Cottmeyer. Click here to see the original post in full.
One of the big wins of any agile method you pick… Scrum, Kanban, Extreme Programming, AUP… is that you get a built-in ability to balance capacity against demand. This natural throttling of work helps us better manage expectations between the customer and the team. It allows the team to work at a sustainable pace, dramatically reduce thrashing, and helps everyone get more predictable over time.- Scrum has us meet with our Product Owner once every couple of weeks during sprint planning. The Product Owner gets to decide what we build. The team gets to decide how and how much, based on their historical velocity.
- Kanban introduces visual controls and explicit work in process limits to make sure that teams don’t confuse being busy with actually creating value. We can’t start more work, until the other work we’ve already started has left the queue.
When we get in the business of comparing the merits of the various agile approaches, we all kind of assume that limiting work in process is a good thing… it’s just a matter of how of best to accomplish that goal. That said, I’ve actually encountered a few organizations over the past few months that don’t value limiting work in process… they value saying ‘yes’ and then letting the chips fall where they may.
It is politically safer to say ‘yes’ now, give it your best shot, and then deal with...read more
