Product PODs Reimagined–From Ideal to Real

Product PODs (or product-oriented delivery for accelerated software development) were envisioned as a vehicle to reduce time-to-market, enhance engineering maturity and foster innovation. POD models work well for Wipro’s customers or any company that is facing challenges like delayed launches, lost revenue opportunities and innovation taking a back seat to engineering scaling issues. 

But when the pandemic hit, POD launches and structures were severely affected. Co-location was no longer an option, customer priorities changed and goals were modified to work as quickly as possible and support both new and existing programs. This led to the creation of different POD models, which carry the same values and philosophy of traditional PODs but were customized to align with emerging needs and challenges. 

The Ideal POD

A co-located multi-disciplinary agile team allows companies to achieve higher efficiencies. A typical composition includes a team of backend and frontend engineers and designers supported by quality and DevOps and led by an architect who acts as the product owner. The team is equipped with niche skills – UI, cloud-scale/native, microservices, DevSecOps, AI/ML – and expertise in reusable solution accelerators and modern toolchains that can significantly help improve productivity and quality of product development.

The tyical POD team characteristics include outcome-driven product development with adherence to Agile principles. PODs are self-organizing teams with a product engineering mindset that focus on people and communication. They are designed to specifically follow modern product engineering practices while focusing on non-functional expectations.

PODs Reimagined and Restructured

Classic POD

The Classic POD includes 6-8 members with complementary skills. The team works as a single unit for accelerated software product engineering. This model is most relevant when faster release cycles and time to market are required. The best KPIs for this model include sprint goal success rate, velocity trend, business value-added, failed deployments and cross-team collaboration. The Classic POD works best with fixed capacity, outcome-based and sprint-based costing business models.

Compose POD

This POD model includes a POD owner who defines, plans and coordinates all work. It requires a strong leader who guides and acts as an orchestrator to the entire team. This model is most relevant when individual work items are not very complex and can be handled by the junior team, but a leader is needed to own and coordinate the overall deliverables. The best KPIs for this model include sprint goal success rate, velocity trend, failed deployments, cross-team collaboration and skill versatility. The Compose POD model works best with fixed capacity and outcome-based business models. 

Incubate POD

This POD model typically includes 1-2 members of a full-stack team. It is suitable for quickly realizing and validating a proof of concept (POC). Once the POC has been validated, the client can convert to a Classic or Compose model. The best KPIs for this model include time to market and satisfaction surveys. The business model for this POD is time and materials (T&M).

While the composition of the different models changes, the characteristics which define an ideal POD – one team, ownership, cross-team collaboration, a culture of excellence, delivery focus – should always be included.

Key Challenges of Different POD Structures

There are key challenges to address when building PODs for different customers including skill availability, ensuring product quality, the need for polyglot programming, infrastructure concerns and the rise of remote work.

• Skill availability : Finding the right skill at the right time is an issue for any POD model. To address this issue, an architect community can be utilized with diverse backgrounds to identify and train on future needed skills. Additionally, each POD should have at least one member with the required domain skills. To fill any gaps, focus on effective communication within the POD.
• Ensuring product quality : For best product quality, focus on non-functional requirements (NFRs) from day one even if not explicitly called out. Include UT, code coverage and automation in the definition of done. And build a culture of shared accountability.
• Need for polyglot programming : Each POD member should be trained on the required primary and secondary programming languages. Supporting new languages can be enabled via the architect community.
• Infrastructure : Work with customers to ensure POD members have the same infrastructure as the customer team. Challenges and performance impact should be clearly articulated and highlighted to senior management. Identified dedicated SPOCs to help resolve infrastructure-related issues.
• Remote Work : Conduct regular meetups and ice-breaking sessions to ensure a “team connect” environment. POD onboarding sessions should be conducted for any new team members.

Best Practices for Any POD Model

Regardless of the POD model in use, several best practices should always be followed. Include at least one POD member with domain skills and expertise and make a plan to upskill the rest of the team.Always enable alignment with customer-used productivity tools. Every POD should support polyglot programming and every POD member should be skilled in one primary and a minimum of one secondary language/technology. When setting up the POD and the infrastructure, do not compromise on the dev environment. Make resolving any infrastructure issue a high priority. Always focus on NFRs.

The best-laid plans can go awry but a team with the right set of skills and clear objectives can help overcome any challenges. PODs are a good solution to meet today’s challenges. They are very much in demand, can scale and can be the differentiator between a good and a great product. The focus must be on creating the right foundation for the PODs – considering both domain and technology. Put equal importance on both tech and soft skills to build a strong agile culture with a product mindset. 

Radhakrishna Singuru

Chief Architect, Cloud Platforms and Security Engineering Practice, ER&D, Wipro Limited

Radha has more than 25 years of experience in product and system software engineering. His experience spans cloud and virtualization technologies, security, distributed systems, network switching and stacking software in multiple industry domains.

Rajan Singh

Program Manager, ER&D, Wipro Limited

Rajan has more than 16 years of experience in project and program management. He has led several critical programs using Scaled Agile, Scrum and Waterfall methodologies for industry-leading organizations.