Why Practice 1: Say What, Why, and for Whom Before How

In honor of the 10th anniversary of this blog, which I first started under the name Techniques of Design and then became To Be Agile, I'm starting a new blog series. Actually, I'm starting nine new blog series, a series on each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.

Also, I've recategorized my blog posts and most of them relate to one of the nine practices. Now you can look for posts based on your specific needs around the nine practices. Over the last decade, I've written hundreds of posts on this blog on a variety of Agile engineering practices.

I tried to make the content of my blog accessible to both developers and managers. Both in my blog and in my work I try to make the Agile technical practices accessible to everyone so that the entire organization can get on the same page with how we build software.

My book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, focuses on nine specific Agile engineering practices that support the creation of extendable software.

This is the first post in a series of nine blog series, one for each of the nine practices in my book.

This first series is on Practice 1: Say What, Why, and for Whom Before How. While this is not a technical practice per se, I think that it is one of the most important practices for all technical and non-technical people on a development team to do.

Agile does not replace requirements with a single sentence story but rather uses stories as placeholders for conversations between the Product Owner and the team about what to build. One of the traps that I see teams get into is that when they talk about features they speak in implementation details. This is partly because of the way we communicate in English. We speak in terms of implementation and so when a Product Owner or Business Analyst talks about a process or how the system should behave, they often talk in terms of implementation details.

This is not a good practice. It's far better to focus on what you want, why you want it, and who it's for. This helps the team better understand how to create value for the user of their feature.

I'm a huge fan of Simon Sinek's book, Start with Why. When discovering a system it is often best to start with why the system is wanted in the first place. In my book, I say start with what because Practice 1 is really about communicating ideas and not about generating ideas. I fully agree with Simon Sinek when he talks about starting with why but he's talking about generating ideas and anchoring them in meaning. In Practice 1, I'm talking about communicating ideas and specifically communicating the features of a system.

I find that when I think about features in terms of who it's for, why they want it, and specifically what they want, then I can build more of what they value and so the system is more successful for them.

It's easy to get bogged down in implementation details. I want to try to avoid that by focusing on goals and constraints. What is it that we want to achieve and in what context do we want to achieve it? We can figure out the details later.

In Agile software development in general and Scrum software development specifically, the customer representative or Product Owner plays a critical role. In many ways, I feel that the Product Owner acts as the director on a movie set, helping to coordinate a large effort.

Not everyone can direct the feature film. And there are very few directors that studios will give $100 million to in order to make a film. Great Hollywood directors are superstars. On a lot of Agile projects, the Product Owner becomes the superstar or the singular visionary for the product.

The Product Owner isn't a technical role but it can be a critical role in providing consistency and focus to the product. After all, the most important thing of all is to make sure that we're building the right thing for the marketplace and that's the primary job of the Product Owner.

I'm excited that I get to expand on the Seven Strategies that I presented in my book for each practice in these blog posts. The following seven blog posts are based on "Seven Strategies for Product Owners" from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. Enjoy.