“We don’t have time for planning. We have to focus on delivery.”

I have heard this dozens of times from leaders of delivery teams who are struggling to meet expectations. It has always been well-intentioned, reasonable, and wrong.

Bear in mind, the people saying this are not dumb. They’re successful people who have built a reputation for getting things done. They know how to get maximum performance out of their teams. So why am I saying that they’re wrong?

Because they’re confusing doing work with producing value.

They’re saying that effort matters more than understanding. That when push comes to shove, doing something is preferable to stepping back and understanding what work we should be doing. That even if we don’t know that we’re doing the right thing, doing something is preferable to doing nothing.

This may not be the case.

(Image copyright Gary Larson – http://www.thefarside.com/)

The root cause here is cognitive bias. We think that effort is what leads to results, because our lived experience tells us that you don’t get results without work. This is correct, but insufficient: undirected or poorly directed work can make things worse. A sledgehammer is not better than a hammer for driving nails. Further, there is not a 1:1 relationship between effort and the creation of value. I’m sure you’ve had at least one experience where you’ve expended hours on something that took seconds for someone else to solve. I know I have.

But we don’t think that way most of the time. We’re at work, we have responsibilities, and because we value work so highly, we want to be doing work-like things: making stuff. Not planning or analysis or research (unless that’s our work, of course). This kind of thing is part of what Max Weber was writing about back in 1904: our values are bound up in the way we work.

Take that cognitive bias and put it in charge of a development team that has a deadline, and the result is a leadership team that says things like “focus on delivery” and de-emphasizes planning in favor of coding more features according to the specs in the stories we have in the pipeline.

The problem this creates is pretty substantial. We’ve all seen this fabulous chart, right?

Take another look. “Defects” aren’t just bugs in the implementation of software. In fact, the biggest defect is building the wrong thing, not building the thing wrong. Defects in the requirements themselves, way over at the left. Cases where what we think the user wants isn’t what they want at all, and we don’t discover that until the product hits the market and doesn’t sell.

Okay, so how do we fix this?

First, let me restate the problem: Work done without an understanding of the goals and intents of the work—without knowing who we are doing this work for, and how it will make a difference for them—is at high risk of being wrong. What we need is some way of de-risking things, of increasing the chance that we are building the right thing, and that all of the effort we are putting in is actually going to result in the creation of value.

That’s a big part of what Agile has been trying to get at since well before it had a name: creating feedback loops to course-correct by showing increments of completed work to the customer frequently and changing the things that don’t meet their needs or expectations.

How do we do that before we have any completed work to show, though? How do we catch the defects at the requirements stage, or as close to it as we can?

There are two tools that I use with teams that help get detection as far left as possible: Personas and User Story Mapping. These help the team doing the work of creating the product understand who the customer is and what they value. Organizations that use them find that their development teams are more productive, because they produce the right things more often. Not just because the developers understand who the customer is and how they will value the work, but also because the conversation about how to deliver that value is happening earlier in the process, and everyone is engaged in it.

Take the time to understand what you’re doing. If you don’t have Personas for your users, create them. If your team really understands the user, it won’t take long. If they don’t, it will take time, but it will pay dividends almost immediately. If you don’t have User Story Maps that explain clearly what your users are trying to do in the system, organized into use cases, create them. It will take a few hours, but will pay you back immediately – in the next sprint at the latest. Unless your organization is planning sprints in advance, but that’s a different problem.