Does Mastery Matter?

Firstly I have to mention the inspiration for this post is a recent(ish) episode of The Agile Pubcast where Geoff Watts and Paul Goddard (both in the UK) were joined by Chris Williams from Canada, so this one matched many of my interests 🙂

Chris mentioned sporting events to see in Toronto but he missed that the Wolfpack has joined the North American Rugby League and (hopefully) we’ll get to see some rugby again soon.

I will give him kudos for recommending the Loose Moose – I’ve worked close to it for a few years and have enjoyed many of the beers they have on tap. I’m definitely in for a meetup if Paul & Geoff make it to Toronto! (Blanche de Chambly is fine but try adding orange juice to turn it into a beermosa!)

Their topic was “the concept of mastery as a discipline, and how failure is still a stigma”. Definitions of mastery include “full command or understanding of a subject”, “outstanding skill; expertise”, and “possession or display of great skill or technique”; in general it relates to knowing a subject thoroughly.

Personally I see it more as a journey than a destination – unless your chosen subject is quite tightly constrained then there’s probably always more to learn. In my experience, often when I think I’m close to reaching a peak I discover that it’s a false peak and the real peak is further, or sometimes that there are multiple peaks that I could strive for.

Whether it’s a journey or a destination, I believe mastery is essential. But does everyone need to master everything? No, of course not – for one thing, it’s not possible to master everything! Also, that’s part of the purpose of being a team – each team member brings their own strengths and interests. There used to be a popular concept of “T-shaped people”, meaning an individual with expertise in one aspect and a broad understanding of others, and then teams would be the sum of these Ts (and similar shapes).

Whenever I discuss mastery it’s a fairly safe bet that I will bring up one of my favourite films: Jiro Dreams of Sushi (2011). It focuses on 85-year-old sushi master Jiro Ono, his renowned Tokyo restaurant, and his relationship with his son and eventual heir, Yoshikazu.

I find it amazing to watch someone who has spent decades mastering his art and to hear him talk so profoundly about his approach: “You must dedicate your life to mastering your skill. That’s the secret of success and is the key to being regarded honourably.”

How do agilists and sushi chefs get better? Incrementally. 🙂 “I do the same thing over and over, improving bit by bit. There is always a yearning to achieve more. I’ll continue to climb, trying to reach the top, but no one knows where the top is.”

As a prog rock fan, one of the musicians I follow is Robert Fripp (of King Crimson) and despite being recognised as a great guitarist he still practices for multiple hours every day. (Here’s a recent video clip of him talking about practice.)

I believe it’s important to take pride in what you do, and that means not just wanting to be good but wanting to improve. Those improvements often don’t come easily, and that’s where the discipline comes in – no-one can make you better if you don’t want to improve, so start by identifying the area(s) you want to master.

Watching the F1 Grand Prix this morning was a reminder that being at the pinacle of motorsport requires lots of practice; repeatedly rehearsing for various situations (e.g. a pit stop) is how teams build mastery and resilience.

It’s also interesting to hear the drivers talk about learning from their experiences; they focus on finding something which can be improved for next time, not wallowing in how they failed. They study how a problem occurred, identify the root causes, decide what to change, and then implement it. With minimal testing time between races, F1 is like testing in production – a mistake can be expensive so you try to minimise the risk but when something goes wrong (because eventually it will!) you make sure to learn as much as you can.

When I see failure being stigmatised, it’s often down to a misunderstanding of how we work. We cannot be right 100% of the time, so we try to reduce the risk by working in teams (“two minds are better than one”) and making small experiments. The evaluation of an experiment should show the hypothesis is accepted or rejected – the experiment isn’t a failure.

For example, if an online retailer were to propose that changing the “buy now” button to red would result in more sales, then they could conduct an experiment. The result might be that it does show an increase in sales; alternatively, it may show no increase. That is not a failure – it is a new piece of information. If the “no increase” outcome is called a failure, then we will end up demotivating the team and killing creativity.

Here’s an experiment to try: if we refer to the outcome of experiments as “discoveries” rather than “failures” then we will see more enthusiasm for conducting experiments and that will lead to a better product and a happier team.

Keep your backlog brief

Your product backlog is probably too long. A quick way to tell is to look at the items at the bottom of your backlog and consider two questions: do you know their origin (who requested them and why), and assuming the team works through the backlog and eventually completes those items will they still be valuable? There’s a good chance that the answer to at least one of those questions is no, and that’s an indication that your backlog needs attention.

I often refer to Henrik Kniberg’s “Agile Product Ownership in a Nutshell” video because he covers so many key points, especially the need for the PO to say “no” so that the backlog remains relevant and realistic. The backlog should not be a place where ideas go to die! When a stakeholder says “I really need feature X” they’re probably hoping to see that feature delivered in a few weeks or maybe a couple of months – if the PO has to tell them it’s going to be 6 months or more, then why are we doing agile?

Aside from the benefit of setting realistic expectations with your stakeholders, keeping your backlog brief makes it easier to see what’s there. (This is especially useful if you use a tool like Jira which randomly adds new items to the top or bottom of the backlog!) There is also less effort invested in creating those backlog items, which means there’s probably less resistance to throwing them away when the direction changes. The same can be true for the sprint backlog. If your sprint backlog is long and unwieldy then the root cause may be that the team are breaking things down into overly detailed tasks, over committing in sprint planning, or have too much capacity (e.g. sprint is too long, or too many people in the team).

One concern I’ve heard about having a short product backlog is that it doesn’t give the team a sense of long-term stability, e.g. the team may be disbanded (or even laid off) once everything in the backlog is done. However, I think if the team are concerned about their future then there are bigger issues to address than the backlog, and artificially adding items to try to calm the team is disingenuous, contrary to the openness and honesty we promote.

The Scrum Guide describes refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items”, which is usually how product backlog items are made ready for sprint planning. I think what’s missing is the attention that a PO gives the product backlog, maybe in conjunction with the stakeholders, to prune the backlog in order to keep it focused on the upcoming needs – probably the largest part of the PO role is the communication with the stakeholders, and I think Henrik’s video gives a great overview of how much happens often without the team’s knowledge.

One More Thing

In the current (2020) version of the Scrum Guide the word “commitment” is used with regards to the sprint goal – “Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.

So what should happen after the team and product owner agree on the goal for a sprint, create a sprint backlog and start the sprint … but then someone* tries to add something to the sprint? (*The “someone” could be the product owner, a manager, or it could be a critical production defect.)

The Scrum Guide doesn’t provide much in the way of guidance other than “If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

What does that negotiation look like? A colleague from a previous company, Kiryl Baranoshnik, wrote a post with some good suggestions but I have a slightly different set of suggestions. Like Kiryl’s post, I’ll break it into two parts: Immediate Action and Retrospection, but I’ve not had time (or the skill) to create my own infographic yet.

Immediate Action:

  1. Postpone it
    The first decision should be whether the work really must be done in the current sprint – if it’s not important and urgent then it probably doesn’t deserve to jump the queue. The default answer should be to add it to the product backlog and only bring it into the sprint if it absolutely cannot wait.
    If the product owner decides it must be done ASAP, then the team should follow their standard refinement practices, e.g. referring to their Definition of Ready and estimating the new story.

  2. Exchange it
    A question that I have found to help focus the product owner on whether the new work really justifies disrupting the sprint is to ask “If we were to bring this new story into the sprint then we will remove the equivalent (estimated) size of work from the lowest priority items in the sprint backlog – is that ok?” This tends to make it clear that some of the originally planned work is unlikely to be done, which often has a knock-on impact on the product roadmap.

  3. Absorb it
    If the team are confident they have the capacity to complete their sprint goal as well as the new request, then they can choose to bring the additional work into the sprint as is. The risk is that, despite their confidence, the team are unable to complete everything; this should be raised with the PO and discussed just the same as the team would do if a regular (uninterrupted) sprint was in jeopardy.
    I put this option last as it can sometimes be more of a non-decision, e.g. because the team may feel pressure to accept the new work in addition to their plan or be overly optimistic. If it is the route taken then I strongly recommend the team make it clear that, even though they will try to absorb the additional work, it could put the lower priority sprint backlog items at risk. It’s always important to talk to the product owner if reality isn’t going as planned, but in this instance, I think it is especially important for the PO to be aware.

In summary, the three reactions to choose from are: “no, we’ll put it in the product backlog”, “yes but something has to make room”, or “yes we think we have room for it”.

If the decision was either flavour of “yes” then the team and product owner should hold a retrospective to discuss the root cause (why did this work appear after sprint planning?) and how it impacted the sprint. I would recommend a retrospective even if the answer was “no” because the root cause question should still be addressed – why wasn’t the new request just added to the product backlog?

One other thing to discuss is how often these unplanned requests arise: if it becomes frequent then the team and product owner should discuss whether the sprint length is appropriate (if two-week sprints are frequently interrupted then maybe try one-week sprints), or if the nature of the incoming work is simply unpredictable (e.g. support teams tend to use kanban’s flow approach rather than sprints). There could be other causes, for example is the product owner able to say “no” to stakeholders (see Henrik Kniberg’s excellent “Agile Product Ownership in a Nutshell” video) but ultimately the aim of the retrospective is to identify the root cause(s) and experiments to try to address them.


  • Leaving room for emergencies
    If the sprint interruptions happen frequently then there may be a temptation to leave some capacity unplanned, ready to insert the additional work. The reason I list this as an anti-pattern as it can hide the problem but also because it can give a distorted impression that the team is over-delivering.

  • Having one team member assigned to emergencies
    A slight difference to the previous one, I’ve seen teams allocate one team member (often rotating the duty each sprint) as their “on-call” person; they plan the rest of the team’s sprint as normal but the selected individual works from an unplanned “to do” list. Again, this hides the problem of late-breaking unscheduled work.

  • Saying “yes” without being able to consider the impact
    Teams that don’t feel they can say “no” or discuss how the additional work impacts their sprint plan aren’t really planning their sprints – if you can’t say “no” then saying “yes” has no meaning. Morale tends to be very low as the team has no control over their workload, which management often describe as “lacking engagement or ownership”.

This list could probably include a lot more anti-patterns, but please leave a comment if you’ve had success with these Immediate Actions or seen other ways to handle the mid-sprint request to add One More Thing.


I’m suffering from blogger’s block this weekend – I can’t think of a topic for a new post. I’ve jotted down lots of small things but nothing that I could write more than a paragraph on. But if I dig a bit deeper, I don’t think the topics are the problem – I just can’t conjure up enough excitement to give any of them enough attention. It’s a good thing I’m not getting paid to update this blog – a job comes with expectations and timelines, and trying to be creative under pressure is just not conducive to producing something worthwhile.

So how do developers cope when faced with a deadline? I remember when I was a developer that I often needed to leave a problem overnight before I could start to find potential solutions. But that was back in the bad old days of waterfall or plan-driven development – someone sets a deadline (usually an artificial one) and then we had to meet it.

How is an agile approach better? Here are a few things which spring to mind:

Deadlines are rare, but when there really is a deadline then the scope is variable. It ought to be obvious but I’ll spell it out because this should have been true in waterfall too but rarely was – if you fix all three sides of the iron triangle (time, cost & scope) then the only variable left is quality. Time is fixed because of the deadline; cost is the equivalent to the number of people working on it; so if you don’t allow scope to change then you’re basically forcing developers to cut corners. [I’m ignoring the argument for adding more people when the deadline looms – Fred Brooks covered this many years ago.]

Rather than adding people when it’s too late, why not start with two (or more) people working together from the beginning? Most companies require code changes be reviewed because they know having a second person look at a problem helps improve the quality … but collaborating on the design (when you’re tackling the problem) rather than reviewing the code (when you’ve picked a solution and gone down that route) results in an even better outcome. Having someone to discuss ideas with is so valuable that solo developers often use “rubber ducking” (yes, talking to a rubber duck!) as a way to clarify their thinking.

I find visualisation to be incredibly useful, for myself and when I’m sharing a concept with someone I’m coaching. When a team is discussing their confidence in meeting their sprint commitment, I find a burndown chart can challenge the overly-optimistic (“We’ll get it all done on the last day”) and lead to conversations with the product owner about relative priorities, expectations, etc. When discussing a new feature and how it will benefit the end-users, sketching the user interface may help build a common understanding, and story mapping can build empathy with the customer.

Frequent feedback can help too. Sometimes the enormity of a problem can be daunting, so break it down into more manageable pieces and take smaller steps towards the goal. Getting feedback on a small part of the challenge can be stimulating and provide inspiration for the next steps.

Please leave a comment: how do you cope when you hit a creative block?