Blog

It’s about Requirements Discovery, Not Delivery

By: David Hawks | Jul 23, 2015 |  Article

Part 2 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…

The second problem in the “Deliver Double the Value in Half the Time” series is that the Team doesn’t have a shared understanding of their purpose.

Finding the Right Requirements

Many of us have lived in a world of three false assumptions:

  1. The customer knows what she wants
  2. The developers know how to build it
  3. Nothing will change along the way

The reality is we live in a world of constant discovery:

  1. The customer discovers what she wants
  2. The developers discover how to build it
  3. Many things change along the way

Creating a shared understanding takes an investment of time. A common thought may be that developers are paid to write code, so that’s what they should be focused on, not sitting in a meeting to talk with Product Owners or Stakeholders to actually understand what it is they’re building. Some organizations will decide to have someone, maybe a Business Analyst, figure it out and write it up and then feed that under the door to the Team with a pizza and then just expect them to build what’s written out. How’s that working out? Are we effectively communicating what it is we are trying to build and more importantly, are we effectively iterating through to validate all the assumptions that we have going into it?

User story mapping helps discover requirementsA great technique to develop shared understanding is User Story Mapping (see “User Story Mapping” by Jeff Patten for more details). Get your team and stakeholders in a room together and get them talking. Make the switch from “requirements delivery” to a “requirements discovery” process.

Requirements delivery means what is to be built communicated through a big requirements document – we expect the Team to read it, we expect the Team to understand all the stuff that was analyzed over the last x weeks or months and we expect them to understand it because it’s communicated through the document. But there’s no such thing as perfect requirements. So getting the team involved in the discovery process, doing something where they are interviewing stakeholders and walking through scenarios of what the customer is going to do (like user story mapping) is really valuable time spent. Through story mapping, the Team gains knowledge of what the customer is trying to do.

One team who builds a consumer-based product took half a day to go to the mall to interview customers. Think they built better software after actually talking to real customers? Definitely! Teams are making decisions every day about what the software’s going to do and how it’s going to behave. If they have no understanding of who the customer is or what that customer wants, they’re going to make it up as they go. If we don’t give developers clarity, they will get really creative: “I can imagine…” ,”Wouldn’t it be cool if…??”. “No, it wouldn’t!” Because we’re not going to get our product shipped. And there are all these other features on the list and they’re not that cool… but the customer wants them. They don’t need the coolest. We’re trying to get the Team to focus on building the minimal thing, getting it out there and learning from it. Let’s accelerate learning, let’s make sure we understand the problem we’re trying to solve, and not just giving the Team solutions to go build. It’s common for teams to need guidance to reach this next level. Go here if you’re interested in learning more about our supplementary Agile coaching services like agility tune-ups.

Next topic in the Double the Value in Half the Time series: Shorten Feedback Cycles.

Leave a Reply

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

< Back