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
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.
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.
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.