Tag: value stream management

  • Value Stream Management Consortium Makes Debut

    Value Stream Management Consortium Makes Debut

    A consortium dedicated to advancing the adoption of value stream management best practices is being launched today with backing from Digital.ai, HCL Software, Plutora, ServiceNow and Tasktop.

    The Value Stream Management Consortium (VSMC) will create an open community around which organizations that are seeking to expand DevOps workflows and processes across functions and organizations can more easily collaborate.

    VSMC chair Helen Beal said that while value stream management has been around as a concept for years, the number of organizations that have fully embraced the concept remains relatively small. The VSMC is dedicated to enabling organizations to orchestrate software development processes more flexibly, she said.

    VSMC Chair Helen Beal

    That goal has proven elusive, because it requires a level of collaboration between release managers, DevOps managers and product managers as well as IT and business leaders. Value stream management provides a framework for enabling organizations to embrace value stream management concepts as they become more adept at employing DevOps workflows to manage multiple application development initiatives simultaneously.

    Initially, Beal said, the VSMC will function as a central hub of information and education pertaining to value stream management. Ongoing research will track how organizations measure value. Eventually, the VSMC will provide certified training, Beal added.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, an appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business is growing steadily as organizations realize how dependent on software they have become.

    As organizations come to terms with this new reality, many also realize there is a much greater need to align software development with their core business processes. Value stream management platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics and then define the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to the massive amounts of DevOps data they collect.

    Business leaders are especially anxious to understand how any software development project delay might impact future revenue projections. Rather than being a set of tools employed mainly by IT leaders to track software development projects, value stream management platforms make it possible for other stakeholders to track KPIs spanning multiple software development projects. It then becomes easier to make informed decisions about how to reassign resources across various projects as different bottlenecks are encountered.

    It may be a while before organizations achieve that level of DevOps sophistication, but as software continues to eat the world it’s only a matter of time before value stream management becomes the table stakes organizations will need to survive and, hopefully, thrive.

  • Plutora’s Bob Davis: Work From Home and Value Stream Management

    Plutora’s Bob Davis: Work From Home and Value Stream Management

    American writer Orison Swett Marden said, “Success is not measured by what you accomplish but by the opposition you have encountered and the courage with which you have maintained the struggle against overwhelming odds.” After the year that’s passed, with operations and development teams forced to scatter and work remotely, it’s a sentiment DevOps teams are currently all too familiar with.

    This demand to keep DevOps teams productive under the extraordinary circumstance of 2020 has placed an increased emphasis on effective management, including on value stream management tools, so leaders and team members can have greater visibility into delivery pipelines.

    To get a sense of the state of the value stream management market, I reached out to Bob Davis, chief marketing officer at value stream management platform provider Plutora. Below is an edited version of our conversation.

    George Hulme: Thanks for taking the time today, Bob. Could you tell us a little about Plutora?

    Bob Davis: We are a value stream management platform provider. When I first arrived here, we recognized that sales, marketing, financial and human resources teams all have their systems of record. They have Salesforce, ERP (enterprise resource management) systems, and various financial and HR platforms that enable people to practice their profession more easily. IT didn’t have anything like that at the time.

    We set out to provide that capability for the software development side of IT. Today, the market is caught up. Everybody is moving into value stream management as a platform to provide that visibility across an entire toolchain, from the idea to production. That’s where we play. We’ve been in this space since it began over two years ago. The market is just exploding with the work-from-home trend, and how the pandemic kicked digital transformation into high gear.

    Hulme: It appears that a significant percentage of the work-from-home trend is here to stay. I’m seeing surveys showing about 19% of people previously suspected that they’d be working from home in a year. That figure jumped now to near 50%.

    Davis: If you start to parse what work from home means, you’ll find it means many different things to different organizations. Some have a hybrid model with people working from home two to three days a week. I recently read a Gartner survey that said 74% of organizations were going to have some element of work from home. It’s not all or nothing.

    Some companies have decided that they are not going back to work until well into this year. All of these companies have to make sure they have governance compliance in place for this new workforce, and that they can successfully manage the complexities of software development. These challenges are at least an order of magnitude, if not more so, more difficult than typical office workers working from home.

    Hulme: Is one of the reasons behind those challenges struggling to maintain being on the same page across the organization?

    Davis: That’s a great point, George, because when we go out with our teams at many organizations, a lot of the effort helps people fast-track their processes. We are asked, “What is the best practice for automating builds? How often should I be automating builds? What KPIs do I establish to make sure that people are striving to accomplish what we need them to accomplish?”

    For example, one of the things that Lean and Agile methodologies promote are smaller work items, quicker check-ins, faster processes. They encourage cutting work down into smaller bundles to be done more quickly so that teams can iterate much more rapidly. We’ve seen that managers will often create a KPI for a performance management program to measure how often code gets checked.

    That’s horrible because now I can just check in code all the time. Yet, are people making actual progress? Are they actually delivering software, or are they just checking in small iterations of code all day?

    Organizations have to be very careful with how they manage people. They have to be cautious with what metrics they set up to keep their eye on delivering value and delivering software more quickly. This is something organizations struggle with. They want to know where to start and what metrics they need to implement. And how to make those metrics visible so people can see and understand them. That’s what provides the ability for product owners, managers, executives and other stakeholders to view the progress and status of what’s going on without disrupting people with calls and endless meetings.

    Hulme: That has to be tremendously more challenging with the work-from-home trend than years prior.

    Davis: I recently heard a great quote: “As people end up working from home, the need for human contact and human interaction, socialization, is peaking.” People are hungry for that. At the same time, the need for managers to not be in the face of the employees has never been higher. That is, the motivation and the productive nature of employees is proportional to how well they feel trusted. And it’s proportional to how well they understand where they’re headed and understand how to do their job and are left alone to do that job.

    It’s a leap of faith to leave people alone and simply trust them. You need systems that provide you the ability to collaborate; watch the progress. You need systems that will help you understand where people might be struggling, all without having to dig in and micromanage your people. Indeed, as we are learning, managers can effectively do this with Zoom, or Slack, or some other tool that provides good communication flow within a work-from-home environment. But in software, the handoffs and dependencies are so complicated that those tools are simply not enough. You need a collaboration tool that provides effective management in software development.

    Hulme: Do you believe remote development teams can communicate as collaboratively as they did in person, with modern software collaboration tools?

    Davis: Yes, I think they can. Especially when office collaboration tools, such as Zoom and Slack, and software collaboration tools work together. We can leverage Slack to communicate tasks. So we not only layer on top of the individual tools people have and integrate with them, the practitioners working within those tools can make it available to all of those stakeholders involved in that process. And when there are tasks or handoffs, the system can be configured to notify them how they prefer to work: email, Slack, instant messenger, task list on the dashboard. There’s a lot of different ways, depending on how people want to work.

    Not only that, but it can automatically alert people to what is happening and what’s needed. Fascinatingly, one of the interesting yet deceptively tricky questions to get an answer to is, “Where’s the status of a feature?” If a team is in the process of building something out, and they have a specific feature, such as check cashing in a banking app, it should be a pretty straightforward question to get answered.

    Yet, about seven or eight different teams are working on various aspects of that application. For instance, there’s a product owner who, without the right collaboration system, has to go and essentially track all of those teams down and find out where their status is.

    With a software collaboration system, you can make that query without bugging anybody. In some respects, you can collaborate more efficiently and more productively than you can when you’re all sitting in the same room. That’s because before, we would have walked over and interrupted somebody. Now you’re just looking at a dashboard, or you’ve gotten an alert on Slack, and you see what you need. Boom.

    Hulme: How important do you think it is to have useful data and that value stream knowing where things stand to keeping the system flowing and individuals knowing where they fit on deliverables?

    Davis: I think the ambiguity, unexplained delays and unforced errors are among the things that upset human beings the most. Just ask somebody that’s standing in a line that’s not moving, and it hasn’t moved in a while; how restless the crowd gets. The nature of software development is such that there are tremendous numbers of handoffs, no matter how you do your development.  It doesn’t, whether it’s an old fashioned waterfall or the most advanced development and deployment models in operations at places like Spotify — you have a lot of handoffs. And if you can’t see what you’re doing because you don’t have visibility into those parts, then you’re going to run into an incredibly frustrated team. And you are going to see a lot of finger-pointing when the question comes up, “Why didn’t this release go out?” And then there’ll be five or six different groups pointing to different reasons. You get a lot of anger, a lot of discontent.  And it’s something you have to avoid if you are going to succeed.

  • Copado Adds Value Stream Management to Salesforce DevOps Platform

    Copado Adds Value Stream Management to Salesforce DevOps Platform

    Copado, a provider of a DevOps platform for building applications that extend software-as-a-service (SaaS) applications from Salesforce, this week announced it has added value stream management capabilities.

    Andrew Leigh, chief marketing officer for Copado, said providing a platform that accelerates the development and deployment of application code is no longer sufficient. The winter 2021 release of the Copado DevOps 360 platform now includes value stream management capabilities that enable organizations to better prioritize DevOps projects, he said.

    In response to the COVID-19 pandemic more organizations than ever are now relying more on SaaS applications that can be accessed easily by employees working from home. IT organizations are also now using platforms such as Salesforce to jumpstart digital business transformation initiatives. Rather than write develop entire applications from the ground up, many organizations are employing low-code tools from Salesforce and others to extend, for example, customer relationship management (CRM) platforms.

    Leigh said most of the activity revolves around professional developers who are increasingly applying best DevOps practices to build those applications. Copado has certified more than 25,000 developers on its platform, he said.

    Given the current state of the economy, Leigh said interest in DevOps platforms is rising among organizations building Salesforce applications because they want to ensure a return on investment (ROI). Organizations that are investing six figures to build these applications are especially interested in value stream management tools that help make sure these projects are delivered on time.

    The value stream management capabilities added by Copado include support for the Scaled Agile Framework (SAFe) for building complex applications more efficiently. It also provides the ability to synchronize stories from Jira and Agile Planning boards.

    The latest version of the Copado DevOps 360 platform also adds a suite of declarative pipeline builders that allow non-technical teams to define and manage value pipelines without a single line of code. That capability is intended to simplify version control and automation flows to enable developers and administrators who manage Salesforce instances to better align their efforts.

    Copado added deeper integrations to third-party testing tools that incorporate artificial intelligence (AI) and updated its static code analysis and compliance tools.

    Salesforce is clearly not the only SaaS application platform that organizations are looking to extend, but it is among the fastest-growing. For its most recent third quarter, the company posted revenues of $5.42 billion, an increase of 20% year over year. The company is now lifting its future guidance to slightly exceed pre-pandemic levels. Salesforce is projecting fiscal 2021 revenue at the end of its fourth quarter will total $21.11 billion. Revenue guidance for fiscal 2022 has been raised to $25.5 billion. Salesforce earlier this week also announced its intention to acquire Slack, a provider of a messaging platform that is used widely by DevOps teams.

    Leigh said a dedicated DevOps platform for Salesforce applications is necessary because Salesforce applications are constructed using a set of objects and tables unique to the platform versus traditional application code. Regardless of the reason for requiring a dedicated DevOps platform, interest in building and deploying custom applications on top of the Salesforce platform has increased sharply since the start of the pandemic.

  • Value Stream Management: Treat Your Pipeline as Your Most Important Product

    Value Stream Management: Treat Your Pipeline as Your Most Important Product

    When it comes to accelerating customer value, it’s dangerous to focus only on the development and delivery of a digital product. For many enterprises, most time is invested before a single line of code has been written. That explains the recent focus on value stream management (VSM)—it’s forcing us to think beyond Agile and DevOps and consider the whole system, not just one stage in a complex process.

    By extending our visibility further upstream where work originates, we can begin measuring the value of creating and protect workflows end-to-end to meet business outcomes sooner. Thinking about how software delivery work moves between all teams in the value stream from request to operation leads us to the significant realization that our tooling pipeline is our most important product and we should treat it as such.

    The Rise of Value Stream Management

    The growth of value stream management in software delivery has emerged because Agile and DevOps are not enough to remain competitive against the breakneck speeds of the tech oligopoly. The progressively maturing practice takes a systematic approach to continuously measuring and improving end-to-end flow to accelerate time-to-value. Consequently, new tooling is emerging as we think end-to-end in how we collaborate and work faster together—and measure our productivity and effectiveness.

    Measuring and understanding end-to-end flow isn’t easy. Software delivery is highly technical and creative knowledge work that can span thousands (or tens of thousands) of IT practitioners. Information is scattered across heterogenous toolchains comprising discipline-specific tools. In fact, some 42% of large-scale software delivery organizations use four to 10 core collaboration tools for portfolio management, design, enterprise agile planning, testing and ITSM, and dozens of additional tools to support the CI/CD pipeline and operations. 

    Mik Kersten, “Mining the Ground Truth of Enterprise Toolchains, IEEE (Volume 35, Issue 3, May/June 2018, p12-17

    Measuring flow, therefore, involves tracing constituent units of value creation and protection as they traverse all team tooling in the form of artifacts such as activities, capabilities, epics, features, stories, bugs and incidents. Yet for too long we’ve been too focused on “the right side” of the value stream, thinking about how products are built and delivered through Agile and DevOps tools, without visibility on how they’re requested, analyzed, processed and designed. Our ability to support customers is hindered because we don’t know where and why work is slowing down outside of development. Our product pipeline is broken, our visibility fractured.

    A ‘Broken’ Product Pipeline

    Traditionally, CI/CD tools include source code management, build, deploy, quality management and service management. Moving more to the right, you have release management and service management. But too often organizations have ignored integrating tools further to the left such as planning and portfolio management, product management, requirements management and risk management (static and dynamic security scanning tools). This impacts our ability to see and measure end-to-end flow.

    In”Accelerate,” lead time is defined as the portion of the value stream from (last) code commit until deployment. While this is essential to improve, it only covers the time from the build being produced through deployment. We need to account for the time that elapses before it hits a developer’s backlog. To shift IT from a project to a product focus, you need to reduce end-to-end flow time by measuring earlier in the delivery life cycle by “shifting left.” As such, you need tooling across the whole value stream through the ideate, create, release and operate phases. A focus only on optimizing the CI/CD tooling and practices is too narrow a view that produces diminishing returns over time.

    The Great Disconnect Between IT and the Business

    Because of this lack of a holistic view, IT teams don’t feel like they are able to influence the business side of the house, where most of the work in progress (WIP) starts, such as requests for features or application changes. These intake processes many times result in teams taking on too much WIP and neglecting work. Many teams need to “stop starting” and to “start finishing” to deliver business value more quickly. Crucially, this is the area where business leaders have their own processes and where tools are less likely to be used; it’s a world dominated by spreadsheets, documents and PowerPoint presentations. This is where work is least visible and measurable. And this is precisely where we need VSM: to turn the light on starting with the customer needs so we can continuously improve end-to-end flow. This requires a culture shift from both IT and business/product owners. And that requires taking a broader, more holistic view of the tools and practices in the business space.

    Architecting for Flow

    An end-to-end integrated pipeline product can be architected for flow. For example, tools used for visual system management (e.g. Jira, Azure DevOps) are becoming more of a commodity with the real differentiation becoming how they can be integrated with tools used for portfolio, defect and service management, since those are the sources of work that will flow into product-based teams for development of business value and unplanned work. Teams should think about how they can work more closely with business portfolio teams on continuous flow (and funding) because eventually this work will become the next bottleneck that needs to be addressed on the journey to accelerate business delivery capability.

    Keep an Eye on Value Protection Work 

    With end-to-end visibility into work across the pipeline, you can abstract that connected technical data into overarching value stream metrics—known as flow metrics—to identify areas where to run experiments to improve end-to-end flow. Here we mustn’t just focus on work that creates value but protects it, too.

    We should provide our software delivery teams with the psychological safety to devote time to address debt and neglected work. Debt creates a drag on feature velocity because changes become more complex and take longer to make. In addition, with higher technical debt, more time is spent on addressing defects, which starves the capacity to perform feature work. As debt builds, the following is observed:

    • Flow velocity decreases.
    • Flow time increases.
    • Quality decreases as the code base becomes more fragile/costs increase.

    All of these result in reduced happiness for both the customer and the team, increasing the risk of team burnout. There are many cautionary tales of this occurring where market leaders ended up losing considerable market share due to inattention to technical debt. These stories exemplify why it is necessary to observe flow distribution to ensure that prioritization decisions made with the product owners, include providing necessary capacity to address technical debt.

    Applying the concepts of value stream architecture to your end-to-end pipeline is the key differentiator for organizations that are trying to make it through disruptive periods such as today, as COVID-19 widens the gap between those who have mastered software at scale and are thriving and the many enterprises struggling to pivot and adapt in the digital-first climate.

  • 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.

  • Don’t Tool Up a Broken Value Stream

    Don’t Tool Up a Broken Value Stream

    A well-known failure mode for business process automation is to automate a broken process. The same goes for tooling up value stream management (VSM). If you have an overly complex value stream – immobilized with dependencies, a clumsy way to move work from ideation to engineering or disagreements over who has power over the plan – then trying to tool up your value stream to make it visible is a waste of time and money.

    First, form engineering teams capable of delivering business value, and form program or product owner teams to feed backlog to those engineering teams. You may need a portfolio or strategy team to set prioritization across all of the programs. If you must matrix manage your teams, ensure that the business (not engineering) is the strong side of the matrix.

    Such an engineering team should be able to take a chunk of business value, a small epic, and develop, test and deliver it with very few, if any, dependencies on other teams. How you define business value in this case should be very close to how the customer would define value. It’s okay to have some component teams or service teams provide value to multiple other teams, but organize to have few of those because dependencies kill agile.

    Done well, your portfolio team can have a kanban of epics in which the status of those epics is clear, instead of complicated. This is because there are few teams involved in building those epics. The portfolio team will be able to see epics move frequently. They should all slide over a column every month or three. You don’t need a sophisticated VSM console because it’s so simple. Whatever tool they have their epics in will most likely have a cumulative flow diagram (CFD) and info on lead time, flow time and cycle time for the epics. That’s the level at which they need to manage, and all the info they need is (more often) able to be in a single tool.

    It’s the same all the way down, at the program and delivery team level as well. When features map to sprint goals and when velocity is stable and dependencies are few, each engineering team can understand their own process. They can manage their own value stream with whatever simple tool they happen to be using at that level. 

    To achieve higher levels of velocity, agility and predictability, companies need to connect people, process and tools effectively. Integration has its place, even in messed up situations. It can be a useful tactic to help deal with a complex and hard to understand value stream, but integration and VSM platforms will not automatically fix your situation. That’s because VSM is human.

  • Practical Advice on How to Use Lead Time

    Practical Advice on How to Use Lead Time

    Many ALM tools and Value Stream Management platforms graph lead time, but few really tell you what to do about it, how to use it and why you shouldn’t use the average. In fact, so much of what is written on this subject is rather vague and hand wavy. Part of the reason is that Value Stream Management is a big job, and it isn’t something a tool can provide. Rather, it’s a human endeavor. Another driver for the hand waving may be that the writers really don’t know much about lead time because they’ve never actually used it.

    Improving the value stream is a big topic but there are definitely things we can cover in this space: how to use lead time, how to get it, prerequisites to using it well, techniques or approaches and references for further study. I’ll start with the simplest, most mechanical topic, and move to the harder topics last.

    What Is Lead Time?

    Lead time is how long it takes a work item to get through a system, such as your IT development value stream. If your system is under control, recently measured lead times can be a good predictor for lead time in the future. People want to know when stuff will be done so they can make plans.

    Lead time is also a lagging indicator for many of the actions used to improve, well, lead time and flow. It’s what some people call an output metric—you make a bunch of improvements to the system and improved lead time is what you get out of your efforts. 

    Where to Start

    Measure lead time separately for the few types of work where it really matters, such as production defects and epics or initiatives. For every work item, record the start and end dates. But first you have to define what you consider the start and end. If you are using the measure to communicate with a customer, use dates from the customer’s perspective. If you are trying to improve the development part of the pipeline, post planning, then start the clock when it’s scheduled for dev. In that way, some people distinguish flow time from lead time. Cycle time is sometimes used for an even smaller slice of the value stream, usually just one step—I’m not going to debate here whether that’s a proper or official use of that term.

    Whatever you do, for heaven’s sake, don’t use the average lead time. Instead, use a percentile. I use the 80th percentile. For illustration, the 25th percentile is the point at which 25% of the observations fall below that point. The 80th percentile of your lead time observations (measures) is the point at which 80% of your historical lead time observations fall below that point. The 50th percentile is not always the median, but for the sake of this article we can say it’s close.

    Average, however, could be materially off. It’s worse to use the average than the median because the average can be thrown off by outliers more than the median and 80th percentile. If you are good enough with statistics to correctly identify and remove outliers, that’s great, but few people do that at all (much less with statistical precision) and it’s really not necessary for most IT work.

    The only thing I’d use the median for is to monitor the trend—to see if the median is improving. But using it for forecasting or expectation setting would be bad. You see, when using median, 50% of observations took less time, but 50% took longer. You wouldn’t want to tell a customer that he has a 50/50 chance of getting a fix in two weeks. Telling them they have an 80% probability of getting a fix in three weeks, in my experience, is more palatable.

    You want to be able to tell your customers (or marketing, management, support or program management) that 80% of the time you resolve this kind of issue in “n” weeks. Most people are happy with those odds. Anything higher takes in so much of the long tail of the distribution that it makes forecasts not terribly useful for planning.

    How to Get the Graph

    Use the lead time graph in your existing tooling if you can; get the data into a data warehouse and use a BI tool if you must; or use Excel only as a proof of concept or if your organization is small. More on this below. Compute your 80th percentile lead time expectation every sprint or month, and graph it in a bar chart so you have a new bar every period.

    How to Get the Data

    It’s easy to find the 80th percentile in your dataset. If your tooling can give you your choice of percentiles for lead time, that’s fantastic. If not, you’ll need to gather all of your lead time observations. You can do it in Excel, but then you’ll be forever updating Excel with fresh data or re-importing the data. That’s workable if you have a small number of teams and observations to input each sprint. Otherwise, you’ll want to get it into a database and make a BI dashboard. 

    How Much Data to Get

    You don’t need a whole lot of data.

    “Data beyond 24 weeks is most likely out of date,” said agile data and probabilistic forecasting guru, Troy Magennis. 

    How to Compute It

    In Excel, use the percentile.inc function. Generally, order your lead time data from smallest to largest, multiply your number of observations by 0.8, round up to an integer, then identify the observation at that location. Technically, you should average the two observations at that point if you didn’t have to round, but I’ve not found that materially significant in any of my data for these purposes so I don’t do it.

    What to Do with It

    I publish my 80% lead time expectation. I talk about it with the people who are anxiously waiting for the delivery. I talk about it with my engineering team. I talk about it with my management team, PMO, project managers and program managers. I talk about it with my lean and agile coaches and consultants and scrum masters. I talk about it with my team leads. I want everyone in the loop and on board with the improvement goal. I use it to explain how certain behavior, such as expedites and high work-in-progress (WIP), work against improving the lead time expectation.

    Look at your bar chart showing the changes in your lead time expectation over time. See if it’s moving in the right direction. Use A3s, Toyota Kata, lean principles and systems thinking to improve the system. Engage your upstream and downstream neighbors in the improvement process and in making process policies explicit.

    What if the Data Isn’t in One Tool?

    Change your process before you change your tooling, and don’t tool up a bad process. A common problem is when an organization doesn’t have the beginning and ending lifecycle states of a given class of work in a single tool. I didn’t say value stream here because you don’t need the whole value stream mapped for every class of work in order to get lead time. You can combine data from multiple tools in order to get the end-to-end, but the simplest thing that could possibly work is to have your top-level item reflect or approximate that end-to-end flow.

    Before deciding you need a new tool, there are a couple of easier approaches to try first:

    • Add the starting or ending date to the items of interest, whichever of those is missing. Sometimes I see those planning an initiative only track the item until it’s approved and released to engineering. It may be easier to add another date to that item and track it to delivery to production than to change tooling.
    • Add more steps to an existing kanban. Likewise, it may be easier to add additional columns to a kanban and keep the items on the board until they are in production. Or get them on the board earlier in their lifecycle.
    • Add another kanban. It may be that you don’t have a kanban. Your initiatives or your production requests aren’t tracked well. Get them in a kanban. This is not the same as changing tooling. You probably already have a tool that can give you a kanban. Use it. Every organization should have an epic kanban.

    Prerequisites

    You can use lead time as a lagging indicator of your process improvement efforts without any of these prerequisites. However, if you are using lead time to set completion date expectations, you should attend to these matters first: stable teams, predictable teams (stable throughput), a stable system (few process changes) and low WIP.

    If you are trying to make predictions, being predictable is helpful. A leading indicator for predictability is velocity variance or throughput variance. I compute that as the standard deviation divided by the average, and I want that to be 0.2 or lower. That 0.2 is the point at which the numbers are more reliable, in my experience with many organizations’ data.

    You need to have stable teams. Your organization will not be predictable if your team makeup is changing all the time, or if you are moving people around between projects or if you are allocating people to multiple projects.

    You need to control your WIP at every level. Put all of these on your metrics dashboard:

    • The number of items being worked on per individual. This should be one per individual, or less. It’s usually easier to gather this data at a team level. At a team level, the number of items being worked on should be less than the number of individuals. Encourage working together. If you are pair-programming most of the time, your WIP should be less than the number of pairs. With TDD, good test coverage and good continuous integration practices, you should be able to get multiple pairs on one user story.
    • The number of epics or initiatives each team is working on. This should be on your metrics dashboard, and list teams with more than one epic in progress. But remember, it’s not the team’s fault. Fix the system. Don’t blame the team.
    • The number of open sprints. This should be 1 per team. On your dashboard, list the teams with more than 1 open sprint.
    • The number or epics or initiatives the organization is working on. Graph this measure each sprint on a bar chart so you can see the trend. Work to improve (lower) the trend.
    • The number of releases being maintained (fixed, patched, level 3 support). Graph the trend and work to lower it.
    • The number of releases being supported (help desk, service desk, level 1 and 2 support). Graph the trend and work to lower it. 

    Conclusion

    Lead time, if tracked and used correctly, is a great predictor for how quickly work will be completed, allowing you to more accurately forecast delivery dates. You should measure it, talk about it and review it often to see what improvements have been made, and can be made. And remember:

    • Measure lead time separately for the few types of work where it really matters.
    • Use percentiles rather than averages for more accurate forecasting and expectation setting. 
    • Adjust your process before you change your tools.

    — Andrew Fuqua

  • Tasktop Delivers Viz Value Stream Management App

    Tasktop Delivers Viz Value Stream Management App

    Tasktop this week announced the general availability of an application to manage projects based on a flow framework that captures events as they occur across the software development toolchain.

    Company CEO Mik Kersten said Tasktop Viz is the first substantiation of the flow framework in software that provides a value stream management application to enable organizations to more effectively manage software development projects. Tasktop Viz doesn’t necessarily replace project management software as a system of record for billing purposes, for example, said Kersten; however, it does provide a way to visually model the software development environment in a way that makes it easier to identify bottlenecks and potential opportunities to reallocate resources.

    Kersten said from a management perspective, existing approaches to managing software development projects are broken. They depend too much on software developers to manually enter data to update a project management application, which they don’t do as often as they should because it takes time away from developing software, he said. Tasktop Viz takes advantage of application programming interfaces (APIs) to automatically capture metadata from across the software development toolchain, providing instant visibility into software development projects without requiring DevOps teams to engage in an additional coding, Kersten noted.

    Tasktop Viz

    Kersten has been making a case for the adoption of an approach to managing software development projects based on the flow framework for several years. Tasktop Viz now provides IT teams with an application that is designed from the ground up using that model.

    Of course, the concept of value stream management applications has been around for some time. The debate now is not so much over the value of these applications as much as it is which architectural approach to building these applications best reflects modern software development. As the number of dependencies between projects continues to expand, it’s becoming next to impossible for organizations to manage multiple software development projects relying solely on spreadsheets and existing project management applications.

    That issue is further exacerbated by the fact that businesses are now more dependent on software than ever, so any delay to a project could have a dramatic impact on future revenues.

    Kersten said that despite the obvious business benefits, the biggest obstacle to adoption is more psychological than technical. Many software development teams are reluctant to adopt tools that might illustrate how chaotic the software development process within their organization really is. It’s critical that organizations that adopt value stream management applications do so with an eye toward wanting organizations to improve rather than just deploying another tool to measure metrics that are used to increase the amount of code being written.

    Of course, there’s no correlation between the amount of code being written and the quality of the applications being developed. The real challenge is to not just accelerate the rate at which applications are being developed, but also to ensure that once those applications are deployed in a production environment the number of fixes required are kept to the absolute minimum possible.

    — Mike Vizard

  • Human Transformation Breeds DevOps Skills and Success

    Human Transformation Breeds DevOps Skills and Success

    As part of its mission to advance the human elements of DevOps, DevOps Institute has released its 2020 Upskilling: Enterprise DevOps Skills Report. The year-over-year data builds on the inaugural 2019 project but it’s more insightful and more regional than last year. DevOps Institute is grateful to the 1,300 respondents this past year who took the time to share their insights that allowed us to present this important research to the community.

    One thing that is abundantly clear is that human transformation is the single most critical success factor to enable DevOps practices and patterns for enterprise IT organizations. Traditional upskilling and talent development approaches won’t soon be enough for large enterprises to remain competitive. This is because the increasing demand for IT professionals with core human skills is escalating to a point that business leaders have not yet seen in their lifetime. If there is but one call to action from the report this year is that we must update our humans through new skill sets as often—and with the same focus—as our technology.

    Thoughts on Skills

    What we continue to see is a well-recognized gap between the skills needed for digital transformation and the skills available in new and existing talent. According to 58% of the Upskilling report respondents, finding skilled DevOps individuals is a huge challenge, whereas 48% of respondents say the retention of skilled DevOps individuals is a challenge.  

    Unfortunately, the term “skill” is so broadly generic, which fuels the belief that there is a single stack of competencies that will guarantee enterprise success. That’s simply not true. The modern IT professional has to possess a set of skills across at least four categories: process, function, automation and core/human skills. Within each category, individuals must know which skills are considered must-have, nice-to-have or not as important—which leads to the question: How do you know? Seeking the answer to that question is the genesis of DevOps Institute’s Upskilling: Enterprise DevOps Skills Report project.

    Additional Takeaways from the 2020 Upskilling: Enterprise DevOps Skills Report

    • The DevOps journey is difficult for at least 50% of respondents since it changes the traditional structure of IT.
    • The DevOps human must have a hybrid set of skills since process skills and knowledge (69%), automation skills (67%) and human skills (61%) are the top three must-have skill categories in 2020.
    • Upskilling needs attention now since only 31% of respondents had a formal upskilling program while 38% do not,  21% said they were working on standing up a program.
    • Agile, DevOps and ITIL are getting strong competition from Site Reliability Engineering (SRE) which grew by 5% from 2019.  Value Stream Management and Systems Thinking are also gaining traction.

    To learn more, download the Upskilling 2020: Enterprise Skills Report.  The data is very granular and can serve as a waypoint for individuals and enterprises trying to plan their upskilling initiatives.

    — Jayne Groll

  • DevOps Deeper Dive: DevOps Consolidation This Way Comes

    DevOps Deeper Dive: DevOps Consolidation This Way Comes

    The merger of XebiaLabs and CollabNet VersionOne announced this week will accelerate the ongoing consolidation of providers of DevOps platforms that has been slowly gaining momentum for the better part of two years.

    Under the terms of the agreement, the unnamed combined company will be led by Ashok Reddy, formerly with Broadcom, CA Technologies and IBM. Current XebiaLabs CEO Derek Langone will become president of the combined company. Current CollabNet VersionOne CEO Flint Brenton is stepping down from the combined company.

    CollabNet has been trying to make a case for employing value stream management tools to better align application development projects with business objectives ever since it merged with VersionOne, a provider of an application lifecycle management (ALM) platform anchored around version control software, in 2017. Late last year, CollabNet VersionOne was acquired by TPG Capital, which pledged to make $500 million in funding available to drive organic and inorganic growth. The decision to appoint Reddy as CEO of the combined company was made by TPG.

    XebiaLabs, meanwhile, raised $100 million capital in early 2018 to drive investments in building a continuous delivery platform. The goal now is to more tightly integrate the respective platforms of the two companies to advance value stream management with Global 5,000 class organizations, says Langone.

    “There is no enterprise-class player in this space,” said Langone.

    Rival offerings either don’t scale to meet the needs of larger enterprises or they are simply too shallow to meet business requirements, he noted.

    Of course, value stream management is where most of the rivals of the combined entity are also focused. CloudBees, for example, has already rolled out value stream management modules as an extension of its continuous integration/continuous delivery (CI/CD) platform. CloudBees CEO Sacha Labourey said the company is now taking that concept to the next level by building a software delivery management (SDM) platform that normalizes data from multiple data sources. The open source Jenkins CI/CD platform, along with the Electric Cloud application release platform CloudBees gained via acquisition last year, would be one of many data sources for that platform, he said, while value stream management would be one of several applications available to different classes of users within that SDM platform.

    While mergers and acquisitions among DevOps vendors have been occurring slowly, Labourey said he expects the pace of such deals to increase in the months ahead as organizations embrace more complex modern application architectures based on microservices.

    “The destination is now clear,” he said.

    GitLab, meanwhile, has already signaled in 2020 that it will be adding value stream management capabilities to its namesake platform. Rather than trying to merge disparate code bases acquired by acquisitions, GitLab is building an end-to-end platform on a common code base, says Jackie Meshell, a senior product manager for GitLab.

    “We’re seeing the market follow that fast,” Meshell said.

    There are, of course, other approaches to value stream management applications that span multiple application development platforms, including offerings from Plutora, Tasktop and Panaya.

    Value stream management has become an industry buzzword of late as more organizations appreciate the degree to which their businesses now revolve around the rate at which software gets built and delivered. Value stream management applications are roughly the equivalent of business intelligence software for business managers, who pull metrics and data from application development platforms to determine whether projects are falling behind and what impact those delays might have on the business.

    Most business leaders are going to lean toward value stream management applications that can be applied across multiple application development platforms, said Bob Davis, chief marketing officer for Plutora. Few organizations are standardized on a single application development platform, he noted.

    While it’s still early days in terms of adopting value stream management applications, Davis said it’s already apparent that in the age of digital business transformation the category is red hot.

    “Value stream management these days is everywhere,” he said.

    It remains to be seen whether a strategy that focuses mainly on slower-moving enterprise IT organizations will succeed at a time when more agile startups continue to gain share at the expense of larger incumbents in almost every industry. Many of those enterprise IT organizations may get exposed to value stream management by acquiring a rival that has already adopted an application. Of course, it’s also just as likely that by the time many of those enterprise organizations reach the point where they need value stream management applications, it may be past the point where they remain relevant.

    Regardless of how they get there, however, wider adoption of value stream management as an extension of SDM is coming. The only unknown now is how and when.

    — Mike Vizard