The most important change you can make to help your team succeed

How busy are you?

Are you close to a deadline? Is the team feeling pressure? Every team I visit seems to be under the same heavy workload, and consequently has a lot of improvements to the process, the environment, the technology that they can’t quite get to yet. They know they need to get to them, and they will…. when they have time.

But they won’t get time.


TL;DR: Build slack into your iteration

Take a break

The nature of time

When I started trying to write a book I spoke to a colleague, Jon Jagger. I whined that I just didn’t seem to be finding the time and he replied with wise words: “You won’t find the time. You’ve got to make the time.”

The same is true for any tasks that support the development team that don’t obviously deliver immediate working software for the customer. The reasons for this are many, but the root cause is normally disempowered teams. Teams who ask their product owner to prioritise tasks that the product owner has no way of prioritising appropriately. Most POs should not be asked to choose between a user story that delivers a feature they understand and a technical task that they don’t. It’s a no-brainer – they’ll always choose the user story to maximise customer value. Even if the technical task will actually deliver greater customer value.

Before I continue, I’d like to remind you of two things: sustainable pace and commitment

Sustainable pace

The agile manifesto is quite restrained in its pronouncements. One of the 12 principles it states is this: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” This doesn’t mean we don’t work hard. It doesn’t mean we never come in early, work late or come in at the weekends. It does mean that we don’t do any of these things regularly. We don’t want our doctors or airline pilots working when they’re exhausted and the same goes for a software development team.


At the beginning of a sprint, Scrum teams used to commit to the stories that they were going to deliver. “Commit” is a strong words. There’s an implied guarantee. Which is why the 2011 Scrum guide replaced the word “commit” with the word “forecast.” They did this because “reality keeps on showing us that it is difficult, if not impossible, to always fulfil this self-imposed commitment without making compromises to quality.” I think this was a mistake – not because I want teams to compromise on quality, but because I want teams to think harder about what might go wrong. A commitment that is missed will give everyone involved pause for thought, but no one blinks an eye if a forecast is wrong (usually).

Failure and success

There are lots of ways to fail. We fail when we commit to too much. We fail when we underestimate. We fail when the unknown-unknowns derail our project. We fail when the bus factor is too low and the team member burns out or moves on. We fail when we haven’t understood what our customer wants.

There are lots of ways to succeed too. We succeed when we deliver what the customer wants. We succeed when we uncover risks early and can take steps to mitigate them. We succeed when we communicate our level of uncertainty and enable the customer to make informed decisions. We succeed when the customer decides to cancel the project early because it’s not technically feasible, it’s too expensive or the market just isn’t there.

Most project successes today, however, are failures dressed up as successes. They succeed despite not meeting their time or cost estimates. They succeed because they’re useful enough to release even though they don’t deliver the benefits envisaged. They succeed because they were too important to fail.

But there’s one thing we can do to give every project a better chance of really succeeding. To brew the champagne that we want to drink. To actually delight the customer.


It’s not new, it’s not clever, it’s not original. It’s slack, ladies and gentlemen.

Commit to less than what you are confident that you can deliver in an iteration. Then, when you’ve delivered your commitments, you can decide whether to pull another story off the backlog or implement that improvement that will really help the team. If an unforeseen problem erupts, you’ll have some wiggle room to help you deliver your commitments anyway. You’ll have time to ensure that knowledge is shared and skills are transferred. You’ll have time to really talk to your customers, to understand what value they’re looking for. But you have to make this time – and slack is the tool to use.

We still treat team members in a Taylorist way, as machines whose utilisation should be optimised, forgetting that the tasks that we undertake are creative, thought tasks that can’t be measured simplistically using hours-in-the-office, lines-of-code-written or bug-reports-raised type metrics.

Building slack into your iteration is not sandbagging – it’s showing professionals the respect they’re due. And in return they’ll deliver the software you want.







2 responses to “The most important change you can make to help your team succeed”

  1. allan kelly Avatar

    I tend to disagree with your advice here. I advise teams to schedule more work than they expect to do, I believe a little pressure is good, I don’t see how velocity will ever increase unless you attempt to do more. Since I prefer strictly mathematical calculation of velocity that is axiomatic. I also advise setting expectations accordingly, teams and their clients need to recognise it’s a probabilities game.

    I do agree that you will not do work unless you make time for it. But I want this work to be visible, not hidden as it is with a slack approach. Work to improve the team and their environment should be agreed, planned and scheduled in the planning meeting just the same as any other work.

    Option 1: the product owner type person should prioritise this work with other work. This might mean the PO needs to understand the nature of improvement or it might mean developers need to get better at explaining why the work is beneficial.

    Option 2: set a strategic investment (or tax, use your favourite term) level, say 20%, developers then nominate 20% of work, or possibly get 1 in 5 iterations themselves.

    Improvement is too important to leave it hidden slack working.

    1. Seb Rose Avatar

      We have had this (minor) disagreement before 😉 It’s only a minor disagreement, because we both want to build trust between the PO and the team, we both want to continually improve the development process and we both know that estimation is, at best, speculative.

      My experience is that teams start off scheduling too much work; that product owners are reluctant to pay the ‘tax’ that you talk about in Xanpan; that retrospective actions remain un-actioned. So, I recommend commitment and slack, because I’ve seen it work. You recommend pressure and tax, for the same reason (I assume), but I’ve seen this fail (sometimes spectacularly).

      Maybe we need some case studies.

Leave a Reply

Your email address will not be published. Required fields are marked *