Rethink Your Understanding

Transforming Software Delivery

Agile

Agile Era Leadership: Overcoming Legacy Leadership Friction and Four Industry Conversations

by

11 min read

The world has fundamentally changed in the past few decades. The rise of knowledge work and complex digital systems has shifted how we operate and compete. The practices needed to manage these new ways of working are different. Past success does not guarantee future success. Clinging to past mastery can hinder progress. Whether through bottom-up or top-down approaches, it is widely observed that the success of your transformation greatly depends on having a sponsor who comprehends it at the highest level possible. Ultimately, an organization’s success or failure depends on how much effort those with the most power put into learning the practical models they have chosen to use. This article targets digital delivery and operations leaders.

“We shape our buildings, and afterward, our buildings shape us.” Similarly, we shape the architecture of our organizations (how they are wired), which then shapes the behavior of the people within them.”

Winston Churchill

I am thrilled to witness a growing number of organizations within the Agile, Lean, and DevOps global IT and software delivery communities making remarkable progress in culture, successful delivery practices, and overall advancement. However, it is disheartening to observe the prevalence of negative leadership stories and discussions among older, more experienced leaders, which hinder the transition from the previous era of large projects, function-based teams, handoffs, and waterfall methodologies to the modern practices we embrace today. This friction impacts the transformation of work and the realization of its potential.

What problem are we attempting to solve? 

The negative impact of leaders who adhere to obsolete practices and metrics on contemporary agile work methodologies is apparent. Leaders who have previously achieved success are encountering challenges in obtaining a profound comprehension or achieving success in the constantly evolving realm of digital delivery practices.

Outdated models and a lack of understanding of leadership can lead to conflicts and unsuccessful change attempts. To drive this change, new or current executives need to clearly understand modern practices and operations and the rationale for change to take charge. These individuals must also have the authority to implement the required transformations.

Friction from Giants

Senior leaders who cling to outdated practices and metrics often create friction within their organizations, particularly when their decisions, based on legacy knowledge and amplified by their rank, undermine progress and innovation. While assuming positive intent, these leaders must recognize that their reliance on antiquated expertise is causing friction and hindering collective efforts. Leaders must invest time in acquiring new skills and applying modern methods to achieve positive outcomes. It is crucial for individuals to distinguish between purpose, outcomes, and alignment and to recognize the disruptive consequences that arise from prioritizing outdated metrics and egos. As seasoned professionals in their respective domains, these leaders must enhance their performance and grasp the strategies and metrics their teams utilize.

Consider this a belated follow-up to my article from December 2021, titled “Established Organizations, Digital Literacy, Mindset, and the 4th Industrial Revolution.”

Digging in

The shift in senior leadership mindsets from traditional, pre-agile methodologies to modern practices like Agile, Lean, and DevOps must be addressed in the evolving landscape of software development and organizational management. This resistance, especially among senior leaders familiar with legacy systems, stems from a deeply rooted adherence to outdated metrics and methods. It’s a scenario that poses challenges for digital transformation and threatens the fabric of collaborative, cross-functional teams. It is astonishing how many individuals continue to encounter this issue.

Failed agile transformations are often traced to misalignment and senior leadership friction. I have personally encountered this challenge. Once, we had a senior stakeholder who championed new ways of working and challenged the incumbent mindset. However, when that leader retired, the responsibility fell on me and our teams. Without my knowledge, a series of discussions awaited me after his departure, along with the integration of new owners and C-level team members with traditional success mindsets and limited familiarity with agile practices and organizational team structure.

Why Leadership Adaptation Matters

Coming from a background of successful leadership in the software delivery realm, I unintentionally encountered challenges when embracing agility during our digital transformation. However, November 2018 marked a turning point in my career. Then, I realized the need to revise the strategies that had previously led to my success to align with new practices, methodologies, models, and cultures. It was time for a shift in my understanding and approach. I needed to unlearn, relearn, and rethink my understanding.

In recent years, the impact of entrenched mindsets on modern practices has emerged as a prominent focus in my writing, conference presentations, and personal and executive discussions.

Personal Struggles with Resistance

From my experience, confronting resistance from new C-Level team members, board members, and other executives who may need more experience or knowledge in agile, lean, and DevOps principles can be daunting. The risk of job security is a significant concern, as it could impede the progress of transformative efforts. Striking the right balance between advocating for change and navigating the complexities of organizational power dynamics is crucial.

Leadership Challenges: Four Real-World Conversations

I am presenting four instances of conversations with individuals who have contacted me, expressing their challenges with senior leadership and adjusting to change.

Case One: Transforming the Top

Most recently, a colleague in my network who works for a large telecom organization reached out to me, sharing their struggles, which align closely with the challenges I have been discussing in my talks on legacy senior mindsets, team structures and roles, productivity metrics, and the recent hurdles I have encountered.

I recently gave two talks at conferences about my organization’s digital transformation, sharing insights from my career journey and experience with metrics. I recounted my challenges when new C-level executives and board members pressured me to measure “productivity units” from my engineering team. These expectations were similar to what my Sales, Marketing, and Customer Support counterparts were delivering. I have shared our journey from focusing solely on individual output to prioritizing team productivity, impact, and outcomes. The effectiveness of software engineers can vary depending on their roles within teams. Engineers on small cross-functional teams must recognize that the responsibility for delivering software lies with the entire team, not just individual members. While writing code is an important task, engineers on these teams have a broader range of responsibilities. The recent introduction of Value Stream Management and Flow Metrics has played a critical role in facilitating discussions and driving changes in metric expectations that focus on team productivity.

“Hi, Phil! I encounter similar challenges with upper-level management, who resist discussing new ideas and suggestions for improving our processes. The prevailing status quo overwhelms and stresses my colleagues. I actively seek connections with enlightened stakeholders to join an initiative fostering constructive discussions, but it remains an uphill battle. I observe a reluctance to speak up and voice our concerns, and maintaining a proactive and adaptable mindset while practicing patience is crucial. I derive this insight from your own experiences as well. How did you handle resistance from senior leadership during this transition? And did you use roles like agile coaches or value stream managers to help you?”

My response was, “Handling resistance was no walk in the park. I often stood alone against new C-Level team members and board members. The key was to confront challenges logically and professionally. I relied heavily on my ability to present compelling examples and a clear vision of the desired outcomes based on the models and measures that properly match the practices. If you can, it’s crucial to stay proactive and adaptable. Find those enlightened stakeholders; their support can be a game-changer.”

This conversation highlights the difficulties of leadership during times of organizational change. It underscores the significance of being resilient, thinking strategically, and having the courage to advocate for change, even when facing opposition from top management, who may require more comprehension or be hesitant to adopt new approaches.

Case Two: Purpose over Process

I spoke with an experienced leader in agile transformation at a well-known global beverage company. During our conversation, we discussed our experiences with digital transformation. She shared a challenge she encountered with a senior leader who became frustrated with their agile transformation and the use of Scrum for software delivery. To address this, the leader switched their approach to Kanban, focusing more on tools to overcome the obstacles hindering their shift to agile delivery methods rather than dwelling on the reasons behind the struggle.

“Thank you once again for your time yesterday. I hope it’s all right if I email you now while it’s still fresh in my mind. During our conversation, you mentioned that you were a few years into the transformation when you faced a major disruption. You also mentioned that most, if not all, teams start with Scrum before transitioning to a version of Kanban. I would like to know how long your teams typically use Scrum before transitioning. Additionally, I’m interested in learning about the deciding factors for the transition to Kanban, especially if they vary. Most importantly, we also discussed some leaders’ challenges in embracing agile and letting go of command and control. I would appreciate any recommendations or resources you may have to help bring them along.”

The executive leader’s challenges in adopting Agile stem from focusing on tools rather than addressing underlying issues. A better understanding of Agile principles is necessary. They should explore the root causes behind the struggles with Scrum, uncertainties in transitioning, and the difficulty of shifting away from a command-and-control mindset. Furthermore, effective navigation of these obstacles requires more leadership support and education.

Case Three:  Beyond Misconceptions

In 2020, a Scrum Master shared her experience working at a prominent for-profit educational institution that adopted SAFe as their guiding framework. There was friction coming from the CIO who was driving the initiative. She recounted instances where team members were reassigned to new roles without adequate training, resulting in their struggles to embrace agility. The most surprising aspect of our conversations was when she disclosed that the CIO attributed a failing or struggling transformation to a lack of understanding of the developer role among all team members. Instead of investing in targeted training for each team role, he mandated everyone attend a several-week coding boot camp. Even a product owner in her 60s was forced to learn coding instead of being offered additional training for her particular role. This training was expensive in cost and time.

The CIO believed that a need for more understanding of the developer role among team members caused the struggling transformation. However, this reflects a narrow interpretation of agility. Agile transformations are not just about technical skills or specific roles. They are about embracing collaboration, continuous improvement, and customer-centricity. The CIO’s misunderstanding of the Agile mindset, inadequate role-specific training, one-size-fits-all approach, neglect of the human aspect of transformation, resource misallocation, and lack of Agile leadership all contributed to the failure of the Agile transformation in this scenario.

This ineffective approach hinders  progress by excessively focusing on tools and roles, disconnecting from the true essence of agility. Led by an authoritative leader and an unconventional version of Scrum, it demonstrates a lack of respect for team members. Unfortunately, this behavior is observed in many leaders within larger organizations.

Case Four: Productivity Fallacy

The recent McKenzie article on measuring developer performance, released in August, has ignited a heated debate. It raises concerns that senior leaders, who may need more familiarity and experience with modern delivery practices, must be more discerning when interpreting this article. The emphasis on individual metrics aligns differently with a team-oriented, outcome-driven approach. An interesting point is that the McKenzie article was published about a week after I submitted my first two summer talks on team productivity over individual output focus, as referenced in the abovementioned example.

Recently, I experienced an organization undergoing valuation efforts to secure next-level funding or attract investment through acquisition from a larger organization. As part of the valuation, the investors mandated a Sema code scan (from the Sema website: Serving CTOs, CIOs, and other Senior Engineering leaders, plus the C-Suite and Boards of Directors, with comprehensive codebase metrics).

The main concern was how assessors perceived the team’s capability and productivity. The analysis focused on identifying key team members based on code commits. This data only considers coding contributions. The list of “top developers” or valuable team members, as perceived by the investor, was inaccurate. Several crucial team members essential to the organization were ranked outside the top 10. I have been discussing the impact of evaluating performance solely based on code commits and similar metrics over the past few years. Today, cross-functional teams deliver solutions, not individual developers. The key is team productivity and outcomes over individual output.

When businesses are presented with metrics, they are often misused, with a tendency to prioritize individual performance over team results. This poses a risk as team members may prioritize actions that boost their numbers rather than focusing on team outcomes and overall improvements. Consequently, this can lead to subpar output being delivered.

If your organization still operates in functional groups, it may be acceptable. However, focusing more on metrics related to the system, flow of work, and team performance is essential. Acknowledging that developers contribute through code commits and mentoring, collaboration, design, architecture, and problem-solving discussions is crucial. In today’s cross-functional agile teams, developers have broader responsibilities beyond just writing code. In such cases, the team collectively delivers software and value rather than individual contributions.

Understanding the Legacy Leaders’ Dilemma

Experienced leaders occupying critical senior leadership, executive, and board roles have succeeded and found solace in traditional methods (refer to the supplement at the end of this article for a detailed explanation of these traditional methods). Familiar with their mastered ways of working, they need assistance navigating the paradigm shift brought by Agile and DevOps. Their resistance is not just a matter of preference but is deeply intertwined with ego, vulnerability (they are supposed to be the experts), and a fear of the unknown. This reluctance to embrace change becomes a significant roadblock in the journey toward digital transformation.

The Detrimental Impact of Legacy Metrics

Much of my experience and conversations surface the demand to use legacy metrics that do not fit team-based practices and models. The insistence on using metrics that focus on individual productivity, tailored for past practices, has a cascading negative effect on modern teams:

  • Eroding Team Dynamics: Modern roles like software engineers in cross-functional teams rely on collaboration. Evaluating individuals based on outdated productivity metrics undermines this collective effort.
  • Misaligned Incentives: Old metrics create misaligned incentives, leading to a competitive atmosphere that damages morale and team spirit.
  • Stifling Innovation: Focusing on narrow, output-focused metrics discourages experimentation and adaptability, hindering personal growth and team innovation.
  • Inaccurate Assessment: Roles crucial in enabling the team, like agile coaches or value stream managers, are undervalued as their contributions don’t fit traditional productivity metrics.
  • Resistance to Change: Using outdated metrics fuels resistance, creating friction and potentially derailing transformation efforts.
  • Impeding Talent Retention: Adherence to outdated metrics makes an organization less attractive, potentially leading to losing talent who seek dynamic and collaborative work environments.

The Humbling Journey of Adaptation

Adapting to new methods requires leaders to embark on a humbling journey of unlearning and relearning. It’s a process that can bruise egos but is essential for growth and development. This adaptation is about acquiring new skills and reshaping one’s understanding of leadership and success.

The Crucial Role of Senior Stakeholder Commitment

Unsuccessful Agile transformations often highlight the importance of more substantial commitment from senior stakeholders in fostering emerging knowledge and skills. This lack of alignment not only slows down progress but also creates unnecessary friction within the organization.

Conclusion

Without enlightened leadership at the top, there is little hope for change. The cases in this article are just a small example of dysfunctional leadership and a misinterpretation of agile principles. It’s challenging to feel like we’re progressing or improving the situation under such leadership.

Adapting to change can be challenging, especially when legacy senior leaders create friction in modern digital transformation practices. It’s surprising how often this conversation comes up, even after over a decade of digital transformation. The fact that these conversations still happen today highlights the importance of continuous learning and the crucial role of professionals in guiding this transition.

For a transformation to succeed, leaders must be willing to evolve and embrace new paradigms while letting go of outdated practices. Thriving in this dynamic landscape requires committed and adaptable leadership eager to acquire new knowledge and support transformative efforts from the top down. Only then can we fully unleash the true potential of Agile, Lean, and DevOps practices.

Poking Holes

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

Let’s talk: [email protected]

Software Delivery Teams, Deadlines, and the Challenge of Providing Reliable Estimates

by

4 min read

During our end-of-year annual sales kick-off conference this week, I witnessed a leader presenting our roadmap to the sales and marketing teams. One of the highlights was announcing the expected delivery date for a new core product in 2024. This announcement was the first I had heard of this expectation, and now expectations have been communicated to the organization. I quickly jotted down a note, “How comfortable are we in announcing this delivery date?“. I thought about my past experiences and the ongoing discussions about the challenges our delivery teams face with deadlines and estimates, even in the Agile era, and it inspired me to create this short post about providing estimates.

In my role and experience, I mentor teams and technical leads. One common issue they face is their reluctance and need for more confidence in providing estimates. The problem I am addressing is the teams’ hesitation or lack of confidence in estimating and sharing a practice that has worked well for me.

For the past 24 years, I have been responsible for providing estimates. I have given estimates for past and current delivery practices. I also aim to support team leads who may feel uncomfortable giving forecasts due to the level of accountability and uncertainties involved. It’s important to note that these questions are typically asked when teams have the least information about the problem they are trying to solve.

Love-hate relationship with estimations

Exploring software estimation dynamics, I have a love-hate relationship with it. Estimation’s psychological impact on teams is complex. While necessary, estimates often face misinterpretation and misuse by management. Communicating probability confidence is a solution. It eases team pressures and brings realism to management. Building buffers and resilience is valuable. Incorporating contingencies is practical, not guilty. Teams intend well, but estimates become stringent targets, fueling fear of commitments. Incremental delivery and feedback increase confidence. Iterative processes refine accuracy and empower teams to adjust timelines based on real-world feedback. Converting unknowns to knowns enhances estimation accuracy, team confidence, and management of expectations. Flexibility and adaptability are crucial in software estimation.

Estimates, regardless of delivery practices

Despite our delivery practices, providing estimates remains crucial. Leaders rely on estimates to set strategy and make informed economic decisions, especially when faced with resource constraints. They are making calculated bets on the future.

For the organization to plan and make decisions, delivery teams must provide estimates regardless of their delivery practices (waterfall, agile, or others). Leaders rely on the target date and hold teams responsible for meeting the estimated deadline.

Many teams hesitate to give estimates because they feel pressured to be precise. They also feel the burden of uncertainty and are accountable to the organization when estimates are shared widely, the sales team counts on the feature, and customers expect to utilize it.

I recommend always giving a probability when providing an estimate. We are X percent confident about meeting the target date based on available information and uncertainties. Considering what we know and potential unknowns, we have a 40% confidence level for our current forecast or estimate.

Probabilistic estimations

I recommend using probabilistic estimates as a practice that has been effective when providing estimates. Can we provide a date within a probabilistic range?

Team: At this point, we are x% confident in our estimate.

Product: What level (or percentage) of risk are we willing to assume when communicating delivery deadlines or dates based on the probability of the estimate?

Probabilistic estimations are not just about predicting dates but about understanding the degree of confidence in these predictions. Here’s why this is crucial:

  • Reduced Pressure for Pinpoint Accuracy: Traditional estimation methods can put undue pressure on teams to provide precise estimates right from the beginning, even when all variables are unknown. On the other hand, using probabilistic estimations allows for a range of outcomes based on the available information at different points in time. This approach acknowledges the complexity and uncertainty in software projects, relieving the team from the unrealistic expectation of pinpoint accuracy.
  • Shift from Certainty to Probability: Shifting the focus from absolute dates and numbers to probabilities and ranges can reduce the stress of committing to specific deadlines or budgets. Teams can express their confidence in terms that better reflect the reality of software development, where uncertainty is always present.
  • Increased Sense of Control and Ownership: When teams can provide accurate estimates that align with their understanding and confidence, they feel more in control and accountable for their work. This sense of ownership often increases job satisfaction and motivation as teams perceive their expertise and knowledge to be valued and effectively utilized.
  • Encouragement of Open and Honest Communication: Probabilistic estimations create an environment that encourages expressing uncertainty, fostering honest and productive discussions about project timelines, scopes, and risks. This approach helps prevent a culture of over-commitment and under-delivery.
  • Reduction in Stress and Burnout: By setting realistic expectations, probabilistic estimations can help reduce stress and burnout caused by aggressive and often unattainable deadlines. This approach supports a balanced workload and helps maintain a healthier work-life balance for the team.

Incorporating probabilistic estimations into product delivery practices improves the accuracy and reliability of project planning. It also promotes the mental well-being of teams by creating a realistic, transparent, and pressure-free environment. 

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.

Unpacking The State of Value Stream Management Report 2023

by

3 min read

VSM Adoption

In December 2020, I introduced Value Stream Management (VSM) and Flow Metrics to our teams. Our journey of adoption has been a continuous learning experience, drawing insights from the Value Stream Management Consortium and other industry leaders as we exchange experiences. Over the past three years since our initial adoption, VSM has made significant strides in the industry.

VSMC State of Value Stream Management Report

Since 2021, The VSM Consortium1 annual State of Value Stream Management Report2 offers a comprehensive overview of the recent evolution in this field. This year’s report covers valuable insights that deserve careful analysis and distillation. I’d like to highlight three aspects that have captured my attention regarding measuring and prioritizing value and the accompanying advice provided.

Measuring Value:

  1. Value Reporting Lines Matter (slide 19): Teams reporting to CEOs indicate higher Performance and a closer connection between software engineering teams and the rest of the organization.
  2. Value Metrics (slide 20): Organizations prioritize business over customer metrics. Typical metrics include sales/revenue, active users, feature usage, NPS, and profit margin.
  3. Key Practices (slide 21): The report highlights the importance of measuring the value achieved, taking into account observability and customizing metrics based on the nature of the work.

Leading with Value:

  1. Visualizing the Entire Organization as a Value Stream Network is Key (slide 25): According to the data, one-third of the respondents have visually documented their organization as a network of interconnected value streams. The findings indicate that higher-performing organizations and larger companies are inclined to perceive their organization as a value stream network.
  2. VSM Implementation Roadmap (slides 23-24): VSM practices have evolved, and organizations can use an implementation roadmap to track progress. The “Connect” step has experienced significant growth. Respondents who complete the ‘Connect’ steps are 5-10% likelier to achieve a lead time of less than one week. Conversely, those who haven’t completed any roadmap steps are over three times as likely to have the longest lead time, exceeding three months, compared to those who have completed any step—and four times more likely than those who completed the Connect steps. Next is the inclusion of the Assess stage in the roadmap this year. Establishing a baseline of the current state when starting a journey and measuring progress as an organization progresses is important. This new step provides a comprehensive understanding of the journey and enables effective progress monitoring.
  3. Organizational Performance (slide 26): VSM adoption drives organizational Performance by aligning teams, making work visible, and using insights for continuous improvement.

Advice Section (slide 27):

  1. For Change Agents: Emphasizes the importance of visualizing work, taking data-driven actions, focusing on value realization, and understanding that flow and value realization are equally important.
  2. For CXOs: Advocates for aligning teams, visualizing value stream networks, connecting product management and software engineering, and adopting a data and insight-driven approach.
  3. For Product Creators and Software Engineering: Encouraging collaboration between product creators and software engineers, adopting VSM as a framework, and having a dedicated value stream lead (something we will consider for 2024).

Final Thought

This report sheds light on the evolving world of Value Stream Management, its impact on organizational dynamics, and its importance in the broader business landscape.

The adoption of Value Stream Management (VSM) is gaining momentum, and organizations must stay current with this trend. The VSM Consortium is a fantastic hub for VSM knowledge, education, and assistance. It’s an invaluable resource for anyone looking to dive into the world of VSM!

References:

  1. Value Stream Management Consortium, https://vsmconsortium.thinkific.com/
  2. The State of Value Stream Management Report 2023, https://www.vsmconsortium.org/state-of-value-stream-management-reports

Poking Holes

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

Let’s talk: [email protected]

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

Beyond Features: A Software Engineer’s Code of Conduct for Delivering Impactful Product Outcomes

by

3 min read

“The software industry is a great example of an industry where the responsible thing to do is not always the easy thing to do.” – Bill Gates

and

“With great power comes great responsibility.” – Uncle Ben, Spider-Man

When you are hired to work for someone else, it is essential to prioritize their interests in your work. The organization, its customers, and your team trust that you have their interests at heart.

In the rapidly evolving world of software development and digital product companies investing in digital transformation, cross-functional product delivery teams often grapple with effectively managing four critical aspects of their products: features, technical debt, risks (security), and defects. 

Moving Beyond the Feature Factory Mindset Today

Despite the widespread adoption of agile, lean, and DevOps practices, an excessive focus on delivering new features can lead to technical debt and deprioritized defects, ultimately hampering the team’s efforts and overall product quality. This misalignment of priorities and culture is often the result of overdominant voices influencing the end product.

Showcasing Security, Quality, and Performance as Core Product Features

One solution to this challenge lies in cultivating a team mindset and culture that values risk (security), quality, and performance (technical debt) as integral aspects of the products delivered to customers. As one Product Manager insightfully mentioned in a podcast, he and his team view quality, performance, and security as core “features” of their products.

To effect lasting change in team culture, we must foster collaboration and alignment across all roles, working together towards a shared purpose and goals. This balanced approach to feature development, technical debt management, risk mitigation, and defect resolution can lead to a more purposeful alignment of goals and exceptional customer products.

Introducing the Software Engineer’s Code of Conduct and Responsibilities to Product Delivery

As a software engineer hired to craft and deliver software on behalf of my team, my organization, and our customers, I will:

  1. Goal Alignment, Outcome Clarity, and Realization: Developers should ensure their work aligns with broader organizational goals and clearly understand desired outcomes before starting any task. Work items include features, technical debt, defects, and security risks. Clarity promotes alignment, purpose, and direction, ensuring every effort contributes to the organization’s strategic objectives. Additionally, clarity involves evaluating results after project completion. Teams should compare actual metrics with expected ones to assess the impact of their efforts. This reflective process fosters continuous improvement, ensuring that work advances progress rather than just increasing output.
  2. Strive for excellence: I will produce high-quality implementations using the best of my abilities and skills at the time, and I will speak up when quality is compromised or overlooked.
  3. Foster collaboration: Actively collaborate with team members to share knowledge and achieve collective goals, recognizing that teams – not individuals – deliver software.
  4. Embrace testing and continuous improvement: Implement all required automated tests, follow test-driven development practices, and actively participate in pull request code reviews to ensure high code quality and incorporate feedback before deploying to production.
  5. Prioritize security: Ensure code is secure and adheres to best practices to minimize risks and vulnerabilities before production and address any existing vulnerabilities in the code I work on as part of my daily routine.
  6. Manage technical debt: Regularly refactor code to maintain readability, optimize performance, and minimize accumulated technical debt, speaking up for any debt that is being ignored.
  7. Use my voice: Feel safe speaking out when the other five responsibilities are neglected, and seek alignment from the team to understand why.
  8. Protect intellectual property and responsibly use AI: I recognize the benefits of leveraging AI in software development. However, I will act responsibly to protect my organization’s intellectual property. I will not share proprietary information or code without proper authorization and will ensure that AI technologies are used ethically and in compliance with applicable regulations.

Adopting these principles for software engineers working in cross-functional teams can help prioritize a balanced approach during product planning. This will lead to consistent production of high-quality, secure, and performant software while avoiding a backlog of risks, defects, and technical debt that can result from constantly adding new features.

Poking Holes

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

Let’s talk: [email protected]

Related Posts