Refactoring AppsFlyer Engineering’s Planning Process

This post outlines how we built & defined a completely new planning process to help optimize delivery time on projects and streamline dependencies between teams that ultimately enabled a more forward-thinking approach to strategize & plan for new product innovations.

AppsFlyer is built on the values of continuous learning and improvement, with an engineering culture deeply focused on excellence and craftsmanship. As a hyper growth startup, whose success even took us by surprise, one of the biggest challenges in an environment of explosive growth is scaling intelligently. Whether it being technology, people or processes, we do our best to execute this as painlessly as possible.

Imagine an engineering organization that is used to working in startup mode, now growing exponentially, it is crucial to think about how to manage engineering operations at scale. This can be pretty scary for those involved who prefer to maintain their familiar way of doing things — unjustly holding on to the fear that change could adversely affect culture, and even because sometimes a sub-optimal known is less scary than the complete unknown.

This is what I was basically up against when I set out to try and build a more scalable R&D planning process that wouldn’t hinder our speed and agility, and at the same time maintain our startup atmosphere.

The Dream

The reason I chose to join AppsFlyer Engineering and take on what seemed like a daunting task at first, was because I liked the mindset based on thinking differently and challenging the conventional way of executing things. I knew that due to this mindset, I could build processes that are designed to be pragmatic, simple and fully transparent, by creating constant feedback loops from the users and by monitoring our systems very closely. All of this together, would enable us to understand the pains and failures and fine-tune the processes accordingly.

ֿThe Reality

Now, think about a group of 350 people in a complex organization, with a variety of teams and many dependencies (where in this case I define a dependency as the degree of relation between teams which drives or prevents the functional execution). Add to this a growth rate of a hyper-growth startup, and on top of that the day to day reality of a massive engineering organization.

At startup size, this can be managed informally with ad hoc processes, but once teams start growing exponentially (think 10–20 new hires monthly), there needs to be a more organized process and method that is aligned across the entire engineering organization. I had to find a way to build a truly manageable planning process that will impact the way the organization thinks and functions in its day to day operations and align with this changing reality, all while maintaining the startup atmosphere that enables us to to move quickly, and adapt rapidly to changes that may arise.

This new planning process made it possible to break down silos between different teams and provide better transparency & predictability to the entire organization regarding engineering tasks, which resulted in greater trust in the timelines between business units in the organization (something that formerly had a very high degree of unpredictability). Below you can find a practical breakdown of how we refactored our planning process so that you too can apply some of these ideas to your own engineering organization.

Planning for change

When I first presented the new planning process 2 years ago, I provided the following guidance to the R&D group (this is the slide I presented to the team):

Presenting a new process as an experiment reduces the friction and objections, leaves room for exceptions and curiosity to see what will happen in the future.

Building a new planning process for a large-scale R&D organization can be engineered for success by following a few best practices and methods that can be learned, internalized, and ultimately shift from theory to practice. For optimal results and in order to maintain your stakeholders as partners throughout, it is important to focus on three key elements:

1. Communication
2. Metrics
3. The process, built with straightforward and logical phases

In this blog I chose to focus only on the process itself and leave the metrics and communication for following posts.

Planning Process Phases

In order to create an all-in attitude, the defined goals must feel right to the team, align with their pains and create the possibility to improve these pains.

At first there was quite a bit of apprehension with how the process would affect day to day work, but we managed to dispel this by building trust when improved velocity and reliability was quickly achieved.

Goals:

• Improve visibility and find hidden dependencies
• Provide reliable ETAs at scale
• Measure the ratio between product enhancements / bugs / infrastructure tasks and unexpected tasks
• Improve the R&D/PM cooperation
• Improve our predictability all the time
• Provide solid content for the quarter

Planning

Planning is performed once a quarter, and is built in one quarter increments. If you’re wondering why, this is because quarterly increments make it possible to set up achievable goals, step by step throughout the quarter to accomplish these goals, and ultimately demonstrate success rapidly, which helps drive motivation.

A single quarter can be broken down into small manageable segments of two-week sprints that have leaner milestones which can indicate if you are on track, and allow for experimentation with more tolerance for short-term failures. The smaller milestones also keep the team motivated and easily predict if any changes to the plans are necessary.

This way the data reflecting the impact of changes is much easier to collect, can be measured and even shared.

Remember, we live in a startup world with a high level of unpredictability — meaning not everything can be planned for, so ensuring there is tolerance & flexibility for changes to the plan, are good for the business.

Good change-management process supports and accepts changes, reflects the costs of every change to the organization, and helps monitor them.

Company goals

An important phase in the planning process is working according to the company’s business priorities. These are defined by our CEO on a quarterly basis. As the company’s business goals don’t change every quarter, we found it useful to hold a Q&A session between the CEO and the R&D/Product management in order to clarify open dilemmas and unclear goals.

The company’s business priority list should be clear and easily understandable by the entire team.

Build your team backlog

A team backlog is a prioritized list of tasks for the development team that is derived from three primary input sources:

• Product roadmap (product enhancement)
• Priority tasks from customer service teams
• Development team tasks (Infrastructure, training, etc)

Each R&D team should maintain an updated and continuously managed backlog.

Build your short list

Each team should discuss and agree upon the items to be completed in the planned quarter and provide the following information for each item:

• Priority
• Dependencies (on other teams)
• Rough ETA (in weeks)
• Planned month (1st, 2nd or 3rd month of the quarter)
• Risk factors

In some cases, a few meetings are needed until the list is finalized. All three input sources should be addressed by this list.

To more or less understand the scale of this shortlist, the number of items on the list we had per team were 5–8 (including 2–3 main items).

As we fine-tuned the process from quarter to quarter, some teams realized that planning small items is not required as they are usually removed during the quarter, hence they only planned main items.

Dependency Mapping

After all teams’ short lists are ready, R&D management meets and each team presents only the items that have dependencies on other teams. By the end of this meeting, each team has a new list of items which includes its short list and additional dependency-items received from other teams’ short lists.

At this stage, on a big board, the company’s business priorities list is written and from this point on, every priority conflict between the teams should be resolved.

Realistic list

The team circles back and meets again to build the realistic list by prioritizing all of the new items that have been added according to the product priority list. At the end of this phase, each team has a complete list of items they commit to completing in this quarter.

Presenting the plan

A meeting is scheduled with the company’s management for each team to present their list of commitments for the upcoming quarter. Feedback is collected and additional fine-tuning is done again to conclude the final plan.

— — — — —

We have managed to come a long way with our engineering organization and provide much more stability and predictability in our development process, resulting in transparency to the entire business that ensures we’re prioritizing our innovation.

That said, we still have unsolved issues we are working on ironing out. As I mentioned in the beginning, it’s a continual and iterative process. Aspects we are still working on optimizing include:

• Building and communicating a proper working process for “unplanned” work still remains a challenge and is largely managed ad hoc. This requires more fine-tuning to be aligned with real-world scenarios.
• Since we chose short increments for our sprints, we are still seeking the optimal way to visualize progress per team, as fine-grained as daily dashboards of progress. We’re still working on figuring out the best way to achieve this level of transparency.
• We are still struggling with dependencies and are trying different approaches to tackle this. Stay tuned…

So while we have made significant progress, there is always room for improvement. We are continuing to work on refining the process so that we can provide an excellent product without compromising quality.

That’s it for now, I hope this article has provided some practical tips for how to build a more predictable and sustainable planning process. The next article in this series will dive into the tools we provide our managers with to control their team’s efficiency and productivity.