- Written by Lee Allison
“Aren’t you guys doing off-site big-room planning?”
I had been working for Drillinginfo, a small-medium sized player in the oil and gas data field in Austin, TX, for almost six months when I heard that phrase. In fact I was sitting in a training room when I first heard it. In the room with me were several other members of our company’s PMO team: some project managers, Scrum masters and a few business analysts. The speaker was a consultant from an Agile tool vendor who was there training us on how to use his company’s tool, and we were having one of those end of the day, far-reaching industry conversations that can either be really fun or as boring as... well, a room full of boring things.
During the course of the training it had been brought up that we were having some pretty major pain points, all centered around the fact that we were growing out of our small Scrum roots. About a year earlier we had implemented Scrum and, predictably, it had had great impact on the development teams themselves, but it had not yet penetrated anywhere else in the organization. What we didn’t realize then, but were about to learn all about, was that we needed to take the next step into the world of larger Scrum.
"Teams are getting better at planning
and feel more comfortable pushing back
on requests for too much."Anon feedback from our fourth iteration
You see, what can sometimes be lost is that “by the book” Scrum only talks about implementations for single, independent development teams. At the time of this writing core Scrum has no guidelines for operating with other development teams, marketing, sales or anyone else. But few, if any dev teams actually operate this way, and thankfully Scrum is starting to recognize and remedy this shortcoming. Drillinginfo was at that point in its Agile journey. Single-team Scrum had been implemented across multiple teams, and we, the project managers, Scrum masters, and business analysts were all searching for that next step. We had a collective “What now?” look on our faces.
Of course, scaled Scrum has been around for a few years. There are many different names and acronyms, but for the most part they all share one big drawback: They are heavy, heavy, heavy. In many cases their target audiences are the huge code shops with hundreds of development teams working on major software efforts that total millions of lines of code. That’s all well and good if that’s who you are, but we weren’t. Drillinginfo sat comfortably in the “no longer a mom-and-pop but not yet listed on the Dow” zone where so many companies sit. In fact, the large companies targeted by most scaled Scrum efforts probably had more salespeople than we had in our entire organization.
"Our team had a much clearer picture
of the requirements from Product"Anon feedback from our first iteration
But that doesn’t mean that there aren’t useful lessons there. Lessons that could provide as much benefit for you and your organization as it did for us. This is the first in a series of articles about one of the highest-impacting and easiest-to-implement lessons anywhere within the larger, scaled Scrum world: Big Room Release Planning. The Twitter version of this is pretty simple: “Get everyone together and agree on a release plan.” Naturally it’s never quite that easy, but we’ll try to shed some light on the process, the preparation and the details as much as is possible. All of the articles will be full of real-world experience and great advice from the folks who brought Big Room planning from a cool idea into a mature, eagerly awaited event for our organization.
Speaking of people; during my learning journey through Scrum I’ve had the pleasure of working with some amazing people, and none better than while I was at Drillinginfo. But even better, some of those folks have agreed to join me in writing these articles. Over the next few months you’ll see new articles being posted here on AllisonAgile.com by these great agile-loving folks: Mary Orcutt, Melony Gibson, Midhun Kadavil, and Angela Antony. Not only do I consider these people great friends, but great agilists who have seriously “been there, done that” in the world of software development. Truly, I am humbled that they are here helping me.
Also, we're going to be balancing these articles for both Kanban and Scrum, both of which are in use here at Drillinginfo.