When I facilitated the Product Owner Value Game at IBADD2016, I asked the participants to suggest some things about the activity, or product ownership in general that puzzled them. A couple of the Puzzles brought up were:
- The math behind exploration & reward of doing so
- When to commit to deliverable vs additional research
To answer these two questions, I’m posting an excerpt from Beyond Requirements: Analysis with An Agile Mindset. This particular excerpt is from Chapter 2 – Helpful Concepts and discusses the idea of Discovery and Delivery.
The third way of categorizing analysis is along the lines of when we do it. It is often helpful to compartmentalize activities. This is probably one of the reasons that people latched onto the various phases described in plan-based approaches (analysis, design, development, testing). There are certainly some advantages to splitting up the activities that go into knowledge work. No single person is really good at every aspect of knowledge work, so organizing the activities into groups can certainly help break things down into manageable chunks and apply focus to the various aspects.
But what is the best way to organize those chunks? When people reference the Winston Royce paper that is cited as the source of waterfall planning, they usually zero in on the diagram showing several different phases that occur when building a large system. But on the first page, there is an interesting and often overlooked picture of two boxes, “Analysis” and “Coding,” along with the following comment:
There are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it—as is typically done with computer programs for internal use. It is also the kind of development effort for which most customers are happy to pay, since both steps involve genuinely creative work which directly contributes to the usefulness of the final product.
Royce goes on to say that this approach is woefully inadequate for larger software development projects and reveals a bit of his philosophy about how to treat software development teams:
An implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed to failure. Many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay for them, and development personnel would rather not implement them. The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.
While I don’t agree with everything in that passage, I find it interesting that Royce focuses on analysis and coding as the two activities customers value. I had been searching for some straightforward way to describe the key activities in IT efforts which, based on my own experience, tend to break down into “figuring out the right things to build” and “building the things right.”
Ellen Gottesdiener and Mary Gorman identify the right words to put around those ideas in their 2012 book Discover to Deliver. There it is: discovery and delivery. It has alliteration and everything. They further cement the concept by wrapping the two words in an infinity symbol to represent how both activities interact and influence each other. Royce would be proud that someone finally listened.
Here’s how Gottesdiener and Gorman define discovery and delivery. I’ll assume these definitions going forward in this book.
Discovery: work that explores, evaluates, and confirms product options for potential delivery
Delivery: work that transforms one or more allocated candidate solutions into a releasable portion or version of the product
The most helpful aspect of this concept is having a label to associate with different types of activities. Traditionally teams have tracked what was going on from a delivery perspective but have frequently not visualized discovery activities. Tracking their efforts to figure out the right thing to build can be just as helpful as tracking how they are building the solution, so I often use separate discovery and delivery boards. I’ll talk more about those in Chapter 15.
All aspects of knowledge work involve some aspect of discovery. We’re still “discovering” things about the need and solution when we’re in the process of building it, testing it, and deploying it. It’s useful to differentiate the two activities to reinforce the focus of each activity. Discovery increases your understanding of the need and solution to set up delivery. Delivery is primarily about building, testing, and deploying output, but those activities help your team build further understanding of the need and solution, which in turn influences your discovery. Sure, discovery still happens in delivery, but the majority of work done there is building stuff to help increase understanding.
To really know when you should move from Discovery to Delivery, I find the idea of the definition of ready to be helpful. I discuss the Definition of Ready in this blog post, and also in Chapter 15 of Beyond Requirements.