• Skip to primary navigation
  • Skip to main content
Rethink Your Understanding

Rethink Your Understanding

Transforming Software Delivery

  • Home
  • Practices and Mission
  • Collaboration
  • Posts
  • Podcast
  • Endorsements
  • Resources
  • Contact

Agile

Agile Software Delivery: Unlocking Your Team’s Full Potential. It’s not the Product Owner.

December 29, 2022 by philc

10 min read

This article examines the role of leadership in agile software delivery teams and product organizations. The Product Owner is often considered a leadership role. This article highlights the importance of having an experienced Scrum Master or Agile Leader as a leader on the delivery team. These individuals bring impartial leadership and provide additional benefits to the delivery ceremonies, ultimately impacting the success of the product delivery.

The article also explores the challenges faced by product and technology teams when working together to deliver software in organizations where these are separate functions. The tension between Product Owners, Scrum Masters, and team members can lead to friction and difficulties in aligning goals. Many articles, posts, and podcasts cover the toil between Product Owners and teams. This article aims to provide an alternative perspective on addressing this issue and offers alternative options for improving collaboration and prioritizing work. The insights provided in this article may help organizations better understand their context and adjust their team’s approach for better outcomes.

Your decision regarding team leadership is critical

If you’re utilizing Scrum, Lean-Agile, Kanban, SAFe, XP, etc. – or if you’ve created your version of these methodologies – the roles of Product Owner and Scrum Master were designed as leadership roles to give teams an advantage in achieving success. For teams that want to develop high-quality software with security and performance protocols factored in, three influential leadership positions are necessary: product owner, agile leader, and engineering manager (or technical lead). The level of engagement between these three leadership roles helps the teams succeed.

The Agile Leader Model. This post assumes the following:

  • Your organization or department embraces Agile, Lean, and DevOps practices tailored to meet your unique needs.
  • Your teams are organized as small cross-functional delivery teams.
  • Your team follows a delivery practice, for example, Scrum, Kanban, Lean-Agile, or any method that suits your context.
  • Features are just one of your focuses. You recognize four types of work that flow through your digital product value stream: feature, debt, defect, and risk.1
  • Most importantly, the Product Owner is a part of the delivery team and regularly participates as a team member. If not, why?

In many product and service organizations and delivery frameworks, the Product Manager or Owner is solely accountable for deciding what the team should focus on. Understandably, the Product Manager and Product Owner are responsible for the organization’s product strategy, delivery, growth, and capabilities. They are under pressure and held accountable by the organization to prioritize products over all else. However, this does not necessarily mean that absolute authority or responsibility belongs to the Product Owner; other factors are also at play.

Roles

Here is a summary of the Product Owner’s responsibility from “The Accountabilities of the Product Owner” from scrum.org as published in November 2020: The Product Owner is a member of the Scrum Team and is responsible for maximizing the value of the product resulting from the team’s work. They provide clarity to the team regarding the product’s vision and goal and work to deliver value to all stakeholders. The Product Owner is accountable for successful Product Backlog management, which includes developing and communicating the Product Goal, creating and communicating Product Backlog Items, ordering them, and ensuring they are transparently understood. They may delegate this responsibility to others on the team but remain accountable for its accomplishment and the value delivered. The Product Owner must also earn the respect of the entire organization to make decisions and get the support they need for those decisions. They are the final decision maker for changes in the Product Backlog and should also be getting customer feedback on the product.

Likewise, the Scrum Master/Agile Leader’s responsibility summary: A scrum master is a coach and facilitator in a scrum team responsible for implementing and guiding the scrum framework. They establish processes, resolve conflicts, protect the team, and facilitate meetings. Agile leaders prioritize people, learning, and adaptability over processes and embody an evolutionary mindset of self-awareness and growth. Two key capabilities are the ability to encourage conversations regarding prioritization and attention to the types of work; the other is encouraging discussions about team improvements through team metrics (system data) and team health (qualitative data). To be an influential scrum master and agile leader, one must be humble, responsive to change, embrace uncertainty, and be willing to evolve themselves and the team systems.

Challenges and Responsibility

The question of who should determine what work to prioritize among the four types required for an effective digital product is essential. While the Product Owner is typically responsible for deciding what a team will work on and deliver, team autonomy can give members a sense of responsibility and the power to make decisions. Autonomous teams must deliver work that benefits the organization and regularly understand needs, performance, and consequences while speaking to the value of each type of work (features, defects, technical debt, and risk) for the organization’s goals and technology. However, accountability for delivery can also fall on the engineering manager if the team structure includes one. The debate over the effectiveness of product owners leading teams, levels of team toil, and the role of Scrum Masters in assisting them is widely discussed in articles, posts, and podcasts.

The Problem

The problem with traditional approaches to work management is a need for balance in decision-making, clarity of roles, and conflicts of interest; there needs to be more common alignment and shared understanding of goals between the team and the organization. This is a human-driven problem, not one with Agile, Lean, or DevOps techniques. In the industrial era, work was predictable, and workers followed orders from managers with little autonomy. In the previous waterfall software development generation, IT served as the customer of the product team or business, with projects managed by project managers but limited purpose and authority for IT workers. This mindset and experience can create difficulties in transitioning to an Agile working method. It may be assumed that the Product Owner initially instructs the team on what to do; however, this approach only works if Agile is implemented with a more collaborative approach, where the team works together to prioritize and allocate work that aligns with organizational and performance goals.

Having the Product Owner decide what the team should work on can be a conflict of interest with the other types of work.

Three key books helped me to shift my mindset, Team of Teams 2, Turn the Ship Around 3, Team Topologies 4.

Teams

Great teams comprise exceptional Product Owners, Agile Leaders, and Technical Leads who can collaborate to achieve remarkable outcomes.

Product and IT teams must work as colleagues, not just customers and suppliers, to deliver solutions to external customers. In this context, I refer to having a small cross-functional team design. The product owner is on the same hierarchical level as developers and other team roles, each drawing on their expertise. The product owner knows the business and customers, while developers are experts in product implementation, performance, quality, and development processes. The production or operations engineer has expertise in cloud solutions, scaling, and cost. By combining their skills and working together as a team, they can allocate and prioritize the four types of work to meet organizational and performance objectives, leveraging the power of social capital.

Skills

Your teams benefit from having T-shaped skillful team members. T-shaped skills are a combination of exceptional competency in one particular field (represented by the vertical line) and an understanding and proficiency in related areas (horizontal line). Your teams should have clear roles and responsibilities around each member’s primary skills (vertical line in T-shaped skills).

Effective teams do not have an “us” versus “them” mentality (product versus technology), wherein one position dictates all work assignments. By creating a balanced team aligned with the organizational and platform investment goals, joint decisions can be made about work prioritization within a set time frame. Collaboration ensures that teams have a clear purpose, an understanding of business and customer needs, unity of goals, and the ability to achieve company objectives successfully. The organization benefits from the team’s prioritized work. To assess team performance:

  1. Consider the impact of your Product Owner and Agile Leader.
  2. If the team is struggling, ask if they have a clear understanding of organizational goals, their work’s impact, and if they are being encouraged to make decisions or kept on a tight leash.
  3. Ensure that the team has a unified understanding of the four essential components of work and that the senior leadership team understands how the team’s prioritization contributes to both short-term and long-term objectives.

A Solution: The Agile Leader

Some organizations that move from waterfall to agile practices have started to overlook the significance of the scrum master role. A misunderstanding or grasp of the role or financial constraints leads organizations to remove this team member, divide the role responsibilities among other positions, or assign different individuals to take turns as the scrum master. I suggest that the Agile Leader (also known as Scrum Master or a similar title) plays a vital role in achieving high-performing teams and exceptional delivery performance based on team structure and work requirements.

Assumptions of your Agile Leader or Scrum Master:

  1. Belonging to a team: You are a permanent member of one or more teams and refrain from frequently switching between teams or floating in and out of them.
  2. Facilitating delivery: You are dedicated to fostering a productive and collaborative environment within your team by coaching, encouraging team practices, promoting psychological safety, and facilitating communication and decision-making.
  3. Improving team performance: You are responsible for continuously evaluating and improving your team’s performance, helping to remove any barriers impeding effective delivery.

As a Product Owner, it is part of your job to be aware of the value behind your product, explain its worth to teams and stakeholders, comprehend and communicate what needs to be accomplished to deliver the product, and undertake many other duties. However, the responsibilities of coaching, motivating work practices, objectively evaluating team health, and driving effective delivery may better fit the role of an Agile Leader, with the Product Owner focused on delivering features. The Technical Leads and Developers focused on technical debt, quality, and risk; the Scrum Master or Agile Leader is the only role free from conflicts of interest and can focus on the team’s health, promote collaboration, identify anti-patterns, resolve conflicts, and encourage team members to solve them. With agile leadership, the potential for conflict of interest is removed.

Good Agile Leaders lead teams.

Agile leaders, coaches, and Scrum Masters strongly understand empathy, giving and receiving feedback, and the human side of our work. They place a high priority on the happiness of their teams. Incorporating it into Scrum, Lean, and Kanban gives you excellent tools, techniques, and leadership skills for managing workflow effectively.

Agile leaders play a crucial role in fostering collaboration and enabling team members to reach their full potential. They are trained to coach, facilitate team conversations, and create a productive environment where everyone feels supported as a product owner, technical lead, quality assurance personnel, or any other role. Effective coaching is a crucial aspect of the Agile leadership role; it aims to empower individuals with confidence and knowledge.

Agile leaders continuously invest in their core abilities. To offer the best advantages to their teams, they focus on cultivating T-shaped skills and learning enough about other teams’ needs and roles. A well-rounded viewpoint comes with expanding one’s knowledge outside of regular practices.

Team Delivery Efficiency

Agile leaders should facilitate processes and take a proactive role in ensuring delivery efficiency. This is achieved by incorporating metrics and practices that monitor and enhance delivery speed and quality. Experienced Agile Leaders help teams identify waste and bottlenecks in delivery and encourage collaboration and conversations to improve flow. They highlight how measuring flow (delivery efficiency) and realization (value impact) ensures you’re building the right things and building them efficiently. Operational efficiency improvements must focus on both. While teams focus on flow (delivery efficiency improvement), Agile Leaders can challenge product management to define and track anticipated outcomes to avoid misalignment with broader goals, ensuring feedback loops in verifying value realization.

Partnership

Skilled Agile Leaders, Product Owners, and Technical Leads are the three foundation pillars of delivery teams. Agile leaders should provide a strong foundation of trust between themselves, the Product Owner, and the Technical Lead by having regular one-on-one meetings with each team member. They can use coaching contracts for these discussions to help them review what the Agile Leader has observed, what the team is saying, and, vice versa, what the Product Owners or Technical Leads have observed. This approach can improve collaboration, prioritization, alignment, and team delivery.

Comparing an Agile leader to the head coach of a football team is a fitting analogy. The Product Owner can be viewed as the offensive coordinator and the Technical Lead as the defensive coordinator. Like head coaches, Agile Leaders must develop strong relationships with their team members and proactively remove obstacles that impede effective delivery. The success of the delivery teams can be correlated to the effectiveness of the Agile Leader in fostering a supportive and collaborative environment and accepting that part of their role is to coach others and teams to become better at what they do.

I created the following picture to illustrate this model:

Underlying image from Apple TV’s Ted Lasso, Warner Bros. TV.

Good Agile Leaders are in tune with team health and keep a team moving forward.

Final thoughts: Providing the team air cover

Suppose you subscribe that the agile leader role, having the least conflict of interest, can guide, arbitrate, and encourage team decisions through collaboration. In that case, Every team still needs a reliable shield to bear the heat when things go wrong. Usually, this is done by a senior leader or an experienced team member with organizational clout. When the team has unity in goals and skills, psychological safety, enjoys their work and sees the purpose in the value they deliver, motivation to grow better, and authority to make their own delivery decisions with someone who always has their back — then you know they are unlocking their full potential.

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. Mik Kersten (2018), Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press
  2. Stanley McChrystal, Tantum Collins, David Silverman, Chris Fussel (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio
  3. L. David Marquet (2013). Turn the Ship Around!: A True Story of Turning Followers into Leaders. Portfolio
  4. Matthew Skelton, Manuel Paris (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press

Filed Under: Agile, DevOps, Leadership, Product Delivery, Software Engineering

The Artistry of Software Engineering: Harnessing Creativity for Impactful Business Solutions

September 17, 2022 by philc

5 min read

“Software is a great combination of artistry and engineering.” – Bill Gates

As a senior leader and software engineer, I have witnessed the exceptional capabilities of software engineers firsthand. I recently came upon a conversation that software engineers are human. Of course, they are. After catching up on the context for the statement, it centered around measuring individual software engineers and how older physical production line measures were morphed into earlier attempts to measure engineers’ performance. Hopefully, organizations treat all employees as humans in their approach to performance and culture. The role is not distinguished by the fact that the workers are human or non-human but rather by the need for problem-solving skills, creativity, and experimenting and managing unknowns.

Software development differs significantly from traditional manufacturing processes, such as car production or house building, where the end product is well-defined and established. In software development, there is inherent uncertainty and the need to manage unknowns, aptly described by the Cynefin framework1. Whether your software development and delivery lifecycle is more function-based and waterfall, cross-functional and agile, lean, or a combination thereof, it is not uncommon for scope creep to occur. Could this be due to consistent learning and uncovering of unknowns throughout development? Understanding how we look at software engineering work and measure software engineers’ performance and return on investment in a company is important.

Unfortunately, many organizations still rely on traditional productivity measures that treat engineers like factory workers churning code. This viewpoint is flawed, as software engineers are skilled problem-solvers who creatively craft elegant solutions. Software engineers are more akin to artists than factory workers. Just as we would not evaluate a painter’s worth by the number of brushstrokes or paintings they create, it is crucial to understand that assessing a software engineer’s productivity extends far beyond the lines of code they produce.

The Human Side of Software Engineering

I agree that it’s important to acknowledge that software engineers are not machines but human beings. By recognizing their human side, we can better understand what drives their creativity and passion. Software engineering is a unique mix of art and science that requires technical expertise, problem-solving abilities, and a keen sense of intuition. A software engineer must balance constraints and opportunities to deliver a functional or visually appealing solution like an artist.

Each software engineer brings a unique approach to implementing solutions, and addressing problems, informed by their experiences, knowledge, and innate talents. This diversity of thought and process makes the field dynamic and exciting, ultimately driving innovation and business growth.

Creating Impactful Software and Fostering Team Satisfaction

In software engineering, team satisfaction is closely tied to creating and shipping products that make a tangible difference. Teams feel a sense of pride and accomplishment when they see their work in the marketplace, positively impacting users and solving real-world problems.

Streamlining the process of shipping software can raise team engagement and enjoyment. This involves providing the right tools, support, automation, and environment to help engineers transform their ideas into reality. Capturing and sharing data-driven insights that motivate teams to improve by identifying bottlenecks is also important. A culture of safety, open communication, and collaboration can help teams navigate challenges more effectively and create more impactful software.

The Importance of Developer Experience for Business Success

A crucial aspect of software engineering that often goes overlooked is the “developer experience.” Generally, developer experience refers to the environment, tools, and culture in which software engineers work. Fostering a positive “developer experience” is vital for nurturing the growth and creativity of these talented individuals.

A supportive and engaging workplace can make all the difference in enabling software engineers to explore new ideas, experiment with different techniques, and ultimately create innovative solutions that drive business value. Conversely, a stifling or uninspiring environment can impede creativity and hinder progress.

Measuring Productivity – A Business-Centric Perspective

To evaluate software engineering productivity honestly, we must move beyond basic measures like counting lines of code or completed tasks. Instead, we should consider an engineer’s work’s overall impact on the business. Depending on your organization’s team structure, team metrics may be more valuable than individual metrics. New methods and practices are available for measuring team productivity and efficiency that don’t focus solely on individual performance. Consider shifting your focus from individual productivity to individual performance. Some factors to consider when assessing a software engineer’s performance might include the following:

  1. The quality of the code produced – Is it efficient, scalable, and maintainable?
  2. Collaboration and communication – Does the engineer work well with their team, fostering innovation, sharing and receiving feedback, and team member support?
  3. Adaptability and growth – Is the engineer continuously learning, adapting, and refining their skills to stay ahead in the competitive landscape?

Conclusion

Software engineering is not merely a routine job on a production line. Instead, it involves a complex and imaginative process that requires a combination of technical proficiency and artistic flair. If businesses appreciate the crafting aspect of software engineering, provide a supportive environment for developers, and emphasize producing and delivering purposeful software, they can unleash the full potential of these skilled individuals and empower them to come up with innovative creations.

References:

  1. Cynefin Framework. https://thecynefin.co/about-us/about-cynefin-framework/

Poking Holes

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

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

Filed Under: Agile, DevOps, Lean, Software Engineering

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 5
  • Go to page 6
  • Go to page 7

Copyright © 2025 · Rethink Your Understanding

  • Home
  • Practices and Mission
  • Collaboration
  • AI
  • Posts
  • Podcast
  • Endorsements
  • Resources
  • Contact