"Pod" mania - the revenge of the cloning machine

The recent fad in the "Agile" community is what I call "Pod" mania.  Create clones of similar looking "Pods" and call them teams, and then group these "Pods" under "Release Trains" - Yuck. Hierarchy is now being replaced by "Podarchy" at the bottom level (worker bee's) with rest of the hierarchy is firmly in place.

The latest fad is driven by so called methodologies like SAFe which relegates methods like Scrum and Kanban teams to the lowest strata of the "Agile" hierarchy designing a machine that forces "Pods" to work on a small pieces of a larger problem that the "Pod" doesn't understand or not capable of solving. This is perpetuated by large consulting organizations like McKinsey's, Deloitte, Accenture and others who clone and "sell" the same model to 1,000's of top corporations. How "Agile" is that?

Agile is in the simplest form is doing the right thing that is required in the context of the work that is being done. Not a pre-defined answer in "Pod" formation without context to the work being done and the situation in context of the organization in which the work is done.

I cant imagine that amount of effort being put into standardization, order and replicability. A single pod often looks like this...

And when cloned... multiple "Pods" look like this...

Let me ask one question -

How would one know what work is coming down the pipeline? And if so, what combination of skills, competencies, knowledge and competencies are required in a "Pod" before the so called "Pod" is formed?

And a second follow up question to the above -

Can work be really broken down to fit a "Pod"? And if so, then why does one require so many "Pods" which struggle to release anything together to the market in the first place? If the "Pods" are clones with all the capabilities, should they not create and release things to the market independently of each other? Where is the hiccup in completing independent work quickly?

Small moves. Big Payoff's

Let's now look at this from the lens of Small Moves. Big Payoff's

• Small moves - Eliminate roles: When methods like Scrum or Kanban are practiced in the eco-system, one key dimension is to move away from "Roles" on the team. Scrum for e.g. prescribes only role called "Team Member" or "Developer" who help develop Products based on whatever they can pitch in to work on. There is no way to predict in advance what work will come by and therefore the ability to multi-skill team members and broad base their skills sets them up to do whatever problem comes by (Big Payoff).
• Small moves - don't clone pods: When multiple teams work together there is value in looking at skills, competencies, knowledge and experiences across the teams. There might be requirement for a UX designer in every team and it might be sufficient to have this skill only in a few teams. That would mean providing collective responsibility for utilizing the skills across teams delegating them to figure out how to finish the work together.
• Small moves - eliminate or reduce dependencies to the maximum possible - "Pods" are formed and then dependencies are managed. The idea is to get teams independently finish features on their own pulling together whatever support is required from other teams in order to finish the work in the shortest possible cadence.  Often from a few days to one or two weeks at the maximum.
• Small moves - understand what a "Product Owner" really does. We will take this up in another article.

These are just ideas to get you started and there are more "Small Moves" possible, but these three are potentially a starter set.