Life is full of limitations: No parking, no running, no diving, [no stairway](http://www.youtube.com/watch?v=WStE470Nu4s) 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](http://en.wikipedia.org/wiki/Project_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](http://www.kanbandistilled.com/), and my [running list of links](http://delicious.com/chris.heisel/kanban).
For me, the essence of Kanban is fixed scope, but flexible schedule. Sure, you can quote a [lead time](http://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-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](http://leansoftwareengineering.com/ksse/scrum-ban/) is a great transitional step for teams and clients when trying to go from Scrum/Agile or, *shudder* [Waterfall](http://www.waterfall2006.com/), 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!
