If you are an agile practitioner you are likely to have read the book “Scrum – The art of doing Twice the Work in Half the Time” from Jeff Sutherland. I am a fan of Jeff and I believe that what he has done for software development in the last 20 years is great.

I do have issues with the book’s title though.

That title is what makes people think that being agile means being able to go fast and deliver more stuff.

Is this what real agility is? Let me tell you a story.

At a client of mine a couple of years ago, I was asked to coach a product team and help them with a new product they were starting to work on. I was excited about it and asked the product owner to meet for a coffee and initial chat.

He kindly agreed and told me: “before we meet, have a look at our requirements document so you will know what the topic is”. He also told me that a high level estimation had been done and that the product would take from 6 to 8 months based on one agile team and that there would be licensing costs associated with an automated scanning system we had to acquire.

Attached to the mail there was a document of about 50 pages with detailed workflows, low fidelity prototypes of the screens and quite a lot of explaining text. I skimmed through it looking for a description of the problem that the product was meant to resolve, but couldn’t find it.

I read and reread the document and I couldn’t find the original problem that the product had to resolve, it was not there.

When I met the product owner, after agreeing the weather was miserable (that’s how we start any conversation in Dublin regardless of the season) he started describing his solution. I let him explain to me the beautiful features to build and the amazing technologies we were going to use.

When he was finished, I asked him: Why are we building this?

The initial reaction (completely normal) was a defensive stand for his solution. When I probed more, it was clear that after having worked for so long on the product on his own he had forgotten the nature of the initial problem that triggered the decision to build this product.

Using the 5 WHYs technique, in about 10 minutes, we eventually got to the initial problem that we needed to resolve.

At this point the conversation became different.

I asked what he thought were the features we should prioritise to resolve the problem so that the customer could have something earlier than in 6-8 months. That triggered the interest in the PO that identified 5 features (about 30% of the total described in the document).

I then took each feature and asked him if it was necessary to resolve the problem we just identified. After another 10 minutes we agreed that 1 single feature, that accounted for about 1/15th of the initial solution, would resolve the customers problem. To avoid making the PO feel bad about having done so much unnecessary work, I told him that we would build the other features incrementally, and that it was a great success that he had identified a single feature that would be useful for the customer almost immediately.

We then agreed to identify outcomes of success for the full product and start measuring immediately as soon as we released the first feature.

These read something like:

“We will know we have succeeded when 30% of customers do X instead of Y” or

“We will know we have succeeded when we will have 40% less support calls related to problem X”

et cetera. I made sure the business outcomes were related to the initial problem, not any product.

What ended up happening is that we built the first feature in 2 weeks (opposed to 6-8 months) and the measurements told us that we had reached what we wanted already.

We never built the other 14 features, we stopped because the business outcomes we had set were reached.

And yes, you guessed, we didn’t have to buy the licenses for the automatic scanning system either.

As a coach, my mission in organisations is to guide teams and navigate problems, maximising value with minimum work. This is always welcome when meeting CTOs or CIOs because – most of the time – less work means lower costs and earlier delivery.

We did 1/15th of the work and got business outcomes earlier, a big improvement IMHO from “doing Twice the Work in Half the Time”, what do you think?