At the fast-growing stage, any company starts facing the problem of scaling. In this article, we’d like to share how we manage scaling while staying adaptive to the market changes and suggest experiments to implement in your company (check the “try/avoid” sections).
First, you need to define what is “to be agile” for your company. For PandaDoc, agility means:
Try. Define the goals to optimize within your organization and try to accomplish them together, like “highest value” and “resource optimization”.
To deliver the highest value first, we avoid teams being experts in one area and boost learning based on work priority, collaboration in code, and cross-teams code reviews.
Feature Teams take a customer-centric element from the backlog and ship to the customer.
Try: Identify the teams you need to deliver according to your optimization goal.
Many people misunderstand Scrum and apply a so-called copy-paste one, like in the picture below. This way, every owner optimizes their work even if it has lower priority.
That's why we have one product owner within one backlog and multiple teams that pick items from it according to priorities.
Try: Count “backlogs” or other lists in your organization — their amount is a good indicator of overall agility. More lists mean more local optimizations.
No managers coordinate task’s assignments or work between teams, as it’s a team’s responsibility. PandaDoc uses multi-teams for sprint planning, backlog refinement, sprint review, and retrospectives. This promotes better efficiency but requires good facilitation skills and a proper toolset for work.
Try: Define where your teams are learning from customers, internal stakeholders, or each other, as well as the duration of learning cycles and how to speed it up.
We also use certain coordination practices between teams and individuals:
As soon as you have a question, it is better to get up and talk to people.
Every team member inside PandaDoc should be open to questions from other teammates and expect the same. There is no need for formal, official, and slow coordination.
Scout is a team member who investigates its environment and reaches out to other teams or departments to get clarifications or check status. Usually, Scout is selected for one Sprint.
For example, your team needs to clarify the final technical decision on your feature with another team. Then, Maria, as a Scout, visits the other team Daily Scrum to clarify this.
Traveler is the person sent by your team (or into your team) for a couple of Sprints to learn or teach something.
For example, your team starts additional development inside a feature done by another team but lacks knowledge of the technical implementation. Then, you ask Alex to join your team for the one sprint and boost your delivery with pair programming or consulting.
To manage cross-team coordination, we have numerous communities in PandaDoc, such as Backend Guide, QA Guide, and so on. The team consults with communities about technical decisions or searches for a Traveler to join them. Component Mentors may join teams to teach and mentor them about a complex technical component.
We are avoiding the structures requiring others to complete the work started by other teams. That’s why there are no testing departments, release managers, or cross-teams. The rule is either do this work by yourself or onboard another team for 1-2 sprints.
Try: Use “8 Lean Wastes” to think about your company and system — what wastes to eliminate to achieve your optimization goal?
We think from the perspective of continuous learning and apply “5 disciplines of Learning Organization” (see the picture below).
On Scale, we define several blocks to scale organization according to our goals: Feature Team, Track, Organization on Scale.
Most (>90%) of our teams are feature teams (see Figure 1).
Every feature team can deliver a potentially shippable increment alone or with other teams for a complex feature. Also, every feature team has a Scrum Master and an Engineering Manager, who works with 2 to 3 teams. We grow new teams by training new members in existing teams until they become proficient. Then, we create a new team.
Multiple teams are grouped into Tracks (see Figure 2). Each Track focuses on a specific client area or driving business metric and includes:
Here is what makes tracks succeed:
Tracks are temporary: they can be adjusted or updated anytime due to product changes.
Specific Tracks focus on defined objectives, such as product-led growth, navigation, document-related use cases, integration with PandaDoc, B2B sales democratization, and shortening cycle time. All the Tracks, except the Platform Track focuse on external customers and include feature teams.
We use the LeSS Framework within our organization. Every Track uses Scrum and follows the main guidelines and rules of LeSS (see Figure 3).
Figure 3. A Track’s process in the LeSS framework.
All Sprints are synchronized within the organization for all Tracks, which promotes consistency. Also, the track is running all required Scrum events.
We designed Tracks to be independent and self-managed. Every Track has leadership, including a product director, engineering director, head of design, and a scrum master.
The Track is the main scaling unit of the organization as it helps meet new business needs and support with significant resources. Usually, we launch a new Track when at least 3 teams are working in a new area. The current organizational structure follows LeSS Huge guidelines (see Figure 4).
Figure 4. Organizational structure according to LeSS Huge guidelines
Every Track has an Area Backlog from the Product Backlog controlled by one Product Owner (in our case, the CTO). This allows us to move teams between Tracks and change Tracks if needed, as well as start new Tracks or close them.
The structure is highly adaptable and enables us to prioritize goals in our system structure. At any moment, we can shift to working on the highest-value priorities.
A sprint review is an ideal way to show all the hard work and accomplishments of a team at the end of a sprint. Based around transparency, it shows work that’s completed or unfinished, plus projects that have been added and removed from the sprint. One of the most valuable parts of this informal meeting is feedback from participants, as it’s often better understood verbally.
If you had a chance to check out the first issue of Bam-Boo magazine, you already know that PandaDoc is a remote-first company. All Pandas are free to choose where to work and, most of the time, how to plan their work day.
Businesses are constantly adapting to internal and external events to remain competitive and deliver what their customers need. This is a normal and constant process, and it usually happens gradually over a long period of time with pricing changes, new product launches, market repositionings, and expansion. But once in a while, an extraordinary event like COVID-19 makes a business jam-pack major changes into a very tight schedule. That's what this story is about.