How do your agile teams divide and conquer?

From the Easy in theory, difficult in practice Blog
My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Why setup virtual PMOs and when should PM templates be standardized?

Divide and conquer!

Virtual PMOs – a survival guide

A PM’s got to know their limitations!

Overcoming Newton’s First Law with Organizational Project Management maturity

Categories: Agile, Project Management

A good practice with agile delivery is to keep team sizes small to reduce the number of communication channels. But when planning a product release which cannot be delivered by a single team or pod within a reasonable amount of time, we need to structure the work across multiple pods of five to a dozen team members working in parallel but also orchestrating release cadence and work item priority based on the dependencies between work streams.

So how should work be structured across the pods?

Focus on features or capabilities

Feature-centric pods take ownership for completing one or multiple features or customer journeys which will provide meaningful value to their stakeholders. For example, a pod working to launch a purchasing portal might deliver browsing and searching capabilities for users.

Benefits of feature-centric pods include that they will rarely struggle with demonstrating tangible progress to their stakeholders at the end of each sprint and as they have end-to-end responsibility for a customer-facing feature, the magnitude of coordination between pods to deliver value is reduced. Should funding for the product run short, there is a greater likelihood of delivering some key functionality to their customers.

While feature focused pods align well to the “what”, from a solution design perspective, there is an increased requirement of cross-pod collaboration to ensure that data models and design approaches are aligned, and there could be specific enabling capabilities which get distributed in this model but which might have been better delivered by a single pod. Specialized competencies might also need to be stretched across multiple pods if the features each pod is delivering requires those skills.

Focus on components

Component-centric pods divide work based on a defined solution design or architecture. For example, one pod might take ownership for data interfaces while another is responsible for user experience. This model resolves the concerns with the capability-centric approach but introduces the need for greater discipline from an integration testing perspective and can make it challenging for individual pods to be able to demonstrate tangible evidence for what they have achieved to their non-technical stakeholders. Given the higher degree of feature-based cross-pod dependencies, productivity differences between pods can also cause greater impacts than with a capability-centric approach.

So let’s be pragmatic with our approaches!

Sometimes, the right answer might be to use a hybrid of the component and capability models. For example, if multiple capabilities are relying on a solid data foundation, a pod might take on that work and start earlier than other feature-based teams to address foundational dependencies.

(Note: this article was originally written and published by me in December 2016 on my personal blog,

Posted on: March 05, 2018 06:59 AM | Permalink

Comments (8)

Please login or join to subscribe to this item
Does component-centric pods increase specialization or decrease generalization in the same way that for example separating developers and testers etc does? I'm not saying it does, but just asking the question. For some reason after reading this article about pods, I thought of the Pod of Pod of Pods? It's the Scrum in me. Thanks for the article Kiron :-)

Good article Kiron.

In the end having an agile mindset will deliver the product or service. The key is flexibility to adjust to the situation that the team is in to deliver the project on-time.

Thanks Sante - there is potential for some unhealthy specialization with a component-centric approach from a technology perspective but not from a developer vs. QA/QC perspective. For example, a team might be divided across the layers of a 3-tier architecture. Each would have the necessary analysts, designers, developers & testers, but the specific technical skills of the developers might be focused on UI vs. business layer vs. database.

Thanks Drake - absolutely, adaptive lifecycles demand adaptive thinking!


Very interesting viewpoint, Kiron.

Component-centric development would also have an issue of interdependencies in the build stage. For example, if one team tackles UI and another the logic-layer algorithms, there is a chance that one will be "more complete" than the other.

Yes, if the interdependencies are known beforehand, they can be planned accordingly. But the chance of Murphy's Law striking increases exponentially.

But it is definitely more than just a viable option in clearer, simpler delivery scenarios.

Also, would you have come across a scenario with an augmentation team? This is a standby team with jacks- (and jills-) of-all-trades which jump in to teams of other sprints on an ad hoc sprint-by-sprint basis to provide more flexibility to the outcome. This is one concept that could work really well with the component-centric approach.

Thanks Kiron for the article,

Pragmatic approach really helps to achieve Project Goals in more realistic way and also helps to maintain balance

Please Login/Register to leave a comment.


"The man who does not read books has no advantage over the man that can not read them."

- Mark Twain