Using Agile Pods to Realize the Potential of Your Team

[article]
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.

User Comments

4 comments
Tim Baffa's picture

Nishi, congratulations on a good article around employing Agile Principles in the workplace.

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.

October 31, 2014 - 12:21pm
Nishi Grover Garg's picture

Thanks Tim!

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.

Hope that helps!

Cheers

Nishi

June 5, 2016 - 1:50am
Scott Duncan's picture

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)?

June 2, 2016 - 1:35pm
Nishi Grover Garg's picture

Hello Scott

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.

Hope that answers your question.

Cheers

Nishi

June 5, 2016 - 1:55am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.