Product-oriented DevOps: Coaching Teams to Deliver Exceptional Products

In the realm of DevOps coaching, the value of guiding teams is significant as it fosters resilience and exceptional performance, especially amid challenges. This proactive approach not only equips teams to surmount obstacles, but also instills a mindset of continuous growth and enhancement.

At the heart of this coaching process lies the shift from a project-focused perspective to a product-oriented one. Unlike projects with fixed boundaries, products evolve organically to meet evolving customer needs, highlighting the necessity for adaptability. The shift to a product-centric mindset cultivates flexibility, innovation, and a broader outlook, enhancing teams’ capacity for change and market relevance.

This summary delves into the third episode of The Art & Science of DevOps Coaching series, “Product-oriented DevOps: Coaching Teams to Deliver Exceptional Products,” highlighting the journey from rigid project thinking to dynamic product approaches, the importance of a customer-centric ethos, and the instrumental role of coaching in facilitating this transformative process. These key takeaways also uncovers strategies for introducing product management practices, the art of balancing autonomy and standardization, and the pivotal role of effective communication and collaboration within this paradigm shift.

Managing a Project to Product-Oriented Shift

The role of DevOps coaches in an organization serve as the cornerstone for bolstering confidence and offering support to achieve the high performance required to accomplish business outcomes, particularly during periods of heightened challenge. This proactive approach not only enables team members to tackle difficulties, but it also instills a mindset of resilience and continuous improvement.

As a significant part of this coaching process, there is a compelling need to shift the focus from a project-centric perspective to a product-oriented one. While projects have defined start and end dates with fixed scope and objectives, products are continuous and evolve over time to meet customer needs and deliver ongoing value. This transition highlights the importance of flexibility and open-mindedness within teams. Instead of considering deliverables and initiatives as isolated projects, viewing them as components of the product life cycle helps cultivate a broader perspective, making teams more adaptable to changes and fostering innovative thinking while delivering customer and market value.

Typically, projects have set timelines, clear instructions, and a specific focus. But while we’re working on these projects, the world keeps changing. Projects often rely on outdated information and take a long time to complete. Project commitments can lock us into a specific focus and delivery expectations, even as the world around us continues to evolve. This is the major difference between having a fixed mindset and a growth mindset. A fixed mindset, often associated with a project-oriented approach, tends to emphasize completing predefined tasks and projects within set parameters. The focus is on achieving short-term goals and adhering to predetermined plans, potentially limiting adaptability and innovation. A growth mindset, aligned with a product-oriented approach, encourages continuous learning, adaptation, and improvement. This mindset emphasizes delivering ongoing value to customers through iterative cycles of development, feedback, and refinement. A fixed mindset can lead to rigidity in project execution, while a growth mindset drives a dynamic product-focused approach that values customer-centricity, agility, and innovation.

We should prioritize what is the most relevant experience users are looking for right now and always be evaluating and adapting our ways of working. Adopting a product mindset allows us to use up-to-date data to make decisions and learn as we go. Once a product is continuously delivered to the customer, we should focus on learning from that ongoing experience and planning our next steps, rather than sticking rigidly to a long-term plan.

A product mindset is all about the customer instead of delivering a pre-defined scope. It means promising to do our best to deliver value not just at the end of the project, but every day. It helps us be adaptable and focused on the customer. However, making this shift can be difficult as many companies and organizations are used to working in a project-oriented way.

That’s where coaching comes in, enabled by leadership to empower the product managers. Coaches help translate the company’s vision into clear, achievable goals. A good coach gives confidence to their teams to do things differently in a pragmatic way and provides education, hands-on support, and guidance. Coaches can help teams become more empowered, adaptable, and empathetic, and they can promote a culture of learning. The role of a product owner is also important here, particularly in terms of building up psychological safety, and developing feedback loops from customers and the team itself. Shorter cycles, regularly incorporated customer feedback, and a willingness to adapt are all essential. In growing the team towards DevOps excellence, product owners rely on coaches for a mindset shift from command and control to mission command driven by compelling purpose. In a transition to a product owner role, the coach is the one enabling the person to be an adaptable leader and practice active listening. Leaders on the other hand, should be there to provide support, guidance, and help in overcoming difficulties, all leading to valuable and meaningful work.

Coaching for Product Management Practices

To efficiently introduce and embed product management practices into a DevOps team’s mindset and daily work, a coach needs to focus on five key areas: setting clear team objectives, coaching the product owner, being pragmatic with practices, understanding the product and its team, and avoiding creating technical debt that leads to re-work.

Defining objectives and understanding context: When initiating a broader transformation or coaching your DevOps agile team, it’s crucial to begin by defining clear objectives and aligning what you’re aiming to achieve. Recognize whether the objective is faster delivery or more value, and establish the specific context of the organization or team. Identifying potential impediments to these objectives, such as problematic process flows or psychological safety issues, is a vital step in the coaching process.
Coaching the product manager: When working with Product Owners, personalized coaching and precise translation of business requirements into actionable items are essential. A good approach here would be to focus on what matters right now, and start working towards delivering it in small steps. This includes engaging the business in key steps such as demos and reviews to show value added in small iterations, and emphasizing the importance of meetings through cost analysis. Encourage a culture of experimentation and learning from failure to foster growth.
Be pragmatic: Implement effective practices that simply work for that particular team, such as 121 coaching, planning poker to estimate complexity, and retrospectives, to facilitate better communication and continuous improvement. Encourage the use of these and other techniques to explain the need for change and overcome resistance. Consider here resistance to change and overcoming it by organizational change practices.
Understanding product lifecycle: Focus on understanding the loop of a full product life cycle, from discovery to delivery and back again, which allows for quick learning and adaptation. Diving deeper, discovery is about what makes the life of a customer easier based on data and evidence. Then, as soon as possible, deliver fast your assumption to verify the hypothesis; learn from your customer to validate their needs and come to short feedback loops really fast. When it comes to releases, start with a limited release to speed-up the delivery lifecycle as much as possible.
Avoid technical debt and re-work: To avoid duplication of efforts, establish clear boundaries and guidelines. Promote collaboration and encourage thoughtful consideration of existing solutions to foster innovation and efficiency instead of starting from scratch.
Minimal viable team structure: Consider creating minimal viable teams of 8 to 10 members that can effectively support specific product aspects, promoting agility and efficiency. “Slicing and dicing” the teams work the same way as your architecture by, for example, introducing micro-services that will support faster implementation and higher reliability as well as predictability. A smaller team can boost confidence and commitment among team members.

Balancing Autonomy and Standardization

Balancing autonomy and standardization in a team-oriented setting can present an intricate challenge. Guiding teams towards shared objectives is paramount, with a primary focus on converting customer needs into product discovery. This approach necessitates consistent interaction with the teams, including regular check-ins to discern similarities and recurrent themes. By actively identifying teams engaged in similar tasks, redundancy can be minimized, promoting efficiency.

Establishing a conducive environment for open discussion and collaboration is vital for fostering teamwork. Overlapping efforts should be acknowledged and addressed, urging a shift towards collaboration rather than competition. By promoting a culture of learning, mistakes are no longer seen as failures but rather valuable opportunities to refine processes and make improvements.

Effective communication forms the backbone of these strategies. It helps to align efforts, avoid duplication, and facilitates the sharing of experiences, findings, and solutions across teams. This collective learning is an asset to the organization, promoting faster problem-solving and innovation.

Experimentation with tools should also be encouraged. However, it’s important to consider the team’s workload and objectives while introducing any new tools. An analysis of potential benefits and costs before their adoption ensures that the tool serves a purpose and isn’t just changed for the sake of it.