Rethink Your Understanding

Transforming Software Delivery

Engineering

Engineering’s Business Value: From Black Box to Clarity

by

6 min read

This post is the first installment of my three-part series on connecting technology to business outcomes. In this foundational article, I delve into how organizations can redefine the value of software engineering by aligning technical efforts with measurable business results and customer impact.

Introduction

As a software engineer and technology leader with 25 years of experience spanning both waterfall and agile eras, I’ve heard the same refrain: “Technology is a cost center.” I’ve participated in reduction-in-force initiatives, stacked ranking exercises, and engineering team cuts—all driven by this persistent mindset. This experience has shaped my mission today: fundamentally changing how organizations view technology investments by directly linking our work to business and customer outcomes.

The Problem to Solve

The fundamental challenge in technology leadership has remained constant through every era: how do we effectively link and communicate the ROI of our engineering investments? This challenge can be addressed as organizations shift to a product operating model and embrace Value Stream Management (VSM). These frameworks focus on aligning work with value streams that deliver measurable business and customer outcomes, ensuring that engineering efforts are tied directly to strategic priorities.

Technology roles, commanding some of the highest salaries in modern organizations, often become prime targets for cost reduction initiatives. The math seems simple on paper—reducing engineering headcount produces an immediate, significant impact on the bottom line. Yet calculating true costs and ROI becomes complex when team members are shared across multiple initiatives. Modern organizations are solving this through intentional team design: implementing stable, cross-functional teams with dedicated software engineers and selective sharing of specialized roles like Product Managers and Agile Leaders across a limited number of teams. By moving work to teams rather than moving people between teams, organizations can more accurately track costs, measure value delivery, and demonstrate ROI at the team and value stream or product level.

For many senior leaders, the world of digital products, systems, and software engineering can feel like an entirely foreign language—and for good reason. Despite its critical role, technology efficiency and performance are often treated as a “black box” within organizations. Meanwhile, departments like Marketing, Sales, and Product consistently align their efforts with measurable business outcomes.

This disconnect creates a significant gap in organizational insight and decision-making. Are we employing the right number of engineers within our budget? Are we simply hiring engineers without a clear plan for assigning work? By adopting smarter hiring and capacity management practices, we can minimize unnecessary overhead and avoid layoffs caused by poor resource planning. The key to closing this gap lies in establishing frameworks and improving visibility to clearly articulate the tangible value technology brings to the business. It all starts with defining clear, measurable outcomes.

Operational Efficiency, Realization, and Alignment

Until new solutions emerge, technology success stems from excelling in two core areas, seamlessly linked through strategic alignment.

  1. Flow: Operational efficiency in delivering value, from ideation to implementation
  2. Realization: Measurable business impact of technology initiatives

Well-structured OKRs bridge these areas by translating organizational strategy into team-level objectives, ensuring every technical effort connects directly to business outcomes.

Flow: Modern tools and practices have revolutionized measuring and improving performance. Agile methodologies, Team Topologies, DevOps strategies, value stream management, and advanced analytics now offer insights into operational workflows and delivery efficiency.  

Realization: Modern tracking and measurement tools empower teams to gather, organize, and analyze meaningful data, even when results take months or longer. The insights provided by these technologies “close the loop” by clearly connecting technical efforts to tangible business outcomes. Even when the results fall short of expectations, these insights empower teams to reflect, refine, or pivot their approach entirely.

Team alignment: Product Operating Model and OKRs

The shift to a product operating model is fundamental to linking engineering efforts to business outcomes. Organizations enable teams to own changes throughout the product lifecycle by aligning teams around products instead of projects. This ownership fosters expertise, accountability, and a long-term focus on delivering customer value. Unlike the traditional project-based approach, which often prioritizes short-term deliverables, the product model supports continuous improvement and meaningful outcomes over time.

OKRs are a powerful tool for bridging the gap between technology investments and business outcomes. When crafted effectively, OKRs should reflect your team’s primary responsibilities and stay within their span of control, ensuring alignment with the organization’s broader goals. This approach keeps everyone focused on the same mission while linking team efforts to delivering real customer value.

By creating a clear line of sight between your team’s work, customer value, and measurable business outcomes, OKRs provide a roadmap for demonstrating the tangible impact of technology investments. They turn abstract efforts into visible results, demystifying the role of engineering in driving success.

Start with Outcomes

Success in technology is often misunderstood. While delivering stories, releasing epics, or launching products signify progress, they fail to guarantee success. True success lies in whether the work delivered creates valuable outcomes. Even when outcomes fall short of expectations, success can be found in the insights gained—insights that help teams refine their approach and uncover overlooked factors. This shift in defining success is crucial for demonstrating technology’s business value.

Product managers are responsible for defining and measuring feature outcomes, while technical team members are accountable for articulating the anticipated results of addressing technical debt. This dual ownership ensures that both business features and technical investments are tied to measurable outcomes. When technical teams can link technical debt to specific business impacts, these investments transform from mysterious “maintenance work” into strategic initiatives with clear business value.

Alignment and Purpose

Starting with anticipated outcomes enables teams to develop meaningful OKRs that cascade from organizational strategy. By first defining the expected impact of their work, teams can craft team-level OKRs that naturally align with broader strategic objectives. This outcome-first approach ensures that every epic and initiative has a clearly defined, customer-centric goal and connects directly to the organization’s strategic direction. This approach prevents the common anti-pattern from creating OKRs, focusing solely on output rather than meaningful results.

By documenting both anticipated and actual outcomes at the epic level, teams can:

  • Track how their work contributes to business results over time
  • Make data-driven decisions about resource allocation
  • Better prioritize work based on expected impact
  • Build a straightforward narrative around technology investments
  • Bridge the communication gap between technical and business stakeholders
  • Leverage modern tools to provide visibility into both efficiency and impact

ROI for Engineering Teams

By evaluating the return on investment (ROI) of our cross-functional teams—comparing development costs with the financial benefits of improved features or business outcomes—we can make smarter decisions about resource allocation while showcasing the measurable impact of our engineering efforts.

Summary

It’s time to demystify technology’s role in business success. By adopting an outcome-based approach, defining actionable OKRs, and framing decisions regarding business value, we enable technology to drive growth. These practices don’t just justify investments—they link technology investments to business results and create a roadmap for long-term success.

This mission is personal to me: to reshape how organizations perceive technology—from a cost center to a catalyst for innovation, growth, and customer satisfaction. This transformation demands connecting technical decisions, code, and architectural choices to measurable outcomes. When we align technology with clear business and customer value, we not only bridge the gap between investment and impact—we close it entirely.

Next in the series

In the next article, I’ll share how a personal leadership epiphany can transform our engineering organization from a cost center into a strategic partner, with practical insights for driving business results. Read Now →

Poking Holes

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

Let’s talk: phil.clark@rethinkyourunderstanding.com

Profitable Engineering: Linking Software Engineering to Business Results

by

3 min read

From Code to Impact: A Leadership Series on Linking Software to Business Success

In late 2024, a 360-degree leadership assessment brought candid feedback from an executive peer outside the tech sphere that hit hard: “Focus more on driving business results.” After years of leading digital transformation—scaling our organization from $10 million to $110 million in revenue through changes in culture, team design, architecture, and modern practices like Agile, DevOps, and VSM—it became clear that we hadn’t effectively articulated how our technology initiatives contributed to the company’s bottom line. This series is my response—a thoughtful exploration of aligning engineering efforts with measurable outcomes and turning technology into a powerful engine for business success.

My goal is to change how organizations view technology investments by showing a clear connection between our work and business or customer outcomes. In this three-part series, I draw from 25 years of experience in software engineering and technology leadership, where I’ve often seen technology labeled as just a cost center. These articles aim to provide practical insights and strategies to shift this perspective, highlighting how technology can drive innovation, growth, and customer satisfaction. By adopting modern practices, a product-driven operating model, and data-driven insights, we can create engaged teams that act as business partners rather than cost centers, delivering value more effectively.

This series is for technology leaders, Product Managers, and anyone looking to align engineering with organizational goals. We’ll cover how to clearly show the value of technology, integrate outcomes into workflows, and connect technical work to business success.

This series offers a comprehensive guide to aligning software engineering with business success, balancing foundational concepts with leadership insights and practical steps for transformation. Each article can stand alone but builds on the others—starting with the basics of technology’s role in business, advancing to leadership strategies for driving outcomes and concluding with actionable steps to empower teams. The intentional overlap reinforces key ideas, while the progression delivers a cohesive, engaging narrative that equips readers to drive meaningful change.

Series Summaries

1. Engineering’s Business Value: From Black Box to Clarity

This foundational article addresses the challenge of linking engineering efforts to business outcomes. It introduces shifting to a product operating model and Value Stream Management (VSM) as frameworks to align technical work with strategic priorities. The emphasis is on defining clear, measurable outcomes to articulate the tangible value technology brings to the business.
Read More →

2. Transforming Engineering: From Cost Center to Strategic Partner

This article builds on the first article and delves into the evolution of engineering roles within organizations. It reflects on leadership experiences and the importance of balancing operational efficiency with value realization. The article discusses embedding outcomes into workflows and the necessity for technology leaders to communicate the value of technical investments in business terms.
Read More →

3. Breaking Free from the Build Trap: Delivering Meaningful Outcomes

The final article focuses on moving beyond a feature factory mindset by concentrating on outcomes rather than outputs. It highlights the pitfalls of the build trap and underscores the value of starting with outcomes, fostering accountability, and ensuring successful delivery. The piece challenges technology leaders and teams to adopt a mindset centered on meaningful outcomes that drive engagement and impactful business results.
Read More →

This series encourages you to rethink your approach and join me in this transformation journey. Feel free to share your thoughts, experiences, or perspectives. I’m always up for a great conversation!

Crossroads 2024: Reflections on Leadership, Legacy, and Modern Practices

by

5 min read

Preface: Defining the Last Chapter

As a software engineer and leader who has experienced two distinct eras of software delivery, I’ve witnessed the transformative power of today’s practices. Modern approaches to team design, architecture, and processes drive fast flow, delivering value faster and out-innovating the competition.

Now, I find myself where my leaders once stood—in the latter part of my career. My mentors have challenged me to reflect on how I want to spend these remaining years, placing me at a pivotal crossroads. Recently, my organization was acquired by a larger global enterprise—a familiar environment from my past experiences, with its inherent expectations and complexities.

During an interview for a national publication, I was asked a question that resonated deeply: “What is your role now?” The interviewer noted that my website suggested I might be a consultant. I thrive as a VP of Technology or Head of Software Engineering, where I influence transformation, inspire teams, and design systems that deliver exceptional results. The role allows me to lead with impact, foster innovation, and continuously learn and experiment.

As I approach the final chapter of my career, I ask myself: How do I want to spend these years? Where can I make the most significant impact? This reflection is not about uncertainty—it’s about clarity of purpose. My mission remains steadfast: to inspire leaders, empower teams, and leave a legacy that champions modern practices, continuous learning, and the art of the possible.

The Journey: Transforming Leadership and Leaving a Legacy in Modern Practices

I began my career as a software engineer, driven by a love for problem-solving and building creative solutions through software code. While I still value those things, my focus has evolved toward technical leadership—specifically, helping senior leaders create environments where technologists can thrive and deliver exceptional results.

This journey has been shaped by personal experiences and remarkable technological advancements that have redefined how we work. Cloud computing has dramatically lowered barriers to experimentation and innovation, enabling teams to deliver solutions at unprecedented speeds. Methodologies such as Agile, Lean, DevOps, and Value Stream Management have unlocked new possibilities for collaboration and delivery. Advancements in architecture and cloud technology, along with modern team design, have made these changes both practical and impactful. These innovations have inspired me and driven this mission forward.

My journey has sometimes been challenging. In 2018, I realized that my mindset, rooted in past ways and successes, clashed with the future we were trying to build. A manager on my team encouraged me to read books and articles, while a peer suggested foundational works like The Phoenix Project. Meanwhile, an Agile leader pointed out that some of my outdated habits—like calling team members “resources” or moving individuals between teams—were disrupting the stability and collaboration essential for cross-functional success.

Their feedback and reflections brought me to an important realization: to thrive in current practices, I needed to unlearn outdated methodologies, adopt a growth mindset, and incorporate experimentation as a fundamental aspect of leadership. Recognizing the need to move beyond past expertise, I committed to continuous learning and re-evaluating my approach to leadership and competitiveness in today’s software delivery landscape.

At the core of this transformation is culture. A strong culture precedes processes, tools, and methodologies. It places people at the center of an organization’s purpose. Teams can achieve extraordinary outcomes by fostering trust, ensuring psychological safety and a sense of purpose, and encouraging diverse perspectives.

As seasoned leaders, we must temper our egos, challenge our viewpoints, and remain open to new opportunities. Leadership isn’t about perfection; it’s about progress, building trust, and empowering teams to thrive.

Exploring the Potential of AI

Like many others, I am invested in understanding how AI transforms our world. Generative AI tools empower developers to work more efficiently, solve problems faster, and explore creative solutions. At the same time, these advancements present challenges as we adapt our governance, understanding, processes, and cultures to leverage AI’s potential.

AI is still in its early stages, but it is important to adopt it thoughtfully and be “the human in the loop” in the process. I see AI as a tool that complements modern leadership, opening up new opportunities for innovation and engagement. It has the potential to boost productivity, empower teams, and reshape how we deliver value, which motivates me to continue exploring its possibilities.

Today’s Goal: Value and Fast Flow

Pushing boundaries is essential to achieving fast flow and delivering value. However, managing “knowledge work” presents unique challenges. In most cases, we rely on predictions—our best guesses—about outcomes and timelines, often navigating unknowns in new requests. Leaders expect accuracy, yet the reality of uncertainty demands adaptability.

Over my career, I’ve witnessed how great teams operate and how leadership can either drive or derail success. I bring this experience to organizations, helping them deliver value faster, safer, and more effectively by aligning modern practices and tools with their specific contexts.

  • What: Deliver value through fast flow by integrating processes, frameworks, and technology tailored to the organization’s needs.
  • How: Leverage practices and frameworks that enable faster feedback, reduce risks, and minimize wasted efforts. By implementing a mix of culture, team design, architecture, Agile, Lean, DevOps, Value Stream Management, and modern infrastructure, organizations can pivot quickly and respond to real-time feedback—staying on course, adjusting direction, or halting when necessary.
  • Measure Success: Use outcome and flow metrics to drive continuous feedback and improvement, ensuring every step adds value and minimizes uncertainty.

Mission: Building Teams, Empowering Leaders, and Delivering Impact

Having led teams through two distinct software delivery eras, I’ve never been more passionate about my role than I am now. Our industry’s changing tools and practices have expanded what’s possible, inspiring me to build teams and organizations that set new standards.

My mission is simple: to deliver the right digital products quickly, securely, and efficiently while fostering a culture of innovation and engagement. I aim to meaningfully impact teams, organizations, and customers, helping them achieve exceptional outcomes through modern practices, a product operating model, and data-driven insights.

High-performing teams prioritize based on expected outcomes, driving efficiency while maintaining a strong sense of purpose. This alignment enhances engagement, ensuring a greater impact for every dollar invested.

Conclusion

I will honor those who influenced and inspired me if I can continue to help even one senior leader, organization, team, or individual create thriving environments, rethink leadership, or achieve better outcomes.

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: phil.clark@rethinkyourunderstanding.com

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: phil.clark@rethinkyourunderstanding.com

Shift Left Security, Security Unit Tests, OWASP Top 10, and AI: Key Practices for Secure Development

by

6 min read

What are we trying to improve? The adoption of practices to find security vulnerabilities early in the development lifecycle.

What outcome do we hope to achieve? Additional security coverage, where applicable, earlier in the software development lifecycle.

Let’s Shift Left

Are you familiar with the term “shift left”? It is a popular concept in the tech industry for good reasons. I define shift left as enabling the earliest feedback. It’s about determining if your code modification is functioning as intended and detecting any potential damage to pre-existing code as soon as possible. 

Why should we postpone identifying an issue until the last minute? The cost of detecting an issue increases as it is detected later in the delivery flow (cost is a whole other conversation). For us, we started shifting left for quality, running tests at all levels, and moving from depending on extensive, long-running tests in staging or production environments to reducing the number of these tests and replacing them with tests earlier in the flow (shifting the tests left). Several libraries support unit test implementation in most languages. Our journey started several years back with Martin Fowler’s article on the practical test pyramid1 and adopting the practice of test-driven development (TDD).

Security Shift Left Mindset

Security has become indispensable to our work in the evolving technology and software development landscape. It’s no longer just about developing features but ensuring they are secure and reliable for our users. Significant improvements have been made at the platform and systems levels. Here’s the kicker: what if we did the same “shift-left” approach for security? Developers can access helpful tools such as profilers, static analysis, and dynamic analysis scanners. The objective is to identify security issues quickly alongside quality and defects. Why not make security-based unit tests a core practice of your team?

OWASP Top 10: Key Practices for Secure Development in the coding stage

We want to ensure our code is secure and get feedback early. One way to do this is to follow the OWASP Top Ten2 security risks while writing and compiling our code. We can use unit tests to help prevent these risks from happening.

1. Injection (OWASP A1): Create input validation tests to mitigate injection flaws.

// Java
@Test 
public void testSqlInjectionVulnerability() { 
  String maliciousInput = "1'; DROP TABLE users; --";  
  assertFalse(isSqlInjectionSafe(maliciousInput)); 

}

2. Broken Authentication (OWASP A2): Develop tests to verify session management and authentication.

// Java
@Test 
public void testSessionExpiration() { 
  User testUser = new User("Test User"); 
  Session testSession = new Session(testUser); 

  Thread.sleep(MAX_SESSION_TIME + 1); 
  assertFalse(testSession.isValid()); 
}

3. Sensitive Data Exposure (OWASP A3): Formulate tests to prevent inadvertent data leaks.

// Java
@Test 
public void testDataLeak() { 
  User testUser = new User("Test User", "password"); 
  Logger testLogger = new Logger(); 

  testLogger.log(testUser);
  assertFalse(testLogger.containsSensitiveData()); 
}

4. XML External Entity (XXE) (OWASP A4): Test XML parsers for correct configuration.

// Java
@Test 
public void testXXE() { 
  String maliciousXML = "..."; // some malicious XML   
  assertThrows(XXEException.class, () -> parseXML(maliciousXML)); 
}

5. Broken Access Control (OWASP A5): Assert appropriate access levels for different user roles.

// Java
@Test 
public void testAdminOnlyAccess() { 
  User testUser = new User("Test User", Role.USER); 
  Resource restrictedResource = new Resource("Restricted Resource"); 
  assertThrows(AccessDeniedException.class, () -> restrictedResource.access(testUser)); 
}

6. Cross-Site Scripting (XSS) (OWASP A7): Implement tests to check how the application handles untrusted data.

// Java
@Test 
public void testXSSVulnerability() { 
  String maliciousInput = "<script>alert('XSS');</script>"; 
  assertFalse(isXssSafe(maliciousInput)); 
}

Other examples for the user interface (JavaScript)

1. Cross-Site Scripting (XSS) Protection: To prevent XSS attacks, you should test that your rendering function properly escapes user input.

describe('XSS Protection', () => {
  it('should escape potential script tags in user input', () => {
    const userInput = '<script>alert("xss")</script>';
    const escapedInput = escapeUserInput(userInput);
expect(escapedInput).toEqual('&lt;script&gt;alert("xss")&lt;/script&gt;');
  });
});

2. Injection and Input Validation: Confirm your software correctly validates the user input and prevents SQL injection.

describe('Input Validation', () => { 
  it('should invalidate input containing SQL Injection attempt', () => { 
    const userInput = "'; DROP TABLE users; --";
    expect(isInputValid(userInput)).toBe(false); 
  });
});

3. Authorization/Access Control: Ensure certain UI elements are accessible only to authenticated or authorized users.

describe('Authorization', () => { 
  it('should not show the admin button for non-admin users', () => { 
    const user = { isAdmin: false };
    render(<Dashboard user={user} />);
    expect(screen.queryByText('Admin Panel')).not.toBeInTheDocument();
  });
});

4. Token Handling: Verify that authentication tokens are stored and handled securely.

describe('Token Handling', () => { 
  it('should not store tokens in localStorage', () => {
    setAuthToken('exampleToken');
    expect(window.localStorage.getItem('authToken')).toBeNull();
  });
});

Check out this YouTube video: DevSecOps wins with Security Unit Tests.3

What about AI?

As we focus on modern security practices, it’s worth touching on these efforts’ using artificial intelligence (AI) advantages.

While you can find posts and articles from earlier this year (2023) concerning the security vulnerabilities that code assistance tools like GitHub copilot can create. However, you can also find posts and articles detailing how quickly the security features of these tools are improving.4

There is no perfect solution. Still, tools like copilot can learn from past incidents, analyze patterns, and predict vulnerabilities. They can generate test cases based on software behavior and suggest edge cases to enhance our unit testing process. These tools can enhance security unit tests. Machine learning models can be trained on numerous secure and insecure code examples, predicting whether a new piece of code might contain security vulnerabilities based on patterns they’ve learned. These tools can flag potential security issues as developers write code, providing immediate feedback and opportunities for learning.

AI can assist in static and dynamic security testing. One example is that AI can help with the time-consuming task of sorting through false positives in static code analysis results. Additionally, AI can identify patterns in code that humans may overlook and point out areas that require further examination. In dynamic analysis, AI can help mimic the actions of real users by interacting with the software as humans would, finding vulnerabilities that manual testing might not uncover. The continuous learning process of AI models also ensures that our testing procedures will evolve alongside new threat patterns.

Wrapping this up

While the OWASP Top Ten may not encapsulate all possible security issues, it provides a robust foundation for our security practices. Incorporating these tests into our daily workflow is a strategic move that will substantially enhance our products’ security. Such tests should be designed to verify that the user interface effectively implements various security measures. For teams yet to adopt this “shift left” practice, it is imperative to start integrating security testing earlier in the development process and uphold high-security standards.

To stay ahead of evolving threats and reinforce our software’s security, we should also consider the integration of AI into our security strategy. AI can enable us to identify and tackle potential vulnerabilities proactively. However, it is essential to remember that these powerful tools are intended to supplement, not substitute, our existing security practices and intuition.

Let’s focus on enhancing our security practices as we move forward. We should adopt emerging technologies like AI while keeping our main goal in mind – creating secure and reliable software for our users. By implementing strategies such as “shift left” security and utilizing the tools available to test the security of our code, we can stay ahead of evolving security threats and maintain the trust of our users.

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.

References

  1. Martin Fowler (26 February 2018), The Practical Test Pyramid, martinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html
  2. Aimee, Nikki, and featuring Abhay Bhargav (26 September 2021), DevSecOps wins with Security Unit Tests, youtube.com, https://www.youtube.com/watch?v=i34Ihbuslgw
  3. OWASP Top Ten, owasp.org, https://owasp.org/www-project-top-ten/
  4. Shuyin Zhao (14 February 2023), better AI model and new capabilities, github.blog, https://github.blog/2023-02-14-github-copilot-now-has-a-better-ai-model-and-new-capabilities/