Demystifying Agile: Rants of a Madman – Yes Virginia, Capacity Planning Is Part Of Agile
If I had a dime for each time a Fundamentalist Agilist told me that “In Agile you don’t do capacity planning” or “If you are doing Agile Team capacity planning then you are not doing Agile” or “Who cares about team capacity?! Iterate until you can ship; whenever that may be!” I’d be rich. These seem to be the same people who go nuts when I share that I’m fine with managers being scrum masters. Go figure… The good news, as with any extremist view, is that there are sane people in the middle that know better based on real world experience.
Truth be told, other than for some very trivial efforts that only ran a couple of sprints, I’ve never ever been involved with an Agile effort that didn’t involve some level of capacity planning. Never. I’ve also never met a successful R&D leader who hasn’t had to do this. When I look at some of these professional Agile “coaches” who shout out that “capacity planning is waterfall” in an effort to block or stonewall capacity planning, most haven’t worked on a team that had meaningful deliverables in the commercial marketplace or in IT after you pull away the layers of their bios or resumes. On the flip side when I ask folks who have really delivered true products under Agile I’ve found that all have had to look beyond the current sprint in flight and plan in some way for future sprint capacity. If they didn’t do it themselves, then somebody had done it for them. I felt vindicated in this view last week when I attended a dinner panel discussion put on jointly by the Technology Association of Oregon’s Developer’s Forum and the local PDMA chapter here in Portland. The entire topic was about capacity planning under Agile and the panel addressed this challenge head on.
The good news is Agile provides us a great framework and unparalleled transparency to do capacity planning like no other methodology. We know how many sprints fit between now and a fixed or desired end date, we know how many sprints we need on the back end for hardening, we know how many sprints we already have loaded with known work from our backlog, we know (or should be learning) the velocity of our Agile teams. What that leaves us with is a number of sprints left in the middle of this release cycle where an Agile team can take on new stories. Top down Agile planning allows us to look at those remaining sprints in the middle, look at the epics and/or stories we think we’ll see come over the transom (even though we may not know what they are today), and identify the pinch points in these sprints were we may require additional agile team capacity or may need to proactively push product owners to begin bumping stories out of our already planned sprints and in to the backlog for the next release.
Proactively solving for this capacity issue helps us identify how to prioritize and stage our projects as well as how to prioritize and staff additional agile capacity when we think we’ll need it. It also helps us land the plane and make our commitments. I know, “I’m doing it wrong.” I just don’t care: so are a lot of us with successful delivery track records over the years with Agile teams so I’m cool with it… As a purist you should be cool with it too if it works, right?
About this series: I love Agile; I also hate Agile. I love how it can free teams to truly delight customers while delivering high quality products on time. I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size. My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.