Case Study - ABInBev's Sales BI Team

AB InBev, is a multinational drink and brewing company based in Leuven, Belgium. It has approximately 630 beer brands in 150 markets, 164,000 employees based in nearly 50 countries worldwide. For 2020, AB InBev’s reported revenue was 46.9 billion USD.

AB InBev Europe started its Agile experiment in 2019 with a simple, open-ended question: "What benefits can Agile bring to us?"

Since then, Agility has brought faster, more focused deliveries across more than 70 teams and 10 business lines. It has transformed the culture of the company and customer experience, while creating momentum and tangible business results in areas as diverse as  commercial, HR, logistics, supply chain, and finance.

In this article we present the case study of ‘Sales BI’,  one of the most successful underdog stories of ABI’s journey. 

Sales BI (short for Business Intelligence) is the key reporting tool for all operational and tactical sales KPIs. Pulling in data from various sales and distribution sources across the org, it then massages it into actionable insights leveraged by salespeople across Europe.

Sales BI's net promoter score in 2019 - when the Agile pilot started - showed that its users hated the software. Its NPS started out at -73 in 2019. Since shifting to an agile way of working, NPS has reached highs of +71 in 2020 and stabilized around +48 in mid 2021. At the same time both the number of users and average session duration grew.

Before 2018, business intelligence in the Sales sector was an ad-hoc, manual process based on spreadsheets. Initiatives were started to build a robust tool that would support Sales. Based on the existing program governance of the time, it was approached as a fixed scope, fixed budget project and outsourced to third party preferred suppliers.

The result was an all round failure, classic of traditional approaches. Missed deadlines, non-working features, angry users. The project was canceled and restarted. Twice!

During 2018 a the 3rd attempt to deliver the tool was underway. Stakeholder pressure and apathy had grown exponentially, exposing the team to an ongoing cocktail of "We need this yesterday!" and "Yeah, right! You've failed twice, what has changed now?"

Steering committee meetings revolved around status updates, escalations, red-amber-green indicators, tasks that the team and vendor were working on, and planning spreadsheets. Months had gone by and there was nothing to show, pressure was high, and their backs were against the wall.

Plan B

While the traditional project was underway, a couple of people from Business got fed up and decided to try something different on their own - in parallel to the main project. In practice, they forked or branched the project from a business perspective. They called their initiative “Plan B”.

A common pitfall in IT projects is to start building architectures and solutions before having validated business assumptions. Clear requirements don’t guarantee business success. The requirements could be guiding you towards building the wrong thing. Plan B decided to focus first on the business problem, then on the technical solution.

Using off-the-shelf, "no code" tools, a team of non-technical business people went directly to talk to end users. “What are the issues you're facing currently? What reports or BI would you like to have?” The goal was to build a skeleton or prototype as quickly as possible without getting bogged down by project management governance or technology.

A few weeks later, the first prototype was ready to show.

The team handed it over to willing ‘beta tester’ end users. It was a raging success. The simple delivery provided enough functionality to enable end users to get work done faster and better than before.

A few months later, the prototype had grown to become a massive spreadsheet connected to multiple databases and dozens of users! Plan B team started panicking. They were a victim of their own success. Agility had enabled them to go too far, too fast. They had ignored the technical side for too long and the solution was no longer scalable. The team could barely go on holidays.

It was time for a pivot. The moment had come to turn that prototype into a technically sound product that could be scaled and maintained sustainably. 

Can Brewers be Software Developers?

Recognizing that the practice of outsourcing everything could be improved, the Director of Zone - the central hub that provides tools and services to the countries - tasked one of his direct reports to investigate the possibility of building an internal software development department. The hypothesis was that bringing software development in-house and applying Scrum - the world-class project management framework - would produce higher quality software, respond quicker to customer requests, and lead to better customer satisfaction. 

It was decided to launch 2 experiments to test this hypothesis. The first candidate project was called Central Planning. Plan B was the ideal 2nd candidate. Sales BI decided to cancel Plan A and pour the remaining budget into Plan B.

The projects had similarities and a few differences.

6 months after both teams started, the differences in output and outcomes was stark. Central Planning had delivered working software multiple times, users were becoming happier, and the team was collaborating well. On the other hand, Sales BI kept running into various organizational challenges and was unable to produce usable working software.

Sales BI was not following key principles of the Agile Manifesto:

4th principle: Business people and developers must work together daily throughout the project.

• The Developers had never met their users nor saw those users use Sales BI.

6th: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• The team organized themselves into expertise silos, communicated actively inside those silos, but not enough outside of those silos.
• During the kickoff weeks the team had the luxury of being physically together. Being co-located has the added benefit of serendipity, of bumping into a colleague and striking a conversation without needing to schedule it. Afterwards however - before and during COVID lockdowns - , the team was distributed throughout Ukraine and they didn't make space for having unstructured conversations.

7th: Working software is the primary measure of progress.

• Instead of reviewing a working product and engaging in conversation with the audience, the Sprint Reviews were plagued by conversations about status of tasks and red-amber-green indicators.

In order to remedy those issues, at the beginning of 2020 the Developers were brought over to Leuven HQ to experience the AB InBev reality. It was a mix of functional workshops - refining backlog items, working agreements, etc. - and some intangible, team-building activities.

Sales people go around the country, visiting bars, restaurants, and supermarkets to sell their beer brands. Which establishments they visit, which brands they attempt to sell is data that comes directly from Sales BI. What better way for the Developers to understand the challenges of using the Sales BI or to experience its shortcomings than actually hop in the backseat of cars of those salespeople? 

In early January of 2020 the team did exactly that. The Developers split up in pairs and each went out with one salesperson. At the end of that day, during the debrief, it became clear that the Developers empathized with their key users.

The positive effect of this experiment was evident immediately. Previously, when encountering a decision point during development, the Developers would stop and seek clarification from the Product Owner. This was a slow and low-quality process. Now, with this new and fuller understanding of their end-users, the team was able to make decisions on their behalf which led to faster and better resolution of those questions.

Another impediment that disappeared after the week of bonding was the team's way of working. 

In the beginning, the team focused on developer “efficiency”, focusing on their own technical skills which led them to organize themselves in silos of expertise - database, middleware, and front-end. It proved to be a flawed strategy. Each silo built things that the others couldn't use, all of it was dumped onto the teammates responsible for testing, and no working software was created.

They decided to try a different approach focusing not on development efficiency but on solving the customers problem. 

Instead of organizing themselves as a single team of 9 people, they assembled in 3 cross-functional sub-teams. They call these sub-teams "pods". The members are tightly integrated within each pod, yet each pod is loosely independent from the others. Rather than working on a technical part, each pod works on a complete user-facing feature from beginning to end. The positive impact was measurable: velocity increased, releases followed suit. 

The pods also improved requirements. Previously, requirements were written with the technical phase in mind and it had to be "translated" so that anyone outside the team could understand.

Now, with the team focusing on solving a customer's problem, the requirements are written from the user's perspective which requires no translation and the team is constantly reminded of the problem they are trying to solve.

Previously, when the team was not delivering a usable increment, the discussion at the Sprint Reviews - or as it is officially named internally: Management Committees, "ManCom" for short - revolved around status updates and escalations. Stakeholder attendance was understandably low.

With the team's new-found productivity, ManComs changed entirely. The team focuses on showing the working product and listening to feedback. It is an informal conversation which users and stakeholders eagerly attend. It is not unusual for the PO to invite 20 people and 40 actually show up. In the past, the PO would lead the entire meeting. Now, different team members take turns presenting, increasing the team's engagement, and improving their understanding of stakeholder feedback.

The positive impact of this experiment is even measurable in the slides presented in the Sprint Review. Before, the team could have 14 slides where 0% related to the working product. Now 80% of the 'non-agenda' slides present new features.

A secondary benefit is that the recordings of the Sprint Review become product documentation. Those recordings capture the team explaining a newly developed feature and the stakeholders reaction and questions to them. Which turns out to be similar questions to other users.

"The backlog was filling itself", said Ryan, the manager of the Sales BI program. "Stakeholder collaboration ended up turning Sales BI into a different animal", he continued, admitting that his original vision for Sales BI didn't materialize. And the organization was better for it.

"When the team was not delivering, the stakeholders focused on deadlines. When they started delivering, the conversations shifted to 'what's next?' ", further reflected Ryan on the impact of Agile.

Sales BI success has both proven the hypothesis that software development is a core competency and clarified what benefits Agile could bring to AB InBev. Its learnings seeded a new way of working that now encompasses most of the departments of the company. On average, Agile ways of working have proven to increase a product's NPS / customer satisfaction by 50 points, reduce the time-to-market by ⅔ , and team members are & remain engaged.

Traditionally in large organizations business people have had two options when faced with a need to develop a new tool:

1. Deal with IT, with all their bureaucratic budgeting and project management processes, and associated costs, delays and failures
2. Go rogue and hire an agency “on the side” to deliver their solution, which is typically low quality, not fitting into the overall architecture, and gets them into fights with IT.

The new approach teams up key people from IT with business teams to develop rapid prototypes that focus on fulfilling end user needs using off the shelf lightweight tools and components that integrate directly with production data sources in a secure way. Under the careful watch of IT security and data experts, business people are encouraged to explore together with their end users in a contained way, developing fast and valuable solutions.

Don't think of scaling when starting.

One of the principles of the Agile Manifesto is “Simplicity”.

Plan B was able to park all the scaling conversations. Scaling technology, scaling features, scaling contracts, and scaling stakeholders & users,. 

Do seek the advice and alignment of your architecture team to ensure that experiments as Plan B don't cause havoc within the ecosystem.

Keep initial teams small.

The Plan B team began as 2 people bouncing ideas off each other. They had a shared goal, desire to solve a problem, and eagerness to learn new technologies. Only when the product was in wide usage did they consider creating a larger team around the product.

Scrum Master must be equipped with habit-changing skills.

Culture is the shared beliefs and behaviors of a team. The Scrum Master of Sales BI understood that changing it required them to start with atomic habits and build on each little success.

The Scrum Team must observe the users using the product / service.

You have to make it a habit for the Scrum Team to observe the user experiencing the product / service. The team will better understand the context and empathize with the users. Which will increase the quality of their decisions.

Cross-functional teams are a must.

Teams might dismiss it at first, but you must keep coming back to it. Look at the organizational structure and processes for incentives that are prohibiting the Scrum Team from becoming cross-functional.

Prepare the Sprint Review.

The Sprint Review is the most important interaction that the team will have with users and stakeholders. Prepare it ahead of time to have to project that "laid back yet in control" confidence.

A winning formula:

1. Prepare a couple of days before the review. Which PBIs can be presented, how, and who will present them.
2. Start the Review by reminding the stakeholders of the Product Goal, the goal of the release, what's been done previously. A user story map is a great tool for that.
3. Present - not demo yet - each item. A great formula is the "before and after".
4. Ask for feedback.
5. Let someone from the team demo the new features.

Turn your Sprint Review recordings into documentation.

Don't let your preparation go to waste. Use it to build your documentation for your documentation. It has a polished and "fresh off the oven" explanation of how the feature works, why it exists, and might even have a couple of questions from the audience.

If you want to learn more about this subject, subscribe and access our next course: Certified Scrum Master.