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 humans 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).

Can you Sprint when there are a lot of unknowns?

Over the past few months I have spoken with people from a number of teams who have found themselves facing a large amount of uncertainty in their mission, their precise roadmap has been unclear, and the technical details of how to achieve it foggier still.

This is a common scenario for teams, particularly in start-ups where there is a significant rate of development (or growth) and a large amount of risk and uncertainty in the roadmap ahead.

Often, I hear these teams say that they should use Kanban because planning is difficult with such uncertainty. I can understand the logic and thinking that leads people to this conclusion, but I'd like to challenge it:

One of the rules of Scrum is that in each Sprint the team produces a potentially releasable increment [of product]. To achieve the Sprint Goal teams typically implement Product Backlog Items, but there is no requirement that PBIs be the only work that a team can complete, nor even that they are completed at all in achieving a Sprint Goal. It would be unusual, but conceptually a Sprint Goal could be achieved without a single PBI being done.

If we contrast this to a Kanban or continuous flow approach where the focus shifts towards progressing individual cards rather than the greater goal, we can start to see that Scrum is in fact ideally suited for environments where there are a lot of unknowns, and a lot of uncertainty.

If Kanban teams try and optimise their flow as you would expect a team practicing continuous flow to do (since WIP, cycle times and lead times would be key metrics), they will soon struggle as a consequence of the uncertainty and unknowns; it is difficult to achieve 'flow' when it's not clear what work needs to be done, or indeed how work can be done.

This leads to an interesting conclusion that would be echoed by many leading Scrum Masters worldwide; Scrum is ideally suited and intended for environments that are complex, and therefore have many unknowns. This is in stark contrast to the common view that scope is fixed within a Sprint.

It is this latter view that I believe leads many to defer to Kanban and continuous flow when there are many unknowns. The irony is that this leads teams to consistently choose a way of working that isn't suited to the problem space that they are in.

There is, however, a further level of uncertainty where not even a Sprint Goal can allow for the flexibility in scope required. This is particularly rife where there is no concept of a product, yet and so there's a lot of experimentation and trial-and-error in trying to build something that gains traction in a market.

Product Owners, engineering decisions, and 'technical debt'

When you’ve got a software product, it is composed solely of items like the code, static assets, supporting architecture and infrastructure (hereafter referred to as 'the tech'). These items are often thought of as being a necessary part of the product, but really they are the product and trying to separate them is a logical fallacy similar to trying to separate the food from a meal.

I think it's worth pausing and thinking about that for a second because it is an important concept to understand and embrace: in a software product the "tech" is the "product", and vice versa.

Things that are truly good for the tech are ultimately good for the product, and for the product to succeed the tech must itself succeed.

So why then, do team continue to treat the two as entities that are somehow distinct? Even the notion of things like 'tech debt' shouldn't exist. Let's explore that…

Of course code, architecture, infrastructure, etc. matter but not for the sake of themselves; none of these things can stand alone. If things are unstable, unscalable, or difficult/slow to update, that directly impacts the product value that can be delivered. ‘Technical debt' therefore, is more accurately labelled as ‘product debt', or even just 'debt'. Technical issues that have no impact over the product (or the future development of the Product) are completely irrelevant. There are surely no exceptions to this.

If a codebase requires refactoring because making changes is error prone and therefore slow, this has direct influence over the product value that can be delivered. If issues such as this go unaddressed, the rate of product value that can be delivered will decrease (probably exponentially) over time. If product value cannot be delivered, that's a product concern first and foremost.

It’s probably not for the Product Owner to specify specific implementation details, but they do have a very significant stake and interest in how their product is built since the decisions made can have significant influence over the success and possible speed of iteration.

A common over-simplification is that the Product Owner has responsibility over “what” and the Development Team have responsibility over “how”, and while this may be true at a very high level, The Scrum Guide reminds us that "The Product Owner is responsible for maximising the value of the product and the work of the Development Team". If architectural and 'debt' style tradeoffs will influence the delivery of value, the Product Owner should be part of such decisions. They may or may not have the technical knowledge (or the interest) to know whether a Product should be written in Python or C#, but they may care about the advantages of each. They may also care whether a new feature is implemented in a generic way, or hard-coded, especially if there is a big difference in implementation time.

I think that many of these issues have roots in legacy ways of working where there was a more distinct divide between Product Management and Engineering disciplines, and where product changes were captured in lengthy and detailed specification documents. In the agile world, where we’ve come to value things like valuable working software, and individuals and interactions we can do a lot better than handoffs of specifications. We can communicate, collaborate and negotiate with honesty about different solutions and the pros and cons that they bring because we’re now one team with one goal.

We must never lose sight of the importance of good technical practices, but only in so far that they can support the product. "Being agile" is never an excuse for cutting corners, but it does challenge our long-held beliefs about how teams can work together to satisfy our users and customers through early and continuous delivery of valuable software.