Deliver Some Value Now, Deliver More Value Later

January 30, 2015 | Author: PM Hut | Filed under: Agile Project Management

Deliver Some Value Now, Deliver More Value Later
By Brian Dear

We have a hypothetical application that lets small hotel owners and managers accept reservations over the web. Visitors can visit the site and book a room. The application helps managers keep track of their available rooms as well as keep records about their customers.

In organizations that don’t do Agile correctly there’s a common pattern:

  • A product manager wants a feature, in this case, let’s say that it’s “email notifications for a new hotel booking”

  • The product manager creates a User Story for this feature. The user story is some version of “As a hotel manager, when a customer books a room in my hotel, I want to receive an email containing that customer’s relevant reservation information”

  • The development team begins building the feature. They finish it and deliver the story for user acceptance.

  • The feature is reviewed by the project manager and other relevant stakeholders. The feature meets the requirement, however the card is rejected because the stakeholders, while happy with the email feature, decide that, in addition to an email notification, the user ought to receive a text message notification as well. Since it’s all about “notifying the user of a new booking,” this is considered a “part” of this user story.

  • The development team gets instructed to add text messaging. The product manager adds text messaging to the email story card and the card status is changed from “pending acceptance” to “in development”

  • The development team completes the text messaging addition, delivers the card and the product manager, along with the stakeholders reject the card because they weren’t happy with the flow of the text message process. They have a meeting to determine how they’d like the feature to work, the card is kicked back to the developers, annotated with notes, and development continues.

This cycle continues until eventually, the “email notifications” card is accepted and deployed.

While to the casual Agile enthusiast, it would seem that this is agile. Starting with a base feature, then iterating on it until the feature is “correct” However, this is the furthest thing from agile; it’s scope creep. Scope creep is when an original feature grows, almost imperceptibly beyond its original intent.

Doing It Agile

Understanding the pain

To understand this, we need to examine this feature on two levels. First, we should decide on what business value of this feature is designed to provide. Start with the user.

Before this feature is created, the only way a user would know if someone booked a room at their hotel is by logging into the system and checking their dashboard for new bookings. It requires the user to proactively participate. It requires an action on the part of the user for them to gain value from the software.

What has been happening though is that a busy hotel manager doesn’t have the time to constantly log into the system to check for bookings. So occasionally, guest are arriving without the manager even being aware of the reservation. The room wasn’t ready, guests were mildly annoyed; Guests complained on Trip Advisor and the average rating for the hotel went from 4.5 stars down to 2.5 stars. Business suffered, employees were dismissed, the local area became filled with crime and poverty due to the loss of jobs, eventually the hotel closed and the owner died penniless and alone — all because the manager wasn’t getting notified about new bookings.

In this case, the business need is that a manager needs to be notified when something important happens on the system so they can ensure that the hotel is able to act and prepare accordingly. The goal is “to ensure that the right people get the information they need when they need it”

It’s important to note that we haven’t mentioned anything about how we achieve that goal. We didn’t discuss email or text messaging or phone calls or carrier pigeons. We simply defined the specific business problem our feature is trying to solve.

Understanding the goal

It’s pretty clear that a hotel manager needs to get notified somehow. We aren’t sure what is the best way just yet, but we do have some basics theories. Using Lean principles, we want to think of the most minimal way we can solve this problem. What is the absolute minimum we can build to deliver value quickly? We decide that the easiest way would be to use an email notification. The dev team assures us that this could be quickly built — which means the hotel owner gets his problem solved as soon as possible. It might not be the perfect solution, but it is a solution that we could then later expand upon. The important thing is to deliver value right away. The hotel has a real pain point and it’s costing them money.

Achieving the goal

The email notification feature gets a user story. The dev team starts the story and delivers. The story is accepted and deployed. The hotel manager now gets email notifications and the problem improves.

Iteration and Improvement

Email notifications are helping the problem; the pain is reduced, but not completely solved. We learn that email notifications work well, however the manager complains that, while his job has gotten easier and he’s missing fewer bookings, he still misses a few because he doesn’t always check his email consistently throughout the day (he’s a busy gent!) However, he always carries his phone with him while working on the property.

Armed with this learning, we decide that a text message might be the best way to ultimately solve this pain. We then create the feature to add text message notifications to the existing email notification system. Meanwhile, during this process, the email notification system is working and delivering measurable value to the hotel.

We then repeat the process with the text message notification system until ultimately the pain point is solved (or at least solved enough that we can move on to creating more value in some other part of the system.

Isn’t scope creep just accelerated iteration?

One might argue that in the opening example, we simply accelerated this process. After all, ultimately, in both versions of the workflow, we ended up with email notifications and text message notifications right? However, there’s a subtle, yet profoundly important difference. In the first example, we didn’t learn, we assumed. We assumed that email notifications would not be enough, when they just might have been. We short circuited the learning process. While in this case we were “right,” much of the time we won’t be right because we can’t predict the future. We can’t always predict how a system will actually perform when used by real people.

Don’t delay value

Also, another problem that the first approach presents is that we’ve delayed the delivery of value. Instead of getting the email notification out the door where it can start delivering value immediately, we delayed it in order to be more “complete” We could have potentially cost the hotel money, when instead we could have at least stopped some of the bleeding. Remember, the goal of all software projects is to deliver value as quickly as possible.

Be mindful of costs, especially opportunity cost

Finally, what if the email notifications would have been enough? We’ve driven up our development costs building a feature that might not have been worth the cost. We also have the opportunity cost — what other features got delayed or pushed back because we thought we needed text messages, when in fact we might not have needed them? Budgets are not unlimited. If you multiply the cost of scope creep across an entire project it can result in significant cost overruns. One project on which I was hired to consult suffered from this to such a significant degree that the original $300,000 budget exploded to $1.2 million and, as of this writing, still hasn’t been delivered. Will Rogers summed it up best, “When you’re in a hole, stop digging” At the point of the project where the cost overruns have gone to such an extreme, one must ask oneself, is the additional “value” created from the scope creep worth the additional costs incurred?

Key Points to Remember

  • The point of iteration is to deliver value sooner and maximize learning.
  • Don’t assume. You can’t predict how users will actually use your product

  • Stop the bleeding; deliver some value now, add more value later.

  • Opportunity cost is a real cost.

Brian Dear is an entrepreneur and a software engineer. You can read more from Brian on his blog.

PM Hut - The Project Management Hut: Project Management Article Separator

Project Management Categories