Empowering Teams with Agile Product-Oriented Delivery, Step By Step

Being a program owner brings many team-related challenges. If you’ve struggled with unclear goals, running targets, low team collaboration or morale, skewed team velocity, or variation in story pointing in your projects, you’re not alone. Program owners may resort to micromanaging to regain control, but this can breed trust issues and hinder project execution.

Agile Scrum is an excellent way to address these problems, mainly when teams work independently on smaller projects. In large engagements, where teams strive to collaborate on global integration platforms, there is a higher need for accountability and ownership.

Agile Product-Oriented Delivery (POD) is one such working model to help you through this journey. In this article, you’ll learn more about this execution model and see it in action via a step-by-step illustration of how it was applied in a recent customer engagement.

Getting Started

A customer enlisted GlobalLogic to partner with their internal team in building a real-time monitoring portal that tracks the migration of 40+ million consumers to their new billing systems.

We started with the most established model for design & development: Scrum. The model worked well – that is, until the start of the integration phase, which brought together over 30 customer and GlobalLogic scrum team members working on a single release. Cracks in accountability and ownership began to surface, and the lack of One Team spirit was causing adverse impacts on timelines and quality.

Recommended reading: Agile Transformation: Are You Ready?

Identifying Key Issues in Team Structure

What had begun as a relatively small team of 15 grew quickly into a mid-size team of 60. Project deliverables and agile ceremonies – the daily scrum, planning, review & retrospection – involved the entire team.

The team acknowledged that there were problems and, on retrospection, identified the following key issues and challenges:

• No clear communication within the team, which had multiple leaders to answer to in a model of distributed accountability.
• No clearly called-out ownership.
• “One Team” spirit was missing.
• Lengthy team meetings were resulting in inconclusive outcomes.
• There was little visibility into the outcome of each team member’s efforts.
• There was a greater focus on budgets/forecasts than the value delivered.
• The size of the team meant members and leaders could not truly know all team members and their capabilities.

Planning for Team Transformation

As a result, we identified and worked on 5 capabilities that would help our team’s transformation journey.

Recommended reading: 6 Key Advantages of Quarterly Agile Planning

Reframing our Goal in a Product-Oriented Delivery Model

Our team deliberated on the identified problems and where we wanted to be. On consensus, we implemented the Product-Oriented Delivery (POD) working method. Our objective was clear: we needed to improve accountability and collaboration across teams, building in agility and discipline, alongside consistency and scalability.

What is the POD Model?

The POD Model is an increasingly popular software development strategy that builds small cross-functional Groups/PODs that own specific tasks or requirements for a product. Teams are structured into Groups/PODs with 8 (+/- 2) members, each working as an independent unit toward its set goals.

By definition, a POD is a small group of autonomous and self-governed team members with complementary skills working for a common purpose. The POD method focuses on teamwork and getting the job done, allowing each team autonomy. It also builds trust, as the team self-organizes and self-executes projects.

A POD’s team members will collectively have the skills to design, develop, test, and operate a product, ensuring self-sufficiency. Using this model shifts responsibility for decision-making and task completion completely to the PODs.

Establish the POD Way of Working

Plan the POD Teams

The first step is to define the operating model for POD-based delivery. We defined each POD as having 8-10 professionals; above is the composition that we put in place for our team.

POD Project Execution

In planning, we looked at the number of epics/features required and split each team to focus on separate, unrelated prioritized features. Each POD team/member had clearly called-out responsibilities.

We then established a cross-cutting Guide Team to support all assigned work. This team comprised the Program Manager, Architects, Product Owners, and DevOps/IT engineers.

The project execution model for a POD focuses on:

• Features planned for independent execution by POD teams.
• Team capabilities required for teams to deliver current/future product backlogs.
• Team distribution, based on geographic spread, that distributes features based on the skills, and requirements of the customer.

Measuring POD Functioning

Based on the size of the project, POD teams will be defined and created to sustain continuous growth and improvement. It is therefore important to define the KPIs and success criteria for these teams.

Identifying the measurement period and acceptance criteria for each metric is essential, Here are some more critical metrics to track and have customers agree upon:

Now look at the metrics we defined and reported on, either weekly or by release. The measurement ranges defined the success criteria of the project.

Fig (5). Virtual Operating Control Center KPIs

Key Takeaways

The POD team structure and way of working together can improve efficiency, collaboration, communication, and of course, empowerment. Here’s a sample of the results we experienced by transforming from classic scrum to product-oriented delivery teams.

Fig (6). Before-After Comparison of Key Metrics

And what did we learn? Here are some key benefits we identified as results of implementing the POD model:

• Enriched Customer Experience. Connecting with the customer via POD teams enables partner team members to interact frequently, maintain visibility on priorities, and improvise accordingly.
• Improved Quality of Deliverables. Focused goals for each POD team accelerate the establishment of higher-quality milestones.
• Increased Team Effectiveness. Each POD focuses on customer goals and ensures they align with those expectations.
• Faster Release Deliveries. With improved Team collaboration, flexibility, and ownership, POD teams work more effectively on releases.
• Triggers Team Innovation. Teams are continuously looking to improve and find ways to achieve faster results.
• Cross Functional Adoption. POD team members acknowledge the various roles that make up the Guide and POD teams, and better understand the parts each role has to play.
• Transparent Collaboration. The POD team can define the success of the project quickly with inter/intra-team collaboration.
• Team Confidence & Morale. A positive spike was observed, sprint on sprint.

Want to learn more?

• Blog: Agile Thinking: How Can I Help You?
• Whitepaper: Using Cyclomatic Complexity to Gauge a Project’s Health
• Video: Digital Leadership – Creating a Software Product Driven Organization