This document provides guidance for software teams currently using Scrum who want to integrate Holacracy into their structure. It recommends: 1) replacing certain Scrum meetings like backlog grooming with Holacracy's Tactical Meetings; 2) using Governance Meetings to improve roles and accountabilities uncovered in Scrum retrospectives; 3) defining initial roles like Scrum Master, Product Owner, and Developer. The benefits of this approach are seen as increased transparency, better decision making, faster improvements, and a greater sense of empowerment within the team.

1. Open Source 1
Holacracy & Scrum Guidance
Concept by Joshua Stanley
EXECUTIVE SUMMARY
The primary objective of this document is to provide initial guidance for software development
teams that are currently using Scrum (or other Agile methodologies) and beginning to integrate
Holacracy into their team structure. It assumes knowledge in Scrum and Holacracy processes
and artifacts.
We believe the benefits of structuring teams and roles around the work using Holacracy
provides a powerful and scalable platform for Scrum teams to make better decisions, faster
improvements, and have a higher sense of individual empowerment within the team and
organization.
We believe Holacracy provides a great structure to enhance existing feedback loops within the
Scrum lifecycle. We will look at 1) Tactical Processes, 2) Governance Processes, and 3) Roles in
Holacracy and make recommendations to assist teams currently using Scrum.
1) TACTICAL MEETINGS
Common events occur within software development teams delivering apps, where grooming
sessions, release planning meetings, user experience reviews, and other backlog related
discussions are needed to feed inputs to the Product Owner of the team for the purpose of
continuously prioritizing and defining the “what” for incremental delivery. We believe these
meetings can be replaced within primed Tactical Meetings.
A Tactical Meeting’s purpose is to surface data, share progress, and triage tensions into next
actions. As part of this process, circle members can bring tensions that relate to the work that
the Scrum team should perform from a given role’s perspective. Here are three explicit areas
for consideration:
1. To feed inputs to the Product Owner and drive discussions around the work, each circle
member should consider tensions for potential backlog items (i.e. a circle member
proposes an action to create a story).
2. To accommodate design review feedback and feasibility discussions, relevant roles
should consider tensions for review during tactical meetings (i.e. a UX role presents a
new feature design for feedback).

2. Open Source 2
3. To plan releases, relevant roles should consider tensions for future releases,
dependencies, and sequencing (i.e. a circle member proposes a release schedule for
review and feedback).
In addition, Tactical Meetings can provide a venue for the team to coordinate non-development
work that is often left outside of the Scrum process. See the Holacracy Constitution for
traditional Tactical Meeting guidance (i.e. working agreements, team outings, etc).
It is recommended that a circle have at least one Tactical Meeting per month, or once per
sprint.
We anticipate Tactical Meetings replacing the following existing sessions:
 Backlog Grooming
 Story Writing
 Release Planning
 UX Design Review
 Non-development Planning
It is not expected that a circle would cover all of the above areas in every tactical meeting.
2) GOVERNANCE MEETINGS
Role clarity and accountabilities are areas where Holacracy provides great transparency. We
believe Governance Meetings are ideal in assisting a Scrum team in explicitly stating role
expectations and accountabilities.
Retrospectives in Scrum offer a team an opportunity to reflect and enhance roles and
accountabilities as they relate to their Holacracy circle. As Retrospectives uncover opportunities
to improve existing roles and accountabilities, or reveal the need for new roles and
accountabilities, they can be surfaced through Governance processes in Holacracy.
We recommend a Governance Meeting cadence of once per month to facilitate these changes;
however, when timeliness is a factor, the Governance process can be initiated by email as
outlined below:
1. A team agreed action item is the result of a Scrum retrospective.
2. A self-elected individual is made known to compose the Governance proposal in an
email to the circle’s distribution list (<circlename>@hola.company.com).
3. Circle members reply all with “objection” or “no objection”.
a. If all circle members reply with “no objection”, the Secretary then initiates the
change within GlassFrog (HolacracyOne software).

3. Open Source 3
b. If any circle member replies with an “objection”, the topic must wait for an
official Governance meeting. This meeting can either be scheduled for
immediate resolution, or wait for the next scheduled Governance meeting.
3) ROLES AND ACCOUNTABILITIES
A circle has autonomy within Holacracy to define roles around the work as they see fit. In order
to combine Scrum and Holacracy, we’ve provided four default roles that are proven to be
effective within the Scrum methodology.
The four recommended roles for executing Scrum within Holacracy circles are:
1. Scrummaster
Default Purpose: To act as the servant-leader of the development team and enact Scrum values
and practices.
Default Accountabilities:
 Facilitating interactions within the circle
 Removing impediments and shielding the team from external interferences
 Reporting team's progress and making the team’s effort transparent
2. Product Owner
Default Purpose: To act as the product visionary and drive innovation to maximize product
revenue and support the parent circle’s strategy.
Default Accountabilities:
 Prioritizing and sequencing backlog items
 Defining the user stories and their acceptance criteria
 Approving working product deliverables
3. Technical Owner
Default Purpose: To provide technical guidance relating to architecture, best practices, and
design.
Default Accountabilities:
 Facilitating technical decisions for the product
 Incorporating team feedback and emergent patterns into the overall design
 Enforcing developer best practices with the team
4. Developer
Default Purpose: To enhance the product by aligning with the Product Owner’s vision and
delivering a solution with the highest quality, lowest technical debt, at a sustainable pace.
Default Accountabilities:

4. Open Source 4
 Estimating the size of backlog items
 Writing code that adheres to the acceptance criteria
 Maintaining and increasing test code coverage
These recommended roles and accountabilities are starting points, and a baseline for operating
in Scrum. We fully anticipate each circle evolving these roles to meet the needs of the team,
work, and purpose.
BENEFITS OF HOLACRACYINSCRUM
Here is a list of benefits we anticipate for existing Scrum teams integrating Holacracy’s
structure:
 Increased Product Transparency – Regular metric reviews and project updates in
Tactical Meetings will ensure consistent awareness of product progress.
 Better Decisions – The integrative decision model is very effective at collecting full team
reactions and feedback while allowing for a proposer to address a tension.
 Faster Improvements – Structured Governance and Tactical Meetings provide
opportunity to identify role accountabilities or actions that can be raised after Scrum
retrospectives, providing a venue to take next steps.
 Higher Sense of Empowerment – Holacracy excels at allowing individuals to have a voice
in their circle, as well as a channel to reach other circles. This builds empowerment and
engagement in the team.
 Clearly Defined Roles – Setting clear expectations and accountabilities is a tool for
reducing team conflicts.
 Evolving Roles – Holacracy provides a path for role adaptability. The existing Scrum
roles can evolve to include additional accountabilities, while maintaining the
recommended baselines.