Using Agile Pods to Realize the Potential of

Your Team
Summary:

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 agile teams by involving members of different expertise and
specialization, giving complete ownership and freedom, and expecting the best quality output.

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.
Comments:

I have a few thoughts though about the concept of Pod Leaders.

I see the role of a Pod Leader as a potential single point-of-failure, especially as they seem to
perform as the main liaison between the Pod and the business.   What remediation methods do
you employ Nishi, in the event you are unavailable (illness, vacation) to serve your pod?

Also, the role of a Pod Leader seems to limit both leadership opportunities within the Pod and
communication with the business around requirement prioritization and refinement.

I would perhaps either rotate the role of a "Pod Leader" within each team so that each Pod
Member has the leadership opportunity to work with the business in that capacity, or I would be
in favor of eliminating that role altogether in favor of the entire team being responsible for
working with the business around prioritization and refinement.

Answ: In practice, we used the same concept of rotational Pod Leader , as you highlighted! And
it was made sure that the Pod Leader was not a Manager , but a member of the team playing the
additional role - like a developer or tester. I myself have played the role of a Pod Leader when I
was the tester in the team. 

The role in essence is not managerial at all , but just a point of contact for managing
communication from th team to outside , like status reporting of the progress and getting issues
resolved. So, it is like a servant leader role.

Who takes responsiblity to coordinate the time commitments of the people with specialities who are
not part of the Core Team?  What if more than one team needs the time of such a person at the same
time?  What do such specialists do if no team needs their time (over a certain period of time)?

Asnw: The constituent resources of the Pod and the rotation of resources is ideally managed by the
Project manager, since he is managing the tasks and requirements and is aware of the outputs and
timelines from each Pod. The common resources are kept independent and report to the manager. The
Pods can raise request for expertise and resources required , and the manager assigns them fully or
partially to the Pods as per need. In our case this happened mainly with the White Box Tester , UI
experts and Automation engineer.