Rethink Your Understanding

Transforming Software Delivery

Product Delivery

Beyond Facilitation: The Agile Leader’s Place in Cross-Functional Team Dynamics

by

9 min read

“Alignment is a force multiplier.”

― Gereon Hermkes

I was invited recently to a meeting with Agile Leaders, Product Owners, and various cross-functional roles. The aim is to establish a regular meeting among team members to align on the reasoning behind our team structures, identify who leads the delivery, and clarify team roles. Following a word cloud exercise, it became evident that team members were not on the same page regarding why our teams are structured as they are, the essence of agility, diverse perspectives on metrics, and, notably, a product owner questioning the value of the Agile Leadership role on the team or not understanding the role responsibilities. Besides administrative tasks and facilitation, what are the responsibilities of a Scrum Master or Agile Leader?

What problem am I trying to address? Team alignment: should we have agile leaders within teams? If yes, what additional responsibilities do they carry beyond team facilitating rituals?

Questioning the Agile Leader role is not uncommon. More recently, certain organizations have dismissed these team members to cut costs, failing to recognize the significance of their role. They have redistributed some responsibilities among the remaining agile team members.

Cross-functional delivery teams striving for enhanced alignment on Agile and Lean practices, team purpose, responsibilities, and the Agile leader’s role may encounter hurdles. Conversations within my extensive network in the past two years and themes in various podcasts have shed light on the dynamic between Product Managers/Owners and Agile Leaders/Scrum Masters. In misaligned teams, Product Owners often scrutinize the roles of Scrum Masters or Agile Leaders, the team itself, its practices, and the accountability for the team’s deliverables.

Two books, among many that shaped my perspective

In Agile software development, balancing various responsibilities and understanding the unique team roles is crucial to fostering an environment that encourages efficiency, innovation, and adaptability. This article synthesizes insights from Agile methodologies, “Team Topologies” by Matthew Skelton and Manuel Pais, and “Project to Product” by Mik Kersten, offering a comprehensive view on enhancing team dynamics for optimal performance. Here, we delve into the essence of Agile leadership, team composition, challenges linked to dominant product management, and the vital importance of harmonizing the four work types: features, defects, technical debt, and risk.

 “Team Topologies” emphasizes the importance of intentionally designing team structures and interactions to optimize workflows and enhance the software delivery process. This approach is fundamentally aligned with the principles of Agile methodology, where the focus is on creating teams that can operate with high autonomy, clear purpose, and minimal necessary interaction to reduce cognitive load and foster innovation.

The book introduces four fundamental team types: Stream-aligned teams, Enabling teams, Complicated Subsystem teams, and Platform teams. Each serves a unique purpose within the organization, from directly delivering value to customers to providing specialized knowledge or infrastructure that supports other teams. This structured approach to organizing teams underlines the necessity of having an Agile leader who is not only versed in facilitating collaboration and alignment but also skilled in navigating the team through the complexities of modern software development environments.

Reducing the unnecessary cognitive burden on teams, a fundamental concept elucidated in “Team Topologies,” clarifies why a product manager, already juggling multiple responsibilities, cannot effectively assume the role of an Agile leader. Product managers are crucial in shaping the product vision, aligning it with market demands, and focusing on customer-centric features and growth. On the other hand, Agile leaders foster team dialogues, ensuring a comprehensive understanding of the organization’s current and future states and that of the customer and system. This ensures conversations encompassing feature development, technical debt management, quality enhancement, and risk mitigation. By adopting this approach, the team’s efforts are channeled toward sustainable and high-quality software delivery.

“Project to Product” by Mik Kersten, enriches our understanding of Agile team dynamics and the importance of Agile leadership, especially in balancing different types of work. Kersten’s book emphasizes modern businesses need to adopt a continuous product-focused value stream to avoid becoming obsolete, much like Nokia or Blockbuster did. This approach aligns with Agile principles by focusing on delivering end-to-end value to customers, underscoring the critical role of Agile leaders in facilitating this process.

Kersten introduces the Flow Framework, which models the entire organization as a value stream, highlighting four types of work: features, defects, technical debt, and risk. This framework complements our discussion by providing a structured method for balancing these work types, ensuring that teams stay focused on one at the expense of others. A dominant product manager might skew the team’s efforts towards feature development, neglecting technical debt and risk mitigation. However, with their unbiased perspective and dedication to the team’s overall health, Agile leaders are crucial for ensuring that all types of work are addressed appropriately, aligning with organizational goals and the system’s performance.

“Project to Product” also challenges outdated business and technology ideas, advocating a shift from project-oriented management to a product-centric approach. This shift is essential for fostering Agile teams that are adaptable, collaborative, and capable of delivering continuous value. The book’s emphasis on avoiding local optimization and focusing on the end-to-end value stream resonates with the Agile leadership role in facilitating a balanced approach to work prioritization.

Incorporating Kersten’s insights, it becomes evident that Agile leadership is not just about facilitating daily stand-ups or managing sprints; it’s about embracing a broader vision that aligns team structures, software architecture, and value stream architecture. This alignment is essential for creating high-performing teams that can navigate the complexities of modern software development, delivering value rapidly and effectively while maintaining the health and performance of the entire system.

The conflation of product management with Agile leadership is a common pitfall 

An overbearing product manager, assuming control over the team and dictating priorities based on a singular focus on growth, can stifle the very essence of Agile methodology. Such an approach undermines the team’s autonomy and creativity, jeopardizing the product’s long-term sustainability and quality. It creates a culture of mistrust and resentment, diminishes morale, and disrupts the collaborative dynamics essential for Agile success.

The balance and interplay among Agile leadership, product management, and technical leadership are where the magic of Agile truly happens. Agile leaders ensure that all types of work — features, technical debt, quality assurance, and risk mitigation — are balanced and prioritized according to the team’s collective understanding of organizational goals. This balanced approach, guided by Agile leadership, empowers teams to deliver high-quality products that meet customer needs while fostering an environment of continuous improvement and adaptation.

Agile leadership, like product ownership or the technical leader, is not about hierarchical control but about enabling a culture of collaboration, empowerment, and excellence. It’s about guiding teams through the complexities of software development, ensuring that every member feels valued, heard, and motivated to contribute their best. When product owners or managers question their role, Agile leaders have a compelling narrative to share — one that underscores their critical contribution to nurturing high-performing teams that are agile, resilient, and aligned with the organization’s strategic goals.

The strength of Agile software development lies in its emphasis on people, interactions, and customer-centric outcomes. By affirming the unique value of Agile leadership, organizations can ensure that their teams are efficient and productive, engaged, innovative, and aligned with a shared vision for success. This holistic approach to team dynamics and delivery sets Agile apart, making it an indispensable methodology for achieving excellence in today’s fast-paced and ever-evolving software development landscape.

Understanding our Agile team structure

Agile teams are intentionally cross-functional, comprising diverse skill sets and expertise to ensure that the team is self-sufficient in delivering value. This structure is designed to provide all the skills needed to deliver value in a team, foster collaboration, encourage shared accountability, and facilitate rapid responses to change while focusing on delivering customer value. 

Every team member contributes unique value, whether developers, quality assurance specialists, or product managers. While we require various specific roles, no single role outweighs the importance of others. Instead, Agile thrives on peer-to-peer interaction, underscoring the importance of every team member being seen as equals. This egalitarian approach eliminates silos, encourages open communication, and leverages the collective wisdom of the team to overcome challenges and seize opportunities.

The ecosystem of roles

In a high-performing department, Agile teams, renowned for their collaborative approach, typically consist of developers, quality assurance specialists, product managers, and Agile leaders like Scrum Masters. This diverse structure promotes autonomy and swift adaptation to change, highlighting peer-to-peer engagement and transparent communication. The power of Agile lies in breaking down barriers and harnessing shared expertise.

The Agile Leadership role

At the core of the Agile framework lies the Agile leader. This role can be a topic of debate, especially when compared to dominant product management. The Agile leader is not another cog in the wheel of task execution but a pivotal force that empowers the team to reach its full potential. Unlike product managers, who focus on market demands and product features, Agile leaders bring unique skills to nurture team health, streamline processes, and uphold Agile values. The Agile leader operates from a vantage point of neutrality, emphasizing team health, process efficiency, and adherence to Agile principles. They act as the team’s compass in navigating work complexities, stressing collaboration, team coherence in four types of work, problem-solving, and continuous improvement. 

  1. Delivery efficiency and optimization: Measuring flow (delivery efficiency) and realization (value impact) ensures you’re building the right things and building them efficiently. Operational efficiency improvements must focus on both. As Value Stream Management subject matter experts, agile leaders help the team improve delivery efficiency and flow. They can help the teams identify bottlenecks and waste and improve flow. They analyze the data and bring the conversations to the team to understand bottlenecks and experiment with improvements. They challenge product managers or owners to define and track anticipated outcomes to avoid misalignment with broader goals, championing the importance of feedback loops in verifying value realization and “closing the loop.”
  2. Facilitation Skills: Agile leaders are trained in facilitation techniques to conduct effective meetings, workshops, and Agile ceremonies. This ensures that team interactions are productive, engaging, and aligned with Agile principles.
  3. Coaching and Mentoring: A significant part of Agile leadership training involves coaching and mentoring skills. Agile leaders learn how to coach team members, foster a growth mindset, and facilitate personal and professional development within the team.
  4. Conflict Resolution: Agile leaders are equipped with conflict resolution techniques to navigate and mitigate interpersonal conflicts within the team. This training is crucial for maintaining a collaborative team environment.
  5. Change Management: Agile transformation often involves significant changes in team dynamics and organizational culture. Agile leaders are trained in change management strategies to smoothly transition teams to Agile ways of working, ensuring buy-in and minimizing resistance.
  6. Neutrality: The Agile leader is the team’s compass, steering the group through the complexities of project delivery without bias towards any specific type of work. They aim to ensure the team can perform at its best, irrespective of the work type—new features, technical debt, bug fixes, or risk mitigation.
  7. Removing Impediments: Agile leaders are skilled in identifying and removing obstacles that hinder the team’s progress. Their sole incentive is the team’s success, which allows them to act impartially and decisively in addressing challenges that impede efficiency and productivity.
  8. Promoting Agile Values and Practices: Through coaching and mentoring, Agile leaders instill and reinforce Agile values within the team, promoting practices that enhance collaboration, continuous improvement, and customer satisfaction. They are the custodians of Agile ceremonies, ensuring that these practices are meaningful and contribute to the team’s growth and success.
  9. Ensuring Collaboration and Consensus: In fostering a collaborative team environment, Agile leaders ensure that decisions are made collectively, with input from all team members. This consensus-building approach ensures alignment with organizational goals and harnesses the team’s collective expertise.

On the flip side, the role of the product manager or owner is distinct yet crucial. They act as the link between customer needs, business goals, and the development team. Their main aim is the product’s success — establishing the vision, deciding on features, and ensuring deliverables meet market demands. While focusing on product and growth is key, it can sometimes narrow the perspective by prioritizing feature development over critical aspects like addressing technical debt, ensuring product quality, and managing risks.

Conclusion

Your choice is how you organize your teams, considering that context varies and there is no one-size-fits-all approach. I acknowledge the importance of the Agile Leadership role in propelling our team to success. The alignment among Agile leadership, product management, and technical proficiency is crucial for top-tier Agile teams. Agile leaders foster team engagement and advancement by leveraging data insights, assessing efficiency metrics, handling team dynamics, promoting team coherence on objectives, and facilitating necessary discussions for teams to align with current requirements and establish work priorities. Collaborating, embracing shared responsibility, and managing diverse work types are vital for team efficiency and focusing on delivering sustainable, high-caliber software solutions. Making decisions on features, defects, technical debt, and risks in line with organizational objectives is essential for the overall health and performance of systems and solutions.

Related Posts

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.

Pressures of Strategic Talent Cost Rebalancing in Agile Teams: Optimizing Global Geographical Costs for Cohesion and Efficiency

by

10 min read

“If you choose not to leverage global talent and economic benefits while your competitors do, you’re essentially steering your business towards obsolescence.”

adaptation of Lee Kuan Yew’s quote regarding outsourcing

Updated May 15, 2024:

I published this article in February 2024. Recently, a senior leader in my network sought help addressing concerns about his request for a “second shift”—working hours aligned with US time zones for talent located 7 to 9 hours ahead to shift talent in two of his department’s cross-functional delivery teams.

His broader organization informed this leader that finding talent in this region willing to work off-hour shifts to align with US hours is challenging. This leader’s goal is eventually to relocate the entire cross-functional teams to a more cost-effective region, which is also my recommendation. However, given current conditions, he shifted only specific roles from existing teams to the new region (specifically software developers). These team members will need to work off-hours that match US working hours. I do not recommend this approach and believe entire teams should be in locations that foster collaboration. Still, for his specific case, I revisited my article to create a response to his organization’s concerns. 

Here is the message he sent me for help with his response. I changed his name and location to keep him anonymous.

Hi Mark,

Questions are coming up about why we need complete overlap between County/Region X and the United States instead of just a few hours. I’d like to explain why our development process differs from Organization Y (our parent organization). Please send us a justification to help get off-hours approved. Please get it to us by Monday.

What do you think about having a 2-hour overlap instead of the full 8 hours? Also, if we move one or two managers over there, can they operate independently on that country’s/region’s time? Please include this in the write-up as well.

I sent him the following response summarized from this article:

For teams not in the same location or close time zones, without delving deep into organizational design, we have two key structures impacting software delivery: functional teams, organized by specialized skills, and cross-functional teams. Our approach leverages the benefits of the cross-functional team structure.

These small, cross-functional units comprise the minimum roles required to design and deliver software with maximum autonomy, minimizing reliance on external teams or resources and reducing dependencies.

For a cross-functional team to succeed, team members must communicate well, collaborate effectively, and be available. Even though members work independently, teams in different locations should have at least three or four hours of overlap to create a successful working environment.

Team rituals that rely on real-time collaboration may suffer when impacted by time differences. Question and answer sessions during planning, grooming, design reviews, code assessments, or pair programming are crucial for maintaining high code standards and fostering knowledge exchange within agile teams. Substantial time variations to facilitate additional asynchronous collaboration can pose unique challenges:

  • Delayed Code Review
  • Slower Issue Resolution
  • Planning meetings, Design Meetings, Reviews, and Retrospectives
  • Mentoring, Pair Programming, and Swarming

Delays in collaboration and resolving issues can extend delivery times and lower team efficiency, especially for US-based team members collaborating across different time zones. Overlapping working hours can prevent longer delivery schedules and downtime for team members waiting on feedback or approvals, slowing the team’s response to customer needs and market changes.

Original article

This article assumes that your organization has transformed team delivery and design practices. Instead of functional teams based on skills, it focuses on small, cross-functional, and potentially long-lived teams. There are various variations of these team topologies.

Experience

During my 24-year career in software and technology, I’ve seen organizations try to achieve cost synergies by outsourcing and near-shoring. However, due to delays and project management issues, they often bring the talent back in-house, only to reconsider outsourcing in the future due to the higher costs associated with US-based software engineers.

Recently, I discussed dealing with similar pressures with someone in my network. The organization is pressured to achieve specific cost savings by replacing a set number of higher-cost team members with more cost-effective team members from different, more cost-effective locations.

In the changing global business world, larger entities’ acquisition of US-based software companies has made operational cost optimization a critical strategic planning focus. This emphasis on cost synergy actions and efficiency has prompted considerations of balancing global talent, aiming to take advantage of the financial benefits of staffing in more economically favorable locations. At first, the senior leadership suggested a basic concept: if teams in the US face attrition, they would replace the team members with more cost-effective members globally.
This article delves into the challenges of a strategy where your team structure shifts to small cross-functional teams. It suggests a nuanced approach focusing on relocating entire teams to uphold agile principles. The discussion extends to impacts on code review, collaboration, and delivery efficiency.

Reevaluating the Initial Strategy

The senior leadership’s proposal to fill vacancies left by US team members with individuals from cost-effective locations across significantly different time zones emphasizes the potential risks to team dynamics, collaboration, and delivery efficiencies. While cost-effectiveness is crucial, this approach neglects the importance of cohesive, immediate interaction and a shared sense of purpose that fuels agile teams. You risk losing the agility to adapt swiftly to changes in the ecosystem, priorities, or market dynamics, depriving yourself of the ability to be responsive and noble. This inherent delay contributes to increased costs and time constraints.

The Challenge of Integrating Global Talent

“The question is really about the bandwidth of human interactions.”

Brian Graham

The following applies to organizations with entities in more cost-favorable countries or organizations with an outsourcing model. More and more outsourcing service providers are offering entire agile teams.

The main concern in global talent rebalancing lies in something other than remote work, as both companies already have remote solid cultures. Instead, the potential disruption to team bonding, daily synchronous collaboration, and delivery efficiencies are paramount. Introducing team members from different time zones with an 8- to 12-hour difference can significantly impact these critical aspects of software development, especially for agile teams known for their cohesive collaboration and quick turnarounds.

Small cross-functional delivery team model examples:

Impact on Team Rituals and Collaboration

Team rituals that rely on real-time collaboration may suffer when impacted by time differences. Question and answer sessions during planning, grooming, design reviews, code assessments, or pair programming are crucial for maintaining high code standards and fostering knowledge exchange within agile teams. Nevertheless, overcoming the hurdles posed by substantial time variations to facilitate additional asynchronous collaboration can pose unique challenges:

  • Delayed Code Reviews: Conducting reviews is crucial to uphold coding standards and ensure code quality. However, the asynchronous nature of these reviews across different time zones can result in longer lead times for pull requests, ultimately slowing down the development process.
  • Slower Issue Resolution: The ability to quickly address and rectify discovered issues is compromised, extending the feedback loop and potentially allowing defects to persist longer than necessary.
  • Planning meetings, Design Meetings, Reviews, and Retrospectives: Team members need to have overlapping working hours to ensure they get all the benefits of real-time planning discussions, design meetings, and retrospectives. While some of these can be handled asynchronously using tools like Slack or a wiki page, the collaboration could be more effective, and there may be delays in responses.
  • Mentoring, Pair Programming, and Swarming: The option to engage in pair programming or swarming to address intricate problems or explore new tasks may no longer be available.

Implications for Delivery Time and Team Efficiency

Delays in collaboration and issue resolution can lead to extended delivery timelines and reduced team efficiency, especially for United States-based team members working with counterparts in different time zones. Misaligned working hours may result in prolonged delivery schedules and downtime for team members awaiting feedback or approvals, hampering the team’s responsiveness to customer needs and market dynamics.

Considering the Argument for Lower Labor Costs

Cost synergies are highly prized in an offshore model for several reasons. The underlying belief is that they have the potential to result in equivalent delivery performance and reduced perceived costs compared to anticipated costs. When considering employees versus outsourcing to a service provider, managing balance sheets using contractors is often simpler due to the perception of them as variable costs. Contractors may appear more advantageous when examining the fully burdened cost associated with employees. However, a common mistake is expecting contractors or service providers to work as fast and effectively as employees, which is usually different based on my experience and several others in my network. Furthermore, costs can come up due to time-sliced individuals, such as team leads serving as a go-between between you and the delivery teams.

Emotional issues and cultural nuances can have a profound impact on team unity. At DHL, I gained invaluable insights into the power of globally diverse teams working in similar time zones, specifically the Integration and EDI teams operating during US hours.

I shared this article draft for feedback with Bob Langan, a former senior leader at DHL between 2003 and 2014, now retired, and a trusted mentor who offered feedback on the challenges posed by the “follow the sun” model and subsequent offshore/onshore approaches. Despite the higher costs of US employees’ salaries, we often worked far more than the standard 40-hour workweek. We also had fewer national/state holidays and fewer annual vacation days. In contrast, European and Asian colleagues tended to work fewer hours weekly as a general practice, taking longer to achieve the same results as the US teams. DHL Delivery teams charged the commercial business units for their time on a daily rate defined by resource (annual salary / potential person-days). Through analysis, Bob discovered that US teams were frequently as, if not more, cost-effective in terms of cost of delivery due to fewer person-days being consumed and many more potential person-days to work. While this perspective may be different from your current considerations, it was crucial in advocating for maintaining a US team in the initial phases.

The discussion of reduced expenses is beyond the scope of this article. Times have changed. Please feel free to do your research on the current data trends.1,2

Emphasizing a Cohesive Relocation Strategy

Key point: Make a strategic shift to maintain team unity and increase flexibility. Instead of spreading out team members across different time zones, moving entire teams to more cost-effective locations can be a better solution. This approach emphasizes anticipated financial savings while maintaining important team dynamics for agile success. 

I’ve seen the benefits of having teams in different time zones at DHL and my current company. In one team, a member adjusts to a 12-hour time difference, following US hours for years. Dedication is vital when working opposite hours from your usual life. Another agile team has developers in Eastern Europe with overlapping work hours of 3 to 4 US hours. Providing support and proper management for these teams is crucial. Organizations may consider team relocations to align with services or products globally.

Strategic Recommendations

The following strategic recommendations address this nuanced understanding of talent rebalancing, with a renewed focus on:

  1. Prioritizing Team Unity Over Individual Replacement: The strategy now focuses on relocating entire teams instead of individually back-filling positions. This approach aligns with cost-saving goals and the need to maintain effective teamwork within agile frameworks.
  2. Maintaining Agile Integrity Through Cohesion: Effective work schedules, improved collaboration (both asynchronous and synchronous), and strengthened team integration efforts are essential to uphold the core values of agile methodologies and efficient value delivery even in geographical changes.

Conclusion: Reframing the Approach to Global Talent Rebalancing

My primary focus is understanding how distributing team members across different time zones affects team dynamics and effectiveness. This article discussed the cost-saving debate in labor across various global geographic locations, where labor costs and talent frequently shape global redistribution strategies.

The initial idea proposed by senior leadership to replace departing US team members through attrition with more cost-effective global talent highlights the delicate balance between financial efficiency and preserving essential team dynamics for agile success.

As a technology leader in the US and a former software engineer, I prefer something other than outsourcing these positions to other countries. However, in my role and a globally competitive market, it’s important to endorse this approach. It’s a challenge I’ve faced, managed, and supported at times for over two decades.

If you or your organization is facing these demands, I suggest a comprehensive approach to talent rebalancing. This approach focuses on relocating and rebalancing agile cross-functional delivery teams based on geography and overlapping time zones rather than individuals. By prioritizing team cohesion and geographical consolidation, organizations can meet the financial demands of global business while sustaining innovation, efficiency, and competitive advantage in software development. This balanced approach ensures operational cost optimizations without compromising the dynamic interplay and shared commitment that drives high-performing agile teams, preserving their collaborative essence and productivity.

References:

  1. Pete Grieve; Americans Work Hundreds of Hours More a Year Than Europeans: Report, https://money.com/americans-work-hours-vs-europe-china/, Money, January 06, 2023.
  2. Charlie Giattino, Esteban Ortiz-Ospina, and Max Roser; Working Hours, https://ourworldindata.org/working-hours, Our Wold in Data, revision December 2020.

Poking Holes

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

Let’s talk: [email protected]

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.

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