How do your pods divide and conquer?

chopping-woodA 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 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 capabilities

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

 

 

Advertisements
Categories: Agile, Project Management | Tags: , , | Leave a comment

Post navigation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: