Using Agile Pods to Realize the Potential of Your Team

Agile is an ever-evolving field, and its rate of change has exploded exponentially in the last decade. Businesses are constantly trying to catch up with the market pace—and evolving their processes accordingly. Scrum has seen huge success and led to easier adoption of agile in a lot of organizations, but there is a demand to further speed things up while allowing for flexibility in resource and time management. This pursuit led my team to what we call agile pods.

Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of our agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output.

My company, Winshuttle, started the transition toward agile pods by dividing our one large product team of about twenty people into smaller teams of four to five members and calling them pods. The requirements got divided as independent deliverables for each pod based on the expertise of its team members. Because the team members were responsible for the design, plan, delivery, and quality of the output, the ownership level increased dramatically. Also, because complete communication happened directly, the results were faster and more precise.

Pod Organization

An agile pod is designed as per the requirement of the deliverable, involving varying levels of management, development expertise, QA, and creative talent. These teams are customizable and may change depending on the current requirements, creating a relevant ecosystem leading to maximum innovation and faster delivery times.

Pod Features

Agile pod teams are designed to be self-sufficient. The team is self-organizing and works with minimum supervision, creating a higher sense of ownership and maturity. Also, because most required expertise is available at hand within the team, there is a minimum level of dependency on people outside the pod. The pods stay together until the requirements keep coming for their team—say, for one release cycle.

A pod consists of the following team members:

1. Core team: These team members are dedicated full-time to working for their pod. They are part of all discussions, decisions, and standup meetings. The competencies of the core team members add up to the competency of that pod. The core team members may be shuffled between pods during or after the release cycle according to the expertise required.

2. Part-time specialists: These team members are available as part-time resources to support specialized project needs of different pods. They may be working for multiple pods at the same time. Examples would be a UI designer, a white box tester, or an automation engineer.

3. Pod leader: The pod is led by a pod leader, who is responsible for prioritizing the work with the business management team, clarifying requirements, and replenishing the queue for upcoming projects periodically.

The project management team does not interfere with the working of the pod apart from supplying the requirements and clarifying doubts about functionality or priority of tasks to be picked. The pod leader is an interface between the pod and the project management.

Like in Scrum, the daily standup meeting is scheduled so everybody can meet and discuss their updates, tasks, doubts, and risks. The part-time specialists may be included in the stand-ups whenever they are working with that pod.

Leveraging and Working in an Agile Pod

In order to leverage an agile pod, it is important to define clear requirements and then have an onboarding time for the agile team members. The skills and specialization of the team members must be kept in mind when putting them together in a pod, and the onboarding time must be dedicated toward getting them to understand the process and develop a level of understanding among themselves. Working in such a self-organizing and disciplined structure requires guidelines, team spirit, and acceptance among the team members.

In my experience as a pod leader, the first few weeks can be empowering and taxing at the same time. When our team got the responsibility to plan out the complete release cycle, requirements, design, and delivery schedule, participating in all those discussions brought exposure and a broader perspective to all the team members. Though the planning, triages, and prioritizing were new to most team members, once we got the hang of it, it actually felt energizing.

Further on, the communication became direct from the pod to all nodes outside the team, such as the project management group, the outsourced UI design team, and the other pods working in parallel. This reduced the communication time, filled the information gaps, and gave a voice to all opinions alike, and many brilliant ideas came our way.

Also, a major difference came in the dynamics between the development members and testers. We shifted our seating arrangements together, putting the entire pod, including developers and testers, together in a cluster. There were no secrets to be kept! Because the quality was an inherent part of the deliverable expectations from the pod, developers volunteered to help review the test scenarios prepared before testing happened on their components. Testers volunteered to buddy-test each component before it was finalized and released for the iteration level testing. This led to lesser issues in our production level builds, and demos to the project management mainly went bug-free. This also meant no altercations within the team on issues because everything was discussed, reviewed, and tested at buddy level.

All in all, at the end of a release cycle of about five weeks, we released a major chunk of functionalities that would have been difficult to get delivered in the normal scrum manner by any manager in the same amount of time.

Dos and Don’ts of Working in Agile Pods

Although the process may be tweaked per your team’s needs, it is important to follow the basic rules to maintain the spirit of agile.

Dos:

• When you decide to adopt agile pods, prepare the team members by training them in that direction before the actual transition.
• During the onboarding time for the pods, spend time with each team member to clear doubts about the process.
• When putting teams together, take care that their skill sets complement each other. Think about people issues among team members of a pod. You do not want friction or resistance among members of the same team. Try to resolve any differences before the team moves to a pod. If there is friction, the project managers should facilitate a resolution. In my experience, when working in an agile pod, a lot of things do get sorted out on their own, too!
• Get the team together. Even if they are placed globally, get them to meet and sit together periodically to improve communication levels.
• Have an ongoing process to discuss what the team is learning and which situations were tackled better and faster because of being in a pod.
• Share the best practices being followed within one pod with other pod leaders, and encourage an open learning environment.
• Leverage the use of tools as much as possible, paying attention to the team’s suggestions.

Don’ts:

• Self-managing is an idea that needs to be ingrained in the team over time. Do not expect it to begin overnight. Some handholding time will be required for the team, especially for the pod leaders.
• Don’t introduce new technology or tools midway through the process. Let the teams decide on the tools and processes they need, and get the best results out of them.

Project managers must not try to micromanage or interfere with the working of the pod. The basic premise of agile pods is to give team members enough freedom to select their own tasks, resolve them, and deliver at their pace. Provide sufficient benchmarks, but do not try to micromanage each task or day.

When tracking the success of the pod, track the deliverables and quality instead of defects or hours logged, as in standard agile. Because the pod works so well together, there may be no defects in the tracking system at all. But that must not be held against the developers or QA personnel. That is agile working at its best.

We need to provide sufficient freedom to agile pods to let the individuals and teams decide, make mistakes, deliver, and learn together. It is sure to bring about ownership and discipline and radically change the outlook of everybody within the structure. It will eventually also change the outlook of the project managers toward their team and help everyone realize their actual potential.

Give agile pods a shot and see how much good may come out of it.