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.

So, give agile pods a shot and see how much good may come out of it!

Do share your experience..

Also read my write up about Agile Pods – published at –

http://www.agileconnection.com/article/using-agile-pods-realize-potential-your-team?page=0%2C2