Journey to Agile: How Braze Reimagined Its Software Project Management Process

We spent the first five or so years building Braze without much in the way of formal project management. We used design docs, Trello, spreadsheets, heuristics, best practices, and a whole lot of meetings to get a tremendous amount done. No two projects were the same—some were run by an army-of-one who kept the current status in their head, while others were meticulously documented practically down to individual commits. It all worked well enough...until it didn’t.

By early 2018 we began to see clear signs that there were some fundamental issues:

• Too many projects in flight at once.
• Too many requirements changing late in the build cycle.
• Too little transparency into what other people were working on.
• Too much time spent coaching people about how to manage projects and properly chunk up work.

These were all part of a web of interconnected, major issues. It was unclear how projects were being prioritized, when they were being worked on, and what was expected to be built. The problem was as core as it can get: how do we work? It was time to fundamentally change how we managed software projects.

Making a Plan

After some reflection, we decided to move toward a tried-and-true methodology for engineering teams—we decided we wanted to become more Agile.

To approach this new challenge, we wanted to put together a group that would represent and leverage the knowledge of our entire product and engineering organization—so we created a committee with eight members representing product management, design, and engineering. We included both managers and individual contributors, as well as people with varying levels of Agile background, seniority, and experience.

This Agile Committee, as we dubbed it, approached the situation with a few key principles firmly in mind:

• We wanted to use proven solutions where possible, both across methodologies and software. It takes a lot of effort to be unique and we wanted to be unique only in necessary and strategic areas. We also wanted people to be able to Google best practices about managing their work—or, better yet, have people join Braze already knowing mostly how to do it.
• We wanted product engineering teams across Braze to be largely consistent in how they operate, because being able to speak the same language is valuable.
• We didn’t want to do anything dogmatically, or without thinking it through. Just picking a method and then going by the book wasn’t good enough; it was important to us that common sense and thoughtful iteration ruled the day.

Armed with those guidelines, we decided to make use of Scrum, which is an Agile framework that’s proven effective for many organizations. It’s widely known, it’s scalable, and it’s the safe, default choice when you’re looking to implement an Agile process.

Next, we faced two main decisions: (1) what tools we should use to support our new process and (2) how we should roll out the changes to our process. We talked about, evaluated, and demoed several pieces of software—and ultimately Atlassian’s Jira proved to be the right choice for us. It’s a well-proven solution, several folks on our team already had experience using it, and other teams within Braze were already using it, opening up an opportunity for better cross-team collaboration because we’d all work within one system.

When it came to selecting a rollout plan for Agile, we had a few key decisions to make. First, how do we train/enable the team? We could hire an Agile coach, have folks with experience on the team do the work of training the others, or get consultants to help out. Second, should we make teams within engineering that had some experience with Agile wait for training before implementing it?

In the end, we decided to let teams who were familiar with Jira and Scrum get started to the extent they felt able, and hired a consultant to help with the organization-wide transition. We weren’t interested in having people on our team or an independent player be primarily responsible for coaching team members through the transition because:

• We didn’t want any individual team to own how we do Agile and we felt that the training would be better received and the suggestions would be more inclusive if they came from a third party
• We thought a consulting business would be more stable and more reliable than an individual Agile coach
• We wanted to have a basic training for the entire engineering organization and to start off without making any assumptions about the knowledge that individuals members of the organization had around Agile
• Finally, we wanted to have the coaches leave at a certain point, in order to make it clear that everyone in our organization was responsible for maintaining the process going forward

Executing the Plan

After a couple of months of planning, we had a big document that detailed everything we intended to do—and we shared it with the organization at large for feedback. Then, after evaluating several vendors, we selected Eliassen to partner with us on the journey to Agile. That journey began with a two-day Agile training run by Eliassen, followed by three months of Agile coaching from an expert who Eliassen connected us with.

From the get-go, we were fairly cautious about moving to Jira and Scrum. Both the internet and our team’s personal experiences were full of cautionary tales about the dangers of overly dogmatic approaches, of how Jira can come to function as an “anti-pattern,” and all the ways that Scrum can go awry in organizations. We’d been heavily cautioned by people we consulted that these changes would likely take time, and that there might well be growing pains before we saw real benefits from Agile.

Thankfully, we instantly found value in the new process. One of the nice things about this transition is that we never felt any pressure to blindly follow any particular aspect of Scrum; to make things work better, we’d do a retrospective on how things were going every couple weeks, and then modify what needed to be modified. And throughout the three months of coaching, we implemented sweeping changes across the engineering organization:

• Everyone learned how to write, groom, point, break down, and pick up user stories
• Standups found renewed focus when it came to finishing the work at hand
• Product, Design, and Engineering all learned to speak the same languages, and interfaces were increasingly well-designed

The Results

Now that we’re on the other side of this roughly six-month effort, the changes are clear—and dramatic. We’ve seen a significant reduction in the issues that led to this effort. With Agile, we now have clear and easy-to-understand mechanics for signoff, collaboration, backlog creation, and grooming, and we regularly run retrospectives on what to improve.

We also have significantly more consistent locations for design artifacts, as well as better aligned expectations about what “done” really is for a given project. Seeing what other teams are working on has become easy and it’s simpler than ever before for folks to understand how to work well together.

Something I noticed at the tail end of this transition is that the total number of open pull requests in the organization at any given time had declined, even as we were doing more and growing the size of our team. By working in smaller increments and focusing on finishing things, the number of items in flight shrank significantly.

The success we’ve had in our organization has also inspired others. We’re beginning to see teams in other departments at Braze beginning their own Agile transformations, so soon more folks will speak the same language and have the tools they need to define and improve collaboration.

Takeaways

Two main elements of our effort ensured its success.

First, the fact that it was driven by a representative committee was essential in obtaining input from around the engineering organization and from a variety of different perspectives. Company-wide, people felt heard and represented on an issue that would impact their day-to-day work. The subsequent creation of a thorough document laying out the motivations and plans for an Agile transition that could be shared with the team was also quite useful. We believe in showing how decisions are made and introducing clear paths for feedback—because it provides context and establishes an artifact on which to give feedback.

Second, the decision to get a third party to help coach our team was essential. Having an objective, experienced partner gave us the ability to quickly make numerous improvements to our process. Our coach knew what good looked like and was able to make recommendations without bias, a number of times we were able to ask, “How would teams normally do X?” and get an immediate, workable solution. If, on the other hand, we’d used internal resources, we would have run the risk that the feedback we received came from a biased party and increased resource contention with existing responsibilities.

Anything Else?

If you want to learn more about how we think about our product and the work that goes into making it, check out Building Braze. Interested in joining our team? Check out our current job postings.