Skip to content

Demystifying Agile: Rants of a Madman – Yes Virginia, Capacity Planning Is Part Of Agile

February 5, 2013

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.

Advertisements

From → Agile, Software

2 Comments
  1. Bravo! Your opening paragraph deserves applause. Of course, I’m reading this while I’m wrapping my head around capacity planning on my own Agile project 🙂 I’m also a volunteer for the PMI Agile Community of Practice. I’d love to republish your article on the community blog (with your permission of course). You can contact me through my blog – just click on the Gravatar photo.

  2. Jean Richardson permalink

    Mark, on reading this, I harken back to our conversation about the range of kinds of Agile consultants you have experience with. (BTW, I was at the event you refer to above and didn’t see you in that packed room–surprising as my experience is you stand out in any tech crowd.)

    Some of what you report in your blog about what Agile consultants advise is pretty darn sobering—okay, wacko. Capacity planning IS part of Scrum, which, last I checked, was the dominant Agile framework at your current roost. It’s possible to make a case that detailed capacity planning is most applicable in the early phases of a Scrum adoption, but calculating capacity is critical to a good commitment, and I always teach it when helping a new Team stand up or facilitating a turnaround. (Poll SM’s I’ve coached, and they should each be able to wave a capacity planning worksheet at you.)

    I just went back and checked the electronic copies of the training materials I have from my own CSM training with Ken Schwaber, and, yup, capacity planning was in there, too. I seem to remember him talking about the SM having a responsibility to protect the Team and calculating capacity before making a commitment was part of that. Further, when doing release planning, Cohn provides guidelines for dealing with forecasting velocity. The relevant Teams used this in a turnaround situation you are familiar with to help them get to a release plan once they knew their projected capacity.

    HOWEVER, the key quote from your post above is:

    “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.”

    “Top down” is an interesting phrase in this case, but setting that aside, the notion that the backlog will be managed based on capacity and that management of the backlog may require moving some stories to the next release is key. Once a release plan is in place, it can be easy for “fear of symbolic death” to set in, and intelligent and skilled management of the plan against emerging reality goes right out the window.

    For what it’s worth, I, too, was dazzled at the array of well behaved product ownership on display last Thursday night. And, I still have my eye out for the kind of Agile consultants described in this blog. I believe they are out there if you say so. It just seems that whenever I think I’ve come across one of those hairy buggers I start asking them questions about what they really mean and why they think what they seem to say they are thinking and the hair falls right off them and, often, a fairly sane human being ends up standing there in a pile of hair that was their fur coat. Next time you see one, call me.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: