Author: Nicole Bryan

  • The Human Touch: The Key to Optimizing Your Software Value Stream Network

    The Human Touch: The Key to Optimizing Your Software Value Stream Network

    Software has no intrinsic value until it’s working in production and supporting a customer’s business initiatives. With that in mind, it’s imperative that organizations focus on how they reduce the time to value, not just time to deploy. And that’s achieved through people.

    A common misconception is that technology underpins a software delivery value stream. This is only half true. Tools add immense value and help people to be more productive—whether through advanced functionality (such as the ability to visualize and manage workflow) or by automating repetitive activities (such as test cases and releasing code). All of this boosts throughput. But it’s actually the human touch that drives a product.

    It’s all about how practitioners work together to understand and address a discerning customer’s needs with software. To that end, organizations must ask themselves, “How do we optimize practitioner collaboration?”

    It’s All in the Artifacts

    Collaboration optimization lies in how organizations handle product-critical information—artifacts such as features, epics, stories and defects—that are created for the very purpose of sharing with collaborators.

    Therefore, the follow-up question that organizations should ask is, “What system do we have in place to ensure these artifacts are flowing in real-time, so the information is always up to date, ensuring that all work is always accurate and adding value?”

    Fortune 100 companies have already asked these questions, making a number of significant discoveries:

    1. The software value stream is actually a social network of collaborators who are connected by artifacts—hence, “value stream network.”
    2. This network consists of two different, but equally important, phases: “plan and design” and “build and deploy.”
    3. The network by default is not explicitly connected because the tools collaborators use do not naturally integrate with each other and automatically flow artifacts between them.
    4. This disconnect forces collaborators to waste precious time chasing up information via manual means such as email, status meetings, spreadsheets, tool-switching and duplicate entry.
    5. This manual communication is non-value work that costs organizations up to $10 million in productivity overhead (based on a typical 1,500-person IT department).
    6. Such archaic knowledge-sharing practices significantly compromises the fidelity of data as it goes from one practitioner to the next.
    7. The “plan and design” phase—the part of the software delivery process that determines what product/feature is to be built/fixed—is detached from the “build and deploy” phase.

    Through these discoveries, the last one in particular, organizations came to an important realization: They have no real way of knowing if they’re building the right product because there are six degrees of separation between the people who design the product, and those who build and deploy it.

    The result? Disgruntled customers and a big loss of competitive advantage. To address this, they’ve created a new infrastructure that provides a framework to connect and support both phases.

    By fusing the value of people and technology into a defined value stream network that is visible and traceable, they have a seamless flow of work that they can see, measure and control. They’re now in a position to identify where value is created and lost, enabling them to make informed business decisions to make better products.

    The Software Value Stream Network

    The enterprise software delivery process has long been misunderstood as a traditional manufacturing system that is linear and sequential—thanks in part to the industry’s failed adoption of the Waterfall model. The negative influence and impact of that experiment still lingers today.

    The process is linear in the sense that there are two clear bookends: A product/feature/fix is requested (A) and then that product/feature/fix is made (B). There are also established phases across the production line: conception, initiation, analysis, design, construction, testing, deployment and maintenance. But that’s where any real similarities end.

    In reality, the process is more of a latent network of critical interactions between collaborators. These bilateral working relationships exist at key stages of the software delivery process, such as developer and tester, developer and operations, etc.

    When you actually lift up the floorboards of the process and peak inside, it looks more like a social network connected by the flow of artifacts, which looks something like this:

    Most of these relationships have developed over time as organizations have introduced a higher degree of specialty in key stages across the value stream. This evolution has been vital in helping organizations to:

    •   More deeply understand customer requests/issues
    •   Clearly articulate the requirements/defects
    •   Enhance product management/optimization
    •   Acutely break down requirements into epics and stories
    •   Write more accurate code faster
    •   Automate and accelerate higher levels of testing
    •   Continuously deploy
    •   Introduce tighter feedback loops
    •   Continuously improve and innovate

    While all these new roles, disciplines, purpose-built tools, processes and methodologies have helped different practitioners to perform better, it’s also introduced huge technical complexities. How do you flow those all-important artifacts if the tools are disconnected by design, and when collaborators are working in silos, trapped in “administrivia” hell? It’s tantamount to having a sports car with no gas and a confused driver. Or an airplane flight network with no air traffic control. It’s a banana republic.

    Building the Right Product via Value Stream Integration

    Agile and DevOps illustrate just how vital integration and automation is to this flow of work. Agile brought in prioritization, feedback loops and sprints to build the most important features as fast and accurately as possible.

    DevOps, meanwhile, has accelerated speed of deployment. In that sense, the build and deploy phase is optimized. Automation has work flowing seamlessly between Dev and Ops teams, and eliminated/mitigated cross-team issues, such as miscommunication regarding what products need to be deployed, and when.

    But what’s the point of faster delivery if it’s not what the customer wants?

    We need to consider how wrong features are developed. If you turn to look upstream, you realize that the teams planning and designing products are affected by the same misalignment that used to plague DevOps teams.

    The disconnections between collaborators and their tools in the creative software design process mean that often what’s implemented isn’t right or is delivered too late. In either case, it doesn’t add value.

    But that can be radically changed through sophisticated toolchain automation, which shares artifact data across tools and automates the hand-offs between owners in the “plan and design” stage.

    From the sales to product to PMO to business analysts, by bringing these customer-centric, product-focused teams together, you dramatically improve the product articulation process and the speed at which its performed.

    You build features closer to the customer’s needs. You contain that precious value. And then through automation you can flow that value downstream to developers to create that value. It is as big a revelation as DevOps.

    How is this all done? Enter value stream integration. This process is much more than just connecting two tools, say Jira and HPE QC. It’s about connecting all tools, practitioners, disciplines and processes to define and create a free-flowing network that is automated and scalable. Think of it as the plumbing in a house. If even one pipe isn’t connected, there’s no flow of work (value).

    Value stream integration connects the pipes to:

    •   Automate Information Flow Across Value Stream: It enables the frictionless flow of artifacts, as well as information from events across the value stream. This removes non-value-added work and bottlenecks; increases velocity and capacity; enables automated traceability; and dramatically improves employee satisfaction.
    •   Enable Value Stream Visibility: When managers want to see metrics and dashboards to understand project status, to optimize the process or to ensure compliance, it has been nearly impossible to get a real-time, holistic view across non-integrated tools. Value stream integration unlocks lifecycle data from these application tool silos by automatically compiling lifecycle activity data into a single database. This data can be used to create consolidated, full-lifecycle reports and dashboards, as well as for traceability reporting.
    •   Create a Modular, Agile Toolchain: Value stream integration enables organizations to use the products that best support each discipline while getting the benefits of a single, integrated toolchain. This drives more value from each tool and allows organizations to easily add, replace and upgrade them, creating a proactive environment for innovation. It creates that value stream network.

    Finally … Manageability

    With this network, organizations can finally see, manage and optimize one of the most important processes in their business: the engine that drives their prosperity in a digital-centric world. You cannot underestimate how important it is to have this network, this complete system. This is the state where innovation thrives, and where continuous improvement can be executed. And, of course, where you gain the essential visibility to be confident you’re always building the right product.

    — Nicole Bryan

  • The Role JIRA Plays in Complex Value Stream Networks

    The Role JIRA Plays in Complex Value Stream Networks

    No one denies that JIRA has taken over the developer space. The verdict is nearly universal: Most developers want to use JIRA only.  That’s fine, but without understanding the role it plays within the context of your entire value stream network, your organization has likely not crafted the most efficient value stream.

    JIRA plays a critical role within any complex value stream—and using JIRA to its fullest along with the other critical aspects of your value stream is the key to delivering software faster and achieving the software results you sought.

    But developers encompass only one role that is required to build complex software. And, as fabulous as JIRA is for developers, it is often not the tool of choice for the many other roles involved in building software, i.e., product managers, product analysts and test engineers. Even salespeople are part of your value stream.

    Fundamentally, we need to recognize and understand that delivering software requires careful orchestration between a large network of people with different roles who have the need for different tools. But we need the overarching value stream of information passing within that network to work together seamlessly. The information flowing through the network needs to be connected and traceable in an automated way. This really boils down to identifying the “centers of criticality” with the associated artifacts and architecting your value stream network accordingly.

    JIRA, Centers of Criticality and the Value Stream

    What are “centers of criticality” in software delivery value streams? They are the artifacts and associated tools that represent the primary connectors of business value to the manifestation of that business value. To be more specific, when the business asks for some new functionality, it is represented as one or more artifacts, typically either requirements, features or epics (sometimes all three). Those artifacts act as the “glue” for all of the other key information from which to “hang off.” You want the tests that run, the change sets and code reviews, the defects, the builds … all of that information should be tied to the requirements/features/epics. And those “glue” artifacts also need to be tied to the originating business initiative or program.  Thus, tools that operate on those types of artifacts really are your “centers of criticality.”

    And that is where JIRA comes into play quite significantly. It acts as the touchpoint—the center of criticality—between what the developer should build, tied to the actual artifacts that constitute the end working software, as well as tied to the originating business needs.

    Consider the familiar example of when a salesperson hears from customers that they really want a new feature. As a result, she wants to tie this net new ask to the opportunity—and be able to track via Salesforce whether the customers are going to get that new feature request anytime soon.

    And here’s a good value stream for it: The request is entered into Salesforce and naturally tied to the customer account. That request should flow to the product management tool in use, which in some cases might be JIRA, but often, especially at large organizations, is a more purpose-built product management, portfolio management or requirements management tool. At that point, the request that originated in Salesforce is reviewed and determined to be three different features. Once the company decides it wants to build them, those features then flow into JIRA as epics. From the epic in JIRA, the development team begins to create the stories and tasks necessary to build the feature, then connects the change sets and tests and defects to those stories and tasks.

    As a result, without any manual effort, the team has created a dynamic network of artifacts that provide full traceability from the very beginning of a customer requesting something through to its final delivery seamlessly. JIRA plays that critical touchpoint role of “what” should be built to the actual bits and bytes of the resulting software.

    Now consider a different example. You’ve released the next version of your application and all is going smoothly. Support uses ServiceNow, or one of the many IT service management (ITSM) tools that exist. Your support team is the originator of much of the follow-on work that happens regarding applications. Tickets originate with ITSM tools—but they, too, need to be connected to the resulting defect that requires attention. So, you need a seamless flow of tickets and incidents from the ITSM tool to the resulting defects that must reside in JIRA. And those defects need to be associated to the stories and epics that were affected. They also reside in JIRA.

    Both examples exemplify the importance of “centers of criticality,” with JIRA being one of those centers of criticality. In a complex value stream network, JIRA plays that crucial role of being the touchpoint between bits and bytes and business value.  But, without flowing information to and from JIRA from the other tools in the value stream, you are left with a broken value stream without real, accurate, automated knowledge of what and why you are building something. Because knowing if you’ve delivered business value comes from understanding the provenance of what you are building. It might be how many customers (internal or external) had asked for the 20 features that were delivered last release. Or how many customers were not going to renew your software if those features weren’t there. Or even how many new opportunities you can follow up on to say that what they’ve asked for is now in your product.

    Conclusion

    Building complex software that truly meets business needs necessitates that there will be an equally complex underlying value stream network that will only be efficient and effective if it is architected from the ground up with careful consideration of the critical artifacts and tools that need to be connected. JIRA is very clearly one of those tools. So, embrace JIRA being the heartbeat for developers—and know that by crafting your end-to-end value stream network with JIRA as one of the “centers of criticality” you can have an efficient, fully connected and fully traceable value stream. Happy connecting!

    — Nicole Bryan