Rethink Your Understanding

Transforming Software Delivery

Metrics

Mitigating Metric Misuse: Preventing the Misuse of Metrics and Prioritizing Outcomes Over Outputs

by

6 min read

The business needs feedback on technology investments. Teams need insights into flow efficiency and potential bottlenecks.

Part 3 of a continuing conversation regarding today’s delivery system metrics: Flow Metrics, DORA, and the traditional concerns regarding the Gamification of numbers.

Links to the previous posts:

Part 1: Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks.

Part 2: Developer Experience: The Power of Sentiment Metrics in Building a TeamX Culture.

What problem are we trying to solve?

Identifying the specific problem you are trying to solve with metrics is essential. Could you suggest other solutions apart from using these metrics? How can we determine where to invest and track progress if we don’t use them?

The problem we are trying to solve is the improved efficiency of software delivery and employee engagement. The focus is on continuous improvement of flow. Using metrics, we can illuminate insights into bottlenecks and obstacles that reduce the team’s ability to deliver software. Our goal is to continuously improve the flow of work, which ultimately leads to better outcomes. Improvements in outcomes reflect efficiency improvements.

Business interest in metrics (investing in technology, investing in work)

  • Are we improving our business by investing in technology? Are we getting better?
  • Return on investment, return on outcomes
  • Delivering faster with high quality

Teams (delivering work, removing friction, feeling successful)

  • Improve efficiency by reducing waste, shortening lead and cycle times, optimizing workflow, and promoting employee engagement.
  • We do this by providing teams with data, insights, and optics into bottlenecks and areas of friction that generate conversations around why these bottlenecks exist and brainstorm experiments to resolve them.

Is there an elephant still in the room? What about the Gamification of metrics?

Concern for system metrics like Flow and DORA is still the team’s focus, as they try to gamify the numbers instead of focusing on the data and looking for patterns that highlight bottlenecks and friction, otherwise known as areas of improvement.

Stakeholders need system metrics, and using them effectively within the organization is essential. Some tools can be expensive. There is also a risk of gaming the system to achieve a desired metric, and these tools’ values decrease when teams focus solely on the numbers.

How can we avoid becoming hyper-focused on these metrics this time around? How can we encourage teams to use them? We should separate the business view from the team’s perspective. The team should focus on the insights and illuminated areas of improvement, not just the numbers.

Some leaders adopting these newer metrics and dashboards measuring flow and DORA still warn that Gamification wins, and teams fall back to focusing solely on improving the number.

Yet, numerous teams have succeeded by fostering a positive culture and adopting the right mindset. These teams analyze the patterns and identify the areas that pose obstacles. Doing so enhanced the flow, mitigated friction, and boosted engagement, activity, and overall satisfaction.

The key is leadership.

Bad managers or incompetent managers will diminish efforts.

If you still fear team gamification and misuse of metrics that defeat the value of modern ways to measure and motivate efficiency improvement, consider improving your leadership instead of blaming the tools or teams.

The increasing pressure on engineering leaders to be “more data-driven” has pros and cons depending on the managers leading the effort, even with today’s metrics and the “why,” bad managers can erode the value of these modern team data insights.

Depending on the competencies of the managers leading the effort, the push for engineering leadership to be more data-driven can have positive and negative effects, despite the availability of metrics and understanding of the “why.” In the case of bad managers, the value of these team insights can be quickly diminished.

Although metrics like Flow and DORA can offer valuable insights into team efficiency and process bottlenecks, it is crucial to remember their purpose. These metrics serve as tools for understanding and improving the system, not micromanaging, unfairly critiquing the team, or ranking performance across teams.

These are “team” metrics. Misusing these metrics to measure individual performance is an unfortunate managerial anti-pattern. As with comparing teams, managers focusing on individual performance can lead to a toxic culture and create an environment where team members might manipulate the metrics rather than focus on delivering value.

If your teams prioritize numbers instead of identifying improvement areas and working together to overcome challenges, consider examining the person guiding the team and reporting the team’s metrics.

Competent and influential managers:

Leadership needs to create a clear cultural imperative, acknowledging that, while sometimes it may be unavoidable, it is human nature to want to focus on the numbers. However, intentionally doing so will not be accepted. It is important to reinforce a culture of improvement and help teams understand that metrics are not the ultimate goal. Instead, metrics result from efforts to enhance different processes, such as removing bottlenecks, improving flow, automating processes, and enhancing practices. With the focus on improving rather than the numbers, each improvement will increase metrics over time.

  • Foster psychological safety for teams to make all work and impediments visible.
  • Don’t use metrics to compare or punish teams. Each team has a unique set of customers, complexity, and challenges.
  • Use metrics in retrospectives to drive discussion and ideas on improvements.
  • Celebrate experiments and improved trends.

The Benefits.

Teams should be encouraged to view and use the metrics differently than how the business views them. Teams finally have data to advocate for investments in other work besides features.

There are ways in which teams can benefit once they have data to back up the evidence of their bottlenecks and show the business and stakeholders the value of investing in and addressing these bottlenecks. Teams can use this data to demonstrate the necessity for investing in technical debt and efficiency improvements rather than just investing in feature work. The benefits include:

  1. More data to act upon: Give your team more data and insights to talk about, and if required, act upon it before things start to fall off the rails.
  2. Exposing Bottlenecks: Flow Metrics and DORA Metrics can help teams identify bottlenecks in their development process. Bottlenecks include areas where work is consistently getting held up, causing delivery delays. By identifying these bottlenecks, teams can focus on improving these specific areas through automation or other solutions leading to overall improvements in efficiency and delivery time.
  3. Promoting Proactive Improvement: Using these metrics encourages a proactive approach to improvement, as teams can use the data to identify potential issues before they become significant problems. Early detection can lead to a more efficient and effective development process.
  4. Demonstrating Value Beyond Features: Often, stakeholders focus on feature delivery as the primary measure of a development team’s value. However, these metrics can help prove that a team’s value extends beyond delivering features. They can show how improvements in technical debt reduction, process efficiency, and team collaboration can also provide significant value.
  5. Facilitating Conversations with Stakeholders: These metrics provide teams with the data they need to have meaningful conversations with stakeholders about where investment is required. They allow teams to move beyond subjective arguments to data-driven discussions about the state of the development process and what is needed to improve it.

By adopting these newer system metrics, with the support from exemplary leadership, and a great culture, teams can avoid focusing solely on the metric numbers to please the business and shift instead towards an improved flow, higher team member engagement, and a more balanced and sustainable approach to software development.

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others. What are your thoughts?.

Let’s talk: phil.clark@rethinkyourunderstanding.

Related Posts

Developer Experience: The Power of Sentiment Metrics in Building a TeamX Culture

by

6 min read

“If you are in a good culture, you will feel and know it, and it’s sometimes hard to put words on those things.” ~ Wayne Crosby

What is the objective of our focus on Developer Experience? We aim to address various aspects, such as enhancing efficiency, encouraging collaboration, boosting job satisfaction, improving output quality, and fostering innovation and creativity.

The Buzz Around Developer Experience

There have been so many publications on this topic lately. Google “developer experience,” and it will return a list of links to DevX definitions, examples of DevX teams, and frameworks.

DevX is a new spin on prioritizing the investment in people and ways of working. I recall every presentation emphasized a people-first culture four years ago. Still, lately, there has been a surge in the number of articles published about developer experience (a.k.a. DX, DevX, and DevEx).

Why is developer experience becoming more prevalent?

During the previous waterfall and project-based software delivery practices, some have argued that developers were treated like a resource from a factory line. They were often referred to as “resources” by the business, measured by their code output and utilization. It’s great to be recognized as a human being and feel engaged and valued. But do the attributes of DevX apply only to developers or possibly many others on a delivery team? In many cases today, cross-functional delivery teams are delivering value.

I have spent much of my career as a software developer and manager of software development teams, my contributions and output have measured me, and I have measured others similarly. I have worked with previous cultures, tools, and practices, and today’s tools, architectures, and ways of working. More than anyone else, I can appreciate the message and focus on the developer experience.

Attributes of Developer Experience

The term “developer experience” refers to the experience of developers as they do their everyday work, including any difficulties they may encounter.

The attributes of developer experience (DevEx, DX) are as follows:

  1. Perception of the development infrastructure: How developers perceive the technical infrastructure (e.g., development tools, issue trackers, programming languages, cloud platforms, libraries) and ways of working (e.g., working agreements, processes, and methods)​.1
  2. Feelings about work (happiness and engagement): How developers feel about their work, including whether they feel respected, care about it, and feel like they belong in their team.1
  3. Value of work (purpose and success): How developers value their work, including whether they feel they’re making an impact and whether their values and goals align with the company​.1

In addition, a fourth attribute, Onboarding and investment in upskilling: Is how developers value an organization or department that prioritizes the onboarding process for new members and invests in their ongoing skills development.

Here are a few of the initiatives that are driving the developer experience:1

  1. Reduce developer wait times and interruptions
  2. Invest in maintaining a healthy codebase
  3. Make deployments safe and fast
  4. Empower teams
  5. Optimize for high work engagement

Developers with high work engagement exhibit persistence, dedication, and a commitment to delivering quality software. They proactively support the organization and consistently produce excellent work when they have the tools, autonomy, mastery, purpose, and a sense of success.

Success Comes From The Team and Team Experience

As of 2023, many organizations have significantly invested in transforming their ways of working through culture, Agile, Lean, DevOps, and cloud technologies. They invested in DevOps and Platform teams that build the capabilities for teams to improve software delivery and the developer experience. It still takes a team to deliver software today. What is so different about developer experience versus quality assurance experience, agile leadership experience, or product owner experience? We should expand the message to Team Experience (TeamX).

I recognize and respect software developers’ specific type of work; it is knowledge work, so developer experience must be acknowledged. However, we need to expand the focus to the delivery team experience, which includes developer experience.

  • What if the Quality Assurance Engineer could spin up an ephemeral test environment to test changes and have innovative tools and ways to run performance, exploratory, and chaos testing?
  • What if product owners could press the “delivery” trigger in an evolved, highly confident continuous delivery pipeline to deliver features to production or review features in an ephemeral environment?
  • Why would we ignore the agile leaders’ need for tools to facilitate team building, retrospectives, sentiment analysis, cycle management, and more?

Most of the “developer experience” aspects relate to the other team roles on a cross-functional team and the team’s overall experience. Therefore prefer to focus on team experience and promote that “teams and team members with high work engagement exhibit persistence, dedication, and a commitment to delivering quality software. They proactively support the organization and consistently produce excellent work when they have the tools, autonomy, mastery, purpose, and a sense of success”.

Treating all workers with respect is important, but for creative work to thrive, a supportive environment must also be provided. I will continue to advocate for team experience (TeamX, TX) over developer experience (DevX, DX), and that developer experience is part of team experience.

Unlocking the Potential of Metrics

As a follow-up to my first post on modern-day metrics, “Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks,” this post highlights the exciting combination of modern-day insights available today. These insights come from both your delivery systems and the team’s sentiment.

Measuring team experience requires both delivery efficiency (system metrics) and team feedback (sentiment metrics).

System metrics: I have become an evangelist and promoter of today’s system metrics and data insights based on value stream management, the Theory of Constraints, and a mix of flow metrics and DORA metrics as a holistic workflow and measurement to accelerate efficiencies and product and portfolio delivery.

Sentiment metrics: Since 2022, I have increased my focus on sentiment frameworks like the SPACE framework2 and, more recently, the DevEx framework created by Abi Noda, Margaret-Anne Storey (author of SPACE), Nicole Forsgren (creator of DORA), and Michaela Greiler (previously Microsoft Research).3

I have learned that it is not uncommon for organizations to start with system metrics and then realize they can benefit from targeted frequent sentiment metrics.

One unique thing about my experience at my current organization is that in addition to a semi-annual organization-wide employee net promoter score type survey (eNPS), we have been collecting simple team sentiment over many years using a Google Sheet, wherein each team member’s sentiment is recorded at the end of their daily standup comments: How are you feeling today? Positive, Negative, or Neutral.

Wanting to expand on our sentiment feedback, we are looking into creating short, consistent, and frequently delivered surveys in-house using existing tools that provide us with this capability or investing in services with significant experience in this area and the types of questions that bring the best results. As we still learn to master value streams and system flow metrics, we must expand and invest in our sentiment metrics.

Final thoughts

Creating and delivering digital products is currently an exciting field. Modern delivery practices, methodologies, and innovative measurement techniques bring positive changes. Two types of data analysis are necessary to evaluate team effectiveness and happiness: delivery system metrics (such as Flow and DORA) and sentiment metrics (measured through surveys).

To remain competitive and succeed in today’s business environment, software delivery organizations must update their delivery practices and adopt modern system metrics and sentiment measurements.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.

References

  1. Ari-Pekka Koponen (28 February 2023), The ultimate guide to developer experience, swarmia.com, short URL: bit.ly/468g0q2
  2. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler (06 March 2021), The SPACE of Developer Productivity: There’s more to it than you think, queue.acm.org, https://queue.acm.org/detail.cfm?id=3454124
  3. Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler (03 May 2023), DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity, queue.acm.org, https://queue.acm.org/detail.cfm?id=3595878

Outcome Metrics and the Difficulty of Reporting on Value

by

4 min read

What does it mean to “deliver value”? Defining value deserves its own focus. This article picks up at the point of the delivery backlog, assuming that your product leadership has identified the customers’ or organization’s needs, prioritized, defined, and outlined the value for the business and its customers, created a business case for the investment (including impact mapping and cost analysis) and defined the expected outcomes from changes or improvements to their digital product.

What problem are we trying to solve?

The outcomes are not kept from the teams, ensuring we are closing the loop.

This article dives into the crucial topic of measuring the outcomes following the release of enhancements or changes and informing the team(s) that delivered the work. Did the change or new feature deliver the expected value? Are we delivering the right things? Knowing the outcome or level of success motivates team members and bolsters their purpose. Teams can use the results to glean valuable insights even when they do not meet expectations.

Fast and agile delivery is not the end goal; value is the end goal

“Making the wrong thing faster only makes us wronger.” 1

In software delivery, it is essential to remember that delivery is not the end goal; value is. It is easy to fall into the trap of delivering software quickly and efficiently. Still, it is all for nothing if it does not provide value to the customer or organization. Delivering unwanted features can be a sad waste of productivity and a misuse of talent.1 These are just a couple of reasons why it is crucial to understand what value means in software delivery and how to measure it.

Organizations need to understand the real-world impact of their digital product changes, so measuring its outcome value, determining the return on the investment, and learning from outcomes are critical. Unfortunately, accurately tracking and reporting outcomes and value returned can be complex due to several challenges.

The challenges of measuring the final outcome of digital changes

What are the meaningful outcome metrics? Are such metrics communicated down to the delivery team level? Do companies practicing OKRs report on the final outcome of those OKRs?

First, many organizations need more tools to help them measure the value of outcomes from software delivery. The lack of tools and data insights can make it challenging to track and report on the success of the delivered changes.

Secondly, measuring the actual ROI requires significant time and effort. It is essential to determine the impact of digital product changes on the business or customer; this can be a complex process. This work may require additional resources, like data analysts or business intelligence tools.

Third, the impact of the software changes may take time to become apparent. It might take months or even years to see the actual effect of the changes delivered on the business or customer. Time duration can make it challenging to accurately track and report the real degree of success or value delivered within the allotted time to influence teams.

Fourth, accounting for the success of an outcome and the value it returns may require additional resources and a shift in the organization’s mindset to prioritize measuring this work.

Finally, there could be pushback when inquiring about the value of the product or platform changes teams delivered. To ensure that the value outcome is consistently tracked and reported, organizations must determine who is best suited for monitoring and reporting the value outcomes of what the teams deliver.

Teamwork and transparency at the team level

For those using Scrum or Kanban or similar lifecycle practices and tools, consider adding elements to the delivery team’s Epics, Features, and possibly User Stories.

Why: Why are we working on this?

Value: Short description of the expected outcome for the organization or customers.

These can align with OKRs for those using them.

Benefits:

  • Shared understanding, alignment, purpose driven development, and delivery.
  • Documenting the why and value enables team alignment and autonomy and increases team member engagement.
  • A more precise understanding of priority reasoning.
  • Learn from the outcomes (gain insights).

Challenges:

  • Tools to help measure the outcome.
  • Measuring the outcome requires significant time and effort.
  • The impact of the change(s) delivered may take time to become apparent, ranging from weeks to months or even longer.

Closing the loop with the delivery teams:

  • Schedule outcome retrospectives with teams.
  • Document the outcome(s) details to Jira, Azure DevOps, Rally, or whatever tool your teams use.

Final thoughts

In many organizations, technology leadership must measure and report on the performance of the software delivery teams.2 Do your delivery teams receive feedback on their work’s value to the organization or customer? Are they aware of the impact and success of their efforts after they deliver on a change? If not, it’s time to reevaluate your approach.

By providing your teams with regular feedback and, more importantly, the overall results or outcomes from their work, you can increase their motivation and a sense of purpose, leading to a more engaged and productive workforce.

If you aren’t doing so already, start tracking, measuring, and reporting on your team’s outcomes to align your business objectives and change investments with their performance, avoid costly and wasteful overproduction, learn from the changes made to your delivered product, and achieve greater success. Are your teams “delivering value”?

Related articles:

  1. Value part 1: Maximizing Technology Team Effectiveness: Insights from a CEO Conversation
  2. Measuring delivery teams: Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks.

References:

  1. Smart, Jonathan [@jonsmart]. “From Faster to Sooner” Twitter, 26 June 2021

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others. What are your thoughts?.

Let’s talk: phil.clark@rethinkyourunderstanding.

Maximizing Technology Team Performance: Insights from a CEO Conversation

by

6 min read

In this article, I share an enhanced version of a conversation with a CEO in August of 2022 regarding the effectiveness of technology teams, measuring improvement, building the right things, and how understanding the purpose and value of their work can impact team effectiveness.

The Importance of Purpose and Value

Achieving success requires understanding the purpose and value of your work. If disconnected from a shared vision, it is vital to pause and reconsider. When clear on how you are adding value, teams can collaborate optimally, prioritize tasks effectively, and comprehend the importance of their efforts. Effective teams solve problems with a sense of mission while being driven by what they bring to these solutions in terms of purpose.

The Measurement Challenge

I recently talked with a CEO from my network about the challenges of measuring the productivity and performance of software engineers and teams and determining if we are making progress. Measuring developer productivity has been a persistent challenge for engineering leaders for decades.

In this discussion, the CEO, whom I’ll refer to as Steve, insisted on his VP of Engineering report on the organization’s engineering productivity. Despite being familiar with outdated metrics centered on individual output, Steve was open to new ideas. As I shared my experience working on this issue in my organization, he was interested in learning how we measure and report the return on investment of the value delivered.

Measuring Progress and Building the Right Things

To assess improvement, it’s crucial to measure both delivery performance and the outcomes of our efforts. Steve mentioned that technology is responsible for measuring delivery performance, but I emphasized the importance of the business quantifying the impact of change and communicating it to delivery teams. Product managers should assess and measure the return on investment of value delivered to stakeholders. However, measuring the ROI of work delivered and business outcomes can be challenging even for experienced leaders. During the conversation, we discussed delivery team performance, but I also wanted to explore the impact of having a clear purpose and value on delivery performance. I asked Steve about his experience measuring the impact or ROI of value delivered by teams.

I suggested: “What if a team could improve from delivering five widgets per week to eight, with the same number of team members and the same number of hours?” I asked Steve, “Did we get better?” His answer was “Yes,” but I disagreed. “How will we know that we are building the right things?” and “How will we know that we have not overproduced and wasted time?” I stated, “the additional three widgets may not provide the expected value, and we could be wasting time and effort without realizing it. Are we overproducing?” As Jonathan Smart said, “Making the wrong thing faster only makes us wronger.” This marked a turning point in the tone of the conversation.

Building the Right Things with Purpose

“People work better when they know what the goal is and why. It’s important that people look forward to coming to work.” – Elon Musk.

The conversation shifted to understanding and communicating value and outcomes rather than just focusing on output. Steve commented that it wasn’t the job of a Vice President of Engineering to question the value; this responsibility for questioning and communicating feature work value lies with the Product Manager, or more likely, the senior product leader — not the head of engineering. Not surprisingly, I took his comments personally. Changing tactics, my intention now was to tie employee engagement back to knowing the value of the work. I asked Steve about employee retention and whether it was the responsibility of the Vice President of Engineering; he agreed and added that it was the responsibility of the Engineering Senior Leader to build a great employee experience and culture.

I brought up the concept of purpose-driven development, where people are motivated by a sense of meaning and fulfillment in their work. I asked Steve about his understanding of extrinsic and intrinsic motivation and if he believed people could be driven by autonomy, mastery, and purpose beyond salary. He agreed. I took this opportunity to tie in the value of engineering teams needing to know the value. Without a shared understanding of value, teams can become demotivated and feel like they are just following orders. To avoid this, it is crucial for everyone from the executive team down to the delivery team members to understand the value of the work they are producing. This leads to more efficient work and prevents wasted energy from overproducing or creating unwanted items. The goal is to ensure that work occurs efficiently and that teams feel a sense of purpose and connection to the outcomes they deliver.

We circled back to the origin of the conversation about measuring performance. The conversation ended with the question, “How do we know that engineering delivery teams are getting better?” As a technology leader, we will measure engineering delivery performance to identify ways to continue improving (get better). My takeaway highlights the importance of understanding the value of what we are producing and how it impacts customer experience and the organization’s goals. Only then can we genuinely answer if we are making progress and delivering the right things.

Measuring the actual outcome of delivery

As colleagues serving our actual customers, the external ones, it is our responsibility as IT and Product to ensure value is delivered to the customer and organization. This helps to reduce the risk of waste through the overproduction of incorrect items and allows us to motivate and retain our team members through purpose-driven development.

Delivery teams must focus on the efficiency and effectiveness of what is being delivered. Unless an experiment is being run to determine the usefulness of a product to a customer group, delivering items of work that have no value to the customers or targeted customer population is a waste of time and energy.

Beyond senior leadership, delivery teams should engage in value-driven discussions, considering the customer’s and organization’s goals, expected outcomes, and the value that will be provided to people. This helps to ensure that the team has a clear understanding of the purpose behind their work.

The product owner is responsible for explaining the value behind each feature and how it connects to the organization’s goals. If the product owner cannot do so, they should re-evaluate their approach. Teams should not be reduced to mere “feature factories” without a clear understanding of the purpose behind their work.

Leaders must measure productivity and performance improvements and communicate the value and outcomes of what their teams are delivering. This creates a shared understanding throughout the organization and ensures that valuable work time is spent on creating truly needed things.

Team members should know how their work contributes to the organization’s performance and customer engagement, fostering a sense of purpose and engagement. This helps to avoid wasting resources in terms of money, employee engagement, and other aspects.

Unfortunately, teams often do not see the outcomes of their delivery. Measuring and reporting on these outcomes is important to determine if the right things were built and if the organization is improving.

Final thoughts

Just as IT is held accountable for measuring and improving productivity, the product team and the organization should be held accountable for communicating value and for measuring and communicating the outcomes of the delivered value. To answer the question, “Are we improving as we get bigger?” one must consider delivery performance and know the outcomes of what has been delivered (are we building the right things?). Defining value and communicating outcomes are essential to ensure everyone is aligned and working towards the same goal.

Link to the next article, value part two: Unlocking the Value of Software Delivery: Difficulty of Reporting on Value

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others.

Let’s talk: [email protected].

Finally, Metrics That Help: Boosting Productivity Through Improved Team Experience, Flow, and Bottlenecks.

by

13 min read

Note: This article has two parts: First, a view on today’s data insights and metrics. Second, our experience researching the tools in the market.

Data is key to improvement, but it is not just about collecting and reporting it. We must use the right data for the right purpose to improve flow and efficiency, and team health. The way that leadership approaches the metrics ultimately still has the largest impact on success. We can unleash our full potential and reach our goals by adopting a metrics-driven improvement culture and methods that provide insights to encourage and motivate teams.” ~ Phil Clark

What is great software delivery?

To be excellent at delivering software, deliver the right changes efficiently, frequently, with quality, and get customer feedback. Move quickly with the confidence and knowledge that you are building the right things with quality and security. Innovate, Adapt, learn, and solve real customer problems faster than your competition.

What problem are we trying to solve?

Better ways of measuring software delivery performance.
How can we make the most optimal impact? We can assess software delivery team performance with useful metrics that both the organization and team members desire and those that encourage and enable teams to experiment and drive their own improvements. With a continuous improvement mindset, no matter how good we are today, we will get just a little better tomorrow.

Digital Product Workflow

Digital products flow across three primary stages: Product Discovery, Product Delivery, and Operations.

If you are performing value stream management, you create an end-to-end (concept to cash) cross-organizational flow of work for the value stream throughout the organization, understanding both upstream and downstream work and eliminating dependencies, waste, and friction.

End-to-end, Product Discovery, Product Delivery, and Product Operation: All stages of digital product management from idea generation to production or customer use, a.k.a concept to cash.

Product Discovery: The conceptual vetting stage of a digital product, from idea to backlog. Ideation, discussion, evaluation, and consideration for which features or products to prioritize and build to set the stage for increasing organizational performance.

Product Delivery: The delivery stage of a digital product, backlog to production.

Product Operation: The operation and support stage of a digital product.

Product discovery uncovers what creates value, while product delivery produces what creates value.

Measuring engineering performance

How are we doing? What are we doing well? What areas can we improve? What are we getting from our investment?

Measuring engineering performance has historically been a low point of my 20+ year technology career. During the first decade in technology, I was assessed solely as a practitioner by the metrics of that time. I vividly recall the metrics constantly reinforcing the notion of being perceived as a mere cog in a machine and the disheartening label of being a cost center.

As a manager, I was responsible for evaluating the performance of software engineers using the same criteria that I was assessed on as a practitioner. Based on these metrics, I would make decisions regarding individual team members, including stacked ranking. I have experienced the negative impacts on culture, engagement, and adverse side effects stemming from legacy metrics that treated people like machines (individual productivity measures, lines of code, and tracking hours).

Knowledge work is distinct from the repetitive workings of a mere machine.

Avoid measuring individual development activities in your business as it harms team dynamics and productivity; doing so will not help you reach your business goals, making it an ineffective use of time and resources. It is not just about the performance of individuals but all about successful teams. A shift to focusing on team outcomes and capabilities and measuring performance for continuously improving team flow is inspiring. Today’s delivery teams are seeking ways to maximize efficiency and streamline workflows. They can now access meaningful metrics to verify their efforts are paying off. By utilizing these revolutionary team metrics, teams can gain visible insights and signals to enhance their product development and delivery process further.

Whether Flow- or DORA-based, today’s metrics should combine system/process data (quantitative) and self-reported data (qualitative).

We are not the teams of yesterday

Significant influences have shifted how we can instrument and measure engineering performance (IT, digital product delivery) from the past. 

The team’s design has changed: shifting from large, skill-based functional silos that hand off work to the next functional team to small, cross-functional teams that can deliver solutions with the least dependency on other teams.

Capabilities have changed: architecture (microservices, DDD, event-driven, lambda, serverless computing, and more), culture, team design, continuous integration, continuous delivery, cloud strategies, automation, quality practices, SDLC (agile, lean), DevOps, platform engineering, and more.

Systems measures have changed (quantitative): It provides visibility to change the system rather than focusing on the individual people.

Dora Metrics (Product Delivery: Development to Production)

Flow Metrics (Product Discovery and Product Delivery: Idea to Production)

  • Project to Product by Mik Kersten
  • Lean practices and Value Stream Management (VSM) and Flow metrics
  • Platforms: There are several options in the VSM and Flow space, such as Planview Tasktop Viz

Self-reported data around team health and sentiment metrics have improved (it can be both qualitative and quantitative).

People aren’t happy because they’re successful; they’re successful because they’re happy. Happiness is a predictive measure. 1

  • Developer Experience (DX); I recommend and focus on Team Experience (TX)
  • SPACE, a New Framework to Understand and Measure Developer Productivity
  • Platforms: DX (getdx) plus one that focuses on team experience (TX) like TeamRetro or agilityhealth. Most likely, several more in the market should be mentioned here. 

Note: I have no equitable affiliation or endorsement benefits from any of my recommendations

Separate the business from the team conversation

Separating business pressure to drive metrics from a team’s motivation to use metrics for improvement is crucial. Teams that focus on continuous improvement and have visibility into metrics can identify and solve bottlenecks, leading to better outcomes and aligned results with business expectations. Metrics can be imposed by the business, risking gamification, or embraced as tools for team improvement.

Teams need motivating metrics. When teams manage improvement insights, they view the metrics as feedback to provide visibility into areas where they are performing well or where they can improve. They mine for bottlenecks and improve overall flow and outcomes. Despite their imperfections, metrics like these help to evaluate the outcomes that teams produce rather than just focusing on the numbers or outputs of individual contributors. Through monthly reviews, the teams can collaborate and develop ways or experiments to improve the bottlenecks.

How might metrics be viewed differently between the business and the delivery teams?

Business interest (focus in on the numbers): 

  • Are team metrics, the numbers, improving?
  • How can we predict the delivery estimates of a team?
  • Are department metrics improving (aggregate of all teams or portfolios)?
  • What actions are teams taking to improve?
  • Capacity, development cost per product, and return on investment.

Benefits:

  • Team throughput and delivery insights.
  • Time to market.
  • Improved predictability.
  • Delivery performance is an artifact of organization valuation. Over time, this creates a higher-quality system with fewer problems.

Risks: 

  • Pressure for individual metrics. Developers are more than just coders. Overemphasizing individual developer focus can be detrimental to team culture and overall performance. It is the collective effort of teams that delivers software, not the work of individual developers.
  • Organization leaders with a heavy hand push on the numbers. Teams use gamification to drive numbers, please the business for what their company wants to see, and risk limited or no real improvements to throughput.
    • If you still fear team gamification and misuse of metrics that defeat the value of modern ways to measure and motivate efficiency improvement, consider improving your leadership before blaming the tools or teams.
  • Comparing teams, pitting them against one another and the behaviors that arise from this, and knowledge hoarding. Each team’s work is most likely different than other teams’ work, making it difficult to compare.
  • Retention.

Teams view (focus on bottlenecks and conversations):

  • How are we doing? Where and how can we move the needle to improve throughput flow?
  • What areas are we doing well? Why might this be?
  • What are our bottlenecks to flow (what steps in our workflow take the longest time)?
  • What are the current obstacles we face regarding lead time, cycle time, PR time, and failure rate?
  • Where can we reduce waste? Can automation help?
  • What capabilities or practices can we change or add to help us?
  • What types of work need to receive the proper attention?
  • More experienced teams: How do we compare to similar cohorts or cohort clusters in the industry (if this data is available)?

Benefits:

  • Teams have the data insights to highlight underlying bottlenecks.
  • Improved time spent in active states versus wait states.
  • Collaboration and knowledge sharing across teams.
  • Autonomy, teams have meaningful metrics to allow them to solve efficiency problems (address the bottlenecks).
  • Teams use qualitative feedback (sentiment metrics) to encourage conversation, improve collaboration, and reduce toil and friction.
  • Team member engagement and employee retention.

Risks:

  • Focusing on individual team member performance. It has been my experience that small teams will not tolerate underperforming team members over time; if the team can’t solve the concern, they can surface the issue to the individual’s manager. I like using the analogy of a music band. The other band members will recognize an underperforming band member.

Leaders must avoid the outdated mindset of individual metrics, measuring individual productivity and lines of code and having teams compete against one another (comparing teams by metrics). Instead, leaders should focus on metrics that improve team flow and delivery efficiency. These metrics should combine system/process data (quantitative) and self-reported data (qualitative).

“When teams recognize the value of today’s metrics and utilize them to enhance their delivery flow, focusing on the bottlenecks and friction points, the business numbers will naturally follow suit. By embracing this approach, improvements become inherent, allowing the numbers to care for themselves.”

Qualitative Metrics: Developer Experience (DX) versus Team Experience (TX)

Prioritizing workplace happiness is crucial for success as it can lead to improved productivity, innovation, and revenue. It surpasses traditional metrics and should not be considered a perk but a key driver of a more profitable workplace.

Developer experience (DX) has been a hot topic in the technology industry lately. Most organizations build software as teams; I speak for cross-functional teams that consist of developers and other roles necessary to deliver software. Developers construct the code, but the whole team must provide the solution.  I recommend ongoing survey questions for self-reported qualitative metrics centered on developer and team feedback (TX). Earlier in this post, I shared the names of a couple of solution providers.

Team experience (TX) includes day-to-day work delivering work on teams. It encompasses all the different points of friction team members encounter in their work, including the organization’s tools, processes, and culture. Improving TX is critical to the business’s bottom line, as research shows it is a top predictor of engagement, productivity, and satisfaction. Companies with top-quartile team experience outperform their competition regarding productivity and their ability to innovate faster.

Summary on metrics

Effective teams want to improve. By offering teams a clear strategy, including an illustrative map (like a value stream or flow map), and specific expectations of outcomes, they can be afforded autonomy. They will be free to make their own decisions. Additionally, by providing them with team-based metrics that spotlight any bottlenecks in their process, the team members can confidently decide how best to positively improve the overall efficiency and effectiveness of their role in the workflow.

The business still needs to see results. Assuming team autonomy and motivating team metrics, as a business leader, you can step away from the teams and leave them alone to do their best work. You identify leaders to support the team to focus on outcomes and performance. You can focus on aggregating the signals of the metrics that matter to you. There is no “one” metric to gauge efficiency. Combining the feedback from multiple signals before raising concerns would be best. This approach means you don’t have to interrupt people or teams to get them to justify their numbers unless you have concerns. Suppose the data over a more extended period raises concerns. In that case, you can gain an understanding from the team of what might be happening and provide any guidance or action that may help them get back on track, if necessary.

A fresh perspective on performance measurement is emerging in the industry. These metrics focus on optimizing flow across the organization and should provide system and process level data (quantitative data) combined with self-reported health metrics data (qualitative data) to remove negative impacts on team culture. This improves engagement and puts improvement decisions at a team level. With this approach, the entire organization should see gains in optimizing the flow of work and improving delivery outcomes.

Removing the pressure of the business’s view on the team’s metrics is essential to foster confidence and trust that the team can review and act on insights, allowing them to identify areas where they can improve how they deliver software. To better insights and increase team engagement, using system-measurable metrics and regular, consistent surveys capturing teams’ experiences (sentiment) is essential. These visible metrics empower the teams to review and experiment with improvements.

Researching the market

The challenge

As a department leader, I am responsible for equipping our product development and delivery teams with performance feedback and metrics that will provide them with insights they can use to continue improving, even if they are already performing at a high level.

My team and I recently evaluated Value Stream Management (VSM), Flow, and DORA metrics platforms to assess the depth of data visibility into the product discovery and delivery phases and workflows through dashboards. The current market at the time of my writing provides many solution providers boasting different features, focuses, and prices, so it’s essential to do your due diligence before choosing one that fits your organization’s needs best.

Most solution providers focusing on VSM and Flow Metrics serve mid-market and enterprise organizations. In contrast, the solution providers focusing on DORA metrics serve small and medium businesses (SMB) and mid-market organizations. This evaluation experience was rewarding; it generated great conversations with solution providers and within my team and inspired this post.

Selecting a provider and partner

Selecting a metrics tool provider requires thoroughly understanding your organization’s needs, goals, and budget. Although we recommend a solution that covers all stages of the value stream, these options are targeted at enterprise-level budgets. They may not be affordable for SMB and mid-market organizations.

After evaluating the market, we identified two primary categories of metrics tool providers. The first category provides a comprehensive view of the entire value stream and can ingest data from various sources. In contrast, the second focuses on development and delivery, with optics around or extensions of the DORA metrics. We found that VSM metrics platforms tend to target enterprise budgets, while DORA metrics platforms are more affordable for SMBs and mid-market organizations.

We prefer a think big, start small, scale-out approach for most change efforts, as we did with our agile and DevOps transformation and our decision to select a VSM metrics solution provider. If development and delivery are your most significant bottlenecks, start with DORA and local metrics. Otherwise, you can expand to other parts of the delivery planning or discovery optics from value stream management solutions to gain operational efficiencies.

In my selection research, I found that some vendors measure performance and efficiency across the entire flow, while others focus only on one stage, measuring product delivery. However, I did not find one solution that measured both stages well. Additionally, I needed help finding a solution that provided strong team health metrics and qualitative data around human dynamics and team operations, in addition to system measures.

Another critical difference I discovered between service providers was the degree of data integrations or data read access available. While all platforms offer visualizations to identify bottlenecks, some providers do not integrate with systems of record that provide deeper insights into stages and the tasks causing the bottlenecks. When evaluating a solution, consider whether additional metrics are necessary to narrow the bottleneck or which components need to change to improve the bottleneck.

Visualizing the instrumentation options

I created the following diagram to help me convey these concepts when having this conversation with others:

Final thoughts

I am encouraged by the digital product delivery metrics available today that focus on teams’ usage to make decisions to improve performance and efficiency. Two measurements are necessary for teams to have the information they need to succeed: system process performance data and human dynamics, sentiment, and how teams operate.

While some solution providers have been in the market for some time, it was apparent that this market is still relatively young and proliferating with new vendors and improved features from competitors. Your approach to metrics and the degree to which you can visualize data in one solution can be the difference for your team. There are drastic differences in prices and capabilities among these solutions. I suggest you examine how you present flow and optimization across the organization. Select a solution that best fits the context of your teams and organization.

Another exciting aspect: Linking data to business value outcomes and impact (closing the loop). We can quantify the impact of our investments in agile, lean, and DevOps software delivery best practices.

Poking Holes

I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others. What are your thoughts?.

Let’s talk: phil.clark@rethinkyourunderstanding.

Related Posts

References

  1. Sutherland, Jeff; Sutherland, J.J.. Scrum (p. 148). Crown. Kindle Edition