Drive Value to Your Projects with Agile Discovery

Frustrated with scope creep, mutating specifications, and hidden dependencies on projects with poor foundations, we standardized our Agile Requirements Engineering process to maximize ROI for our clients and focus on building a shared understanding and vision for a product’s roadmap.

We call this process Value-Driven Development, as it focuses on delivering business value and not just functionality.

Our Agile Discovery Mapping process leverages the best practices of roles typically owned by business analysts, product owners, technical project managers, and lead developers. Through detailed multidimensional requirements mapping, we build bridges of understanding between stakeholders, designers, developers, and the business customers.

Our process focuses on value-first: we hypothesize, set up tracking for, and implement value-driven digital experiments with products, all to make sure you build the right thing for your customer—and for your business.

Why is Value-Driven Development and Agile Discovery Valuable to Your Business?

Have you ever sat down with a client to discuss the Agile requirements for a project, only to find out later that there was a misalignment, that the shared understanding of what you were building was off?

Let’s be honest; it happens.

Whether you are a new solutions provider or one who is seasoned, the shared understanding between you and your clients will always be imperfect because you each maintain your own unique perspective and experience.

But this doesn’t mean you can’t get closer to perfection. Agile Discovery is meant to bridge gaps of understanding between you and clients by giving you the tools needed to pull valuable information about projects out of the client’s head, so you can put it into project specifications and deliver features that maximize ROI for their business.

The foundation laid by Agile Discovery drives conversations and produces an enriched, unified framework for detailing project requirements.

With Agile Discovery, you’ll know how to:

  • Iteratively deliver the most-valuable solution for the client.
  • Plan for the unexpected and deal with roadblocks every sprint.
  • Present risks (as far as technical implementation) early on, and ensure the client understands the risk of additional costs for certain features.
  • Lessen the gap between when requirements are defined and when developers review requirements.
  • Pull value out of the client’s head and put them into the specifications for your projects.
  • Build the most valuable project features first.
  • Build data-driven applications instead of data-informed applications.
  • Make discovery continuous for you and your team.
  • Mitigate risks for both you and the client.
  • Achieve value-driven development through the specification process and continue to deliver business value.

How Communication Breakdown Leads to Project Failure

The leading cause of project failure is a breakdown in communication, either due to ineffective communication, “leaky understanding”, or both.

Ineffective Communication

You can’t telepathically communicate with your clients, and you are limited by the language you have to communicate. Most of the time when stakeholders come to the table, they come with a list of features, requirements, and other things they want the site to have.

“I want a checkout feature, registration feature, and filters to look at electronics projects,” the client might say.

You hear the list of features and you try to bring about a shared understanding through documentation. You read the documentation and believe you have a firm grasp on what the client wants; the client reads the documentation and thinks you comprehend what he wants.

This is how we’ve been trained to think about solutions and services.

In reality, written specifications mean little. Just because you shared some written specifications, doesn’t mean you think about the solution in the same way as the client, and it certainly doesn’t mean you will be able to deliver the client’s vision.

Shared requirements and a listening ear don’t mean shared understanding—period.

Relying on these two components will ultimately lead to:

  • Additional costs during development
  • Frustrations with miscommunications
  • Time lost to project extensions
  • Loss of scope

The moment you sit down with a client and you hear a list of features, you need to be thinking:

  • What goals are the client trying to achieve with these features?
  • What do these features look like to the client and the end-user? How do they react or function?
  • What specific value will these features deliver? (e.g. Increased conversion rates? Boosted sales? Lead generation? Demand generation?   

This thought process and focus is the only way you’ll be able to define what features of a project are going to be the most profitable for the client’s business and, in turn, drive value for yours.

So as the two of you dialogue, the conversation needs to be centered around the business goals the features are tied to. Then, following that meeting, you and your team need to brainstorm heavily around how you plan to deliver the features and requirements requests for the client and the end-user to achieve those business initiatives.

Leaky Understanding

Okay, let’s say you’ve laid the foundation for a more perfect understanding of the project requirements, does this mean communication breakdown and project failure are less likely to occur?

To the contrary, both remain at risk due to “leaky understanding”.

Time erodes all things. It’s certainly true when it comes to long development life cycles. Over the length of the project, the client can fail to remember the details of the project and the initial vision discussed between you two. The same goes for your developer—what you told the developer at the beginning of the project leaks with time.

This can set you back on the road to going over project budget and losing time to project extensions, as well as loss of scope.

Also, local context can be easily confused with global contexts. What we mean by this is there are times when developers assume that some local context for the solution that they are developing some feature for, applies to other parts of the project. You know, business logic sometimes gets applied from one solution to another unrelated solution.

You need to re-discover and review requirements with both the client and your development team along the course of the project to confirm everyone’s understanding of the solution that needs to be developed, including the local context.

Building Bridges of Understanding

This image of an iceberg depicts how you and your client see a project

 

Like the image you see above, when it comes to a project, the client sees the tip of the iceberg. They can only talk about what they know and see at the surface level, and this means they will describe things with simplicity (e.g. how many pages they want and how many different types of content).

They don’t really see the infrastructure or deployment steps, the quality assurance, QA automation. There is so much underneath the surface, and you need to be talking about that with your clients.

Your job as the developer or solutions architect is more just carrying out the project; your job is also an emergency preparedness expert. You have to raise concerns about what's underneath the surface.

Give the client the impression through the discovery workshop that you need to be pulling out all of this information in order to deliver on the things under the surface, such as:

  • Business logic
  • Edge cases
  • Testing
  • Value for user
  • Value for business

How Agile Discovery Mitigates Risks

Change requests, bugs, and scope creep are a natural occurrence with projects. The fact of the matter is that both you and the client are learning about this new system that your building, and how people interact with it will change as they see more of it come to life.

There has to be a plan in place to address these learnings and changes over time.

While risks with project delivery can be mitigated 50% by planning, market condition risks are mitigated by testing out your hypothesis and making sure that what you think is going to be successful and deliver value to the business will really deliver value.

To minimize risks in an Agile fashion:

  1. Plan and develop features month-to-month.
  2. Deploy the release for User Acceptance Testing (UAT) by the client before deploying to production.
  3. As the client and their team use the feature, they may uncover bugs or have a few change requests.
  4. Now, the next time-boxed delivery of features is going to include the results of that UAT—the client’s feedback and results from the marketplace will inform your product backlog and agile development roadmap.

How to Define Value

Value must be looked at in two ways: Value for you and value for the client.

No matter which way you slice it, features are going to cost your company the initial investment as well as maintenance cost. You need to think of the total cost of ownership before you take on the development and delivery of each solution.

Once you’ve done this, your next step is to plan for how features are going to drive value for the client, then be able to prove it.

We define value in the following ways:

  1. Value stories. Value stories describe value delivered to the business. It is what stakeholders define as valuable to their business, and it is what they ultimately expect you to deliver on.
    1. Value story examples include an increase in page views per user session to drive 10 percent growth in display ad revenue.
  2. Trackable KPIs. This is how we make value tangible. You will want to express to the client what tools you have in place to track KPIs and test.

With these components in place, you can negotiate and express which features are most likely to drive value, and how. Then, you and your team can qualify the features that are going to be valuable and prioritize them in a flat backlog where they are ranked by which will deliver the most value to the client.

How to Deliver Value-Driven Development

Stakeholders are looking at the project in its entirety and are expecting a certain result—even if they aren’t clearly communicating this expectation, there is one. Make sure you find it! Even with this expectation, your job is to help the client understand which features are the most profitable and which are going to cost money but provide little return.

A depiction of the Discovery process

 

The Discovery process is designed to help you move through the steps you need to take to render value-driven development.

  1. Build a foundation
    1. A foundation of understanding among team members
    2. A foundation of assets and standardized points of reference
  2. Draw things out
    1. Visual images help build a shared understanding.
    2. Build a user story map to define value delivered to end-user
    3. These 2D maps look at value from the end-user’s perspective. So, we may look at website quality and figure out which maintenance projects will help improve quality of the site.
  3. Narrow the cone of uncertainty
    1. Take ideas and push them through a funnel that’s going to process a very small focused solution.
  4. Roughly size the project’s scope
    1. How much work and effort do you predict project delivery is going to take?
      1. Include how many stories, how many levels of acceptance criteria each feature is going to have, etc.  
  5. Tell a story about customer value
    1. What value are you trying to develop and deliver to your client’s customers?
  6. Tell a story about business value
    1. How much revenue is being delivered to the business with the features that are being developed?
    2. How much additional engagement is being driven?
    3. If you can’t answer those two questions, then the feature may not be worth building.
      1. All features should be designed to do more than have aesthetic appeal. All built features should, in the big scheme of things, be designed to generate value.
  7. Find a balance between cost and value
    1. Are you going to get the value you need out of developing the solution, or is it going to be too expensive?
      1. The question here is the total cost of ownership, both in initial implementation and maintenance.
    2. Maximize ROI by looking at each of the features that are being developed, identifying opportunities where there is a short timeline to return on investment, and reduced initial investment cost and maintenance costs over time.

Making Discovery Continuous with Agile Discovery

When you adopt Agile Discovery as part of your process, you’ll be able to continuously deliver requirements just-in-time.

Not to be confused with rushing to delivery, just-in-time delivery means you’ve ensured high-resolution requirements gathering and a higher-resolution rendering of a value-driven solution before each sprint.

If you are defining features at the beginning of a one-year-long development life cycle, you’ll end up missing the mark with leaky understandings, and perhaps may be affected by changing market conditions as the project progresses.

Discovering requirements and defining features with the client and your team each sprint will allow you to mitigate risks associated with project delivery and market conditions because you’ll be focusing on some section of the solution or some feature that you’ve defined high-resolution requirements for.  And it will be understood by all parties that THIS is what you’re going to build.

Well, there you have it—tools for value-driven development via an Agile Discovery process.

Still not clear? Contact us! We can walk you through our Discovery Workshop.

Get Help With Your Agile Discovery. Waste Less Time.