How We Run Our Growing Engineering Team at Pipedrive

As you may or may not know, we’re hiring. A question that often comes up during interviews is “how does engineering work in Pipedrive?” Here’s my answer in the form of a blog post.

Perhaps it’s useful for deciding whether to apply for a position here, or for fine-tuning the engineering processes in your current organization.

The philosophy behind our engineering efforts

There is a very common mental trick that’s used in long-distance running: break the distance up into smaller parts. Pick a sign on the side of the road and run until you reach it, and then pick the next one. Rinse, repeat.

We like to use this approach as a metaphor for Pipedrive’s product development efforts. We know where we want to get, but we also know that the road ahead of us is long - so we choose to focus on the week and tasks immediately ahead of us.

Before I joined Pipedrive in October 2013, engineering was run by our CTO, Martin Tajur. A fairly small team of 10 engineers was using Asana to organize their work around the different product ideas. Product development used more of a project based approach where bigger features would be developed in several iterations before being integrated into the product and released to the customers.

It was not a rare case that a long-running project would be paused or stopped in favor of other, more urgent changes. For example, one of our backend developers had completely redesigned the way that relationships between companies and users were defined - a large block of work by any metric - but since other, smaller changes needed “more urgent attention”, the redesign was left in his desk stash and wasn’t implemented for months. Once I joined the company and learned about it, we finalized the development.

The framework we’ve adopted

It was clear that such an approach was neither effective nor scalable for the bigger engineering organization we wanted and needed to develop. This is why we decided to adopt the Scrum development methodology, which promotes multiple independent small teams and quick product iterations upon which real user value delivery takes place frequently. We’ve been using Scrum ever since.

A bird’s-eye view definition of Scrum would be that it is an Agile framework for completing complex projects. The process is organized around a prioritized list of tasks that a team needs to complete in order to ship the product to the customers. Scrum values team effort and defines some simple and robust rules for the team to operate within.

Along our road of using Scrum, we have changed and improved our processes substantially. We started with three separate teams: Android, iOS and Web application development. The Web application team was the biggest one, and was soon split into two separate teams.

There’s an element of the Scrum methodology called Retrospectives which have become popular ceremonies in teams. People give and receive feedback, and look out for improvements. This is the backbone of the so called dynamic stability - the process of continual but relatively small change efforts that involve the reconfiguration of existing practices, rather than the creation of new ones.

It is interesting to see how the topics discussed at retrospectives have evolved alongside with the skills and maturity of the team members. Initially, most of the struggle took place around process itself as people were trying to understand what works best. Once routines broke in and became second nature for people, the problems around specifications and task definitions emerged.

I asked some of our developers for feedback on how they feel about the Scrum methodology we’re using. Old timers are saying that the biggest change for them is having more clarity on what the priorities are. Newcomers prize Pipedrive as an organization where Scrum actually works.

In Martin Kapp’s words: “Before scrum, everyone was more or less free to do what they wanted and needed, but it was also hard to keep focus and stay motivated. Scrum has given us focus and clear goals about where we want to go with our product and what we actually want to deliver.”

Henri Kroosmann confirms: “Scrum has improved the visibility and predictability of upcoming tasks. Our team has a better understanding of the company direction and bigger goals that we are trying to achieve.”

How Scrum is applied at Pipedrive

At the beginning of 2015, we split our web teams into four small but independent teams. In addition to that, we shortened our sprint length to only one week. It turned out that two simultaneous changes were too much for the organization. However, we haven’t reverted either of the two as both are necessary changes but we have learned a lesson, and will be cautious about changing too much at once in the future.

Our teams are cross-functional - ideally, there should be five developers, one quality assurance specialist and one product manager in every team. Going through the different phases of scaling the organization means that such a perfect combination will likely never exist, at least not in every team. We either add new people into certain teams, so they could pick up the knowledge and skills faster, or split the teams into smaller (understaffed) ones, so that we could easily add new hires.

Going forward, we’re not likely to split the product teams anymore. Instead, we’ll be adding new types of teams in accordance to our business needs. The next areas of focus are data analysis, core backend infrastructure, developers and operations tools. It is our highest priority to hire people who could either cover the required area or free up some of the people from existing teams.

We believe that it is crucial to minimize the friction and time between the thought and the implementation. We also do not like to repeat ourselves. We try to adhere to the principle of minimizing the amount of work which needs to be done through using the best tools available, and automation.

What we measure - how do we know we’re doing a good job?

To better understand team performance and the impact of process and tool-changes that take place, there are several indicators we follow. Sprint velocity, commitment and delivery are important to track in order to understand if a team is overcommitting or not pushing themselves hard enough.

In the graph below you can see how the commitment amount for the sprint Q1W10 far exceeded the previously delivered amount of points, leading to the real delivery amount suffering even more. One could argue that there might be other reasons too, but failing overcommitted sprints is a very notorious trend. On the other hand, committing to just the right amount of points produces most of the value delivery. Getting there requires a good amount of trial and error.

Another metric that we follow is average task cycle time as it creates insightful discussions about problems in development, as well as indicates the positive trends in task definitions and value delivery. The control chart in the Jira Agile reports section gives an overview of the statistical averages for all tasks’ cycle times and exposes outliers which can be scrutinized for details and reasons.

Our target is to keep the average cycle time for all tasks under 3 days, giving us the ability to get any task ready within one sprint. This is crucial for our ability to deliver committed tasks during one week sprints.

Another important metric defines our bug fixing strategy. The team net bug score is defined as the number of bugs resolved minus the number of bugs registered. We try to keep our score positive over a certain period of time, i.e. we fix more bugs than we add to the list of known bugs.

The tools we use

Our free form communication takes place in Slack, as do all important notifications about automation failures and the recovery from these failures. The team gets notified about the most important business metrics like new or lost customers through a Slack channel too.

Atlassian Jira agile workflows reflect very precisely how one successful Scrum organization should operate and we are taking full advantage of it.

Each developer is free to choose whichever code editors he is fond of and feels most productive with. PhpStorm has been adopted by most backend developers, Sublime Text is used as a generic editor by everyone. Mobile developers use platform-specific tools like Xcode and Android Studio.

Github is the central place for storing all our code. It makes it so easy to integrate with other tools in the code delivery and deployment chain. We use code reviews for all of our code changes and Github pull requests help us to do that.

We have deployed Jenkins as our CI solution but we’re currently sailing away towards Codeship as we hit an issue with scaling Jenkins to run on each and every code branch prior to merging code to the master.

Our localization process can be called state of the art. We managed to implement localization as a parallel process to the development. On each code commit, we extract newly added strings and automatically send them to our translation platform. At the same time, we check if there are any new translations for previously submitted strings and include them into our code.

Our approach to testing is similar to localization - it must happen in parallel to the development process. We invest a lot into automation of tests. Unit and Integration API tests are executed on each code commit. UI automation tests are executed manually by developers to capture functionality regressions. All bigger functionality changes are hidden behind feature toggles and tested thoroughly before exposure to the customers.

Learning new technologies and skills is very important to us as well. We do regular meetups for all engineers, called TEX (Technical EXchange), and sometimes take part of specific training courses outside our office. Sometimes we also get one of the engineers to present a new technology or solution, or pick an interesting presentation from Youtube, watch it together and discuss it afterwards. We also go to key technology conferences, such as Apple WWDC and Google I/O.

If you have questions on this topic, simply leave a comment below. If you’re interested in a position in Pipedrive’s engineering team, check out our jobs page for all vacancies and apply.

Image courtesy: Scrum Alliance, Stocksnap