How Do You Know If Your Organization Is Delivering Value Through Software?

DZone 's Guide to

How Do You Know If Your Organization Is Delivering Value Through Software?

The only way to truly gauge software effectiveness and value is by closing the gap between developers and customers.

· Agile Zone ·
Free Resource

 There are no guarantees that DevOps and Agile will ensure that your software products will provide better value to customers – just that your customers should receive the product faster. Speed, however, is redundant if what you deliver doesn’t meet a customer’s requirements. In that scenario you haven’t provided business value — you’ve just delivered disappointment.

 Thanks to Agile sprints and product prioritization, cross-team collaboration, CI/CD and release automation (among other innovations), organizations are building and deploying products faster than ever. In fact, according to The State of DevOps Report, high-performing organizations are deploying 440 times faster (from code commit to deploy).

Speed is important – the sooner that a product is in production, the sooner a customer can begin using the application and providing valuable feedback. But what if the customer feedback is: “What the hell is this?”

What do you say then?

You ask your DevOps team and they fire back: “We just did what we were instructed to do!” This response isn’t passing the buck; it’s a valid point. A developer’s code is only as good as the level of detail in the epics and stories that they’re working with. And operations will deploy this code unless told otherwise. Both teams can only work with what they have.

The success of a product hinges on two things that take place before a single line of code has been written:

  • Customer success activities upstream: all activities relating to the clear understanding and articulating of a customer’s current and future needs via clever software design.
  • Knowledge-sharing: how the product-critical information created from these activities and changing customer needs is flowed downstream to ensure product accuracy (and value delivery).

Product Articulation

If we accept the fact that DevOps has optimized the product activities downstream, then we should turn our attention upstream to the "plan and design" stage. Upstream is where a lot of the magic happens. That’s where creativity, design, experience and resource management come together to turn a customer’s vision into reality. Its importance becomes clear when you consider what happens during a typical product request:

  • Sales captures the customer's needs and requests — What do they want and why?
  • Requests are analyzed into features/initiatives by product and business analysts – Can it be done well?
  • Effort, cost and time resources are assessed by PMO – Are we prepared and capable?
  • The UX design is sketched and tested by UX designer – Is it intuitive, graphically pleasing and simple to use?
  • The request is broken down into epics and stories by product owner/managers – How exactly do we build this product? 

At least five different types of people are typically involved in the product articulation phase — six if we include the customer. There are also five common types of product-critical information: customer requests, requirements, features, epics and stories. The quality of this data, and how it is shared between collaborators, is what creates value.

It’s also where value is lost because of insufficient knowledge sharing. Poor/incomplete information begets even worse information. The fidelity of the artifact becomes diluted. It’s reminiscent of a game of telephone; even if the first bit of information (the customer request) is clear in terms of what they need (at that moment of time), it’s what happens next in sales that’s matters most.

A customer account team is the first port of call for a customer, the primary touch point and generally the folks who know the customer best. They are an invaluable well of real-time market information and a vital link in the enterprise software delivery process. We only have to return to the typical product journey to understand why.

An account manager agrees to a deal with a customer, working hard to demonstrate how software will support a customer’s business. Now it’s about delivering on that promise. Yet there’s no formal process for submitting new jobs. Typically, the account manager logs the request into a sales tool. They then fire off the request via email to the product team, which uses a product management tool.

The product team, however, is already managing a stampede of priorities to ensure their organization is building the right products, including (but not limited to):

  • Driving innovative feature creation
  • Defining customer requests in great detail
  • Balancing the need to bring down technical debt
  • Reducing defects
  • Managing the flow of work

With all this work to juggle, there’s a strong chance that the product request may fall down a black hole – even if the email heading says “URGENT.” Products are often being pulled in multiple directions, and the onus is on them to manage this complex flow of requests by categorizing and triaging. While they can create a spreadsheet to store all this information, there are two major issues with this approach:

  • All this information is duplicate entry as it already exists in the sales tool, forcing time-strapped teams into wasteful manual non-value work (waste).
  • ­­­­­­­Product doesn’t have the time for this pesky administration, increasing the likelihood that the product request will fall between the cracks.

Sales and product groups need to rethink how they share information. Email is just not fast or clear enough – especially if a feature is business-critical. And this applies to all interactions between specialists in the software delivery value stream from ideation to operation. 

Information should become more comprehensive as it moves downstream between teams. A requirement, for example, should be enhanced by new comments, updates and product definitions from collaborators as it moves from one stage to the next.

And to avoid scope creep and loss of value, there needs to be clear contextual bondage between ideation to production. All epics, user stories, tests, etc., must be tied to the original artifact (a requirement) until it’s deployed. It’s about keeping the family together as you travel down the same road. This level of visibility is achieved through a free-flowing knowledge-sharing network.

The "Why" Behind the Code

You cannot create an effective knowledge-sharing network through email threads, status meetings, spreadsheets, tool-switching, etc. These archaic forms of communication are too slow, cumbersome and susceptible to human error (as illustrated by the issues we discussed between sales and product).

Instead, we need a frictionless, instantaneous flow of knowledge across all key touch points during a product’s journey. This type of network is created by integrating all the teams that plan, build, and deliver the software, by automating the flow of artifacts between tools. The result is a transparent link between practitioners that enables real-time dialogue in their tool of choice.

With this, all specialists can collaborate with colleagues up and downstream as it’s happening – including the customer. Now when developers receive epics or stories, they can see the whole product journey in their tools. They can see everything that has happened in the plan and design stage that creatively transformed a customer requirement into a blueprint for an application. They now have the "why" behind the code.

If developers do have any concerns regarding scope creep from the initial customer request, or that piece of information is missing, or that something just doesn’t make sense or seem right, they have a very simple means to evaluate what’s going on: just open the requirement in the Agile planning tool.

From there, they can easily see all the activities and actions that have taken place since product ideation. They can ascertain which team members in sales, product, PMO, etc. are involved in the process — including what action they took and why, and then directly communicate with them. 

Customer Collaboration

Crucially, because they now have direct lines of communication to sales, by proxy they have a direct line to customers. By combining that knowledge with customer feedback from operations and the field, developers now have a deeper understanding of why they’re building a product, increasing their interest in the value delivered. They’re now asking their own customer success question: “Why am I building this product, and how does it deliver value to the customer?” 

Through an integrated software delivery value stream, “Dev” is now more closely tied to the product and the customer’s satisfaction, as are operations. “Ops” can also see a product’s lifecycle from their own tool to make sure what they’re deploying is what the customer asked for. This shift in practitioner thinking from project to product is dramatically increasing engagement across the value stream, optimizing value delivery as a result. 

Now, with this end-to-end visibility and traceability of a product’s journey, organizations can be confident they’re quickly building and deploying the right software products to extract more business value from IT – increasing customer satisfaction, boosting revenues and enhancing business performance. 

flow enhancement ,integration architecture ,product delivery ,software delivery ,software development ,value chain ,value stream management

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}