Rethink Your Understanding

Transforming Software Delivery

philc

A Balanced Approach to Agile Metrics: Empowering Teams and Mitigating Risks

by

5 min read

Metrics can provide teams with insights and evidence where things are taking longer, are causing friction, and need attention to improve the flow of work. Focus on improving the most significant bottlenecks first.

I recently observed a discussion between an Agile team leader and a product owner. The Agile leader was worried about the business pressuring the product owner for delivery, who then used metrics to shift blame onto the team. Some of our Agile leaders see this product owner as authoritative and controlling. The product owner could benefit from dedicating more time to grasp agile delivery, team structure, roles, responsibilities, and the importance of metrics and team cohesion. However, that’s a separate matter.

After reviewing Flow Velocity, the product owner challenged the team’s work estimate, insinuating that the team’s velocity was not good enough and needed improvement. I sensed that this perturbed the agile leader. Post-discussion, I conversed with the agile leader, acknowledging the product owner’s valid points on velocity improvement. Every team should want to improve velocity. However, I noted the lack of concrete evidence behind the product owner’s critique. What data supported his assessment of the team’s efficiency? His comment seemed biased and lacked a factual basis. This interaction prompted me to create this post.

Introduction: The Foundation of Game-Changing Agile Practices

A strong focus on value stream management, flow metrics, and team structures are at the core of successful digital product delivery. When implemented across the system, these components bring significant changes that reshape agile software development. Over the past six years, my journey has closely involved these frameworks and practices, influencing the structure of my departments. This experience and a culture rooted in modern agile principles emphasize a fundamental belief: prioritizing people, processes, and tools in that specific order.

This philosophy guides our strategy and reflects how we operate. Modern agile principles help us navigate digital product delivery complexities, highlighting the vital role of human elements in achieving success. Our blend of advanced practices and dedication to agile values is the foundation for creating environments where teams excel, innovate, and provide exceptional value.

During a conference presentation last year, I showcased this approach as one of the most promising methods I’ve encountered in my over twenty years in software engineering and delivery. This synergy will help us, and you outperform other digital delivery teams stuck in outdated team structures and practices.

Delving into the intricacies of DORA, Flow Metrics, and Team Health metrics, it’s crucial to recognize that these tools and methods serve a broader mission. They aren’t just goals but pathways to enhance agility, efficiency, and team morale. With this fundamental insight, let’s dive into how a well-rounded metric strategy can empower teams, manage risks, and foster the constant improvement central to agile excellence.

Ensuring Team Metrics Empower, Not Impair

In pursuing agile excellence, embracing modern metrics like DORA, Flow Metrics, and Team Health metrics establishes a robust framework to evaluate and enhance software development practices. Yet, addressing the potential risks linked to the misapplication of these metrics is crucial. Drawing from 24 years of experience, it’s evident that without careful oversight and a profound grasp of their purpose, businesses could exploit these metrics, leading to gamification and focusing on manipulating metrics rather than genuine improvement.

Metrics are essential tools in the arsenal of engineering leaders and teams, providing necessary insights that guide teams toward continuous improvement. The value of these metrics lies not in their ability to compare teams or individuals but in their capacity to provide insights and feedback and foster growth and efficiency within the context of each team’s unique challenges and objectives (bottlenecks or friction). Also, one metric does not tell the story. You should rarely assess a team’s performance on one metric.

Understanding and Communication

Utilizing metrics effectively starts with engaging engineering teams in defining, communicating, and comprehending these metrics. This strategy ensures that teams grasp the significance of each metric about their processes and goals. It underscores the value of teams and recognizes that proficient delivery teams are crucial for successful software development. Embracing these metrics enables teams to identify bottlenecks and obstacles within their team, practices, and workflow.

Context and Comparison

Work context dramatically affects how metric values are interpreted and standardized. Comparing teams is dangerous. Comparing teams without factoring in their unique work elements and context can result in inaccurate productivity assessments. The key lies in evaluating a team based on its previous performance, tracking progress, and pinpointing improvement areas within their context.

Mitigating Risks: Gamification and Weaponization

The danger of metrics being misused by the business and turning team focus to gamification is significant and harmful. When teams worry about metrics being turned against them, their attention moves from getting better to just following rules. This worry can result in manipulating metrics, where teams try to beat the system to boost their stats without improving their productivity or the quality of their work.

Ownership versus Compliance

Separating business conversations from team conversations about metrics is crucial to mitigate these risks. Teams must feel ownership over their metrics, viewing them as valuable feedback mechanisms that align with their goals and aspirations. This sense of ownership encourages teams to care about their metrics, using them to identify bottlenecks, improve processes, and enhance delivery.

The Example of Velocity

I spoke with one delivery team member regarding velocity, or flow velocity. This conversation was a poignant example of how metrics can be gamed. Teams may break down tasks into smaller units to artificially inflate their velocity without necessarily delivering more value. We want teams to break down work into the smallest value possible. But this team’s manipulation to improve velocity underscores the need for a nuanced approach to metrics that prioritizes genuine improvement and meaningful output over numerical targets.

Conclusion

By strategically harnessing tools like DORA, Flow Metrics, Team Experience, and engagement metrics, focusing on empowerment and thoughtful metrics management, teams can revolutionize their path to improvement and agile excellence. Embrace a culture where metrics drive team feedback, insights, and growth, propelling your organization toward continuous improvement, efficiency, and improved team performance. Keeping team metrics conversations separate from business and team-level discussions uplifts software delivery and can sustain team commitment, motivation, and dedication to improvement. When teams unlock the power of metrics for enhanced efficiency and well-being, watch the separate business conversations around the same metrics naturally align.

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

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.

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]