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.

Ever.

TL;DR: Build slack into your iteration

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.

Commitment

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.

Slack

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.