Changing your neighbour’s lightbulb

The other day, I had to change the lightbulb in my kitchen. It took me just a few minutes from spotting the problem to having it fixed.

I know that my neighbour’s house has the same light fitting. If they asked me to help them change the bulb in their kitchen, it would take me just a few minutes to locate a new bulb, remove the blown one, and fit the new one.

But if I wanted to change it myself, without their request for help, or without their permission then it becomes a lot harder; breaking in to their house to do so could well land me in prison.

Sometimes we have all of the knowledge, skills, and tools that are necessary to solve a problem, but we are unable to do so because of organisational or societal boundaries. Even the simplest things can become unsolvable.

Businesses and teams need to structure themselves such that nobody feels that they have to break the rules to help.

Our teams shouldn’t be locked down like our houses are.

When is a Sprint a success?

Let me cut to the chase and offer the following as a definition of a successful Sprint:

A successful Sprint is one where an increment of significant customer/user value has been sustainably delivered in broad alignment with what the team had forecast that they would deliver. As a consequence of their work they now have a better understanding of their problem-domain, and of their next steps. Additionally, the team have agreed what they will do differently (improve) to try and increase the likelihood of success in their subsequent Sprint(s).

Success criteria for a Sprint is something that I have discussed more times that I can keep track of. From interns and graduates fresh out of university to seasoned C-level managers, everybody seems to have their own idea of what 'success' looks like in Scrum.

Probably the most commonly cited definition is that 'every card brought into the Sprint in Sprint Planning is done'. I think that this viewpoint revolves around the common misunderstanding that the Sprint Backlog is a task list, and therefore the definition of success is coupled to that list being completed.

That's a kinda scary definition, because it inverts the first principle of agile software development by suggesting that following a plan is the most important thing.

Another common angle is that 'success' means that the Sprint Goal is done. I greatly prefer this over the previous definition; a well crafted Sprint Goal ensures that there is flexibility in scope, but also provides a 'guarantee' that value in being delivered to the user/customer. If a team is achieving this every Sprint, that is a typically a pretty good sign for the health of the team, and the project. But it is definitely not the only sign of success.

For example, imagine a team that takes on a hugely complicated/complex Sprint Goal, and delivers all bar one very small part of it. Perhaps it is a global product and they managed to release an industry-changing new feature in all bar the smallest of their supported markets. This is probably still a triumphant victory for not just the team but their wider business. If they had taken on a smaller goal which they did get completely 'done' but made no material difference to the business or industry, would that have been more successful? I think that we'd all agree not.

The purpose of a Sprint is to give teams a chance to creatively solve complex problems. It's an empirical process which means it all revolves around inspection and adaption.

This starts to highlight the problem with having black and white 'success' criteria. In a complex domain, we cannot [reliably] predict the relationship between cause and effect. In other words, we can't know before we start exactly how things will unfold. It's like trying to define success for each and every child, before they are even born.

Our definition of success really needs to acknowledge the uncertainty that has brought us towards an empirical agile process, rather than a tightly defined (more waterfall) one. This takes us to where we started this post, with a definition of success which can be applied uniformly and crucially explained to key stakeholders like management.

Your Sprint Goal still matters, but I think it is for the team to define and understand exactly what it means to them. The Scrum Guide says it "…is an objective set for the Sprint that… provides guidance to the Development Team on why it is building the Increment", and I think that is a pretty good starting point.

If you've got a different (or more concise) definition of success, please comment below.

Motivation when times are tough

When things are going well, a lot of things are easy. It's much easier for us to offer perks, and live by our values. It's also much easier to get up every morning with smiles on our faces, looking forward to the challenge ahead.

We can really drive at things, seeing them through to 'done' as quickly as possible. Even when we fail, we celebrate it as a learning opportunity. These are good times, although they still have their challenges.

Motivation generally lags behind environment. When things turn sour, our motivation doesn't instantly drop. We say "we can do better; we must strive to get back to our winning ways of yesterday". Most of us can sustain this sentiment for a while even during tough times.

But what happens when day-in, day-out, our efforts reap neither the results nor recognition that they deserve? That can be tough. Really, really tough. The longer this environment surrounds us, the less motivated we feel, and yet motivation is the key force that we need to break out of the spiral.

In an industry like software there are but a few genuine chances to 'reset'. The problems that we left behind on Monday evening are still there waiting for us on Tuesday morning. There's no 'second shift' to help us out or give us respite when we're feeling overwhelmed. A team struggling with a tough problem in an unfamiliar domain could struggle for months on end, with few chances to 'come up for air'.

Like trying to beat the final boss in a video game, it may begin as a fun challenge that tests our skills as engineers, as product owners, or as project managers, but after a while — even if we are getting better and improving our approach — we often just want to throw the controllers at the TV.

*So what can we do? *

Like in the video game, we need to recognise when it starts to become painful, and take a step back. There's a couple of ways of going about this:

At a personal level, it might mean cutting back on extra hours, and just backing off slightly to let yourself cool off. I'd recommend that you share this approach with your colleagues and manager/lead(s); it gives them an opportunity to help if they can, and also makes them aware that you need a little more breathing space.

At a team level, it may mean that the team needs to spend a little bit of time tackling a different problem, even if just for a Sprint or two. This could be a chance to tackle some technical debt, resolve some bugs, or otherwise just do something a bit different. Sometimes a change is as good as a rest, after all.

What we mustn't do is ignore it and try to 'solider on'.

What managers must do

I saw a video on Reddit recently about a dog that loved to swim. It loved to swim so much that it would swim until it was so physically exhausted that it couldn't swim back to the shore. To protect the dog from drowning, his master fitted it with a flotation aid before it went into any water.

Our strongest employees in a business are often like the dog in this story; they are highly driven and tenacious, stopping only when a problem is solved and mission achieved.

When the dog started to struggle to swim, would its owner have been successful if they simply shouted at the dog, told it to try harder, and to really push itself to keep going? How about if they set the dog milestones, or [ambitious] targets to achieve?

A disappointingly common management failing is thinking that the issue is that people simply have to 'try harder', or 'do more'. With some people in some cases, that's true, but think about our dog; will it work there? When your most-driven employees suddenly have to 'try harder', it would seem like something else is amiss…

As line managers, team leads, agile coaches, scrum masters, CXOs, we all need to actively work to support our colleagues and ensure that we protect people from themselves in times like this, both in trying to protect them from swimming too much in the first place (thankfully human's are slightly easier to explain this sort of thing to than dogs) and then genuinely help them when they do.

But managers are not immune

If a team is feeling exhausted and unmotivated, chances are the person leading them is struggling the most of all. They are putting on a brave face and trying to remain positive, but they are also the one bearing the pressures from the team below them and their managers above. My advice to those in this position is to make sure that those who can help appreciate the struggle that they face. In most cases, that means the person’s line manager, but potentially their team lead as well (if it’s a different person).