How We Plan At Bonial

How We Plan At Bonial

Dan Cripe

Today is the first day of our quarterly planning ritual here at Bonial. As I write this the teams are huddled away passionately discussing, digesting, challenging, and estimating their candidate work items.  We have over a hundred people from 25 different countries and multiple offices working through dozens of epics.  By tomorrow we’ll have a solid plan agreed upon by the engineers, designers, testers, data scientists, operations specialists and product managers as well as their stakeholders.

It wasn’t always like this.

When I arrived at Bonial a couple of years ago, there was no documented roadmap or cohesive prioritization process.  The planning horizon ranged from intra-day for emergencies to a couple of weeks for most other items.  No-one had a clear understanding of what we were working on and why.  The stakeholders didn’t trust engineering and everyone was unhappy.

Getting from there to here hasn’t been easy.  Over the next few posts I’ll walk you through how we got to where we are today.

But to understand the journey we have to start at the beginning-ish…

In 2014, Bonial was a mature startup with seven or eight years under its belt.  We had a very successful mobile and web app being used in a dozen or so countries.  The product development crew was organized into four scrum teams, an ops team and a design team and was responsible for developing all of the user facing systems as well as the critical business systems.  All-in-all, there were 40-50 people working together in product development.

Unfortunately the team was less effective than it could and should have been, in large part due to lack of clarity and governance.  For starters, not only was there a lack of a coherent roadmap, there wasn’t even any clear record of what work was currently being executed.  We had tickets in Jira scattered across a dozen or more “projects,” Trello boards, stickies on blackboards, and whole lot of ideas in people’s heads, but there was no one place a stakeholder could go and get a simple answer to the question: “what is the status of my project?”

What roadmap planning was done happened in a bi-weekly session called the “roadmap committee.”  This was a group of senior managers from the extended product development organization and stakeholders who reviewed development progress and made decisions on new initiatives.  I’m being nice when I say that it wasn’t much fun.  The selection of initiatives being governed was somewhat arbitrary and the value provided by the committee was questionable.  We often hashed over the same questions over and over again.  Unfortunately it was the only vehicle in place to provide some level of two-way communications regarding roadmap and status.

The end result was that no-one was happy.  The stakeholders and customers felt like their needs were ignored and that, when their projects were accepted, delivery was too slow.  The engineers felt like they were in a blender of arbitrary and incoherent requirements over which they felt no sense of ownership.  And the product management team was stuck in the middle, working to adjust to the latest change and managing both unhappy stakeholders and engineers both.  The end result was perceived and real low performance and sense that we were set up to fail.

So we decided to change this; the solution would require a great deal of work in many areas across the people/process/technology spectrums.  It all came together, though, in planning.  Stay tuned for part 2.