6 images Prioritizing and Selecting MMPs

The old adage goes “When eating an elephant, take one bite at a time.” The metaphorical message here is that when something is large and daunting, we need to shift our thinking from trying to get it done all at once to breaking it down into smaller pieces and organizing our entire workflow to deliver those pieces as quickly and efficiently as possible.

Conversely, many organizations take an all-or-nothing approach to feature and capability launch. We try to launch an entire project’s worth of features in a single release. Then, due to the inevitable delays that result from trying to do too much at once, we end up releasing nothing on time. The result is a lot of lost time, a lot of spent money, no new functionality to users, and most importantly, no new value delivery to anyone. One of the key goals of the VMO is to release valuable features to customers early and often and to use those releases to start driving business value back to the organization. This approach accrues business value in multiple forms—increased revenues, improved customer satisfaction, new accounts, cost savings, and customer retention. Crucially, a VMO needs to move the organization toward planning, delivering, and measuring value in much smaller batches.

The VMO also needs to educate leaders on the immense value of not doing non-value-added work. For instance, on one of our recent engagements, a last-minute request came in for a significant project from a C-level executive. With their previous processes, top-down requests such as this would be implemented unquestioningly and immediately. The organization had been resigned to requests from this particular executive. In the past, those requests had regularly resulted in more work in progress, delays of currently in-flight work, and a crowding out of requests already in the portfolio backlog. However, since the VMO we were supporting had recently instituted a disciplined work-intake process, they subjected the executive request to the new process. First, they broke the project down into small deliverables. They then applied weighted-shortest-job-first prioritization to the smaller deliverables. This decomposition and prioritization revealed that the entire project was a clear economic loser. The team was able to go back to the executive and show that the request had relatively low value and was high in duration and cost and that other more economically favorable work would likely get crowded out if this request was to proceed. Once provided with this objective data, the executive saw the light and agreed to cancel the request, saving thousands of hours of work.

The fundamental concept here is to break large project efforts down into small groupings—MMPs, or minimally marketable products—prioritize those MMPs by business value, release them early and often, and then continuously learn from those MMP releases to improve both what we deliver and how we deliver it.

This approach is actually quite intuitive and desirable to many business leaders who understand their markets and customers at a very deep level. In particular, those in the financial services sector rapidly adopt and apply this concept because of the clear financial parallels of investing early and often. Many often evolve this concept quickly to their own needs. For instance, at a midsize bank with whom we worked to implement MMPs, the senior vice president on the business side led his business unit to decompose MMPs into features and then to monetize those features. That is, they assigned estimated financial returns at the feature level and then tracked and monitored those for the verification of business value.

A move to planning, prioritizing, delivering, tracking, and measuring MMPs is a fundamental shift, and we will cover these aspects in detail next.

Plan for a Fundamental Shift from Project to MMP Delivery

For value to flow through the organization and into the hands of customers quickly, the unit of value needs to be small and focused. Big, vague, boil-the-ocean projects and releases are far too complex to be well understood, well designed, well developed, and well tested. They tend to result in massive overruns and low quality. As we’ve indicated earlier, a much more agile approach is to frequently deliver small, tight MMP releases.

MMPs represent marketable, sellable, and deliverable units of value that are impactful enough to be meaningful to customers but are small enough to be quickly delivered and deployed. The VMO can help drive the change away from the old project-centric model of delivering the whole project to the new product-centric mentality of delivering an MMP. The VMO can most effectively do this by changing focus from project delivery to MMP delivery. The VMO should measure the delivery of MMPs. The VMO can then use visual management systems and flow metrics to drive the flow of these MMPs into the hands of customers so that we can derive economic value for ourselves and for our customers faster. To do this, the VMO will need to provide leadership to the organization in the following:

• how to chunk big projects into smaller MMP deliveries

• how to define and identify MMPs within a project or product

• how to align the MMPs with value streams and customer outcomes

• how to best choose MMPs for maximum economic impact on the basis of desired customer outcomes

• how to drive the flow of MMPs through a visual program Kanban system

• how to measure the business impact of MMP delivery on customer outcomes

• how to use what was learned from prior MMP deliveries to adapt both what we deliver and how we deliver it

Clearly Specify What an MMP Means to Your Organization

It is easy to get lost in the details of definitions for related terms such as MMP (minimally marketable product), MVP (minimum viable product), and MMF (minimum marketable feature). These definitions can be very important to the product owner or product manager because they all represent slightly different variations on the theme and are designed to solve different product-related problems. The key thing to remember is that they have a few things in common and that understanding these common elements is most of what the VMO leader needs to know. They are all small, they are focused, and they are useful. They represent small groups of small features that help the user accomplish something specific and useful right now. There are those who will argue these definitions endlessly, but don’t get too bogged down in all of that. Mark Schwartz probably said it best when we partnered with him on agile implementation at U.S. Citizenship and Immigration Services, where he was chief information officer. He said, “Work tiny,” and that is most of what you need to know.

Formally Change the Unit of Work from Project to MMP

The MMP concept is important because it fundamentally changes the VMO’s primary unit of work or focus. Traditionally, our unit of work has been the project. Everything was about the project: the scope, the schedule, the budget, and the milestones. But here is the first big problem with projects: your customers do not care anything about your projects. Projects are internal constructs that are used primarily as an accounting and financial batching mechanism. As such, they have no importance to end users. Another big problem with projects is that by focusing on the completion of the project, we tend to move all of the delivery of value to the end. Focusing on project delivery practically forces us into the mentality of large releases way out in the future when the project is “done.” This may be very tidy from a project mindset: one project equals one big release. Meanwhile, we have spent significant amounts of time and money, and our customers have received nothing from us. If we want to be a more customer-centric organization, we need to start to drop the project mentality.

What users care about are product or service features, and they want them now, with high quality. By putting focus on MMPs or small releases of small features, we change the unit of work to something that is of value to end users: value delivery. This is great for our customers in that they get something now instead of later. This has the not-so-trivial side benefit of accelerating business benefits to us! If we deliver small features sooner, we start to recoup the benefits of those features through new revenue, cost savings, account signups, risk reduction, customer retention, or whatever. If that weren’t enough, through early and frequent delivery, we get opportunities to learn more about our product and our process and our customers and make the necessary adjustments sooner rather than later.

Figure 6.1 represents how the agile model uses early and frequent delivery to accelerate the feedback loop.

Set Process Expectations and Controls for MMP Creation, Prioritization, and Selection

As members of the VMO leadership, it is not likely that the important task of setting process expectations and controls for MMP creation, prioritization, and selection will fall to us. However, this is a critical function for a product ownership team. Given any set of customer-related goals and internal business goals, there are likely to be many possible solutions, many different ways that we could possibly achieve the desired goals. Ideally, we want to get several options on the table to determine which is the most viable given the cost, risks, and upside. Determining what we build and when we build it is probably the most important decision an organization makes. If the answer to this question is “We want it all,” then we can guarantee that we are spending way too much money and taking way too much time to deliver value. The VMO should be putting strong expectations and perhaps even controls in place that give clear guidance to product owners on how to decompose work and deliver smaller units of value. For example, the VMO could define a set of expectations such as the following:

images

Figure 6.1: Agile versus large batch

• Projects must deliver functionality to users at least every quarter, every month, or every two weeks as appropriate for our customer base.

• Releases will deploy useful functionality that creates measurable value to both end users and our organization.

• Product owners will be responsible for ensuring that multiple MMP candidate options/solutions are available for consideration.

• A transparent process will be in place for determining which MMP candidates will be chosen for upcoming release.

• There is agreement on how the business effectiveness of each incremental release will be measured.

• Effectiveness data will be gathered within 30, 60, or 90 days of an MMP release to determine the business effectiveness of the release.

Keep in mind that selecting which features or capabilities that we are going to devote time and money to is a critical set of decisions for the organization. Therefore, it is a critical process for the VMO. We are about to spend significant time and significant money and the results will impact our financial standing and will also have impact to our customers. These are, in a nutshell, important investment decisions, and the process by which we make these decisions should not be taken lightly. Nor should it be done haphazardly and without some level of process rigor. Most organizations put much more process rigor on how we build than on determining what we build. We would argue that what we build and when we build it has a far larger business impact.

Select MMPs for Maximum Financial Impact

Those who have studied lean probably already have a strong bias toward eliminating batches wherever possible so as to create single-piece flow. Believe it or not, we actually do need some batching here in the discovery process. Each MMP candidate is likely to look like a good investment when evaluated individually and without respect to the other competing MMPs. But in portfolio management, we should create multiple investment options and then weight those options against each other to choose the soundest investments. The question is not, “Is this a good stock?” The question is, “What are our alternatives and which is the best investment given our risk profile?” In IT portfolio management, the question is not, “Is this a good project?” Almost every project is going to appear to be a reasonable investment. The question we should be asking is, “Of all the project requests that have been made, which are the best projects in terms of return versus risk versus time?”

The same applies at the MMP level. We should be asking, “What are our MMP options and which ones appear to be the most economically viable?” To make these kinds of comparative decisions, we need to get all of the options out on the table and weigh them against each other in a competitive manner such that only the economic winners move forward. Most organizations evaluate each project or MMP in isolation and simply try to determine whether it’s a good investment. This is not the right approach. Requests are going to come in all of the time, and each individual request, be it a project or an MMP, will probably look worthwhile. Dysfunctional organizations will therefore often try to say yes to all of them, one at a time as they come in. The result is a huge portfolio of project works in progress with numerous in-flight efforts all simultaneously competing for the same scarce resources. The result is huge spending, a lot of juggling, and very little delivery. The mistake that most organizations make is in approving all of the requests and then trying to cram them all into an already overburdened organization. As we explored in chapter 5, this is akin to shoving more cars on the highway, as shown in figure 6.2: we get really great utilization of the highway, but everyone is moving at a snail’s pace. Nobody is getting anywhere anytime soon!

The right way to handle this is to have a regular cycle of work intake, perhaps monthly or quarterly, where we put all of the new requests out on the table and make them compete against each other. We need to evaluate which ones are the most financially impactful with respect to our available capacity, available funds, and time criticality. This ensures that we don’t overload the organization and that we are focusing our limited resources on the highest-value work that can be achieved in the shortest amount of time. This process is commonly illustrated as a sort of portfolio funnel diagram as shown in figure 6.3.

Basically, we want fast return on investment. This helps not only our organization but also our customers, because the focus on speed means that we get solutions that they value to them faster. How will we measure ROI? There are several ways to think about this and many organizations take a somewhat simplistic approach of measuring how much an effort will pay us back divided by how much the effort costs. This is not wrong, but it does ignore a very important part of modern finance: the time value of money as shown in figure 6.4.

images

Figure 6.2: The crowded highway

images

Figure 6.3: Portfolio funnel

images

Figure 6.4: The time value of money

Ensure That Time Value of Money Is a Key Consideration

Unfortunately, most organizations do not consider the time value of money when making their project investment decisions, even though it is one of the most fundamental elements of modern finance. The essence of the time value of money is that “A dollar today is worth more than a dollar tomorrow.” Dollars that we have today are worth more for at least three reasons:

• Money that we have now can be reinvested into other efforts that further enhance our position.

• Money that we have now is not devalued by future inflation.

• If we get the money now, it is safe. Who knows if we will even get the money we are promised in the future.

Dollars that come in the future are worth less. Inflation will make those dollars less valuable by the time we get the money, and who knows if we will ever even get the money. We also lose out on the opportunity to reinvest those dollars to earn compound interest. This is all elementary finance, and yet most organizations do not put enough emphasis on the payback time for their project investments. If they do look at payback period, it is often in terms of years. Those sorts of time frames may have been appropriate back in the 1900s, but they are not appropriate now, when expectations of speed have never been higher.

Consider the following:

• Big waterfall projects take a long time to complete, usually longer than planned.

• Many of them fail outright due to the high risk of even doing big projects in the first place.

• Even those that do not fail outright often underperform against their business goals.

For these reasons, traditional methods of delivery have very high financial risk. These risks can be mitigated by demanding that investments start to prove themselves sooner. We should choose our investments partly on how quickly they can begin to generate positive returns or at least project payback.

By starting to deliver sooner, we get many positive benefits:

• We start to see if this team of leaders and staff can even deliver.

• We start to test out the product and see if our users are going to accept it and use it.

• We start to test out our delivery process to see if it needs improvement.

• We start to test out the engineering decisions that have been made and our architecture.

• We start to get paid back on our investment.

• We start to satisfy some of our customers now.

All of these can be used to make adjustments so that we start to uncover risk early and start to find ways to mitigate it. There is probably no better way to reduce risk than to demand that investments prove that they can deliver in the near term.

To choose the right investments, we need to compare the time value of money for each request and select those that have the potential to achieve the greatest paybacks in the shortest amount of time. This means estimating how quickly we can deploy functionality, how much it will cost, and what we think the business results will be. Easy, right? All we have to do is estimate.

Expect and Account for Weaknesses in Estimation

Historically, while we may be good at delivering product, almost across the board in all industries, project and product teams are absolutely terrible at budget estimation and time estimation. On top of that, we are even worse at estimating the resulting business value that we think will get from a project or product or release. If ROI is the business return divided by the investment, and we are not good at measuring either, then how can we ever hope to make reasonable investment decisions? To measure the time value of money, we need to not only measure ROI but also estimate how long it will take to see the returns. How can we hope to make reasonable investment decisions if we can’t adequately measure what the cost will be, what the return will be, and how long it will take to achieve the outcome?

Most organizations try to put hard estimates in place using actual dollars and calendar time in order to make these decisions. It is not uncommon for our estimates to be hundreds of percent off. Maybe there is a better way; perhaps detailed estimates are not actually necessary. Remember that our goal here is to choose the best investments given all of the requests that have been put in front of us. That means we might only need to compare our options and choose the best; we may not really need the absolute numbers.

Deliver More Value by Delivering Less

In our agile consulting and training practice, we routinely ask our customers to approximate the percentage of software that they produce that is infrequently or never used. The results are shocking and yet sadly consistent. A good 40–70 percent of the software that is produced is never or rarely used. This is a huge source of wasted time and money. The best and cheapest way to get our organizations to move faster and spend less is to not build the 40–70 percent of stuff that our customers do not use. By not spending time and money building this software, we can devote more time and more focus on building what they do want. With the time and money that we have saved, we can make that software the best that it can be through intense quality focus and support. It is no trivial task to discover what customers might actually use. They will repeatedly say that they want every feature under the sun, but when it comes to actual usage, the reality is often quite different. Thankfully, there are tools and approaches that help us to uncover what users might actually value.

Use WSJF to Prioritize and Select the Most Impactful Options

Donald Reinertsen popularized the method of weighted shortest job first (WSJF) in his book Principles of Product Development Flow,1 and the method is now widely accepted and practiced. WSJF says that we should compare our investment options against each other and select the highest-performing ones on the basis of two factors: the upside, or what he calls the cost of delay, and the size or cost of the investment. This is a simple way of taking the time value of money into consideration.

Understand the WSJF Formula

The WSJF formula may seem daunting, but it is really quite easy. The formula compares each investment candidate against the other investment candidates along several different factors. All of these factors will go into weighing the investment option, and the investment that ends up weighing the most is the financial winner. It is the financial winner because it generates the most value in the least amount of time. The method uses five key factors to help you decide which investment option will be the most immediately impactful:

• User business value: How does this MMP compare to the others in terms of delivering business value?

• Time criticality: How important is it to have this particular MMP done by a specific time compared to other MMPs? For example, in tax season, having certain functionality in place may be legally required.

• Risk reduction: How does this MMP compare to others in terms of lowering our risk profile?

• Opportunity enablement: How does this MMP compare to others in terms of creating new opportunities or opening new doors for us?

• Job size: How big or complex is this MMP compared to the others that we are evaluating? This is a proxy, or a substitute, for time and cost.

Putting it all together, we get the WSJF formula shown in figure 6.5:

images

Figure 6.5: Weighted shortest job first formula

Ensure That Scoring Is Done as a Group Activity

One of the most important aspects of scoring is that it is a participatory activity that takes in the perspectives of multiple viewpoints. Do not perform WSJF scoring by having one person do the scoring in isolation. It is not a solo activity to be performed by a project manager or product manager. To weigh multiple MMPs against each other, we need multiple perspectives to discuss and agree on the scoring of business value. We need business inputs on value, time criticality, and opportunity enablement. We also need senior technical input on risk and job size of each of the MMPs. Finally, there should also be plenty of transparency into how these decisions are being made. Remember that deciding what we are going to build and in what order is perhaps the most important decision that our organizations make. This is a portfolio management function and the VMO team needs to be involved. It should not be an ad hoc process, nor should it be dominated by rank or title. It should be based on the sound financial judgment of a portfolio investment committee or team that represents multiple viewpoints.

Generate the WSJF Data

How do we actually score our MMPs using this system? Here is the beauty of the whole thing: we may be able to make good economic decisions without having to estimate either time or money. We can make those comparisons by using a simple point system instead of having to guess at real dollars and time. In other words, I don’t need to estimate that investment option number one will generate $5 million, take 12 months to achieve, and cost $2 million to complete. All I need to know is that investment option number one will probably generate more money in a shorter time frame than investment option number two. By systematically going through a comparative ranking process, we can arrive at the best investments without ever having to estimate how much they will actually cost or how long they will actually take.

Do not do the scoring horizontally, or by rows. Do not try to do one row at a time and assign all of the values and then go to the next row. The point of this system is that you have to compare each item to all of the others for each factor. Doing all of the scoring for an MMP at once misses the point of comparing investments against each other to find the best investments.

images

Figure 6.6: Comparative estimation

In figure 6.6, we don’t know what the cost-of-delay ball weighs, and we may not need to. We do know that it weighs more than the cost-of-investment ball, and perhaps that is all we need to know to move forward.

What we do is lay out all of our investment candidates and find the one with the lowest user business value and we give that one the minimum score of 1 point. We use the Fibonacci sequence for subsequent numbers and then estimate the other MMPs relative to this lowest one. Perhaps we think that some other option will generate two or three times as much user value as this lowest-value one. If so, then we give that one 2 or 3 points. We continue in that fashion until we have scored all of the MMPs for user business value, and with that we are done weighing the business value scores for all of our MMP candidates.

Now we move to the next column and choose the MMP that is the least time critical and give that one 1 point of time criticality. Perhaps there are other MMPs that have much greater time criticality, and perhaps they have functionality that absolutely must be in place by a certain date. If so, we might give those MMPs many more points, 8, let’s say.

The key thing to remember is that to perform the scoring we assign relative points in column-wise fashion. What we mean by that is that we work vertically down the list by comparing each MMP’s business value against all of the others and scoring them. Then we go to the next column and compare the time criticalities against each other. Then we go through again and do the risk reduction, and then we go through one last time and compare the job sizes. See figure 6.7.

images

Figure 6.7: Column-wise comparison

For example, suppose that we had six investment opportunities. In the typical and traditional world, we might be inclined to start on all of them as they are probably all important. In this model however, we want to avoid putting too many cars on the highway and slowing everything down. Instead, we are going to select one or two to get started with, and we select those that will result in the most upside in the shortest amount of time. We would go through the columnwise comparison and end up with the fully populated table 6.1.

Table 6.1: Fully Scored WSJF Table

images

Score the MMPs Using the WSJF Formula

At this point, we have a table that has all of the scores for all of the MMPs or features. We use these numbers by putting them in the WSJF formula to get the scores as shown in table 6.2. As a reminder, the WSJF formula is

WSJF = (business value + time criticality + risk reduction or opportunity enablement) ÷ job size

We perform this calculation for each MMP row, and the MMP that ends up with the highest WSJF score wins. It wins because, by our own comparisons, it seems to generate the highest combination of business value and risk reduction and opportunity enablement in the least amount of time. The MMPs with the highest scores are our best guess at the economic winners and the ones that we should try to do first if possible. From a time-value-of-money perspective, they generate the most upside in the least amount of time.

Table 6.2: Scored WSJF Table with Final Rankings

images

Table 6.2 shows an actual example of a completed WSJF scoring table and the resulting ranking. The winning option, “Auditing” in this case, has a WSJF score of 12.00 making it the clear economic winner over the others. “Authentication” is the next-best-performing investment and the lowest-scoring investment is “Reporting.”

Recognize That the Highest-Value Request Does Not Always Win

Many of us who have been around the agile community for a while may have been taught to prioritize backlog items according to highest business value and work on the highest value items first. That seems like a commonsense way to prioritize work. However, it lacks the critical element of modern finance, the time value of money, which WSJF does take into account. In the example in table 6.2, the winning MMP has a score of 12.0 even though it only has a user value score of 2, making it one of the lowest business value items in the list. It wins because it has a great risk reduction score of 8 and a very low job size, or duration, of 1. This MMP generates a lot of goodness in a short amount of time, so we should strongly consider doing it first.

Deliver the MMP and Learn

Now that we have decided, as a group and using an open and transparent process, what our best investment is, the VMO should prioritize, or sequence, this MMP for delivery. The MMP should get the attention and focus that it needs to quickly get through the agile delivery process and into production so that we can generate value for our customers and for ourselves. When that happens, we can use the data coming back from customers, sales, help desk, and elsewhere to see how we can improve both what we deliver next and how we deliver it.

Summary

In most organizations, investment decisions either at the project level or even at the individual requirement level are made in isolation. We look at each individual project and try to determine if it is a good investment, and we look at each individual requirement and try to determine if it is a good requirement.

The result is that almost all requests are deemed good, resulting in massive organizational work in progress. Most organizations have way too many projects going on simultaneously and, within a project, are trying to juggle too many simultaneous requirements. The result is massive spending, slow delivery, and low economic value delivery. It also results in a huge percentage of features that are never actually used because they are of low value to end users.

One of the key roles of the VMO is to stop this economic madness. The VMO needs to flow work through the organization toward delivery, and that flow needs to be prioritized on the basis of economic value.

With the VMO, we can manage below the project level by changing the unit of focus from projects to MMPs, and we can require that large efforts decompose their deployments into these smaller shippable MMPs.

Requests either at the project level or even at the MMP, or feature, level need to be weighed against each other. Many requests are economic losers that cost far more than the value that they return. Use WSJF to find the MMPs that generate the most value in the shortest amount of time, and try to sequence those first if possible. WSJF is an elegant way to quickly and easily determine the relative economic value of requests so that the organization can focus on the work that will drive the most value in the shortest amount of time. This method is solidly based in a key principle of modern finance, the time value of money.

Try This: Limit Product Work in Progress

A simple and quick way to jump-start the MMP approach is to limit your product work in progress to a few MMPs. Give them the focus and attention that they need to get into production quickly so that you can generate value for your customers and for your organization. Once the MMPs have been delivered, use production data to evaluate their performance so that you can improve the prioritization and delivery of future MMPs.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.87.209.162