Ellen Gottesdiener and Mary Gorman have written a book titled Discover to Deliver: Agile Product Planning and Analysis. The book addresses the planning and analysis activities needed in implementing business products, with a focus on software products and business process change initiatives.
The book is described as providing a "toolkit of Agile/Lean practices for evolving products through the ongoing, interwoven activities of product development". It contains six sections, beginning with a case study narrative of three discovery work sessions. It then goes on to present each of the important concepts, how to use the structured conversation, and ways to adapt your discovery practices. The final section explains the usefulness of thirty-five planning and analysis tools and techniques.
A sampling of the book can be downloaded here.
The authors recently spoke to InfoQ about the book:
InfoQ: Firstly, thank you both for taking the time to talk to InfoQ. Why did you write this book - what is the problem you are addressing with this book?
Ellen: In our client work, we see teams struggling with many similar issues – no matter where they’re located, no matter what kind of products they’re dealing with. If we had a Top 5 “Missed Opportunities” list, number 1 would be missing the chance to base your delivery decisions on value – determining, in a disciplined way, what you expect any given bit of work to return in value to the organization.
Mary: Another missed opportunity we often see is when teams don’t collaborate efficiently as a team. It’s also a challenge to “right-size” stories, to clearly define a product’s scope, and to quickly adapt to changing conditions.
Ellen: In the book, we wanted to share essential, practical techniques that people can use in their daily work to address these and many other problems.
InfoQ: Why are you the right people to write this book?
Mary: The book reflects our ongoing work with a variety of organizations to improve their product development. We have wide and deep experience in business analysis, product and project planning, collaboration, organization development, and change management. To top it off, we both started out as programmers, years ago.
Ellen: We’ve worked in a variety of markets: healthcare, financial, insurance, pharma, software, media, gaming, government contracting, research, retail, manufacturing. We’ve learned from each experience. We’ve taught practices, experimented with new ideas, and implemented the best. Discover To Deliver is an outgrowth of our work.
InfoQ: Who is the target audience for this book?
Ellen: Well, you know what they say: eat your own dog food (or as we prefer, drink your own prosecco). So we applied agile practices to writing the book, and the first area we looked at was our audience (the “User” dimension, as we’ll discuss). We created personas and an empathy map of target readers -- Barry the Business Analyst and Polly the Product Manager. We had other readers in mind, but we focused on these two to start.
Mary: As we wrote chapters and then analyzed feedback from our wonderful reviewers, we realized the book would serve as a shared resource by anyone involved in planning and analyzing software-intensive products using agile/lean principles. That includes people who collaborate across disciplines -- architecture, business analysis, coaching, product management, project management, software development, testing and quality assurance, user experience.
Ellen: So our target audience became the team as a whole. Our goal is to show teams how to collaborate continually to discover and deliver an evolving product. It’s been gratifying to hear from our readers that indeed, they find the book is a shared resource in their teams.
InfoQ: The structure of the book is somewhat unusual - you start with a case study, without first introducing the tools and techniques - why did you take this approach?
Mary: Well, we knew no one order would satisfy all readers – some folks want an overview, others want to jump right in.
Ellen: So we experimented with several ways to organize the book. We had three releases. For each one, we printed out the entire book and hung the pages on the wall. (You can see a picture of the “hanging book” at this blog post that we created while in the midst of writing.) This let us “see” the whole, and we could spot any duplications or inconsistences. It was a huge help in analyzing the flow and the interdependencies. It’s easier to move things on a wall than in a long, dense text!
Mary: And then with each release, we moved some sections based on feedback.
Ellen: In the end we decided to start the book with the case study, because our reviewers overwhelmingly liked having it at the beginning. And we realized, context counts. The case study sets the context for the ongoing use of the examples throughout the book.
Mary: Also, starting with the case study gave us consistency. The case study is the only section that’s a narrative. The reader gets to eavesdrop as a team plans a product release. It’s in dialog format. We didn’t want to disrupt the readers’ experience later in the book by interleaving dialog snippets.
Ellen: We also wanted readers to have it their way -- dip in and out of the book, reading in their preferred order. So we worked with our designer to come up with a navigation bar for the print version. It runs across the top of the pages, and it shows you which section you’re in, in relation to the other sections. That way, at a glance you quickly see where you are, and you can decide where you might like to jump to next. The navigation bar has been a big hit with our readers.
InfoQ: How realistic is the case study you present - are the scenarios things that the readers are likely to come across in their daily lives?
Mary: The case study reflects how we work with teams—it’s a synthesis of the types of conversations we help teams engage in. A group of cross-discipline folks collaborate to analyze and plan product needs—requirements—for the next delivery cycle. Together, they explore options, clarify their thinking, and challenge and learn from each other. The back-and-forth among them is the kind of thing we hear all the time when people are using their time very effectively.
Ellen: While they’re working, they use a variety of techniques and tools. We strove to make the case study broad enough and pragmatic enough that readers can easily see how it applies to their own situation.
InfoQ: A strong message in the book is the concept of VALUE - why is this so important, isn't the purpose of product development to understand business needs and address those?
Ellen: Oh, value is absolutely key – it’s a mantra in agile/lean practice. The question is, Whose value? After all, value is in the eyes of the beholder. Different stakeholders have different perspectives of value.
Mary: So we like to use the term “product partners” to indicate a healthy stakeholder community acting in partnership. The partners include people from the customer, business and technology communities. Together, they collaborate to reach a shared understanding of the product, and they decide what will be delivered at any given time.
Ellen: Each partner’s perspective of value is different. The organization doesn’t always have the same perspective on value as, say, the customer. And vice versa. Same for technology and business, technology and customer. So, for example, customers may value convenience, the business may value complying with regulations, and technology may value readiness or alignment with the existing architecture.
Mary: A crucial part of the process is for the partners to understand each other’s value considerations. Then they quantify the anticipated value. Then after each delivery, as soon as possible, they validate their anticipated value against actual value. Any gap gives them a start on deciding how to adjust their plans for what to deliver next.
So acting as product partners, the stakeholders can make timely, fast, yet informed decisions about what to build next.
Ellen: To help them do that, we created a meta model – the Business Value Model. It shows the relationships between the product’s ends (vision, goals, objectives), the means (the various product options) and the evaluation (partners’ value considerations and decision factors). It’s available for downloading.
InfoQ: Please share the background on the 7 Product Dimensions – what was the genesis for it, how do you use it?
Ellen: Everyone talks about requirements, but there’s often lots of confusion when it's time to plan and analyze them. The classical breakdown of requirements into functional and nonfunctional helps, but it isn’t clear enough. It doesn’t specify what’s included. So we defined the 7 Product Dimensions, which break down all the aspects of a product into categories. Product partners can use the 7 Product Dimensions to ensure that they get a holistic, comprehensive understanding of the product.
Mary: For functional requirements, the dimensions are User (who or what interacts with the product), Action (the capabilities of the product), Data (the product’s repository of data), and Control (how the product enforces constraints like business policies and rules).
Ellen: Then the nonfunctional dimensions are Interface (the mechanism for connecting with users and systems), Environment (the product’s physical properties and technology platforms) and Quality Attribute (for example, performance, usability, security of of operation and efficiency, portability, testability of development).
Mary: For the book, we designed unique symbols and colors for each dimension. You can see the dimensions here.
InfoQ: You present the idea of Structured Conversations - how are these different from normal elicitation conversations that are used in product development today?
Mary: Well, as many of us can testify, not all product conversations are effective! To help teams make the most of their product conversations, we realized our most efficient and effective conversations were, at their core, a meta process we call the “Structured Conversation” It’s not hard to learn, and it’s empowering.
Ellen: The conversation is structured around three activities. First, you explore product options. You expand your thinking, and you consider possibilities for each of the 7 Product Dimensions that’s relevant to the product option at hand. Next, you evaluate the options within and across the dimensions. Using value considerations defined beforehand, you identify which options you believe will provide high value and assemble them into cohesive sets. Depending on your planning horizon—how far ahead you’re planning at the moment—each set of product options could be a candidate solution, a minimum viable product, a minimum marketable feature, or a story. And the third step is, the conversation isn’t complete until you confirm the team’s understanding by verifying and validating the results using acceptance criteria. Validation happens after the delivery cycle.
Mary: In our practice, we find that the structured conversation is a great framework for collaborative decision making across disciplines. And it works at all planning horizons.
Ellen: That’s because it combines divergent and convergent thinking, analysis and planning. We find it levels the playing field by helping partners from all three areas (customer, business, and technology) to equally participate and learn from each other.
We encourage teams to “work the walls”—post the 7 Product Dimensions, explore the options, sketch models. (Check out these samples.) It’s impressive to watch how holistically visualizing the options can quickly facilitate the conversation.
InfoQ: You present a number of different models in the book, could you briefly explain a few of them, and where they are considered useful.
Ellen: The old saying is, “All models are wrong, but some are useful”. A model gives you a simplified version of reality, and that’s useful when you’re planning product development. Analysis models, when used at the right time and with just enough detail, can help you build a shared understanding of requirements. They’re a great addition to structured conversations, and they help all the team members holistically understand requirements.
Mary: We suggest teams create analysis models depending on which of the 7 Product Dimensions they’re exploring.
Often, a user story, which is really about the Action dimension, isn’t enough. If you’re exploring the User dimension, you may need a model like a persona or role map. You might want to draw a context diagram or sketch a mock-up or wireframe to help you explore the Interface dimension, or a conceptual data model for the Data dimension. A story map is also useful for the Action dimension because it gives the team a holistic understanding of all the product’s potential Actions.
Ellen: It’s important to calibrate the breadth and depth of your models according to your time horizon. For example, in what we call the Big-View, you consider your product or portfolio roadmap needs for the next few years. Models will be wide and shallow at this level. The Pre-View time horizon focuses on requirements for your next release, and for that, you need models with more information. And when you’re using models at the Now-View (planning the current iteration, or your work-in-progress), they will be more granular, more detailed, and they’ll include concrete examples.
Mary: Discover to Deliver also includes meta models, which help you choose useful models for each of the 7 Product Dimensions. It also has a “Tools and Techniques” section that describes examples of analysis models based on the case study.
InfoQ: You devote a whole section of the book to adapting your practices - why is this so important?
Mary: Context counts. The tool box of concepts, practices and techniques we’ve just discussed – the Structured Conversation, the 7 Product Dimensions, the Planning Views and so on – are applicable to a wide variety of situations. Let’s be real – you always want to adjust for your situation. So the “Adapt” section offers ways to approach different situations, such as acquiring and integrating commercial off-the-shelf (COTS) software and developing regulated products.
Ellen: We’ve found that the discovery practices in Discover to Deliver are helpful no matter which delivery method you’re using: traditional (waterfall), timebox (Scrum), or flow (Kanban). You adapt the practices based on the triggers, the timing, and the frequency of delivery.
Mary: Another adaptation may be choosing which product dimension to start with. Say you’re working on a business intelligence effort. You’d lead with the Data dimension and then quickly swivel to explore, evaluate and confirm the other 6 product dimensions.
Ellen: Another key question Agile teams struggle with is documentation. So we provide guidance on considerations for adapting your documentation practices.
InfoQ: How would you summarize your overall goal in writing Discover to Deliver?
Ellen: We’ve been working in the requirements area for twenty-two plus years, and this Agile/Lean approach is the most exciting development we’ve seen, in terms of improving both process and product for collaborative teams. Agile/Lean practices call for interweaving planning and analysis, integrating disciplines of testing and user experience, and making incremental headway with sound product architecture. Best of all, you don’t abandon classic good practices from requirements, product and project management. We have a passion for sharing practical ways for diverse disciplines to work together to rapidly produce valued results and continually collaborate to discover and deliver high-value products.
Thank you for taking the time to talk to InfoQ.
InfoQ readers can receive a 20% discount off the price of Discover To Deliver: Agile Product Planning and Analysis. Use code InfoQDtoD when ordering the print version from DiscoverToDeliver. The discount is valid through 15 January 2014.
About the Book Authors
Ellen Gottesdiener, Founder and Principal of EBG Consulting, is a leader in the collaborative convergence of requirements + product management + project management. Ellen coaches individuals and teams and facilitates discovery and planning workshops. A Certified Professional Facilitator, she writes widely and keynotes and presents worldwide. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis, Ellen is author of Requirements by Collaboration and The Software Requirements Memory Jogger.
Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams and facilitates discovery workshops, and she trains stakeholders in collaborative practices. She speaks and writes on Agile, business analysis, and project management. A Certified Business Analysis Professional™ Mary helped develop the IIBA® Business Analysis Body of Knowledge® and certification exam, and the PMI® business analysis role delineation. Mary is co-author of Discover to Deliver: Agile Product Planning and Analysis.