January 10, 2010
Solving for the iron triangle with kanban and scrumban
Life is full of limitations: No parking, no running, no diving, no stairway etc.
One of the keys to project management is knowing and embracing the limitations of a project. One of the other keys is being able to help others see and embrace the same limitations.
In software development there’s been a lot of talk about “Fast. Cheap. Good. Pick two”. But I think the most common iron triangle we face is actually “Scope. Schedule. Quality. Pick two.”
Very few clients would ever actually pick Scope and Schedule, and say “Meh. To hell with quality.”
So the real limitations of our discipline are Scope and Schedule, because almost no one wants an on-time piece of garbage, or an incomplete piece of garbage.
There are two strategies that I use to embrace these limitations:
Kanban (fixed scope)
If you haven’t heard of Kanban, I recommend you read up on it as it really is a great system. Here’s just one quick tutorial, and my running list of links.
For me, the essence of Kanban is fixed scope, but flexible schedule. Sure, you can quote a lead time — an average of how long it’s taken features to go from the backlog all the way to done in the past — but that’s an estimate, not a commitment.
This works great if you’ve got clients who are flexible enough to accept a fairly open-ended delivery date.
Scrumban (fixed schedule)
Scrumban is a great transitional step for teams and clients when trying to go from Scrum/Agile or, shudder Waterfall, to Kanban.
In Scrumban you’ll fix a schedule, a release every two or three weeks similar to Scrum. But unlike Scrum you don’t fix the scope for the sprint.
Instead you work with the client and the team to come up with a prioritized backlog of items for that sprint.
Work during the sprint is popped off the top of the backlog stack, so that the most important work (as judged by the client) is done first.
If the backlog stack gets too small, then, aside from celebrating your productivity, the team and client can regroup and fill the backlog up again.
If the backlog isn’t completed by the end of the sprint, that’s OK because we decided to fix schedule (and quality), not scope.
In consultation with the team and the client, you can take the remaining items and start the next sprint with them, or throw them all out if priorities have changed!
Filed under: Kanban, Management
Previous: A time to work, a time to slack
Comments