Skip to main content

DevOps Lead Time – Let’s Re-Evaluate

It’s hard not to mention “Accelerate” when writing about DevOps; rarely does such a seminal piece of work provide an equally well-defined set of practical applications. It was a landmark engineering and business handbook that, through outlining what we now refer to as the DORA metrics, kick-started a DevOps metrics gold rush.

Lead Time is a member of this DORA metric collection. Its stated definition is the time between a change request initiation to when that change is running in production. This is usually measured by taking the time between the first code change committed in your source control tool and when that change is deployed. Sounds simple enough, right?

There’s actually a fair amount of ambiguity surrounding the best place to start measuring Lead Time. Does the activity ranging from first commit to production truly encapsulate the development journey? 

The appeal of DORA-flavored DevOps metrics is that they can be tied to business impact; they offer a way for engineering to measure something that truly matters to the entire business and that can be easily communicated beyond traditional engineering silos. DevOps lives and dies by its holistic ability to evaluate your engineering process. When it fails, it tends to be because its focus has become too narrow. 

That’s why at Jellyfish, we believe extending the scope of your change lead time metric beyond the first commit to encompass the initial Jira Issue is a more well-rounded practice, one that can help you achieve one of the ‘true’ versions of Change Lead Time. 

Where’s the issue?

There’s a reason Commit Lead Time is the accepted standard within the DevOps community; the data required to accurately measure it is readily accessible to most engineering organizations. All that’s required is a binary pair of dates from your source control tool and you’re in business.

It’s no secret that, in the face of the relative simplicity of all the DORA definitions, they’re not particularly easy metrics to track or analyze. For businesses that are trying to uplevel their teams by adhering to the DevOps methodology, it can be tempting to track DORA in its simplest possible terms. This is understandable and completely valid. 

But in practice, stripping DORA metrics to their simplest definitions can pose a real challenge. This is because, as your toolset and process footprint grows, the complexity of engineering exponentially increases. In the case of Lead Time, the escalating nuance involved in defining processes means that measuring from commit to production might not tell the whole story. You can run the risk of invalidating it as a metric, devaluing your organization’s wider DevOps adherence. 

There are numerous offshoots of Lead Time that address this contingency: Time to Review, Commit to QA and Time to Merge to name a few. These metrics pose their own challenges. Namely, it can be difficult to measure when the data required has to be pulled from across multiple tools. You also need to maintain the data union to assure accurate reporting. 

Jellyfish believes balancing data consolidation with broad engineering visibility is the optimal approach. That’s why, in addition to Commit Lead Time and other metrics, we provide Issue Lead Time within our Engineering Management Platform.

Issue Lead Time is the time from when an issue is created to when that change is deployed. 

You may be wondering: why does including the issue creation have such an impact on the value of Lead Time as a metric? 

By only measuring Lead Time from the initial commit, you highlight a metric that lacks context and applicability outside of engineering. While it may be useful for understanding process improvements within the engineering team, it’s somewhat arbitrary for the rest of the business. A large part of the goal in measuring Lead Time is understanding how long it takes to deliver value to your customers from the time when the necessary change was conceived. Expanding the definition past the first commit to include issue creation gets closer to encompassing the initial change request, and therefore is a better measure for the time between the inception of the idea and when that idea begins to bring market advantage.

There are additional complexities involved when crafting integrations to expand this metric beyond your source control tool — namely, incorporating the likes of Jira in order to capture the instantiating issue. The challenge is worth the reward though. By expending this extra effort you can turn organizations within the wider business, such as Product and Sales, into Engineering stakeholders. This is because they garner more value from the measurement once the conceptual issue is utilized in the metric measurement. They become more invested in Engineering success.  By highlighting how long it takes to bring value to the wider business, we believe Issue Lead Time is a powerful tool toward measuring DevOps effectiveness. 

It’s also worth noting that, depending on the working style of your organization, your engineers may have been thinking and writing code days before the initial commit is submitted. By involving issues in the equation, you incorporate focused time and attention – making it that much more valuable as a metric. 

Conclusion

Software engineering has become the most integral part of our technology driven market. With this rise to even greater prevalence comes an associated responsibility; technical processes can no longer be siloed strictly within the realm of engineering. The scope for measuring engineering success needs to be expanded to reflect business initiatives. By widening the field of view for the metrics you track, you can make strides in aligning engineering work with key enterprise objectives and, in doing so, earn a greater respect and candor with your business counterparts.

Jellyfish has recently added a whole host of DevOps metrics to our Engineering Management Platform. If you’re looking for a solution to support your organization, check out our feature announcement blog post to see how Jellyfish is helping elite engineering teams optimize their DevOps processes. 


Content provided by SD Times and Jellyfish

The post DevOps Lead Time – Let’s Re-Evaluate appeared first on SD Times.



from SD Times https://ift.tt/3pScCNr

Comments

Popular posts from this blog

Difference between Web Designer and Web Developer Neeraj Mishra The Crazy Programmer

Have you ever wondered about the distinctions between web developers’ and web designers’ duties and obligations? You’re not alone! Many people have trouble distinguishing between these two. Although they collaborate to publish new websites on the internet, web developers and web designers play very different roles. To put these job possibilities into perspective, consider the construction of a house. To create a vision for the house, including the visual components, the space planning and layout, the materials, and the overall appearance and sense of the space, you need an architect. That said, to translate an idea into a building, you need construction professionals to take those architectural drawings and put them into practice. Image Source In a similar vein, web development and design work together to create websites. Let’s examine the major responsibilities and distinctions between web developers and web designers. Let’s get going, shall we? What Does a Web Designer Do?

A guide to data integration tools

CData Software is a leader in data access and connectivity solutions. It specializes in the development of data drivers and data access technologies for real-time access to online or on-premise applications, databases and web APIs. The company is focused on bringing data connectivity capabilities natively into tools organizations already use. It also features ETL/ELT solutions, enterprise connectors, and data visualization. Matillion ’s data transformation software empowers customers to extract data from a wide number of sources, load it into their chosen cloud data warehouse (CDW) and transform that data from its siloed source state, into analytics-ready insights – prepared for advanced analytics, machine learning, and artificial intelligence use cases. Only Matillion is purpose-built for Snowflake, Amazon Redshift, Google BigQuery, and Microsoft Azure, enabling businesses to achieve new levels of simplicity, speed, scale, and savings. Trusted by companies of all sizes to meet

2022: The year of hybrid work

Remote work was once considered a luxury to many, but in 2020, it became a necessity for a large portion of the workforce, as the scary and unknown COVID-19 virus sickened and even took the lives of so many people around the world.  Some workers were able to thrive in a remote setting, while others felt isolated and struggled to keep up a balance between their work and home lives. Last year saw the availability of life-saving vaccines, so companies were able to start having the conversation about what to do next. Should they keep everyone remote? Should they go back to working in the office full time? Or should they do something in between? Enter hybrid work, which offers a mix of the two. A Fall 2021 study conducted by Google revealed that over 75% of survey respondents expect hybrid work to become a standard practice within their organization within the next three years.  Thus, two years after the world abruptly shifted to widespread adoption of remote work, we are declaring 20