In this edition of the AgileToolKit Podcast, Bob Payne speaks with Ellen Gottesdiener and Mary Gorman about their book, Discover to Deliver: Agile Product Planning and Analysis, which focuses on creating a structured conversation around the discovery process. If you want to build the right thing you need to get people together and explore the space, find the value and find a way to confirm.
Below is an excerpt of the interview, but as always, we recommend listening to the whole podcast to learn more about the seven product dimensions and the value of shared language.
But for now, enjoy these highlights:
On writing a book together: “Talk about Validated Learning. It was so powerful: the ability for us to be together doing pair writing and then get very quick feedback.
“We also found another powerful aspect was [actually having] the entire book hanging on walls. And literally having the ability to see this and the flow, or lack of flow. We used a Kanban board for activities. And we really tried, as Ellen and I like to say, we really tried to drink our own prosecco.” – Mary
On Agile requirements: “You know the topics around analysis and requirements are going to be with us no matter what the method of the day is, I mean, it all comes back to ‘What is it that we’re building?’ and ‘When are we going to build it?’ so Agile requirements, or Agile product needs, we prefer to call them “Product Needs” will never go away, as a key issue. We’ve run into teams that have been doing Agile for years and they’re still struggling with issues about requirements and their backlog, and how do they make decisions on what to build. And so the full title is actually Discover to Deliver: Agile Product Planning And Analysis.
“The infinity is of course discover to deliver constantly, and as we move from discovery into delivery we have to know how to verify but also how to validate and use that learning from validation post-release to post-delivery to discover and refine what you’re going to deliver in your next cycle.” – Ellen
On structured conversations: “It’s the ‘goal not the role,’ and our goal is to deliver a high value product, which requires this partnership, equal participation, and ways for them to commonly communicate.
“The structured conversation starts with exploring product options. When we think of the product itself, we think of a variety of options, and exploring what those could be, and yet we don’t time or money to deliver all the options, so one of the pivotal aspects [we consider] is … when we have value considerations that would be used as a filter. So you would have X number of options you filter them through the value criteria and then you narrow that down to the highest value options. So, it’s this explore, and then evaluate aspect, and then we say that the conversation is not over until you have confirmed those high value options.” – Mary
On the actual number of product dimensions: “What we’ve discovered over the years in this whole world of requirements and analysis is that there’s actually seven product dimensions. [User] stories highlight two of them but there are actually seven. And four of them are pretty much functional related and three of them are non-functional.
There’s the User, there’s Action, there’s Data and Control, Control would include things like Policies and Rules. Those would be the four functional perspectives of the product. Then there are the three that most people would call non-functional: the interfaces, for the user to be able to interface with the product itself. The Environment as well as the Quality Attributes.” – Mary
On the importance of language: “We talk a lot about how words do count in having a shared understanding, which is really what this book is in many ways: helping teams build and sustain and maintain a shared understanding. Often people throw around business domain terms that are not well defined or because you’re at one part of the value stream versus another, they’re not talking about the same thing.” – Ellen