Embracing Empowerment — A Little Prep Goes A Long Way

Hi I’m Dan, a back end software engineer and agile evangelist working in Waitrose Digital on a cross-functional initiative to add more accurate stock control for certain locations. Over the past few years we’ve been on a journey to become more agile in our ways of working, and to embrace CI/CD tooling and a DevOps culture enabling us to deliver exciting new features and capabilities to our customers in shorter times.

As a direct result, our teams have become more empowered and have a greater degree of autonomy. This is a wonderful thing, but as you might expect has also come with certain challenges! One of those challenges is getting people to look at delivery in a different way that delivers small pieces of incremental value, but whilst still enabling teams to find effective ways of working for themselves. I imagine many of you reading this post have been through similar transformations so may be familiar with some of these push backs…

• “We have too many meetings.”
• “Our estimates are always wrong, because things change.”
• “Refining upfront just creates more work.”
• “The thing that is being built cannot be decomposed into smaller pieces.”

The above list contains examples of objections I’ve had when it comes to having dedicated refinement sessions for story elaboration, though it is far from an exhaustive list! My current team had some of the above reservations when we first formed, which resulted in what I refer to as “planment”. What I mean by this is a single meeting, in which teams try to do backlog refinement and iteration planning at the same time. Whilst this may seem logical at first thought, it’s a deceptively difficult task, and is setting your team up to fail right from the blocks.

We were lucky to have some excellent support from agile coaches, to help us drive towards improved ways of working. Through greater understanding of the Scrum framework (since we utilise 2 week Sprints), and drawing on professional experience from our coaches we were able to come up with effective ways of working that significantly increased our delivery cadence (metrics are a wonderful thing!). The below graphs are examples of the stark contrast in our iteration burndown charts over a 3 month period (12 Sprints). As can be seen, the number of story points delivered between the example iterations has almost doubled, with a more regular delivery over time rather than lots of large deliverables, and minimal mid iteration scope changes.

Taking the example I mentioned earlier about planment, we utilised the framework mechanisms (such as retros) to get us all to shared understanding of why it’s important to do backlog refinement ahead of Sprint planning and below is a summary of what we came up with:

So why is it so important to do good backlog refinement, and why don’t we do it all in Sprint Planning?

All of the objections listed above, could to some degree be addressed by avoiding “planment”.

The “we have too many meetings” objection, is often people objecting to the amount of time spent in said meetings and how productive they feel they were. No-one likes walking out of a meeting with a brain that feels like mush because of the sheer amount of content and switching between goals. Context switching is well known to be inefficient, and by keeping these meetings clearly divided it allows the attendees to focus on the goal at hand.

The “our estimates are always wrong, because things change” is often a result of a lack of refinement. If you’re doing all your refinement in Sprint Planning, then you are likely to miss questions because you are rushing to refine the tickets, and come up with a Sprint plan in your timeboxed meeting. This gives no time to reflect on the tickets and can result in unclear scope due to a lack of analysis.

As for “the thing that is being built cannot be decomposed into smaller pieces”, this is of course sometimes true. However, this is often not the case and is a common cause of over-committing to Sprint deliverables. Doing upfront analysis can often reveal unknowns, that can inform more logical breakdowns of work, or suggest the need for a spike. Spikes are a not immediately obvious way of decomposing work, but can greatly help since when you go into the actual ticket the unknowns are solved and the scope is clearer.

This is a great example of us going through the “forming/storming” phases of the Tuckman model but in an enjoyable way due to the fact that we were allowed to make our own decisions, whilst being provided with the support required to do so, rather than having our processes dictated to us.

Using this approach, combined with the CI/CD techniques mentioned above, we’ve managed to deliver an MVP of more accurate stock management for a small set of products, which has prevented overselling of these products with a plan to roll out to a much larger set of products soon. The long term goal is to roll this capability out across the whole product catalogue, to decrease customer substitutions and to improve customer satisfaction. This incremental approach has allowed us to focus in on the details of certain challenges without getting lost in the overall solution and to get some fast feedback on the aspects already delivered.

In summary, empowerment can be a double edged sword as it requires more ownership and responsibility; however, it enables truly collaborative working in a highly satisfying and engaging environment. If your leadership team has given you the gift of empowerment, embrace it and strive forward to achieve great things (and slay the dreaded planment)!