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.