Essential Agility: How POD Teams Help Drive Change

The Agile methodology is everywhere now: in software development and project management, but also (lower “a” agile) used in other areas of business, from marketing to sales. It’s a customer-centric approach, favoring frequent iterations over what’s seen as a more step-by-step, plodding, linear strategy.  

In our change-driven and pace-centric times, I applaud this initiative, even if I sometimes wonder what exactly it means, day-to-day. 

One area I’ve seen the direct application (and benefit) of true organizational agility is through Product-Oriented Delivery (or Development, aka POD) teams. 

The idea behind POD teams is not new. They surged to prominence in the Covid-19 period as small, self-sufficient groups that could keep safe while getting things done autonomously. And they have since evolved into something both sustainable and scalable. 

Cross-functional teams that own their own tasks can be the ultimate form of agility (or Agility) and I’m a strong advocate in the right circumstances. At PTP, we’ve seen properly implemented and supported POD teams show dramatic increases in efficiency with decreased costs, all while improving employee satisfaction. 

Sound too good to be true? 

They are not without their challenges, and not right for every scenario. Done incorrectly, PODs can bog down what they’re meant to accelerate, and drive-up costs instead.  

In this article I want to consider the increasingly essential need for adaptability and how PODs can make, or break, this initiative. 

What’s So Special About a POD? 

While a traditional organization is made of departments (people with like skills and jobs), each with its own (interlocking) hierarchy, a POD team is made to be more autonomous.  

A smaller unit built for a specific purpose (be it product, task, component), the team is made up not of like-skilled members, but of complementary-skilled ones, covering a full range of needs to get the purpose done.  

In software development this can mean 4–10 members, including technical lead/architect, UI/UX, back-end developers, DevOps, and subject matter experts, all working together, regardless of departmental hierarchy.  

They not only build their assignment, but also support, update, and run it—with full authority and accountability. While there may be a need for additional, shared resources as required (such as additional architecture, database, hardware, and automation expertise), the core necessities of the purpose are met in-team, letting it stand self-sufficiently. 

The potential benefits are many, including:  

• Direct collaboration: As the task owners, team members work together from start to finish to get a job done. 

• Increased efficiency: With experts all in-team, sharing responsibility, feedback is instantaneous, with immediate review, testing, knowledge-sharing, and troubleshooting possible. 

• Ready scaling: Like stackable units, one of the advantages is adaptability at scale. Teams can be moved to and from larger projects, and members can collaborate on other tasks without the need to break up PODs. 

• DevOps ready: The PODs team approach, with direct integration of testing, operations, and continuous development, can be an extremely effective structure for making the move to DevOps.  

The POD /Agile Fit 

I’ve written recently on Substack about Agile and the benefits for increased speed. The core principles from the original manifesto are: 

• Individuals and interactions over processes and tools 

• Working software over comprehensive documentation 

• Customer collaboration over contract negotiation 

• Responding to change over following a plan 

It’s easy to see how the POD, at its best, gets you closer to these ideals. Some view POD as a type of Agile (ala Scrum, Kanban, etc). The POD seeks to embrace the Agile methodology even in its team structures. 

The ultimate in Agile collaboration, this approach breaks down communication barriers, such as across departments and hierarchies, to put everyone needed to get a job done together. 

As a self-sufficient unit, the POD can manage its own task cycles without the chains of outside approval, further enabling fluidity and adaptability with the shortest possible sprints.  

Implementation and Challenges 

At its best, we’ve seen this approach increase efficiency, quality, and employee satisfaction, with a reduction in costs. I’ll look at some of these in more detail in a moment.  

But first I want to consider the alternative: how a well-meaning attempt to implement POD teams can instead cause greater confusion, redundancy, delay, and elevated costs.  

While success requires strong implementation, the right people, right tools, and organizational mindset, failure can come from any of these individually: 

1. Running too fast without sound structure: Agility is about deftness and speed, but without a clear (and communicated) understanding of roles and responsibilities, its more democratic structure can result in redundancy and breakdown.  The more distributed your team, the greater the chance things fall between roles, or when the inevitable problems arise, no one takes the ownership necessary for correction.  
2. Differing methodologies and ways of working: Coming from across disciplines is one of the greatest benefits of the POD approach, but it also presents challenges. Differing departments have their own ways of working, and making a POD team work means getting everyone on the same page. This extends beyond the teams, where some may still expect adherence to traditional timelines and management structures that can clash with the POD itself.    
3. Can be poor outsourcing fit: All of Agile can be tricky with offshore outsourcing, and this is perhaps even more true with the increased pace and interaction expected from POD teams. Time zone is of course a critical concern here, but also language and cultural barriers can make fusing offshore and onshore employees in a POD more challenging.    
4. Breaking them down too fast and changing too regularly: The POD approach is ideal for design-through-ownership, and that means being together for the entire life of the task at hand. Some recognize the appeal, but once a product is on its feet (or near to it), they dismantle the POD, or restructure it, missing out on one of its key benefits. A good POD structure takes time and thrives with its own management!   

So then how do you set up a POD approach to succeed?  It begins, like most initiatives, with a strong organizational commitment.  

I recommend the following: 

• It’s about the right people: Where PODs thrive, its members can be self-driven, self-standing, and ready to embrace the challenges of being part of an autonomous team. For these people, a POD approach is liberating, letting them own not just one cog in a product or task, but a part of the company’s success as a whole, with a clearer view on the outcomes of their craft.    
• Use a phased implementation: There will be things to iron out, and that means patience and commitment. By starting small, you can adjust and learn, and others can see the fruits of the structure at work.   
• Empower your teams: Teams need clear roles and responsibilities, but a successful POD team is autonomous, which means trusted to make its own decisions and take ownership of tasks. This includes inevitable mistakes, which must be learned from. But the POD owner should direct it, while leadership’s goal is to coordinate and empower these teams, not micromanage them.   
• Communication is key: Communication in-team is the key to success, and that means resolving potential issues that prevent a team’s growth and development. This approach also means various teams working in parallel, and alignment between these is critical. POD teams must communicate within, and the organization must communicate broader goals and strategies.    
• Consider nearshoring: Not every organization can have onshore, on-site teams. Nearshore outsourcing can be an excellent fit for a POD team approach, as it resolves the issues at play with offshore outsourcing: in terms of time zone, language, and cultural fit. Nearshore teams come together faster, and work together more easily, and all at an attainable price point. 

Conclusion 

The ultimate goal of the Agile methodology and agility overall is pace—to be more adaptable and responsive—breaking down workplace barriers to getting quality, customer-centric work done on a timely basis. 

But with a PODs team approach, it can also mean more engaged employees, with greater knowledge transfer and a shared investment in your entire organization’s success.  

In a world where change is increasingly constant, it’s how we process it that determines our ongoing success.  

Empowering cross-functional teams capable of innovating, and making their own decisions, organizations can transition their culture into one built around embracing it. 

Check out other articles from PTP From Our CEO and on leadership 

Get the latest updates on recruiting trends, job market, and IT, and expert advice on hiring and job seeking at The PTP Report