Coaching backlog

One challenge as a coach is deciding where to spend your time – do I help team A or team B or split my time between them? If I had the capacity to give both the attention they need then it’s not a problem but of course there’s never enough time to go round. Like so many things, it comes down to prioritisation… but what goes in the backlog? Personally, I tend to think in terms of experiments, e.g. will smaller stories improve the team’s ability to respond to changes in direction?

(I should add that when I say “team” I’m actually thinking about the people in the dev team, the other people they work with, the stakeholders, and the system which encompasses them.)

But who creates the backlog items? Obviously, there are things which come up in conversations with the team members and stakeholders, but there’s also observations and comparisons between the current system and a potential “next level”. Now, we all know there aren’t actually “levels” but there are things we tend to observe in high performing teams compared to relatively new teams. I’m not going to touch on “assessments” here – I’ll save that for a future post.

In order to share this backlog with the coaching stakeholders (which includes the team) rather than a simple backlog of Stories, something like a POPCORN board can help support the conversations around which experiments to try and what the outcomes were. POPCORN is a backronym for: Problems & observations; Options; Possible experiments; Commitments; Ongoing; Review; Next – you can watch Claudio Perrone, aka Agile Sensei, present POPCORN at Agile Testing Days 2017.

Priorities Change

One of the Product Owner’s key responsibilities is to ensure the backlog (well, the top of it, at least) reflects the stakeholders’ priorities. Of course, the certainty of those priorities decreases the further out you try to look: we ought to be pretty confident in the priorities for the next couple of weeks, but less so for a couple of months away, and if we’re thinking 6 months ahead then it’s quite a low certainty. (Your timescales may be different but the “funnel” model should still be applicable.)

The reason certainty decreases the further into the future you try to predict is that things change! Hopefully, you’re learning more about your customers over time, but also their needs change. There are also changes in technology which mean something you couldn’t build last year is now possible, or maybe the costs have dropped so now it’s worthwhile.

Like everything we do in Agile, it’s about feedback: we think the customer needs X so let’s build just enough so that we can test the market, i.e. a Minimal Viable Product. Based on the learning from that we should adjust the backlog, so putting too much effort into the details of a plan that’s likely to change is waste. No matter how much you believe you know what your customers need and spend time drawing up a 12-month plan, if your plan doesn’t change then either (a) you’re a genius, (b) you’re really lucky and should play the lottery, or (c) you’re not listening to your customers.

Even in a tightly regulated market, things change – if your product is constrained by legislation, there can be changes resulting from interpretations of the law or even changes in the law itself. If your plan is unable to reflect those changes in a timely manner, don’t be surprised when someone beats you to the release of a “fully compliant” version.

The key is to have a plan which gives enough context for the current/imminent work but which is flexible enough to react to changing information, as well as to have people who understand that a plan could (and should) change when circumstances change.

Maybe that’s the most important piece: having people who ask why when a plan doesn’t change?