Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

When it Comes to Delivering Business Value, Confidence isn't Enough

DZone's Guide to

When it Comes to Delivering Business Value, Confidence isn't Enough

Check out this criteria that you should use to justify your confidence in delivering business value by justification, not just instinct.

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

In our Transformation practice, we are helping organizations change how they plan and execute work to be done. We help them shift from a focus on outputs to prioritizing outcomes and delivering business value. As the product practice lead, I help our clients on the develop-the-plan parts of Transformation.

Only The Starting Point

The starting point of developing a plan is to focus on outcomes — benefits for the business — and then to determine which things could be built which provide value to users and customers, in ways which contribute to the outcomes for the business. In the world of "valuable, desirable, and feasible," this is the combination of valuable and desirable.

But that's only the starting point. Every plan has an implicit risk in it, and the first area of focus is on the business risk — the risk that these "things" are neither valuable nor desirable. The next step in developing a plan is to understand how much risk is in the plan and to make the risks explicit.

Subtle Transformation

I was working with a client team who had previously made a set of commitments to deliver a set of functionality to stakeholders for the rest of the year. This team had been operating in an "output oriented" mode, committing to a set of deliverables by a given date. Fixed scope. Fixed schedule.

The first steps in the journey of Transformation, for Leading Agile clients, is to move from the heroic-operations mode of asking teams to meet changing requirements to fixed deadlines (the upper left quadrant of dealing with emergent requirements in an organization which values predictability) to the lower left "standard" model of predictability. Stabilizing the system of delivery, such that the team is able to make and meet commitments.

There is a subtle Transformation which takes place here, too. The team must acquire the ability to make and meet commitments on the outputs they are delivering. This is necessary, but not sufficient. The team must also Transform to develop the ability to be outcome-oriented, and that means making and meeting commitments with respect to outcomes.

  • Step One is to predictably deliver the things you said you will deliver. It doesn'tmatter if those things are valuable, or desirable. They only have to be feasible. Of course, if you're wasting the team's time and asking them to build things which are unimportant, then you have a different problem.
  • StepTwo is to predictably deliver the outcomes you intended to deliver when you chose the "things" to be delivered.

So, What Do You Do?

This is where that giant business risk comes in. What if the things you choose to build don't deliver the outcomes you intended? What do you do?

More importantly, what do you do ahead of time? You de-risk the plan. By making those implicit risks explicit. By forming hypotheses and testing them before you commit the team, the time, and the resources to building stuff. But how do you know what to test? You test what is most important to test, those things which are most likely to be wrong, and which would most jeopardize your outcomes if they're wrong.

You estimate the size of the damage of being wrong the same way you estimate the value of being right. Your business case, or estimate, or wild-ass guess of value. Most people would then combine this with their confidence in the mechanisms of value delivery-that the things actually work.

Most people would be wrong.

"I don't care how confident you are. Your level of confidence doesn't matter."

The team described one of the outputs they had committed to deliver, and explained why they believed this "thing" was both desirable to the users and valuable to the business. Something seemed wrong to me, and this was my first workshop with the team and exposure to their plan, so I asked "how confident are you that this thing will deliver the desired outcome?"

The team responded with complete agreement — "80% confident."

I then showed them the following confidence rubric with a 1 to 5 "confidence" scale which I developed while working with another client. Along with some chuckles, the room was filled with only "zero" and "one" responses.

How Justified Is Your Confidence?

5 - a hypothesis based on extensive research

4 - extrapolation from correlated data

3 - inference from related data

2 - "expert" intuition based on domain knowledge

1 - speculation: "I imagine/expect this will work"

0 - "Let's try something and see if it works"

The rubric is a range from "no reason at all to be confident (0)" to "very good reason to be confident (5)." The team now assesses the justification of confidence of all their hypothesized methods of delivering value, and is well on the way to making and meeting commitments in terms of outcomes and not just outputs.

Our early goal to make and meet commitments in terms of outcomes is sensitive to the risk of building the wrong things. When the team delivers the wrong things on time, they fail to deliver the outcomes. They fail to deliver value to the business. To identify where the greatest risk is, in terms of delivering value, we need to combine both the greatest impact of being wrong with the greatest likelihood of being wrong.

The ikelihood of being wrong correlates with the justification for your confidence, not with your actual confidence. Use this rubric to better identify the risks to be tested. Your plan will be better.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.

Topics:
agile ,confidence ,cd ,business value ,value delivery ,agile transformation

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}