Becoming a game-changing product of your environment

Traditional IT delivery models are project centric – and demand, delivery, and measurements are all project based. Projects are short lived and putting a together a new team for each project requires the team to be trained on the domain, processes, and tools. This can lead to quality issues stemming from human error and can cause project delays due to new teams implementing them. The teams work together for shorter time periods – and hence – there is no real meaningful bonding or deep collaboration. The teams also have no ownership or accountability.

In today’s markets, this project-based approach does not serve businesses well – especially when they’re under constant pressure to bring fresh products to market, acquire new customers and retain existing ones. So, in this blog, we’re going to be looking at a product-based approach and how this can help you to better deliver to your customers through improved quality, speed, and employee morale.

Product-based delivery models are customer-centric – and implement a 360° strategy and vision

In product-based delivery models, teams work as independent, empowered units and assume total product ownership. They form the heart of your enterprise’s culture – orchestrating product-specific requests, technical improvements, and horizontal needs across cluster and area borders. The DevOps best practice of “you build it, you run it” is implemented, thereby increasing trust and collaboration between the teams.

Product team members no longer solely execute based on demands but take a more strategic role within your services and operations. They embody and communicate your vision throughout your entire organization – and play an active role in creating:

• Responsive, end-user-facing systems for better customer experiences
• End-to-end business and IT alignment that brings different stakeholders into a “One Team” culture for improved agility
• Heightened speed and synchronicity within product areas and products for faster delivery.

When implementing a product-based DevOps strategy, firstly, we define multiple product areas based on your business functions and current operations. We then structure development teams around them.

The result is a pragmatic approach with “product teams” that feed up into product clusters and then expand into broader product areas.

More products, more problems?

However, as your business grows and your product offerings expand and shift, product teams will need to multiply and change in order to support each of your products. New and growing product teams can drastically increase structural complexity, and duplications and inconsistencies may start to appear.

More talent, fewer problems?

This complexity brings a real demand for multiskilled teams, which may get tougher and tougher to fulfill. Generally, DevOps teams have higher costs due to the deep and wide skillset expected.

The issue of costs here can be compounded further. When organizations implement a product-based approach, a huge volume of operational tasks is moved into your DevOps structure. This can create challenges such as the under-utilization of high-cost talent for more standard, commodity activities. And this can lead to a high-cost pyramid, demotivated developers, and even a loss of business focus. The higher the operational and commodity activities, the lower the value extracted from highly skilled and expensive resources will be.

Additionally, a lack of industrialization can boost the cost of operations, as developers are now broken down into smaller teams. While a lack of standardization and the duplication of tools can hinder harmonized processes, quality, and operational excellence.

ADMnext: putting it all together from the bottom to the top – balancing your appetite for speed and agility with costs and structural challenges

We want you to get all the benefits of a product-based DevOps strategy, while also addressing costs and structural challenges. So, after analyzing market trends and listening closely to our clients, we devised a transversal model for product teams. This model delivers technology and application-independent services across product teams, which we call non-backlog services.

This ensures that we have an overarching structure to unleash DevOps benefits across all individual product teams. This then dovetails with the strong, harmonized foundation of product teams from the bottom up, which enables industrialization, automation, synergies, and correct production costs.

You can also find out more on how a product-oriented mindset, and embracing and implementing DevOps across your organization can really maximize business value in our joint report with Everest Group®: Applications Transformation for the Digital Age – From Delivery Excellence to Business Value.

And to learn how we can help you effectively implement product-based delivery models, contact me immediately or visit us at Capgemini’s ADMnext here.

Author

>

Venky Chennapragada

Application Services