How to design and implement a POD-based DevOps operating model

The do’s and don’ts for successful adoption within your enterprise

In my previous blog, I outlined the necessity for a new POD-based operating model and the benefits it can bring throughout a successful DevOps and Agile transformation. In this blog, we’ll look at how you can actually design a POD-based DevOps operating model, the dos and don’ts for its successful adoption within your enterprise, and a real-life implementation case study.

You build it – you run it: the roles and structure needed for successful POD-based model implementation

The POD-based model is centered on the DevOps best practice of “you build it – you run it.” This means POD teams assume full ownership and accountability for a product from build to support. A POD-based model consists of dedicated roles with complementary skills that are confined to a POD, shared roles that are spread across the PODs as needed, and CoE teams that define standards:

Dedicated roles – POD model dedicated roles include:

• Scrum Master
• Product/Tech Lead (for detailed design/architecture)
• Technical/Business Analyst
• UI Developer(s)
• Back-end Developer(s)
• SDET (Software Development Engineers and Testers)
• DevSecOps Engineers and Cloud Engineers.

Shared roles – POD model shared roles used across PODs include:

• Governance roles – Product Director and Product Owner
• Coaching roles – Agile/DevOps Coach(s)
• Architects – Enterprise, Application, Data, Cloud, Security, etc.
• SRE – Site/Service Reliability Engineering Specialists

CoEs – to establish standards, best practices, frameworks, accelerators, KPIs, and Metrics, a POD model utilizes a host of different CoEs that include:

• Agile
• Cloud
• Automation
• Quality

                                                A typical POD structure

PODs should be structured by product and business area. They may also be set up within a product – using the following criteria across products during demand fluctuations:

• Technology they service (Java, .NET, Angular, Python etc.)
• Software package they service (Sales Force or SAP etc.)
• Location they serve or are present in (US, India, Europe, Mexico etc.)

PODs may be classified by the code change management process within an organization. For example, there could be a POD for performing the design and development of large enhancements, a POD for minor enhancements, and a POD for hot fixes as detailed below:

• Small-POD (unplanned work) using Kanban and fixing priority tickets/production incidents
• Medium-POD (minor-enhancement POD) implementing small enhancements and fixes
• Large-POD (major-enhancement POD) for implementing large enhancements and fixes.

What are the do’s and don’ts of working with a POD-based operating Model?

Dos:

• Do staff a POD with self-motivated, self-driven, and correctly skilled professionals
• Do train all team members on POD-based operating models and standard operating procedures within a POD-based model
• Do address any people issues within POD teams and remove any friction, as good compatibility and collaboration are essential for success
• Do meet periodically with POD members if they are not collocated
• Do share best practices across PODs so team members learn from each other’s experiences
• Do use collaboration tools to build trust and real-time feedback.

Don’ts:

• Don’t expect overnight success, but allow time for the POD model to succeed and manage/micro-manage POD teams – empower PODs so they learn together, fail fast, and deliver
• Don’t track defects logged but track their deliverables – story points/velocity
• Don’t dismantle PODs working on a product – retain them for longer periods.

Case Study: POD-based operating model for a large utility client

One of Capgemini’s large utility clients was looking to attain IT operational efficiencies through a POD-based operating model solution that would ensure the delivery of all current services, and drive cloud adoption, micro-services architecture, automation, and DevOps transformation – along with a 30% reduced headcount after five years. The organization’s applications are grouped by value streams and Capgemini assessed each technology used in each value stream of applications. The salient features of the POD model are listed below:

• PO and Scrum Master are assigned to one value stream and are not shared across value streams
• Developers and Testers have a primary assignment to one value stream and can work on all apps in the value stream
• Developers and Testers have a secondary assignment to another value stream and have knowledge of apps in that value stream
• The intent is to have Developers and Testers develop a deep understanding of apps in two value streams – and not require knowledge transfer for implementing/testing changes or err in quality for lack of value stream knowledge
• After sprint planning in a value stream, the product owners perform sprint planning across the value streams and assign stories/tickets to resources that have bandwidth and knowledge of the value stream applications
• The shared resources, DevOps engineers, Architects, Test Automation Engineers, DBAs, etc. can work across all apps in all value streams

The POD-based model would follow the DevOps best practice of “you build it – you run it” and the same resources that implement a change will perform the maintenance.

A POD operating model for a Utility client: POD sizes, skills, and sharing across two value streams for better utilization and value stream apps knowledge

POD models vary from enterprise to enterprise and significantly depend on current operating models. They need to be designed closely to the existing model and align with variables such as technology, location, vendors, and size of teams for their acceptance and adoption. A POD-based model assumes that as organization is already on its Agile and DevOps journey – and we recommend defining your target POD model based on some of the best practices defined in this article, along with implementing in phases by product, continuously improving the model, and taking in feedback from teams.

In my next blog, I’ll be delving deeper into accelerators and tools for implementing a POD-based operating model with more client case study examples.

To find out more about POD-based DevOps operating models, contact me now to get started or visit us at Capgemini’s ADMnext here.

Venky Chennapragada

Expert in DevOps

I am working as DevSecOps Leader/Architect at Capgemini, leading many large enterprises Bi-Modal IT, DevOps transformations. I Lay out DevOps Strategy, perform current state assessment, do value stream mapping, build road map, business case and a blueprint. I work on automating Environments on AWS, AZURE Clouds. I build Container Orchestration using Docker Swarm/Kubernetes, Setup CI/CD using AWS cloud formation templates, Azure Resource templates or Ansible scripts. I am responsible for source code management to build engineering to packaging to release management.