Building Agility on Scale

What Agility is About?

First, you need to define what is “to be agile” for your company. For PandaDoc, agility means:

1. Changing the development priority without any re-structuring (Adaptability).
2. Working on the highest prioritized items in the backlog (Highest value first).

‍Try. Define the goals to optimize within your organization and try to accomplish them together, like “highest value” and “resource optimization”.

Principles of Scalable Agile

Principle 1.
Any development team can develop any feature and make changes in any component/subsystem.

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.

Principle 2.
One Product - One Product Owner

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.

Principle 3.
Coordination of work is the team duty

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:

Just Talk

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.

• Scouts/Pioneers 

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/Learner

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. 

• Communities, Components Mentors

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.

Principle 4.
There should be no dependencies on people or teams

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?

Principle 5.
Continuous Learning and building Learning Organization

We think from the perspective of continuous learning and apply “5 disciplines of Learning Organization” (see the picture below).

Organizational Blocks on Scale

On Scale, we define several blocks to scale organization according to our goals: Feature Team, Track, Organization on Scale.

Feature Teams

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.

Tracks

Multiple teams are grouped into Tracks (see Figure 2). Each Track focuses on a specific client area or driving business metric and includes:

• Product goal defined by objectives, key results, and long-term commitment;
• Teams working to achieve the Track goal;
• Track backlog from which it inherits its priorities.

Here is what makes tracks succeed:

• Simplicity: up to 6-8 teams per Track to keep a broad focus.
• Flexibility: each Track works within the company, technology stack, and application.
• Self-sufficient: each Track has members with the required expertise to reach a goal.
• Ownership: each Track is responsible for both the technical and product quality.
• Customer-focused: each Track prioritizes value for customers within a single backlog.

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.

Tracks Operation Model

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.

Track Leadership

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.

Scaling of R&D Organization

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.

Conclusions

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.

1. The highest valuable items from Backlog, which lets us avoid local optimization.
2. Highest adaptability: the ability to change plans on the fly to the whole organization.