The Big Room: Wrangling the Product Team

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

There’s plenty to do to get ready for your first Big Room Planning session...

And an important step is prepping your teams.   This includes your Products team, and as a Scrum Master/PM it will serve the interests of you and your teams to devote some effort to this.  It’s good to set expectations and provide them with information on the benefits they’ll derive from the exercise so that they are motivated to put in the required work.

There’s a popular saying that goes something like this “You have to start at the bottom and work your way up to the top”.   When it comes to spearheading a new initiative like Big Room Planning, however, I’m going to go with one of Peter’s Laws* and say “Start at the top then work your way up.” As mentioned in a previous article in this series, you’ve got to get buy-in at the executive level, so when it came to prepping the Products team at Drillinginfo, we went directly to the VP of Products to share the vision, discuss the process and tout the benefits that (we believed then and later proved out) the entire organization would enjoy.  Once we had that commitment to the experiment from the VP, the Products Team came right along.

One of the hardest things to convince any leader of during an agile transformation or experiment like this is to loose the Command and Control reigns.  Big Room Planning requires that the Product team deliver their vision for the specified development window, in our case at Drillinginfo it is per calendar quarter, but also that they are prepared to negotiate.  The quantity of work that will be delivered toward any high level Feature in that timeframe is based on the development teams’ estimations or forecasts that they work out during the event.  It’s very important to coach the Products team that this is an exercise in negotiation and not a dictate of what will be delivered and when.  Setting this expectation early, and then reminding them during the preceding weeks that this is a collaborative exercise, will guide your Products team toward a more agile workflow.

Explaining the benefits that can come from this exercise is the other crucial point in preparing the Products team.  Again, we only needed to convince the VP of the possibilities and then they spread the word throughout the team.  As the agents of change in our organization, the PMO team had been researching and discussing the benefits of large scale, face to face planning for some time before we presented it to the Products team, so we were able to successfully convey how much a shared vision and collaborative planning would benefit the entire company.

 

The process change required from our Products team at Drillinginfo was minimal.  Prior to our initial Big Room session, our Products team was already delivering a high level yearly roadmap of features that they wanted developed.  In an effort to segment that roadmap into workable sized features, our Director of the PMO, VP of Technology and several Development Leads met with them to review the existing plan, identify the most desired features and essentially assign those features out to our existing development teams for evaluation.  From there each Product Owner provided varying levels of detail to the teams to take into the Big Room Planning session.  

It’s important to note here that there’s a fine line between not enough and too much up-front planning.  Some Product owners spent countless hours writing hundreds of User Stories to take into planning only to find later that many of the stories were discarded or never saw the blue light of a developer’s screen, therefore it was a waste of overproduction.  On the other end of the scale, some Product Owners came into planning with nothing more than high level Features and therefore all of the work of breaking those down and creating User Stories needed to be done on the fly, in a condensed time box.  This can be problematic as well, sending your development team into the beginning of their release cycle with too little information to hit the ground running.  There is a happy medium, and iterating on this process has helped our Products team and Development teams learn to work more collaboratively and successfully.

Let’s take a closer look at this conundrum:  In our experience at Drillinginfo we had a product owner that worked with their BA over several weeks leading up to a Big Room Planning session to develop well written, highly detailed user stories.  The level of effort and the excellent work that was produced were admirable, but nearly 50% of those have not been prioritized to be worked. On the other side of the coin is the Product Owner who says “I want you to find a better way to ingest this data set.  Go.” In this case a team has too little information going into a release cycle to begin the project without performing a time-consuming tech spike or research project, thus 20-40% of their development time may be eaten up before they ever begin usable work, and they end up delivering a much smaller set of Features than did the team with all of the upfront planning.  This is where each organization has to find it’s balance.  Ideally you need to engage with the Product Owner for pre-planning to define and understand a handful (5-10 depending on the size of your team) of Features to be developed and break them down into high-level user stories that will encourage those productive conversations that are the lifeblood of Big Room Planning, and of agile development in general.

Regardless of where your Product team lies on that spectrum, you and your fellow agilists need to understand that implementing a big room planning session will call into play all of your combined facilitation, training and leadership skills. You will be engaged at all levels of your organization and with members all over the org chart. Comb your hair, polish your shoes and get ready to shine!

Author Bio:
Melony R Gibson
Author: Melony R Gibson
CSM and PM preparing to test for my PMI-ACP certification, I am active in the local agile community including being co-facilitator of the Agile Mentoring Peers (AMP) Mastermind group. While I'm a relative new-comer to the software development world with just over 3 years into my journey, I'm an avid agile practitioner who is passionate about the transformative process.