I was on vacation last week, thinking about value. Depending on my role, I might think of value as:
- Delivery of a feature or story, assuming it’s the right level of quality and when I want it.
- Information about the story. This might include information from the team about what they think about this story, especially in context of the entire feature set.
- Information about how story might change what the team thinks we should do next, or other roadmap information.
Notice that only the very first way to think about value is about the delivery of this feature. The other two ideas are about information for the product owner and possibly the product manager.
When product owners have feature-itis and treat teams like feature factories, they miss all the juicy information the team might have about this feature and what it means for the feature set and the roadmap.
One PO had what he thought was a high value-low cost story. The story created an easier way to import new data. The customers would be independent of their IT group if this import worked. The team finished the story, demonstrated it and asked if they could watch the PO demo the story to just one of their customers. The team specifically asked to watch this customer.
The PO didn’t quite understand, but he decided the team had good ideas so he did. He demoed the feature to this specific customer. The customer was thrilled and asked many other questions about other data sources and the general cleanliness of the data.
The team took a ton of notes, especially about the questions about other data sources. The PO checked with the customer about the frequency of those data sources. They had a spirited discussion.
Afterwards, the team explained that other data sources were known to have what they called “unclean” data. The import would not be as fast and the customer would have to scrub the data. The other imports would not be low-cost. The team couldn’t tell how high-value the other imports would be.
That discussion helped the PO review the roadmap with the customer. The PO and the customer agreed that the team would provide only one more automatic import. All other imports would be their own little projects to scrub the data as they proceeded.
That meant that of the feature set of 15 possible data imports, the team implemented two. The team provided their customer enough information to request (demand) that the vendor scrub their data before they would consider it for import.
This PO didn’t treat the team as if they were a feature factory. The PO treated the team as valued partners.
The PO didn’t treat the internal customer as if their wishes were king. The PO treated the customer as valued partners who could understand the problems the team might have.
The customer explained to the vendor the problems with the data. If the vendor wanted the customer to buy this data, the vendor had choices about scrubbing it.
Notice how everyone here collaborated to find the best solution for now? When we think about value as not just a delivered story, but also about information, we can change how we work.
Teams can provide more than finished features. In fact, teams should. These teams need a full-time PO to be able to understand and process the information.
Consider thinking about value in these three ways:
- What you can deliver to your customer to make their lives easier
- Information about this story in context of the entire feature set
- Information that might change the roadmap, where the entire product might go.
More information might help us collaborate better, inside teams, with customers, and even with vendors.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Three Ways to Think About Value Opinions expressed by Java Code Geeks contributors are their own. |
