The Process Behind Program Management

By Gifika

We’ve often talked about how Gojek doesn’t build one Super App, it builds three. To achieve this, multiple Product Development Groups (PDG) exist within Gojek. One of these is the GoMerchants PDG, that handles all our merchant-centric initiatives, including GoBiz, our SuperApp for merchant partners.

GoMerchants is an entity formed by the fusion of multiple teams that all had their own work styles. How do such diverse people come together and build amazing things? That’s where Program Management comes into the picture.

The Challenge

GoMerchants PDG was formed from five separate teams (SPOTS, Midtrans, Mapan, GoResto, Nadipos), and each team had a unique engineering culture. Across teams, the total number of staff involved in cross-functional work was ~240 people.

After a discovery phase of the process over 3 months with the various groups, we found that every team was utilising different versions of project management methodology and tools to track team progress. Across various teams, we identified nearly a dozen different types of tools and methods including the Scrum method, Kanban method, Jira tools, Favro Tools, and Trello tools.

The key takeaway was clear: There was no single source of truth for tracking team deployment progress.

The Solution

To achieve our goal of reaching a high rate of (quality) deliverables with clear transparency on progress, the Program Managers decided to build a program that set a single standard workflow for everyone involved. The end result? A meld of Agile best practices and a limited/select set of tools.

At the highest level, Program Management methodology focuses on adding just enough processes to help with efficiency — and not creating convoluted processes for the sake of process. Keeping these best practices in mind, the workflow built by the GoMerchants Program Management team entailed Scrum Process to track backlog priority, using Confluence as a documentation hub, Jira for managing backlog tasks, Pre-Iteration Planning Meetings, Sprint Planning, Daily Standups, and lastly, conducting regular Retrospectives.

The consolidated approach helped the GoMerchants team reach the rapid pace needed to hit targeting of deliverables— but also helped support the team in an environment of rapidly-changing requirements via greater transparency.

There were additional benefits to this approach, as well: Instantaneous feedback from the team on what was working (and what was not), metrics to inform future iterations of the workflow, and a reduction in deployment failure — and rollback deployment risk — thanks to rapid and continuous internal communication.

“Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).” — Collier, Ken W. (2011). Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Pearson Education.

To transform quality deployment with high pace targets, the program implemented far better collaboration for a large team than previously existed.

At the same time, Jira was chosen as the one crucial tool for backlog management for GoMerchants. The factors in selecting Jira were the platform functionality is highly-configurable to the specific requirements of a team, as well, as it has the flexibility to allow for usage in a wide variety of environments and processes.

Scrum Activities

Below is the flow of scrum activity. It starts from Pre-Iteration Planning Meeting (Pre-IPM), Retrospective, IPM/Sprint Planning, and Daily Standup:

Sprints

A Sprint is a time-box of iterations, where the releasable works that align with sprint goals are implemented. A Sprint always has a fixed start and end date — these dates should be of the same duration; typically two weeks.

Sprints notes: While most of GoMerchants PDG uses two-week sprints, the length of time can depend on several factors like the final deadline, number of people in the team, and holidays in the calendar. Some teams use a one-week Sprint cycle due to urgent work that requires moving at an accelerated pace. But, generally it is not a best practice to use one-week sprint cycles as team achievement moments can be missed, quality could be sacrificed, and team burn-out is a real risk.

Pre-I.P.M. (Pre-Iteration Planning Meeting)

Pre-IPM is an activity to review the active Sprint and manage backlog and Sprint goal(s) for the next iteration. Pre-IPM is attended by a Product Manager, Tech Leads, and Program Manager. The Product Manager should write-up the ‘story’ aka plan, in Jira after Pre-IPM. Tech lead should advise if the story and goals for the next iteration are technically achievable.

As a Program Manager, you can use spreadsheets for mapping between the story and team before doing the IPM. Below is the example:

Pre-IPM notes: This is basically a small meeting with a PM, TechLead, HoE/HoP (if necessary) and PgM. The purpose is to finalise the work backlog for the team in the upcoming Sprint. This meeting will help streamline the Sprint Planning meeting by confirming that the final requirements have been aligned by all stakeholders — the goal being to reduce the number of “Requirement Changes” going forward. .

Retrospective

The purpose of a retrospective in IPM is to collect previous sprint feedback from the team. It contains some columns like:

• Glad: What makes you happy in this sprint or things that went well
• Sad: What makes you sad in this sprint and from here we can see how we can improve it
• Mad: What makes you mad or frustrated in this sprint
• Ideas: Idea to improve our next sprint
• Appreciation: Appreciation in this sprint, esp if there’s a pretty big team achievement
• Action Item: Action item to improve our next sprint based on Sad, Mad, and Ideas columns. This is the important part to be followed up so “lesson learned” value from every sprint is really working

We can use several tools to help us collect data, i.e. https://funretro.io/, below is the example:

Send a retrospective link to a Slack channel before IPM and encourage the team to fill the cards. Do the retrospective by talking through each column 15–30 minutes before IPM starts.

Retrospective notes: This session provides the opportunity for a team to look back and see how they can improve. Retrospectives can be a catalyst for organisational change, team change or even a culture change. The Retrospective can be a place to build and enable teams, or to help teams start their journey with a clear understanding of where to go next. It’s a method that is very useful to gauge the Team Happiness state and gain Improvement Feedback from the team. A Retrospective also builds trust and helps make the team grow stronger as individual members know they have an outlet to express their feedback and they will be heard by their managers and colleagues. Since this process is highly actionable, the PgM’s have incorporated it beyond the use case of small teams, and have instituted it at larger scale for the entire GoMerchants PDG Org every 6 months.

IPM/Sprint Planning

IPM/Sprint Planning is an activity that is attended by all members of the team to prioritise the backlog, discuss stories, and determine story points.

Below are the steps taken in an IPM:

Before IPM:

• Program Manager sends a retrospective link to a Slack channel

During IPM:

• Retrospective 15 min
• Open Sprint Report to review active sprint (Done and Not Done)
• Complete Sprint
• Open velocity chart to review the commitment and complete stories from the previous Sprint
• Ask the team who will take a leave and discuss with PM about achievement story (this will be helpful to adjust velocity for the next Sprint)
• The PM explains each story for a new sprint. Make sure there’s always a DoD and add story points
• Add the Sprint Goal
• Start Sprint
• After IPM
• Collect result of retrospective, make sure action items are done/started to be worked on

Daily Standup

Stand up Preparation:

• Set a daily schedule (max 15 mins) and make sure the team is committed to attend stand up
• Remind the team to update Jira 10–30 mins before stand up

During Stand up

• Open Jira dashboard to review story update and movement.
• Create a set of Standup Notes and copy it in the team Slack channel if necessary
• Ask these questions and record the answer to each member: What did I accomplish since the last daily standup? What obstacles are impeding my progress? What will I do by the next daily standup?
• Daily Stand up notes: There are times people will forget to update Jira ticket (it’s a never-ending challenge 💁). As a Program Manager, we need to remind/ensure their team updates Jira (at least) right beforethe stand up starts.

The Results

We’ll let them speak for themselves!

After building a standard approach across teams using Agile, Jira, and other tool sets, the Program Management approach used by the GoMerchants PgM team to combine these elements helped to vastly improve the effectiveness of team performance on 2019 period. That’s a win we’ll take. 🙌

Are you liking our stories? Do you want them delivered straight to your inbox? Sign up for our newsletter!