Sustainable Pace – The Fastest Way To Deliver Software

So you want your team to deliver software faster?

To demonstrate why this request is nonsensical first imagine a mature, high performing Agile team who delivers on average 10 stories of roughly the same size in every 2-week Sprint (i.e. 1 story per working day).

Now imagine we asked the team to take on just ONE story every Sprint. Their capacity is 10 stories, but we ask them to only deliver 1. What might happen?

Well, we can’t be sure but it is fairly safe to assume that the 1 story is guaranteed to be delivered. We can also be pretty sure that it will be of an extremely high quality, given that the team are working well under capacity and so have plenty of time to dedicate to ensuring a bug-free and pleasant user experience. They may also spend extra time on exploratory testing, ensuring that the whole product, of which this story is a small part, is not hiding some ugly buggy behaviour. If they do find some bugs, they may fix them and add some tests to their regression suite to ensure the bugs don’t recur, increasing the holistic quality and maintainability of the system.

Given that the team knows they are an awesome, high performing team and they have plenty of time to spare in the Sprint, they will likely spend a large portion of their time not working at all. Having fun. Slacking off a little. Giving their brains time to breathe, to reset. Enhancing their team culture and spirit.

From a planning point of view, we may not have speed but we sure have predictability. We know that the team delivers 1 story every Sprint so we can very easily figure out when our product will be delivered with close to (if not exactly) 100% confidence.

OK, now let’s instead imagine we ask the team to deliver 2 stories per Sprint. It’s not too much of a stretch to assume we would get a similar result to the above, except this time some (albeit small) sacrifices will be made. Perhaps some of the extra, luxury activities will be left out. Perhaps all of the aforementioned activities will be done but with less time spent on them. So a little less story and product quality. A little less fun and recuperation time. A little less team building. While it’s highly likely that the team will surely deliver the 2 stories, the probability is slightly less than when we asked them to deliver 1 story. So we have a little less predictability.

What about if we extend this scenario to 5 stories? Then 8? Now imagine we’re struggling to hit a contractual deadline so we feel the need to “speed up”. So we ask the team that predictably delivers 10 stories to deliver 12 (now we’re over capacity). Or even 14?

Hopefully you can see where I’m going with this. The more stories we ask the team to deliver, the less time they can spend on quality, the more likely shortcuts will be taken, the more likely technical debt will be incurred, the more likely team culture and effectiveness will suffer, the less fun will be had, the more fried the team’s brains will be and the less predictable we will become at delivering software.

Read that again – the “faster” we ask (or worse, tell) our teams to go, the less predictable at delivering software we become, and that software is more likely to be of a lower quality. Allowing our teams to deliver at a constant, sustainable pace ensures quality, predictable software delivery, a higher chance of happy teams and happy customers, which leads to higher business value (e.g. profit).

In short, by allowing the team to find the right balance and deliver high quality software at their capacity, a cycle of success is created.

So, managers, please think twice before asking your teams to speed up, i.e. deliver more stories (or story points) than usual in a Sprint or sequence of Sprints. It’s like asking a marathon runner to start running faster after 32k for the final 10k – you’re increasing the chances of long term failure (not completing the marathon at all due to fatigue) for a potential short term gain (running some quicker kilometers).

What Price Estimation?

If I want someone to, say, build me a website, in most cases there are two possible constraints I have. I either have a maximum amount I want (or have available) to spend, or I need my website delivered by a particular date. In a truly Agile project, both of these are the same for the supplier because there is a fixed team, i.e. time constraint = budgetary constraint.

Back to my requirements. Let’s say I have $5000 available. If I engage a web design company, I can choose to not tell them my constraint, perhaps because I want to save money and get the “best/cheapest quote”. I can simply ask “how much will my website cost, given that I want x, y and z?”

This is the predicament many software companies have – how do we determine a price for the customer? The answer is invariably to take the customer’s requirements, devise a solution and estimate how long that solution will take. This will then derive the cost to the company, which will determine the price to the customer.

As customers, let’s stop and think about this. Is this the approach I want the web design company to take? Does this provide the best possible value for me? When I engage the web company, would I rather the following:

A: Stay shy about my $5000 budget, and the company comes back and tells me they can build my site for $4500, having based that decision on a fixed design/solution and guess of how long that design will take to build. Perhaps they’ve actually shaved time from the team estimates in order to under-cut a competitor. Perhaps they’ve added on time as a “buffer”, increasing the price for me. We will sign a contract based on a SoW detailing what I will get for my money. If I want to change any of the detail as I start to see the website built I will need to pay extra or I will need to drop out some of the originally agreed features. These small increments will need to be costed accordingly, again based on a guess of how long the new feature will take compared to the original feature.

B: Reveal my budget. They come back and say that my $5000 buys 5 weeks of work, and the team will build the best possible website they can for that price. They might show me examples of other clients’ websites that cost around $5000 to give me an idea of the quality my website will be. They will work with me in weekly iterations to ensure I’m happy with the progress, can change things as we go along and that the key things that are important to me are always being built first. They will deploy my site to a demo URL daily so I can see the site evolve and provide feedback at any time. If after a week, or two weeks, or 3 weeks, I’m not happy with what is being produced I can choose to end the relationship. This makes it clear to me that the web company is absorbing much of my risk and they are very confident they will do a great job for me. I as the customer am the one gauging the progress against my requirements rather than them estimating that they are “on track”. They want to form a working relationship with me in order to build the right thing, and that they might get my repeat business. That I might recommend them to my friends and colleagues. Their mantra is to delight their customers.

Option A requires estimation (guessing/risk/uncertainty), upfront design and makes change hard. Option B requires no estimation, design can change and emerge as we go along, embraces changes as I see the site evolve and shows a company wanting to work closely with me to achieve a result I am delighted with. One that is prepared to front extra risk (of losing money on the contract) because they are so confident in the quality of work they do and of the relationships they form with their customers.

I know which I’d choose. How about you?