Pipedrive Agile Framework: A Detailed View

Co-authored by Juan Gutiérrez

Introduction

In mid-2018, Pipedrive decided to change the way we work in engineering and moved to what we internally call the Pipedrive Agile Framework. Sergei Anikin has previously introduced the rationale behind the decision and the transition and how this framework works at a high level.

Since its inception, the framework has evolved while still retaining its core principles. Juan Gutiérrez Plaza and I wrote about this in our last post, where we emphasized how dynamic and static structures work together to maximize flexibility.

This post will go deeper and detail how the framework works and its strengths and weaknesses.

Overview

Pipedrive looks like a standard organization from the point of view of an organizational chart:

• Product that includes Product Management, Research and Design
• Engineering that includes Infra, Support, DevOps and R&D, among others
• Marketing and Sales that include the regular subunits

With all that, there’s still another structure in Pipedrive — Tribes.

Tribes are, in short, “a big team” owning certain customer-facing services or internal platforms; for example, one tribe is responsible for Insights (data visualization and reports), another one for Ecosystem (marketplace, integrations…), etc. Each tribe includes all the roles necessary (not only engineers) to work, which usually results in tribes of around 15–35 people. In such big groups, work is organized into smaller dynamic entities that we call launchpad and missions.

Tribes

Each tribe is accountable for one area of Pipedrive’s services. Tribes are responsible for the full cycle of the service: from defining the customer problem and finding a solution to maintaining, monitoring and improving it until the service is deprecated.

Tribes have their vision and objectives. In addition to engineering, product management, and design, other non-full-time roles such as data analysts and researchers help support the tribes. The goal is to have the tribe be as independent as possible.

When the tribe owns the entire vertical solution for a customer problem, it’s easier to set priorities and keep a high engagement environment. Each tribe has an Engineering Manager and a Group Product Manager who are accountable for the high-level roadmap. They work similarly, using launchpad and missions as their core way of working.

Missions

Missions are focused engagements to solve a specific customer problem. They have different artifacts compared to classical projects, and a dedicated team runs them. Throughout the mission, the team continuously validates the problem and defines its solution, with more details involved over time.

The mission team

There is a core team for each mission: a product manager, a designer, and a mission lead, usually a software engineer. They are accountable for mission deliverables from problem validation to the solution’s quality and implementation. The team works together akin to mini startup founders in a bigger company.

Each mission’s core team shares the team responsibilities amongst themselves. While there are guidelines and best practices on hand, the roles and responsibilities are sometimes shared based on team members’ preferences.

Various roles are involved in the mission life cycle at different times:

• Researchers to help validate the market fit and obtain customer feedback
• Engineers to contribute with coding, setting the architecture and quality parameters
• Data analysts to help define metrics for customer behavior
• Marketing specialists, content providers, customer support and success personnel to give input and help on go-to-market plans, support materials and more

The product manager and mission lead usually stay on for longer after the mission ends, as they are the ones who should ensure proper implementation of the new/updated feature. Part of their responsibility includes prioritizing issues together with the Launchpad Lead and creating follow-up missions where necessary.

Cross-company transparency

It’s essential to have information about different missions flowing because there might be common or overlapping dependencies or user flows. In Pipedrive, it’s encouraged to challenge the chosen solutions for problems they may have.

For that reason, we have Pitching Tuesdays, a live cross-company event where missions are pitched and demoed.

Pitching is about introducing new missions — the problem statement, the proposed solution, the need for more people and the key success metrics that define the overall mission success.

Demos, on the other hand, are a retrospective presentation about mission learnings and deliverables. Demos are where people across the company learn about upcoming changes and more.

Structure

Each mission team can define their working agreements. Usually, there are

• Daily standups with the entire team, including designers and product managers
• Jira board for tasks to be solved with kanban settings
• Initial planning sessions with recurring updates and follow-ups
• Ongoing retro sessions
• Customer interviews where engineers are encouraged to participate

Each mission is unique in its details. The mission team is ultimately responsible for making all the decisions to validate the customer problem and deliver the best solution.

Agile coaches are on hand to help and support with facilitation and best practices. Managers of the tribes also help each individual with growth, though they may not actively participate in the decision-making.

Timeliness

As in any company, Pipedrive wants to solve customer problems as fast as possible and obtain customer feedback from actual actions — all while ensuring that quality isn’t rushed or sacrificed. The core team will prepare the delivery plan in the early days of mission preparation, though estimations are up for changes across the mission.

Initial estimation for a mission needs set engineering investment before the entire team is assembled after a Pitching. The core team will assess the time plan and change the delivery dates where necessary throughout the mission. Some changes are accepted without much reasoning, while other changes become “alerting triggers” to start analyzing the problems on why the mission is constantly expanding. Learning outcomes are then drawn from such changes and shared with the team and the rest of the company.

We transform this aspect of time into a will to do early and regular deliveries to selected customers (this selection varies based on the mission goal: for instance, customers in a particular region, of a specific size, etc.). What better way to gain customer feedback than to let them use the new/improved feature? The earlier the feedback, the easier it is to decide whether to change the solution or drop it entirely and start from scratch.

Evaluation

Missions are unique. Together with product and engineering leaders, each mission team sets goals for their mission — from code quality, reusability, scalability to customer adoption and satisfaction and more.

Although each mission is usually part of a broader strategic initiative regarding a more significant customer problem, its success is measured separately. For example, suppose customer behavior is measured. In that case, the primary metrics are how many customers notice the update and how many use it, with the central measure being how many customers keep using it.

Learnings

Continuous learning happens across the mission lifecycle. While the focus points and inputs are different, the aim is the same — knowing that the mission is on the right track. More than just customer behavior, there are also technical and organizational learnings to be drawn.

Retrospectives are shared across the company for ad hoc and broader knowledge sharing, while learnings are shared in the demo on Pitching Tuesdays at the end of a mission.

Launchpad

The Launchpad is a purely dynamic team whose size varies depending on internal (priorities) and external (missions) needs. Depending on the tribe’s nature and context, its size is typically between 20% and 33% percent of the tribe’s size. Due to its dynamic nature, it can sometimes be 10% or 90% of the tribe size during short periods.

The team takes care of maintenance and support of all the tribe’s services. They are responsible for reducing the technical debt and improving the quality of the services, including alerting and monitoring. They may also make minor and very targeted product improvements.

A Launchpad Lead, a rotating role of about 3–6 months, heads up the Launchpad. Anyone can be a Launchpad Lead, and tribes choose how they do this rotation, with the most common way being voluntary.

When missions land in a Launchpad, the Launchpad team will take ownership of all the new code from that mission. To ensure a smooth transfer and knowledge sharing, the mission team will meet the Launchpad to go through what has been done, its reasons, and product and technical details. The launchpad lead then has the power to decide if a mission is good enough to land on the Launchpad or not.

Suppose the quality is not up to standard (e.g., good test coverage, monitoring, alerting and logging done, security by design and check-ups, etc.). In that case, the Launchpad Lead will decline the landing, and the mission will continue (or crash). A common strategy for a smooth transfer and knowledge sharing is to keep at least one person from the landed mission in the launchpad. This way, it ensures that the rest of the Launchpad will continually receive this knowledge while avoiding nasty surprises. It is also a way to emphasize the ownership of the people on that mission.

Guilds

Guilds are virtual organizational units that consist of members from different tribes with clear goals. They are self-organized units that anyone in Pipedrive can initiate to unify people with similar interests for a specific problem.

There are more general guilds like architecture and content guilds, specific guilds for some technologies like go-lang, process-related guilds like hiring and onboarding guilds and, of course, the guild that makes changes to the Pipedrive Agile Framework.

Technical guilds don’t own any part of the codebase as the tribes themselves own the code. However, guilds are a great place to share knowledge, ask for advice and add transparency to the processes and service architecture setups.

As a group of people with a shared interest, guilds can initiate missions to accomplish a goal or achieve improvements with tasks done by some guild members. It is expected to invest 20% of the work time into the guild while working on the Launchpad.

Lead Roles

There are four prominent leadership roles in the framework — three dynamic roles and one static position:

• Mission Lead (role) who is responsible for the mission execution and mission team formation
• Launchpad Lead (role) who is responsible for a tribe’s Launchpad
• Track Lead (role) who drives larger initiatives from an engineering perspective that involves different tribes and a series of missions
• Engineering Manager (position) responsible for the entire tribe, its functions, and the engineers in it, and drives initiatives on a company-wide scope

Having roles instead of actual positions allows engineers to experience and learn about leadership in a controlled environment, bringing about multiple benefits:

1. Engineers can improve their leadership skills without changing their position.
2. Engineers can validate if a leadership position is something they would like to lean towards in the future or not.
3. Engineers can grow beyond their core competencies.
4. Engineers can take responsibility for an area that they feel passionate about.

Image Credit: Sagittaria — stock.adobe.com

Highlights

Flexibility. The whole concept of missions is built around flexibility and accepting that our business changes rapidly. As the speed of change is increasing, we should be ready to adapt and reprioritize at any moment. Hence, this framework is set based on constant changes to maximize the adaptability and maneuvering capabilities of the company.

Freedom of choice. Allowing engineers to work on what they care and feel passionate about has many advantages, especially motivation, long-term commitment and quality of work. Their satisfaction is higher, and knowledge is shared more around the company, increasing flexibility.

Ownership. The framework has multiple roles that rotate over time, allowing engineers to own certain areas and have narrower responsibilities. As tribes have clear ownership, engineers get to be a part of this. Additionally, they are allowed to focus on a particular area of their choice and work in missions related to it, enabling ownership in a flexible environment.

Mastery. As tribes own their areas and engineers have the freedom to choose, mastery comes as a choice. Engineers can master their tribe domain as a whole, specific services in the tribe deeply, or even a particular area of interest that they collaborate on through missions. They have all the support they need to dig into those areas and obtain training or other ways to get better. Though it’s a matter of choice, the system is flexible and supportive enough to make it possible without compromising flexibility.

Areas of Improvements

Learning curve. As the tribe is larger than the classic cross-functional team, there are more services for an engineer to handle. That means onboarding the tribe happens step-by-step and service-by-service and takes a long time before the person feels comfortable with all the services.

Extra effort to assemble the mission teams. With nobody telling anybody what to do, assembling the team at the beginning of the mission takes time and effort while not providing valuable feedback for the mission core team.

No reliable plans. Estimates for mission length and size are given from high-level scope bases without knowing the exact team of the mission before the execution phase. With the team being new both in the area of the mission and working together, committed mission estimations are challenging to stick to. As a result, more than half of the missions get extended.

Conclusions

Pipedrive engineering has been working in new areas for three years now. The number of engineers has grown from around 100 engineers to 250. The ownership of the processes and architectural decisions are distributed, and anyone can contribute, give, and receive feedback. This gives a very high degree of self-governance on technical decisions and processes around engineering. We have around 20–30 missions in parallel, while more and more cross-tribe missions are happening. Tribes are formed, changed, and split. People move between the tribes to have the most significant impact and the best personal growth with their internal drive and state of life in mind.

The Pipedrive Agile Framework provides multiple benefits like flexibility, scalability and empowering each individual to own their own experience in the company. It enables the organization’s scalability and allows people to make a difference and have their voices heard. Everyone knows that problem-solving starts from the individual.

All that said, no framework is perfect. We will keep enhancing it, together with everyone. Join us!

Interested in working in Pipedrive?

We’re currently hiring for several different positions in several different countries/cities. Check the job offerings here

Interested in knowing more about how to design versatile organizations?

Join unFIX Foundation Workshops facilitated by Kadri, one of the implementors of Pipedrive Agile Framework — unFIX provides you with a language on how to design organization fits for your situation! As there are no one-size-fits-all models!