Mike Cottmeyer has a post on limiting work in progress which is a topic I’ve wanted to write on for a while now, but haven’t had the time to do so. While I differ with Mike (and many others) that Kanban is an “agile method” – I think we need to do better as an industry and distinguish between these methods so as to not misinform – his point on the need to limit work in progress needs to be made and be made very often.
I’m no Scrum aficionado, so I can’t speak to it as a project management methodology with all the authority in the world, but I have been involved in agile software development in some capacity or the other over the last decade and would suggest that most teams leveraging agile methodologies and methods struggle with managing capacity, in spite of iteration planning and estimation based on velocity. In my experience, estimating based on the past work is only really relevant if upcoming work is very similar, if it’s not, then you’re really guessing but this is a a topic for another day.
This is why I’m big proponent of Kanban – it makes limiting working in progress an explicit property. You have to constrain your development system (and beyond as is possible) to fixed amount of activity based on the individuals in the system (and not necessarily on estimates of previously done work) and manage work in a pull based manner. This would seem like a no-brainer, but many development teams thrash because their are no limits to how much work the team is actually doing. Items get dumped on team members and they are expected to complete everything on time with the highest of quality, sorry ain’t going to happen.
One of my favorite John Wooden quotes is:
Don’t mistake activity for achievement
If your team is working real hard, but doesn’t seem to be getting much done, maybe you need to try limiting how much work is being done in the first place. Limit work in progress explicitly. You might just learn something.