Agile Pods at Xendit

Mochamad Lutfi Fadlan
Xendit Engineering
Published in
6 min readMar 17, 2021

Background

Eight months ago, one of our product teams kept getting bigger and bigger until it reached 11 members in a team consisting of 1 Technical Lead (TL), 1 Product Manager (PM), and 9 Software Engineers. We had broken down into two sub-teams based on the product scope. However, we got into a problematic situation as following

1. The team situation was not ideal

  • Scrum ceremonies took time more than that we expect
  • Felt tired after Scrum ceremonies end
  • We had a lot of contexts to talk about during the meeting
  • One of the sub-teams scopes was too big

2. Hard to have a complete Definition of Ready (DoR) and Definition of Done (DoD) before we start the Sprint

  • We consistently didn’t have a full picture of our tasks before the sprint began. Sometimes the expected outcomes and success criteria for tasks were not well defined
  • Both PM and TL struggled to commit as their plate are already packed

3. We didn’t give enough space for engineers to grow in leadership skills

  • The higher level an engineer is, the more expectation on them to lead
  • We need to support engineers to grow to the next level

Agile and Scrum

Some people get confused about the difference between scrum and agile. Let’s go through it quickly before we jump into the main content of this article.

Agile is a practice involving discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s)

There are 4 main values that Agile brings:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

In Agile, development and testing activities are concurrent. Usually, in the engineering team that is applying Agile, there are best practices applied that we already familiar with these days, such as

  • Continuous integration
  • Automated unit testing
  • Automated acceptance testing

The successful use of Agile depends on how the team follows the Agile principles, which some of them are about satisfying the customer through early and continuous delivery of valuable software, welcome changing requirements, frequently deliver software, and team collaboration.

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value

Scrum is one of the Agile methodology implementations where incremental builds are delivered to the customer in every regular short amount of time (1-4 weeks). Scrum allows us to focus on delivering the highest business value in the shortest time. The Scrum Team consists of 3 roles: Scrum Master, Product Owner, and Developer. There Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective events. Also, there are artifacts such as Product Backlog, Sprint Backlog, and Increment.

The main focus for the Scrum Team is to work on the Sprint to make the best possible progress toward team goals. The successful use of Scrum depends on how the team adheres to values of commitment, focus, openness, respect, and courage.

Agile Pods

The concept of Agile Pods is very similar to Scrum Team. They both small, self-organize, and consist of 3 roles. Below are the differences between Agile Pod and Scrum Team

Agile Pod and Scrum Team Differences

Because of Pods’ designed roles, the team can create an ecosystem where it leads to faster delivery times and maximum innovation. The team works with minimum supervision, creating a higher sense of ownership and maturity, and has a minimum dependency on people outside the pod. The member inside the pod usually stays together until the requirements keep coming for them.

How We Come Up with Agile Pods

Now let’s get back to the subject. So we’re actually implementing Scrum in our team with some modification but still adhere to the main principles. In our team, we have a Tech Lead who mainly acts as a Scrum Master, a Product Manager who mainly acts as a Product Owner, and Developers/Engineers.

To solve the problems that I mentioned earlier, we proposed implementing Agile Pods in the team. We felt quite confident in this concept because

1. We are capable to assign a leader in each pod (Pod Leader) who is responsible for

  • Leading a small team (consists of 2–3 members in total) to deliver epics based on requirements and expectation
  • Owns the pod mission, goals, and risks
  • Lead majority of Scrum events for each pod
  • Make sure the pod have written DoR and DoD in each task before Sprint start
  • Identify resource gaps in a pod

2. Engineers (Core Team and Part-Time Specialist) already mature and independent enough as they are capable to do the following:

  • Deliver epics/tasks based on agreed solutions and timeline independently
  • Own the implementation and release risks
  • Figure out a complete DoR and DoD on tasks they’ve responsible for
  • Review tasks each other with minimum supervision

Additionally, we’re also aligned on the potential advantages for implementing Agile Pods which are

  • Increase engineers focus and freedom on delivering epic
  • Improve team ownership
  • Increase the quality of tasks that we deliver

On the other side, we also had some concerns which were

  1. Afraid it’s not effective, and can’t be proven to be successful
  2. PM was afraid of not giving value to pods
  3. Afraid of grey area on managerial responsibilities between Pods Lead and Tech Lead
  4. Limited knowledge on each pod (pod A wouldn’t know what happens in pod B)

Once we are aligned on why we want to implement Agile Pods and the advantages & disadvantages of it, we did the following next steps:

  • Defining qualitative and quantitative success metrics to address the first concern
  • Clear responsibilities between roles (Technical Lead, Pod Lead, Product Manager, and Engineers) in the team to address the second and third concerns.
Roles and Responsibilities
  • Conduct an additional team ceremony that we call Huddle which is a brief weekly stand-up for all pods in 30 minutes meeting to address the fourth concern

We decided to try this out in 1 month and consider whether we want to continue with this. After 1 month, the team felt happy about it, got benefits out of it, and there are no major concerns. So we decided to move on with Agile Pods structure

The Changes and The Results

Once we decided to adopt the Agile Pods, we did the following actions in our team

  • Split the team into 3 pods where each pod has 1 Pod Leader and 2 Engineers
  • Break down the Scrum events. There are daily stand-up, sprint planning, and grooming events for each pod
  • Settle which pod do what epic
  • Conduct Retrospective and Huddle for all pods together

There are no more complaints about long meetings and far fewer complaints about DoD and DoR. We’re able to break down epics before the quarter began and each pod has a clear scope on what epics that they should focus on in a quarter. We’re able to deliver many epics in each quarter based on what we have planned. The engineers have a high focus and clear scope in that project since we’re decreasing the scope and contexts for each engineer. We’re able to catch potential issues, and bugs earlier not only with that one pod but also across pods. Additionally, we help engineers to grow their leadership skills by giving them Pod Leader opportunities.

More importantly, after the Agile Pods kick-off, we have implemented a lot of process & team improvement, and initiatives in our team which probably not going to happen if we still operate the same way as before.

Hopefully from this short article, I can get more understanding about agile and scrum, and I also hope you can understand what Agile Pods are and get an idea on how to implement them in your team/organization. Thanks for reading!

References

Below are references to my readings and writings on this article

--

--