Rethink Your Understanding

Transforming Software Delivery

Lean

Evolving the Agile Leadership Role: Integrating Value Stream Management into Agile Leadership

by

9 min read

This post is part of my ongoing series showcasing the competitive edge provided by maintaining Scrum Master or Agile Leader roles within teams. If you’d like to read more, please review the related posts section at the end of this article.

Value Stream Management

Value Stream Management doesn’t require you to transform your software delivery practices beforehand or adopt Agile, Lean, or DevOps practices first. It provides visibility into how you ideate, plan, create, and deliver digital products or services. It optimizes the time spent on these tasks by automating and standardizing the workflow from ideation to production and operation. Based on the insights, you can discuss, decide, and experiment with frameworks and practices to improve your system and workflow. I discovered Value Stream Management in late 2020 and introduced it to my department in 2021, after more than six years into our digital evolution. VSM is a natural complement to our Agile, Lean, and DevOps initiatives.

Like Agile, DevOps, and Lean practices, Value Stream Management (VSM) demands organizational understanding, alignment, and expertise. Successful adoption of VSM requires everyone to understand its purpose, benefits, and implementation. Subject matter experts play a crucial role in this process. Introducing dedicated VSM roles—such as Value Stream Managers, Value Stream Architects, and Flow Advisors—is essential for ensuring continuous value delivery and operational efficiency.

Expertise can be sourced externally, identified within the organization, or cultivated through strategic investment. Unlike the early attempts to transition teams from waterfall to agile by merely rebranding Project Managers or Business Analysts as Product Managers or Product Owners, these new roles are distinct and require dedicated training and development. Investing in this development is essential for success.

These new roles can be added to the organization, departments, or current members of cross-functional delivery teams. This article supports the cross-functional team option, recommending that Agile Leaders in cross-functional teams are a great option and can be trained as their teams’ VSM and Flow experts. We are testing the idea of developing VSM skills and expanding the responsibilities of Agile Leaders or Scrum Masters within our cross-functional delivery teams.

The Conversation

A VSM colleague, Patrice Corbard, shared an insightful observation based on published results about Scrum Master maturity in a community Slack message. While I am still determining the research methods used or the accuracy of the research findings representation of the industry, the discussion it sparked was quite interesting. Patrice highlighted that only 8% of Scrum Masters can optimize product value streams. He posed three questions:

  1. Are you surprised by this very low proportion?
  2. What are the benefits of the value streams approach to get scrum masters interested in the subject, particularly in these difficult times when agile coaching roles are being called into question?
  3. What do you suggest to change the game and motivate scrum masters and their leaders/managers?

This inspired me to share how, I have been enhancing the Scrum Master/Agile Leader role by integrating VSM knowledge, experience, and responsibilities.

From the ScrumMatch website: 

Scrum maturity reflects the capability to leverage Scrum to deliver increased business value more efficiently. ScrumMatch evaluates the Scrum maturity of both Scrum Masters and organizations, providing transparency so each can understand how well they align with each other’s needs and expectations. A Scrum Master’s maturity level is displayed on their profile, rated on a 7-point scale from low to high maturity. 1, 2

Here is my summary of their findings. The top three points on the current state of Scrum Master maturity are:

  • Substantial Proportion Lack True Scrum Mastery: 38% of candidates fail to exhibit the essential qualities of a proficient Scrum Master.
  • Most Candidates Are Still Developing Foundational and Applied Skills: 37% of candidates are at the intermediate level, with 10% possessing foundational knowledge, 13% understanding and applying Scrum principles, and 14% starting to enhance their Scrum practices.
  • Limited Advancement to High Organizational Impact: A small percentage achieve higher maturity levels. Specifically, 14% utilize Scrum to enhance product development, 8% focus on optimizing the product value stream, and only 3% can optimize the entire organization.

First Question

“Are you surprised by this very low proportion?”

These findings don’t surprise me; they align with my experiences. Similar to the Product Owner role, The Scrum Master or Agile Leader team role is crucial. Enhancing its value and bringing it to maturity requires continuous investment in learning and hands-on experience. This dedication is essential for adding value to the team.

I attribute the questioning of the value and maturity level of Scrum Masters to several key factors: the commercialization of certifications (ease of access and proliferation of certification mills), the expertise and mindset of senior leadership or executive sponsors (entrenched or outdated perspectives), investment in continuous training, and hands-on practical experience.

Like other team roles, new Scrum Masters and Agile Leaders need time to develop their skills and gain experience. This should be complemented by continuous investment in learning and growth.

Second Question

“What are the benefits of the value streams approach to get scrum masters interested in the subject, particularly in these difficult times when agile coaching roles are being called into question?”

Starting with the second part of Patrice’s second question, which points to the industry debate on Agile and the value of the Scrum Master/Agile Leadership role, this topic commands a separate discussion beyond the scope of this article, and I will be brief. 

Many agile or digital transformation struggles and failures can be traced to leadership, prevailing mindsets, and experiences. However, I agree that the role of the Scrum Master has been diluted by the proliferation of accelerated certifications and the commercial aspects surrounding them. This trend has undermined the significance of the Scrum Master’s responsibilities and their potential to make a meaningful impact on cross-functional software delivery teams. 

Do we need the Scrum Master/Agile Leader role?

Your organization and team design will decide.

First-time product owners need time, trust, and support to grow into their new role. – Roman Pichler

This quote applies to Scrum Masters, Agile Leaders, and Product Owners or Product Managers. These roles add value as they gain knowledge and experience and improve their skills and trust in their teams.

My responsibilities include team design, systems thinking, and delivering high-quality technology quickly. Although I have extensive experience in agile delivery, I am not a Scrum Master and have never held that role. However, I have led and mentored our agile leadership team and am a strong advocate for its value within cross-functional delivery teams.

Conversely, as we progress through decades of digital transformation and move away from traditional waterfall methods, the benefits of Agile practices and the role of Scrum Masters are increasingly debated. Many organizations still struggle with Agile transformations, often concluding that Agile falls short, leading them to cut Scrum Master positions and similar roles from their budgets.

Industry experts, such as the highly esteemed Marty Cagan, argue in his latest book “Transformed” and in related interviews that these roles, as currently defined, are either redundant or lack substantial value. As I interpreted it, Cagan asserts that the responsibilities typically assigned to Scrum Masters should fall to other team members, particularly the Product Manager. I can only partially agree with this suggestion when teams have evolved to mature self-managed levels.

Third Question

“What do you suggest to change the game and motivate scrum masters and their leaders/managers?”

I will combine my response to the first part of question two, “”What are the benefits of the value streams approach to get scrum masters interested in the subject” and question three.

Evolving the Scrum Master/Agile Leader role with VSM

I appreciate that the role of the Scrum Master/Agile Leader remains impartial and uninfluenced by any particular type of the team’s work — be it feature development, technical debt, defect resolution, or security risk. This neutrality allows for a balanced and objective focus on the team’s success. While other team roles have specific areas of focus, the Scrum Master is uniquely positioned to ensure the overall health and performance of the team, utilizing tools like Value Stream Management and Flow Metrics.

Motivation stems from the Scrum Master’s or Agile Leader’s commitment to the team’s overall performance. The primary responsibility of a Scrum Master or Agile Leader on a cross-functional delivery team is to enhance team effectiveness and support greater efficiency. This involves managing rituals, team health, performance metrics, retrospectives, and collaboration. By leveraging Agile and Lean methodologies and incorporating Value Stream Management (VSM), as I propose, these leaders can achieve these goals more effectively. With executive sponsorship and support, the Scrum Master or Agile Leader is ideally positioned to lead VSM initiatives, focusing on the team’s overall success rather than specific product features or technical solutions.

Delivery optimization and oversite responsibilities are natural progressions of responsibility for Agile Leaders. One way to achieve this is through Value Stream Management (VSM), which analyzes the product creation and delivery process. Each team member should understand VSM principles, and having a subject matter expert on the team enhances delivery efficiency and customer satisfaction. Integrating VSM oversight into the role of Scrum Master or Agile Leader helps optimize team performance and align efforts with business objectives, ultimately improving the delivery of business value.

Benefits:

  1. Holistic Team Focus:
    By integrating VSM, the Scrum Master can oversee and enhance the entire workflow, ensuring all processes contribute effectively to delivering value. This comprehensive perspective complements the Scrum Master’s focus on team health and performance.
  2. Enhanced Process Efficiency:
    VSM helps identify bottlenecks and inefficiencies in the delivery process. A Scrum Master with VSM responsibilities can facilitate improvements across the value stream, leading to faster and more reliable delivery of products.
  3. Balanced Work Prioritization:
    The Scrum Master can leverage VSM to encourage teams to balance work priorities more effectively. This ensures that feature development, technical debt, defect resolution, and security risks are all addressed appropriately. This can provide a more even distribution of effort and attention across different types of work.
  4. Improved Metrics and Insights:
    Integrating VSM allows the Scrum Master to track flow metrics and other key performance indicators that provide deeper insights into the team’s productivity and areas for improvement. This data-driven approach fosters continuous improvement initiatives and enables teams to identify actionable steps for enhancement.
  5. Enhanced Collaboration and Communication:
    With a focus on the entire value stream, the Scrum Master can better facilitate collaboration and communication between different team members and stakeholders, ensuring everyone is aligned on goals and processes.
  6. Strategic Alignment:
    By managing the value stream, the Scrum Master can ensure that the team’s work aligns with the organization’s strategic objectives, enhancing the overall value delivered to customers and stakeholders.

Challenges 

Integrating Value Stream Management (VSM) into Agile Leadership tackles the growing complexity of digital product environments. This approach requires a comprehensive perspective on product delivery and team efficiency beyond traditional task execution. However, VSM is still in its early adoption phase in the industry. Despite its strategic importance, expertise in optimizing value streams is scarce in the job market. Organizations like the one I led take proactive steps by recommending and providing VSM training to their Agile Leaders. VSM adoption necessitates investing in training, experimentation, and collaboration with industry experts.

Organizational Impact and Future Prospects 

Adding Value Stream Management capabilities elevates how software product delivery teams and their leaders perceive their contributions to organizational goals. By emphasizing continuous improvement and strategic value creation, Scrum Masters and Agile Leaders can be better equipped through VSM to influence and elevate cross-functional team performance and organizational outcomes. This transformation tackles some of the immediate skills gaps identified by ScrumMatch. It establishes a new benchmark for the capabilities of Agile practitioners’ responsibilities and overall team value, clarity, and flow.

Integrating Value Stream Management into the Agile Leadership role marks a significant evolution in Agile team practices. It bridges a crucial gap, enabling Agile practitioners to link their team’s daily activities with strategic business outcomes. Organizations embracing this approach will likely experience increased agility, better alignment with business goals, and superior performance, positioning them to tackle future challenges and seize opportunities more effectively.

References

  1. ScrumMatch, https://scrumatch.com/, Understanding Scrum Maturity, https://scrummatch.com/en/support/understanding-scrum-master-maturity
  2. ScrumMatch LinkedIn post, April 2024, https://www.linkedin.com/posts/scrummatch_hr-recruiting-scrummaster-activity-7183423788401762304-psjP?utm_source=share&utm_medium=member_desktop
  3. Scrum Masters play a role, LinkedIn Post, https://www.linkedin.com/posts/patricecorbard_hr-recruiting-scrummaster-activity-7185600586954788864-0FmS?utm_source=share&utm_medium=member_desktop, Patrice Corbard, April 2024.

Resources and Recommendations

Related Posts

Poking Holes

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

Let’s talk: [email protected]

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

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]

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]

Outcome Metrics and the Difficulty of Reporting on Value

by

4 min read

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

What problem are we trying to solve?

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

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

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

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

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

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

The challenges of measuring the final outcome of digital changes

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

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

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

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

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

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

Teamwork and transparency at the team level

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

Why: Why are we working on this?

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

These can align with OKRs for those using them.

Benefits:

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

Challenges:

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

Closing the loop with the delivery teams:

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

Final thoughts

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

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

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

Related articles:

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

References:

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

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.