Betting the house on it — How one of our programmes got into gambling (Its sprints 😊)

Across all of our development teams we want to create an environment of experimentation. This means trying new ways of working, adopting a technique we may have seen outside of Redgate or considering a different technical practice to make the way we work more efficient.

In late 2019 I and a few of the other Prod Dev team members visited Manchester to speak to the Co-Op digital and BBC Digital teams. Along with seeing Peter Crouch walk into the BBC Sport office and bumping into the presenters of CBeebies in Costa (Andy really is as tall as he looks on TV) we got a chance to sit down with both of these companies to share how we and they work. We covered a number of areas from making really effective OKRs (Objectives and Key Results) to the role of architects.

One of the things that I took away from the Co-Op development teams is how they encouraged their teams to show progress against their OKRs. In the past at Redgate we’ve sometimes struggled to create OKRs that stuck with a team that didn’t require very laggy metrics or long running OKRs that ended up being more of a KPI. The way the teams at Co-Op and the BBC give a sense of progression against their OKRs was by adopting sprint bets for every team.

So what are sprint bets?

Exactly as they sound. It’s a collaborative agreement between the team doing the work on why they think the work they are about to do will progress their OKRs. This isn’t to be confused with sprint goals which are more focused on the specific work or feature. Instead the bet is more concerned with the outcome of the work — the crux of why we adopted OKRs 3 years ago, i.e driving outcomes over outputs.

What did we do in our programme?

We experimented with sprint bets in one of the dev teams first as part of their typical sprint planning sessions. At first this proved tricky to differentiate from a sprint goal but in time the team got better and better at it. To the point that one of the other teams adopted the same practice, and then the final team in the programme.

So in each sprint planning session the team would sit down and plan their sprint, agree the sprint goal but also add in a sprint bet. We also built an experiment around the adoption of sprint bets to detail what we were doing and the potential outcomes (Both positive and negative)

What did these look like?

An example is in the picture but other bets the teams adopted included: -

• Releasing static data support for one of our products would increase usage — the result was a growth in reoccurring usage of the tool due to the new functionality being built
• Researching Git support for one of our products will increase our confidence that this is the right thing to build — the result was that our hypotheses was confirmed and the team then built the feature
• Releasing GIT support will unblock our users from adopting an extension on one of our products and increase reoccurring usage of the tool — it did with usage now steadily climbing

Has it helped?

In two of our teams this definitely had a positive effect. Both teams were able to demonstrate how the small steps being taken in individual sprints were contributing (Even in small ways) to our OKRs progressing. Other positive practices came off the back of this experiment as well, including the adoption of Grafana to display dashboards for the teams OKRs and the sprint bets we were adopting.

Due to the adoption of Grafana for the teams bets and OKRs other teams in the department quickly adopted the same method.

In the third team the bets were tried and although initially the team continued with them they were found to be too similar to the sprint goals the team had in place. This alongside the fact that the team in question are in a very early adopter phase for their product (Including an EAP phase) meant the team didn’t find them as useful.

Where do we go next?

Whilst this experiment has certainly been a success for 2 of our 3 teams we don’t want to stop there. We’d love to see other teams trial this approach. Particularly those teams that have found it difficult in the past to quantify how the work we do right now has an impact on moving our OKRs.

We also want to spend some more time thinking about the value of the bets we make. Much like the high rollers in the casinos we want to start having a level of confidence in the bets we make for the work having a positive influence on an OKR. This means our next experiment will be all about how confident we are that the bet will make a positive change on an OKR. We will literally be betting the house on some of our bets to see where it takes us in the hope that the saying ‘The house always wins’ won’t be true!

We’ll provide another update on how this has gone in the next few months but in the meantime if you are interested in trying this in your own team, contact us at proddev@red-gate.com or drop a message here.