devopsy.kinsta.cloud

Author: Lance Knight

  • Not Everything That is Necessary Adds Value

    Not Everything That is Necessary Adds Value

    Since the Lean production method for manufacturing arose in the 1930s, organizations everywhere have been seeking ways to apply it to reduce waste and increase productivity. This model has served thousands of companies well, from manufacturing and product design to software development. Yet, one difficulty that comes up when discussing or applying Lean in software development is the debate about what is and isn’t considered value-added work.

    Some people get defensive when certain activities are labeled non-value-add (NVA). Others argue that if a customer expects an activity and is willing to pay for it, it must be value-add (VA). From my perspective, software engineers, business leaders and others must accept the reality that it’s entirely possible for necessary processes to add no tangible value. We must understand the intent of Lean within these classifications. In doing so, we can get past the defensiveness and disagreements and move on to improvement.

    Let’s explore a few examples of NVA activities that are unavoidable—and therefore necessary—to a successful software development value stream:

    • Resolving important defects
    • Rework to meet client specifications (i.e. after clarifying requirements)
    • Project time tracking and billing (i.e. for time and materials projects)
    • Complying with regulatory mandates
    • Testing

    Some customers expect these activities to be performed. Software professionals generally agree that all of these NVA activities can be necessary. Yet many Lean proponents will continue to insist that they are NVA and should be minimized. So, where does that leave us?

    Distilling ‘Value’ to Its Essence

    Regardless of how important or necessary NVA activities might be, from a Lean perspective, unless an activity is adding value to the finished product, it is technically an NVA activity. Testing is an NVA activity. Defect correction is an NVA activity. Complying with regulations, although important to protecting profit margins for the company—and an activity that might incent customers to select your product over your competitor’s due to their reduced risk—is nevertheless a NVA activity.

    This is where we enter the grey area of “necessary but NVA activities that actually add a lot of value.” One prominent example is resolving defects that cannot be postponed. You’re probably shaking your head and thinking, “No way. Resolving defects increases quality which makes the finished software product more valuable to the end user. Therefore, it must be a value-add activity.”

    The answer is actually, “No, it is not.” Why? While the cost of defect resolution may be incorporated into the final price tag of software, there is no line-item charge for it. Most purchasers will not pay extra for defect resolution. They’ll feel that quality software is essential to their project and defect resolution should be included.

    Furthermore, they believe quality should be built-in— designed into the product and the process used to build it. That makes it an NVA activity. It’s necessary to the delivery of quality software but it doesn’t add value in the Lean sense of the term.

    The truth, whether or not business leaders want to acknowledge it, is that NVA activities are built into almost every product or service. When someone goes to pick up a prescription at the pharmacy they are never asked to pay an extra research fee. When someone test drives a car and decides to purchase it, they aren’t charged for the gas they burned during the test drive. Both of those activities were necessary for the final outcome to be satisfactory to everyone, but they added no value to the effort.

    The same is true for successful software delivery. Lean approaches form the foundation for modern software development, but being Lean doesn’t mean that you have eliminated all NVA activities. In fact, quite the contrary.

    Lean suggests that perfection is never achieved. A Lean organization values continuous improvement and is always looking for ways to reduce NVA activities. For all software projects, some elements will always be NVA. The perpetual existence of both value-add and non-value-add are facts of life.

    Optimizing Necessary Activities

    Despite the fact that these activities might be necessary and, therefore, part of the project cost, they don’t have to be excessive. Responsible software professionals and the companies for whom they work will make an extra effort to reduce waste and optimize outcomes in all NVA activities.

    Reducing or eliminating waste is one of the most important tenets of Lean software engineering. Waste can be found everywhere, from too many people working on a project and ineffective communication to an excessive number of manual processes, backlog mismanagement and rework.

    Breaking the Stigma of “Non-Value Add”

    Companies must develop quality software and sell it at a price that pays for the effort. In my experience, the way to do that is by evaluating every activity. Consider whether it is VA or NVA and whether it is essential or non-essential. Then reduce or eliminate the NVA as much as possible, even if it’s essential, and optimize the VA.

    Software professionals should be ready to defend the importance of the many necessary but NVA activities that go into a quality outcome, while remaining unapologetic about calling them what they are—a process, procedure or other activity that adds no value.

  • Building DevSecOps With Value Stream Management

    Building DevSecOps With Value Stream Management

    As teams develop software, testing for potential security risks and flaws is mission-critical, just as it has always been. Yet, cyberattackers continue to exploit code vulnerabilities as open source code remains the foundation for the majority of commercial applications across all industries. Security firms are churning out solutions at an aggressive rate, and both project managers and their teams hope they can purchase some bolt-on tool or license a service to take care of security, painlessly. In the end, vulnerabilities still occur.

    The most effective pathway to secure software code has always been to eliminate vulnerabilities. The question today is, “What is the best way to achieve that goal given such an accelerated, threat-laden landscape?” Before we dig into that answer, let’s take a closer look at the problem.

    Software Security Is Everyone’s Issue

    Even the largest organizations, from Adobe to Microsoft, have been humbled by the number and scope of code vulnerabilities that have been overlooked—and therefore escaped into public release—due to the frenzied pace of software updates. Here’s just one example:

    On May 11, 2021, Adobe issued a security update for Adobe InDesign that addressed multiple critical vulnerabilities. “Successful exploitation could lead to arbitrary code execution in the context of the current user,” the security bulletin read. “Arbitrary code execution in the context of the current user” is cybersecurity speak for “an attacker can execute arbitrary commands or code on a target machine or process.” Arbitrary code execution vulnerabilities are known to be one of the top attack vectors that lead to system penetration resulting in data breaches.

    Given the enormous effort companies and their software teams are exerting today, and the importance of avoiding software flaws in the current threat landscape, how is this happening? It doesn’t help to have publicly available lists of software vulnerabilities posted on the dark web and CVE (ironically, a database of vulnerabilities launched to help companies improve their cybersecurity). Hackers — from solopreneurs to nation-state teams — are having a field day with this information.

    Rearranging the Puzzle Pieces Doesn’t Guarantee Security

    In an attempt to resolve this challenge, industry professionals are coining new terms and calling for new approaches. One I have seen promoted recently is “SecDevOps” rather than “DevSecOps.” With SecDevOps, they assert, security is first—conducted at the start of the project and maintained all the way through.

    This approach isn’t new—it’s essentially a variant of shifting left, which for more than a decade has been an established mechanism in software testing for finding flaws and “failing faster.” In my experience, while failing earlier and faster with any software endeavor has considerable value, it is not automatically going to highlight all security challenges and enable their resolution.

    It is just as important for DevSecOps teams to collaborate and work together, not only to support development and operations, but also to ensure security, compliance and governance are built into every piece of code.

    Insight Is Preferable to Blind Interpretation

    Unfortunately, achieving that collaboration productively comes with challenges. DevSecOps teams need rich, real-time visibility into code vulnerabilities, early, so they can act on that information and update code as it moves through the pipeline. To do that, they need actionable insight—not a motley assortment of data that’s open to interpretation.

    In value stream management, we have seen firsthand while working with our clients that several techniques can be applied to eliminate vulnerabilities more quickly and effectively. All of these approaches hold value, whether a firm is seeking to deliver a new product to market or secure its current software pipeline.

    • Amplify feedback loops. Continuous feedback loops—from DevSecOps tools, for example—give developers more detailed insight into their code’s vulnerability.
    • Run security scans. Give testers the ability to run security scans on their code even before it is committed to identify security vulnerabilities as early as possible.
    • Leverage reporting and analytics. Gaining early access to as much insight as possible makes teams and management more confident regarding swift action to resolve code deficiencies.

    These approaches also support governance and compliance initiatives. As a bonus, they boost software quality, as well.

    The Business Case for Built-In Security, Governance and Compliance

    As mentioned earlier, these activities are integrally connected with the effort to eliminate code vulnerabilities. In case you are thinking, “This is obvious,” take a moment to reflect on this statistic: 60% of data breaches involved vulnerabilities for which a patch was available but not applied.

    The sheer scope of the problem also underscores the lack of attention to security and governance—and any compliance requirements that accompany it.

    Half of websites in production have high-risk vulnerabilities, and 82% of these are located in application code.

    The high percentage of errors in source code suggests it was not checked for vulnerabilities during development, signaling that developers focused on app functionality and gave short thrift to security. This often means they don’t have a program for governance and compliance, either.

    In my experience, a primary reason for these failures is that teams don’t have actionable information from the activities mentioned above, such as real-time feedback from DevSecOps tools. Developers need this insight when they are resolving sprint backlogs. Information relating to high-level security issues must be available so it can be addressed, with issues prioritized and resolved, and not left sitting in siloed DevSecOps tools.

    In many ways, DevSecOps is in the same stage of transformation as DevOps was a decade ago. Teams are frustrated by needs they do not know how to meet, and they hope for fast resolution in the form of tools and solutions. As with virtually every other software challenge over time, there is no replacement for getting in the trenches and fixing the problem rather than placing strategic band-aids.

    If you are not subject to compliance mandates and therefore dismiss the value of software governance, consider this: If your team misses a software vulnerability that results in a major data breach because you didn’t have the insight to identify it—or the governance to ensure it was addressed—your firm may not recover. The imperative for software security—and the governance that helps ensure it stays that way—should be sufficient for organizations to take vulnerabilities seriously.

    Effectively applying the insight gleaned from software code reporting and analytics is the surest way to eliminate vulnerabilities. As an added benefit, the reporting and analytics that informs the software effort can also make the case to upper management for the value of launching future improvement initiatives.

  • The Role of DevOps Feedback Loops in Your Value Stream

    The Role of DevOps Feedback Loops in Your Value Stream

    Feedback loops are found in all systems, organic or inorganic. They propel the recirculation of hot or cold air to raise or lower temperatures; they drive the idea exchange that helps businesses fine-tune operating strategies. Yet, nowhere are feedback loops more important but also misunderstood than in software delivery.

    Attaining the “holy grail” of software development—gaining maximum efficiency and maintaining velocity while reducing or eliminating wait times and waste—involves a variety of value stream activities that generate complex feedback loops. These loops are not sequential. They must operate in tandem and in sync with one another within a constrained environment or delivery flow will be disrupted. Understanding, mapping and optimizing this “ecosystem” is essential to ensuring all feedback loops are timed appropriately and no software activity is thrown off schedule.

    Misperceptions of Software Feedback Loops

    Much confusion arises among business leaders regarding the role of feedback loops in software delivery because they are also invaluable in other business activities. There, feedback loops operate in both open and closed systems. A system, whether open or closed, is a set of elements that take inputs through a phased transition to the emergence of an output.

    For example, assume a bank is developing a new depositor service, and although it announces the service will be available soon, it does not solicit specific feedback on how the service will work. Even if it receives random feedback from the public, it is coming from outside the controlled environment. That’s an open system. If the bank hosts customer focus groups and monitors the outcomes of specific variables without any opportunity for outside influences to impact the process, the activity is taking place in a closed system.

    The use of a closed system, whether in business or software development, embraces the principles of systems thinking—the shift in mindset away from linear to circular. With systems thinking, there are a half-dozen defined components, one of which is feedback loops. Understanding feedback loops is an essential part of value stream management to achieve the goal of delivering value to customers faster.

    Feedback loops can have a very positive or negative impact on software flow because awareness of and action on effective feedback impacts all parts of the system. But, before software leaders and teams can address their feedback loops, they must identify them in the value stream and understand the causality of each loop. As you identify feedback loops, patterns start to develop. These patterns can be direct or indirect, and feedback may need to be amplified or throttled, automated or removed altogether based on the loop’s causality.

    Optimizing the System

    Right now, feedback loops are likely disrupting software delivery flow and impeding velocity for millions of companies around the globe because software professionals, from project managers to software engineers, don’t understand them. Even though they recognize that software activities are taking place and that one activity may impact others, they don’t adequately consider the fact that information and material flow are interconnected, as are request flow, development flow and operations flow. They don’t perceive that software delivery is like a three-dimensional game of chess, with the pieces moving around the board multi-dimensionally.

    They also haven’t analyzed their feedback loops in detail so they can adjust based on reality, not perception or plan. Even if they have mapped the flow and the loops, most are unaware of the severe negative consequences even a seemingly minor issue can cause.

    Follow a Real Example

    Here’s an example that mirrors real-life scenarios I have witnessed time and again. Assume that for a new feature request, Epic 1 has entered Intake. The project gets into the Design phase and other work starts moving across the organization. Since everything is interconnected, the User Story ends up in Backlog waiting for the Epic to be completed. Two more User Stories are completed but the Epic has not moved, so they all sit in Backlog.

    Once the Epic clears Design, the User Stories start moving to the Plan phase and the Epic can go straight to Development. Soon, User Stories are In Progress and Material Flow kicks in. Somebody is working on a sprint, and someone else is working on those two pieces of code to make the change or implement a story. The DevOps pipeline is flowing, but not as efficiently as it could.

    Let’s assume instead that teams and managers now understand the feedback loops, and they have been automated to the greatest extent possible. User Stories are automatically moving from Backlog to In Progress once the Epic enters Development.

    When code goes from Build to Test, if a defect is discovered, automated feedback loops can connect to the right User Story and move the code back to In Progress. The developer fixes the defect and it goes right back to In Progress. The company meets its release window.

    In addition, once these elements are connected, and everyone understands these loops, management gains traceability across the value stream, which makes everyone, including customers, happy.

    Beyond the Basics

    The effort described here may sound like a lot of work to the uninitiated, but in practice, the effort more than pays for itself. That’s a great thing because it doesn’t stop here. In our example, as in virtually every software project, there is a lot of valuable human feedback beyond what I have mapped. It could be the information flow from a product manager through a product owner and on to someone tasked with the development portfolio. Or it might flow from testers to the product owner.

    Companies don’t have to map all this flow, but they should understand and address its potential impact. Furthermore, as project specifics, customer mindsets and other variables change, teams should adjust accordingly. That may mean creating, amplifying, throttling or automating feedback loops—or removing them altogether.

    Once organizations have attained a solid footing, they can explore more options. For example, tools, especially with integrations between and among them, can propel and automate the feedback loops, but they should be aligned, from a systems perspective, with the organization’s project workflow.

    Final Thoughts

    Streamlining flow through more efficient feedback loops is only a piece of the puzzle, but it opens up new opportunities such as more easily recognizing and removing waste. It enables organizations to release software faster, which is an imperative for digital transformation.

    Even if they don’t develop software in-house, firms that use enterprise software, from Salesforce to SAP S/4HANA, often have teams that modify it. Plus, customers and end users are all clamoring for a no-touch, self-serve digital experience. If a firm doesn’t provide, its competitors will.

    In mastering the science of delivering quality code at the right level of velocity, companies propel greater innovation, deliver ROI faster, ensure higher quality with lower costs and deliver products that better fit their intended audience and use. They also position themselves to be value stream leaders, and that pleases everyone from the board room to the sales floor.