Why POD-based DevOps operating models are so popular in DevOps adoption
Blog: Capgemini CTO Blog
Enterprises typically build their operating models around functions they perform like development, testing, operations, or support, etc. Legacy IT operating models are usually SLA driven and have become siloed with minimal coordination, little to no feedback, and a lack of trust. For successful Agile & DevOps transformation, teams are tasked with working cohesively and delivering consistently within a fixed time frame in a sprint. From my experience, changing people – or rather – changing the culture is 70% of the overall effort.
A POD-based operating model for DevOps can help here with cross-functional agile teams that work cohesively on common objectives, a new mindset for collaboration, emphasis on the team rather than the individual, an openness to experimentation and innovation rather than finger pointing or blame games, and total ownership of the product from build to run. In this three-part blog series, I will showcase how a POD-based operating model can address all of the above short comings and pave the way for successful Agile & DevOps transformation, which delivers more value to end customers.
Why do we need a POD-based DevOps operating model?
Ineffective operating models can lead to decreased productivity, poorer quality, and lower employee morale and customer satisfaction. They can also create bottle necks and increase cycle times and waste. Additionally, technologies are evolving more and more rapidly – and so are customer expectations. While businesses are under constant pressure to bring new products to market and acquire customers and retain existing ones. A POD-based operating model can help you here by breaking down traditional organizational structures into autonomous, self-governing and independent teams. But, in order to successfully adopt a POD model and become more productive, effective, and engaged, these teams require a shift in mindset. Overall, a POD-based operating model can offer your business the following benefits:
- Improved communication, alignment, and productivity
- Increased product knowledge for improved quality
- Increased employee morale with heightened ownership and autonomy
- Reduced external dependencies, as a POD model is fully responsible for all tasks
- Single-team ownership speeds up the process and ensures accountability with higher quality
- Better utilization of resources with common skills.
What is a POD-based DevOps operating model?
A POD is a cross-functional team that implements the DevOps principle, “You Build it and You Run it,” and is responsible for the design, development, test, and run of a Product. A PODs consist of 4-10 professionals with complementary skills like business and functional analysis, design and development, and testing. The POD is responsible for some or all applications within a Value Stream.
The diagram below illustrates macro and micro POD-based operating models.
FIG 1.0: Macro and micro POD-based operating models
A macro POD-based operating model provides leadership and end-to-end ownership of product-sets responsible for:
- Overall governance, KPI measurement, and reporting
- Security, SOX, and architecture standardization
- Demand and capacity management
- Monitoring, audits, and Site reliability
- Continuous improvement in operational and cost efficiencies driven by the DevSecOps CoE
- Innovation and scalability driven by the Architecture CoE
- Continuous business process maturity and change adoption driven by the OCM CoE.
A micro POD-based operating model focuses on:
- Feature implementation organized in the form of autonomous and self-sustaining PODs
- POD team composition and size based on product, application, and technology complexities, and future product backlog and roadmaps
- Geographical distribution (collocation) based on the high-touch customer experience requirements of applications and integration with business teams for a given product and business segment.
POD in action: Building a POD-based operating model to help a high-tech client adjust to changing priorities and new opportunities
One of Capgemini’s larger network clients was looking for skilled resources in technologies and packages like: Java, Data and Analytics, DevOps, MuleSoft, Salesforce, Pega, Kafka, and Monitoring. This client’s applications are grouped by value streams and matched to fast changing customer needs in its customer experience organization they expect priorities to change rapidly and be open to new opportunities. Hence, this organization define an operating model that is flexible and extendable and can better utilize resources based on demand. Capgemini worked with this client to define the POD-based operating model illustrated in the figure below to address fluctuating demand.
This organization uses a Scaled Agile Framework (SAFe) for Agile transformation. The product owner for Value Stream 1 conducts product increment (PI) planning for the backlog and then conducts PI planning across the Value Streams with other product owners. The Value Streams that have available capacity would appropriately share their PODs with other Value
Streams that have a demand for similar skills. Overall, this operating model provided the following benefits to the client:
- Decreased time to market for new enhancements and change requests
- Enabled the formation of Flex Teams to adjust to changing priorities and new opportunities
- Improved ROI in resource utilization
- Accelerated Agile and DevOps adoption
- Improved customer experience.
FIG 2.0: A POD-based operating model for a large high-tech client
In the following two blogs in this series, I’ll detail how you can design a POD-based operating model for your business, along with key dos and don’ts for PODs. Additionally, I’ll outline a path for successful enterprise-wide adoption and the benefits you can expect to reap. We’ll also delve deeper into accelerators and tools for implementing a POD-based operating model with more client case study examples.