Posted on Wed, Dec 12, 2012
by Dan Williams
The role of the product owner is understood as critical to fulfilling the goal of delivering products of value to the customer. Since the official beginnings of Agile, this role has also been one of the major pain points in actually providing that value.
To explain, the product owner is one of the three original roles identified in Scrum, along with the team and the ScrumMaster. The role is analogous to that of customer in eXtreme Programing (XP). But what is the purpose of the product owner role? What problem is the introduction of this role, identified as a critical part of both Scrum and XP, trying to solve? [1]
The role of product owner was put forward as a solution to the problem of poor and changing requirements from multiple stakeholders, which sometimes makes the production of quality software next to impossible. The product owner would become the representative of the stakeholder community. He or she would gather and communicate requirements to the team, representing the stakeholder community with a ‘single voice’. This would remove ambiguity and foster improved communication between the business and the developers. Great idea – but what happened?
The role has generally not materialized in businesses attempting to implement Agile software development techniques. The role of product owner ideally combines a development team-facing perspective and a stakeholder/customer-facing perspective. Attempting to combine these two perspectives has been shown to present herculean issues for the person trying to actually perform the role – namely empowerment and representing the voice of the customer.
The first issue is that of empowerment. When describing the role in the first book on Scrum, Ken Schwaber and Mike Beedle state that the product owner is fully empowered to select and prioritize the features making up the product backlog. [2] It turns out that this proposal, which on the surface sounds like a good idea, often doesn’t work out well.
Empowerment sounds good because it reduces the number of communication channels and invests one person with the authority to make decisions quickly. This increased simplicity in communication and speed of decision-making is welcome news to development teams, which need quick turnaround on questions of prioritization and details concerning work in progress.
But it doesn’t work out well due to the number and complexity of stakeholders needing to provide input to the development team and due to conflicts over feature prioritization and design. This short explanation will be expanded in another blog article, but the facts are that, with few exceptions, the empowerment of the product owner is sadly lacking and so the development team is still, often, receiving mixed messages regarding design and priorities.
The reality is that the product owner, or customer proxy, as the role is sometimes called, must still meet with and coordinate multiple internal stakeholders as well as attempt to understand the marketplace and the external customer if applicable.
In the next post, I will discuss the second issue concerning the product owner role: representing the voice of the customer.
Posted on Fri, Nov 16, 2012
by Dan Williams
In a previous blog post, I expanded on the idea of Value by introducing the concepts of intrinsic and instrumental value. Software, I asserted, has no intrinsic value but only instrumental value. That is, software has no value in and of itself; rather, it is considered valuable based on its delivery of features to the user which they consider valuable. The feature itself may have either instrumental or intrinsic value, depending on what that feature or feature set accomplishes.
In this post, I want to discuss initial value and delivered value. Initial value of software delivered is considered to be its cost. When a person purchases an item or a service, they anticipate the delivery of value to themselves. In the case of a television set, I anticipate evenings of viewing pleasure with my wife as we watch British murder mysteries. The television has an instrumental value in delivering pleasure to my wife and me. The value I place on the television in the store is the cost of the set which I am willing to pay in anticipation of the value delivered later in my home.
So the value in the store is not only the instrumental value, which is anticipated, but it also has an initial value or cost which I am willing to pay. The cost provides the starting place for value, both anticipated and realized. That initial value is not the instrumental value which holds the promise of value eventually received, or the delivered value which I will experience over time in my home and which has a non-monetary value. It is the start, not the end, of evaluation.
Initial value or cost is often the only hard metric captured for tracking purposes in software development projects. I suggest that delivered software measured over time is the missing metric which should inform the Product Owner as to whether the project achieved the promised results of profitability, market share, risk avoidance, etc. But who would perform this measurement? I believe it is the Product Owner.
Measurement of these factors is a long-term effort, and demands the continuity of attention of the Product Owner. This responsibility must be made explicit and agreed to by the PO -- otherwise the opportunity to gather empirical data on whether our software development efforts are actually delivering value to our users will be lost and we will continue to rely on cost metrics to evaluate value.
To restate, organizations usually do not measure the long-term benefits of projects. This results in Product Owners equating the cost of the project to its value, hence our traditional focus on project cost and schedule. Measuring benefits such as enhanced revenue or reduced costs over time cannot be the job of the project team due to the duration of the effort. Thus it falls to the Product Owner to define, measure, and test to see if the intended intrinsic benefits were achieved to truly understand project success.
In my next post, I will continue to develop ideas around value and how, to whom, where, and when it is delivered.
Posted on Thu, Aug 23, 2012
by Dan Williams
In my previous blog post, I talked about Jim Highsmith’s concept of value delivered being measured at “…the point-of-sale, not the point-of-plan.” I went on to hearty agreement with Highsmith’s views around doing the hard work of defining what the value of the feature/component is to the customer, and then linking that value to a point system which can be tracked against software delivered.
In this article I want to talk about the concept of perspective and value. People understand the world from a variety of perspectives. When we talk about value delivered to the customer, what do we mean? It depends on what it is the customer values. Let me propose some working definitions for discussion purposes.
Instrumental value is that value the customer places on what the product or service will do for them. We often write User Stories to capture software/business requirements with a value statement of some kind in the paradigm expression. This helps the developer understand why they are writing the application code.
As a client/user/customer, I want to be able to enter my credit card information into the payment screen, so that I can purchase the book. The ‘so that’ phrase is understood as the customer or business value of the story.
Intrinsic value is the value something has which is a part of its character. A developer might say that the code they just wrote is ‘beautiful’. Or that another person’s code is ‘beautiful’. They are expressing appreciation for how the code was written, tested, implemented, etc.
Very often it is the instrumental value which informs the persons view of the intrinsic value of an item. But often, the rose is just beautiful and there is nothing for which the rose will be used.
Monetary cost value is that value the customer places on a product or a service related to its cost: 'I am willing to pay $1000 for that widget.' This is also the value which the Product Owner (customer/proxy/business owner) is willing to pay for the development of the software providing the business functionality.
In doing Return on Investment studies (we are remiss if we don’t do them), we are comparing the cost against return. But I believe we miss an important component in our analysis if we do not attempt to understand and factor in the Intrinsic Value of the product or service we deliver. How would we do this?
In my next blog I want to suggest some methods for better understanding Intrinsic Value and how it is the most important factor in directing the team and the business in deciding ‘What’ to build.
Posted on Thu, Apr 26, 2012
by Joe Justice
A bottleneck in Agile work is probably what you think. It is the area of least flow. Optimizations made elsewhere can't increase the overall flow of the system unless the bottleneck is addressed first. We discover bottlenecks via Value Stream Mapping.
A value stream map can grow in complexity to model complex relationships, but here we only need a very, very simple implementation: To get what we need, it's simply the flow of a product from idea to customer, divided up any way you like along that flow, with a number of days where that division is actively adding value written over the number of days the product is in that division. You may have done this already in your work.
Here is an example from Team WIKISPEED: Converting our halogen headlights to LEDs. The LED headlights start with researching the road legal laws for headlights, then researching headlights that meet the spec, then purchasing, then mounting them, then wiring them, then testing them for compliance with the road-legal specification. In that flow, lets say we find out that one headlight is burnt out at the end during test. We can move testing to right after purchasing to avoid wasted work. We also found the "researching LED headlights that meet the road legal specification" task on our Scrum board/Kanban board hung out in "doing" for 17 days, but actually only had 1 hour of research done. Finally, 17 days later, and we were able to move it to done. We've recognized an opportunity to increase flow by calling for a swarm, adding a resource, or escalating the priority of that task.
Where we find work queing up in a given division, we have found a bottleneck. In this case, maybe the research was waiting for the Product Owner to give more information about whether we were assuming EU or U.S. light distribution patterns initially. One way we can help alleviate the bottleneck in this case is by moving the Kanban board somewhere both the team and Product Owner see while they are working, and adding a red box above the backlog labeled "waiting for Product Owner feedback". This might help the Product Owner have enough information to prioritize their work based on what the team needs to flow.
When done well, a Scrum board, a sprint planning board, or a Kanban board can be a value stream map of the team's part of the overall business flow, updated during each daily standup meeting. When this happens, the ScrumMaster is armed with the information they need to select the right retrospective tool and guide the team's continuos improvement to the very high levels of performance for whcih Agile is becoming famous.
Posted on Fri, Apr 20, 2012
by Dan Williams
In the agile world, incremental delivery of value to the customer is the ‘mom and apple pie’ of countless Certified ScrumMaster training courses and books. What is the value and how is it measured and when is it communicated to management?
In my previous post on Agile Value, I referenced Software by Numbers. (For additional information on the authors and the approach introduced by this book see their website). It introduced an approach to quantifying value using the concept of Minimum Marketable Features (MMF). In the second edition of Jim Highsmith’s book Agile Project Management, he introduces the key concept of linking competitive advantage to early software delivery.
He states that, “Ultimately customer value is delivered at the point-of-sale, not the point-of-plan.” He says, “The agile value ‘Delivering Value over Meeting Constraints’ provides a focus for rethinking how we measure performance on projects.” He explains that though cost and schedule are important, these constraints should be secondary to delivering value to the customer.
The concept of incremental delivery of measureable value to the customer is consolidated in the Agile Triangle of Value, Quality, Constraints, a replacement for the so-called iron triangle of Cost, Schedule, Scope used in traditional project management.
Value Point Analysis is Highsmith’s recommended method to address the what, how and when of delivering value to the customer. After first favorably citing Denne and Cleland-Huang as pioneers in this space, he then disagrees with their approach as overly complex. As an alternative, Highsmith introduces Value Points as an analog to Story Points to measure the delivery of Value to the customer.
The when is during Release Planning. After sizing the Epics, Themes, Features and User Stories using story points for relative sizing, keeping in mind that story points are an indicator of cost and can be easily calculated, value points are a relative sizing used an indicator of benefit delivered.
The what, or calculating the monetary value of Value Points is suggested by using the Net Present Value (NPV) of the Revenue Stream used in the business case to capabilities delivered based on percentage of the delivered already calculated.
The how example he gives is for one Capability, composed of several user stories, which delivered 14% of the release value, and would be worth $350,000.
When the iteration for the Capability was underway, the $350,000 would be divided by the total number of Value Points calculated for all the stories – assume 125 – to give a monetary value of $2800 per point. An individual story that was estimated at 15 value points would then be allocated a value of $42,000.00. The graph below illustrates the comparison of feature cost to value point estimation based on the NPV value derived during the Business Case construction during project Initiation. Management now can measure the incremental ROI delivered:
Value and Cost Delivery
Management requires performance measurements to safeguard against Risk and Cost overruns. Even more important is to measure Value delivered which promotes early releases and early business benefit. To perform Value and Cost delivery we need to do the hard work of up front planning and delivery tracking during the iteration cycle. My next post will continue with more mechanics on value and cost measurement and tracking.
Posted on Fri, Mar 30, 2012
by Dan Williams
I am interested in how to deliver and measure value when using an Agile perspective. I use the term perspective when referring to Agile rather than method or process because I believe Agile is concerned primarily with the promotion of certain values concerning people, work, quality, and value.
My personal interest in this area began several years ago when trying to quantify the delivery of business value, doing more than merely comparing Cost and Schedule a la PMI’s methods. To my way of thinking, Value has to mean more than what something costs. When I say I value something or some service, I usually do not mean what the item or service cost me, but what I get in return. Cost is interesting and might prevent my acquiring whatever it is, but it is not equal to value.
Jeff Sutherland does a good job of summarizing the core perspectives concerning Agile and the delivery of Value. He says, “The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time. It details four core values for enabling high-performing teams. These are:
- Individuals and their interactions
- Delivering working software
- Customer collaboration
- Responding to change”
The core values emphasize people, their interactions, collaboration, and responsiveness to the dynamics of the business environment as the starting points for the delivery of value.
Agile, within the context of software development and delivery, attempts to deliver different kinds of Value, and this may be the start of the confusion. These are at least:
- Respect for persons
- A context of collaboration enhancing the work environment
- Flexibility and responsiveness to reality rather than wish fulfillment
- High-quality work engendering a feeling of satisfaction in the worker and value delivered to the customer
For a business adopting Agile practices, value delivered should be measured.
Business value may be understood in a variety of ways: Increase of income, reduction of cost, and the addition and retention of customers. How would we measure whether Agile was delivering on these goals? Here are some suggestions which will be fleshed out in my next blog posts.
- The business stakeholders must become involved in setting out what they want measured during the project start and then stay involved during the project to measure incremental delivery of what has been termed Minimal Marketable Features. (From Software by Numbers: Low-Risk, High-Return Development)
- Return on Investment (ROI) must be tracked after delivery by someone designated with that responsibility after the delivery of the software. This task is almost always overlooked and I can find no references to a role designated for this.
- Value should be broken down not only by cost reduction or income generation, but also according intangibles delivered to the business like customer satisfaction.
In my next post, I will discuss some proposed tools to capture and promote this viewpoint concerning the delivery and measurement of value produced through the Agile. I will start with a review and discussion of Jim Highsmith’s Value Point method.
Posted on Fri, May 13, 2011
by Dhaval Panchal
This is a variation of “Value Flow” exercise that Sanjeev Augustine did at Scrum Gathering 2009 in Orlando. I found this exercise very useful to demonstrate the benefits of prioritization and lower batch sizes. I have facilitated a variation on this exercise with different learning objectives. Below is a detailed description of how I run this exercise.
Time:
15 – 20 minutes
Input:
- 20 coins of different kinds (1,5,10,25, etc.)
- Secret stash of 20 coins of different kinds (1,5,10,25. etc.)
- Table large enough for 4 people
- Stopwatch (1)
- Participants (5)
- Facilitator (1)
- Time keeper (1)
- Flip Chart or Whiteboard
- Chart or Whiteboard markers
Setup:
- Create a table as shown below on a flip chart or White Board
| |
Round 1 |
Round 2 |
Round 3 |
| All Coins |
|
|
|
| 1st Coin |
|
|
|
| Total Value |
|
|
|
Participant roles:
Exercise Steps:
Round 1: Batch Size ALL
- Ensure all team members can flip or toss a coin.
- Start timer
- The first delivery team member flips a coin until it turns heads. Repeats this step for all the 20-25 coins.
- Only after the first person is done with all the coins, the second delivery person works on the first coin in the batch until (s)he is done is with all the coins.
- The third person picks up the entire batch and then the fourth.
- Time keeper records the time taken for the first coin to be flipped to heads by the last team member.
- Record Total Time on Chart (Row 1st Coin)
- Time keeper records the time taken for all the coins to be flipped to heads by the last team member.
- Record Total Time on Chart (Row all Coins)
- CEO/Product Owner calculates the sum total of monetary value represented by the coins.
Facilitator sets up context that the organization is facing stiff
competition and they have to deliver much faster than they did
in Round 1.
Round 2: Improve Time to Market!
- Facilitator removes the restriction that one person has to complete all the coins before the next person can pick any of the coins. Team members do have to follow the sequence of processing through team members.
- Facilitator asks the delivery team to do a quick 2-minute retrospective on Round 1 and plan for how they will approach the same problem without the restriction of flipping all coins before passing to next step.
- Facilitator kicks off round 2, at the end of timebox. Delivery team members may ask for more time for retrospective, but it’s important that the facilitator holds the 2-minute timebox sacred.
- Start Timer
- Delivery team begins flipping coins
- Time keeper records the time taken for the first coin to be flipped appropriately by the last team member.
- Record Total Time on Chart (Row 1st Coin)
- Time keeper records the time taken for all the coins to be flipped appropriately by the last team member.
- Record Total Time on Chart (Row all Coins)
- CEO/Product Owner calculates the sum total of monetary value represented by the coins.
Facilitator sets up the context, that although the time to
market was okay, competitors have gained parity and the
organization has to focus on delivering higher customer value.
They need to improve on that!
Round 3: Competitive Threat! Prioritize and fix release date
- Facilitator asks the delivery team to do a quick 2-minute retrospective on Round 2 and plan for the how they will approach the problem this time.
- While the team is doing a retrospective, facilitator asks the CEO/Product Owner to prioritize coins based on their monetary value.
- Facilitator declares a time box for round 3. This time box should be the lesser of 4 minutes or the time taken to flip all coins by everyone in Round 2.
- Delivery team begins flipping coins.
- When the first dime comes off the line, tell the team “customer feedback, dimes have no value”
- Facilitator hands secret stash, another random collection, of coins to the CEO/Product owner.
- CEO/Product owner can reprioritize the new collection with other coins that have not yet been picked up by the first person.
- At the end of declared timebox, time keeper declares time.
- CEO/Product Owner calculates the sum total of monetary value represented by the coins.
Debrief:
Facilitator debriefs participants and other witnesses on the exercise. This will vary significantly depending on people’s experiences. The intention of the three rounds is:
Round 1 sets up the organization to deliver fixed value (total monetary value of coins). Team members usually are working at a frantic pace to get most through put with the CEO/Product owner cheering them on.
Round 2 is still about delivering fixed value, however after the retrospective team members intuitively reduce the batch size. So instead of passing 20 coins at a time, they hand off 2 to 3 coins at a time to the next person in line. I have observed that as compared to round 1, the team takes much lesser time to deliver on the same. Improved time to market!
Round 3 is about delivering maximum value with in fixed timebox. This is significantly different than Round 1 and Round 2, since in this case the product ship date is fixed. Somewhere in round 3, injecting customer feedback that “all dimes are useless”, induces additional uncertainity since no one can predict customer behavior/trend. At the end of the round 3 timebox, the team often delivers higher value than round 2 and round 1 even with the uncertainity induced through customer feedback. Debrief points are around product owner prioritization, injection of customer feedback and fixed release dates.
The coins in this exercise may represent features or projects within a portfolio. It is very hard to kill projects/features even after we know that they are not worth the effort. There is tremendous value in killing low-value high-cost projects.
Have fun! I’d love to hear your feedback about how it went for your team.