Buzzvil’s Engineering Culture Through a Developer’s Eyes: Agile Software Development

1. Getting started

Developers are happiest when they can focus on development. You arrive at work on a sunny morning, feeling good, and reopen yesterday’s windows. As editors fill the screen, the data structures and algorithms for your feature load back into your head. This data goes here; that logic should work like this. Soon, you’re so absorbed that the monitor is all you see. Someone taps your shoulder: “Time for lunch.” Many developers love these moments. The pleasure of focused work beats eating five chocolate bars at once.

Now change the scene. Just as you begin to concentrate, someone taps your shoulder. “Let’s have a meeting.” “Have you finished the requirements document?” “When can you deliver this new feature? Actually, we need it next week.” “Could you add one more thing to the feature we discussed?” Oh, no.

It’s not that we don’t understand the person doing the tapping, or the circumstances that make interruptions unavoidable. Software is inherently complex, and creating an environment where developers can work happily is difficult. But must it always be this hard? Probably not. Many people before us have faced the same problems and tried to solve them. Development methods and tools have emerged, and programming paradigms have continued to evolve. We can use that hard-won experience to build a better working environment.

2. Background: agile software development

If you work in development or a related field, you have probably heard this rather fashionable term. “Agile” software development certainly sounds appealing. But despite the fresh-sounding name, the ideas have been around for quite a while. Different approaches to managing software’s relentless complexity gradually took shape. In 2001, leading practitioners including Kent Beck, Martin Fowler, Robert Martin, and Jeff Sutherland met at a ski resort and wrote the Agile Manifesto.

Agile Manifesto (reference: Manifesto for Agile Software Development)

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

As the name suggests, agility involves speed—but specifically the speed of making something useful happen. Imagine a customer who drops into a snack shop for a quick roll of gimbap. If you promise the finest meal imaginable and then begin preparing every ingredient from scratch, they will have left long before you finish, however wonderful the food might be.

A common source of confusion is whether agile is a methodology or a process. It isn’t a prescribed process with fixed development stages and deliverables like RUP, SPICE, or CMMI. The manifesto is better understood as a philosophy about what deserves more weight when developing software. If that sounds abstract, its authors also set out twelve principles:

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity—the art of maximizing the amount of work not done—is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I decided to examine how Buzzvil works against these commandments—twelve rather than ten. Our excellent PMs, Young and Eric, had already introduced useful practices from Scrum and Kanban. Thank you both! We use English names at Buzzvil to make communication less hierarchical.

The image below marks the practices we use or are introducing with red boxes. Rather than give a textbook explanation of each practice, I think it is more meaningful to see how closely our everyday work reflects the twelve principles. If you want detailed explanations of the practices themselves, a search will turn up plenty of good resources.

[Image source: Subway Map to Agile Practices]

3. Buzzvil and the twelve principles of agile development

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Software exists because customers need it. However impressive a product may be, it has no value if nobody uses it. Broadly, Buzzvil has four customer groups: lock-screen users, advertisers, publishers, and operators. They have different needs: a better experience through quality ads and content, improved ad performance through more sophisticated targeting, revenue from a reliable service, and easier day-to-day operations.

Customers aren’t endlessly patient. If our products don’t deliver that value, they won’t wait. Users will leave. Advertisers will stop giving us campaigns. Publishers may abandon the business because they cannot trust the service. Operators may even leave Buzzvil because their work is tedious and complicated.

We therefore quantify the data that represents this value and monitor it in real time. Frequent releases and feedback help us keep improving customer satisfaction. Nothing takes priority over that.

[Image source: Buzzvil data dashboard]

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

From a developer’s perspective, changing requirements are rarely welcome. Nobody enjoys working hard on design and implementation only to see the result become meaningless text on a dark screen. Yet requirements will change. Customers may not know what they want, or a change in the business may make something unnecessary or require a different approach.

Let’s accept it: requirements change frequently, even after a product launches.

Buzzvil accepts this reality. How do we handle it? We break the problem into two parts.

• Receiving and clarifying requirements

Clearer understanding at the start reduces misunderstandings and unnecessary changes later. All requests to the development team go through a product manager. With the broadest view of the product, the PM clarifies what the customer actually needs and, when necessary, consults developers about feasibility. Requirements become more concrete, with less uncertainty and ambiguity.

Buzzvil has four PMs, responsible respectively for end users, advertisers and advertising systems, publishers, and product improvements. Each gathers and refines requirements differently according to their customers. Before each sprint planning meeting, the refined requests are reviewed again and placed in priority order in the product backlog.

• Implementing requirements and checking progress

Anyone who submits a request to the product team can always see how it is progressing. The development team’s Scrum board is visible to everyone, not just developers. We manage it in Trello. Cards can contain detailed information and provide a place for discussion. Developers record progress on the cards, and PMs or requesters can ask questions and make requests there. Changes that stay within the overall scope can be handled through this conversation.

[Image source: Trello, one of Buzzvil’s work tools]

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Customer requirements can change at any time, so we need to gather feedback and reflect it in the product as quickly as possible. Deployment must therefore be simple and automated. Continuous integration, and eventually continuous deployment, can help.

All software assets are version-controlled on GitHub. Before a branch merges into master, Jenkins automatically runs the required tests. New features may also come with new unit tests, which become part of the CI process.

Most deployment scripts—including zero-downtime deployment, build versioning, and library patches—are automated with Fabric. After finishing development, an engineer simply runs fab deploy. Recently, we have been working toward deployments triggered by pushing code to version control. Because deploying is straightforward, we can release small changes frequently and receive customer feedback sooner.

[Image source: system update notifications]

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

Buzzvil has an unusual custom: every two months, everyone draws lots to decide where they will sit for the next two months. There are no exceptions. This removes boundaries between teams. Your neighbor might be a designer or someone from the business side. Working close together lowers the cost of communication and helps us understand one another’s language.

The business and partnerships team does sit in a separate area, because its work involves frequent calls and visitors. This gives that team room to communicate freely while helping others concentrate. Within its own area, the team also redraws seats every two months.

[Image source: Buzzvil’s office]

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trust and respect are my favorite part of Buzzvil’s culture. We believe we work with excellent teammates who make sound decisions and act responsibly. We respect one another. Junior colleagues don’t hesitate to share their views, and senior colleagues don’t insist on having their own way. Everyone has something to learn from everyone else.

At the start of each sprint, we estimate work and plan the schedule. A particular developer may be more familiar with a task, but each person decides which tasks to take. Developers choose their work using their own judgment and plan how to complete it.

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

We use many collaboration tools: Slack, Trello, GitHub, Google Calendar, Google Docs, email, Skype, and more. They are all valuable, but they have limits. Nothing communicates quite as efficiently as a face-to-face conversation. At the same time, interrupting someone every time an issue comes up is uncomfortable, so we set aside a time to talk freely.

Every morning, the development team holds a daily Scrum lasting about fifteen minutes. As in a typical Scrum meeting, each person spends roughly a minute sharing what they did yesterday, what they will do today, and any issues or help they need. Brief questions are fine, but detailed discussions happen immediately afterward with only the relevant people.

We also pair-program when useful, particularly when someone has just joined or needs to work on unfamiliar code.

[Image source: the development team’s daily Scrum]

7. Working software is the primary measure of progress.

At each sprint review, everyone spends about five minutes sharing what they have built. We may look at source code or demonstrate the feature running. We applaud one another’s work and ask questions. The review isn’t limited to visible features: people also share refactoring that made code clearer or easier to extend, and research into new technologies.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Developers decide what to take on in each sprint. Assuming about five hours of focused development per day gives roughly fifty hours across a two-week sprint. Each person estimates the difficulty and volume of their tasks, then plans around thirty to forty hours of work to leave room for incidents and unexpected issues. Product managers keep checking workloads during the sprint to prevent overload.

The word “sprint” can be misleading. It means setting a goal and concentrating on it, not running flat out until you collapse. Working through the night is nothing to boast about. If it becomes unavoidable, either your planning has gone wrong or your boss is doing something wrong. We should encourage sustainable, predictable results over short-lived bursts.

Developers should work with their brains, not simply log time in their chairs. Concentrate when it is time to work, and take a proper break when it is time to rest. One Buzzvil meeting room uses a ping-pong table as its table and is always busy around lunchtime. The lounge has a large TV and PlayStation, and we sometimes hold Winning Eleven tournaments.

[Image source: lunchtime table tennis]

9. Continuous attention to technical excellence and good design enhances agility.

Buzzvil’s servers receive requests from millions of users every day, with hundreds of requests coming from those users. Simply making a feature work is not enough; we need to consider architecture. That includes optimizing ad allocation, search for more sophisticated targeting, and the collection and processing of data, among many other concerns. Design work must continue alongside the implementation of new requirements.

Recently, we have been moving toward a microservice architecture to reduce complexity and rewriting some bottlenecks in Go to improve performance. If something is necessary, we find a way to start. Put it off indefinitely, and it never happens.

Technical debt can still remain. After every three regular sprints, we therefore hold a maintenance sprint focused on these concerns. We temporarily pause new requirements and repair the system. Typical tasks include framework and server infrastructure work, security, and monitoring—things that can be difficult to fit into everyday development.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

Understanding and implementing requirements should be as simple and efficient as possible. Do we really need complicated estimation procedures or reporting rituals to track progress? What matters is getting the work done. For estimates and progress, simply recording the expected time and current state on a Trello card seems more useful. Nobody knows a developer’s schedule better than that developer.

The image below shows my actual Google Calendar during a typical sprint. Study sessions and meetings of our hand-drip coffee club, Kkul Dabang, are personal activities. StrategyTalk is a monthly company-wide meeting. Apart from those, the product team’s meetings consist of sprint planning and review, the daily fifteen-minute Scrum, and a one-on-one with the development lead. There are no wasteful meetings and no meetings held merely to report status. Nobody micromanages developers or asks for reports. Sprint planning, reviews, and daily Scrum provide what we need.

[Image source: Google Calendar, one of Buzzvil’s work tools]

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Work isn’t much fun when you do it only because someone told you to. If someone said, “Don’t look at anything else; just focus on this task,” I might walk out. In fact, one of the main reasons I left my previous job was that the work I enjoyed had been taken away. After becoming a team manager, I spent far more time in meetings and writing reports than developing software.

Developers choose most of their tasks from the backlog themselves. People seem more productive when they can focus on work they want to do. Planning your own tasks and schedule naturally brings responsibility. Even before writing a single line, you check why the feature is needed and whether the code will remain easy to change. We agree that code should not have exclusive individual ownership, but that doesn’t mean writing code we cannot take responsibility for.

12. At regular intervals, reflect on how to become more effective and adjust the team’s behavior accordingly.

At the end of each sprint, after task reviews and demonstrations, we discuss what went well and what needs improvement. Here are some examples:

• Tasks aren’t clearly defined → Have the PM clarify them before they enter the sprint.
• Incidents and urgent issues invalidate the initial sprint plan → Leave a buffer.
• Code review requests concentrate on a few developers → Give reviewers a way to pass reviews to others.
• Test phones are difficult to manage → Label them, store them in lockers, and leave a business card in the slot when borrowing one.
• We need a better approach to unit tests → Guide developers to cover important code first.
• Code reviews sometimes pile up → Use a Slack bot to send reminders just after people arrive and after lunch, and encourage reviews before other work.
• We want to try standing desks → Buy four as a pilot, then discuss expanding their use.
• Development knowledge is scattered → Create a GitHub project and use its wiki to collect it.

Retrospectives cover a wide range of opinions. Once we reach agreement, we turn it into an action item and act. Buzzvil’s development team keeps adapting. We have even discussed playing gentle background music during daily Scrum to keep the mood from becoming too serious.

Maintenance sprints remain a lively topic. Should we defer maintenance until a dedicated sprint, or do it alongside regular work? We keep discussing it and expect to find an approach that fits.

4. Conclusion

To repeat: agile software development is not itself a prescribed process or methodology. Well-known approaches such as Scrum, Extreme Programming, and Kanban exist, but adopting one unchanged simply because others recommend it would be foolish.

Teams have different personalities and tendencies, just as people do. Some are highly structured; others are flat. Some build mission-critical products that cannot tolerate defects, while others need fast feedback in an unpredictable environment. Each team must think about what suits it and be willing to adapt to new ways of working on a foundation of mutual trust.

Buzzvil’s recent merger with Slidejoy has helped our product culture mature further. As two engineering organizations—with similarities and differences—come together, we learn from each other, make compromises, and build understanding. That is how we are creating a better development culture. If Buzzvil had insisted on one fixed approach, we could not be building the team we have today. Understanding our core values and trusting each other make it possible.

We will encounter new problems. When we do, we will adapt again and find a better way, just as we always have.