Translation note

Translation note: this document is a translation of the original which can be found on the bigdata sharepoint at sharepoint:BigData/Self Management/Costituzione/AGILE LAB-rules v0.3 Draft.pdf

Translated by Ugo Ciracì and Eugeniu Ostrovan

Table of contents

1. Foreword and licensing
2. Adoption
3. Changes
4. Principles
5. How we organize ourselves
6. How we work and evolve together
   1. Point results
   2. Continuous expectations
   3. Constraints
7. How we operate individually
   1. Rules
   2. Responsibilities
8. Metrics and checklists
9. Predefined roles
10. Assignment of people to roles
11. TIPS
12. Agilelab meeting structure
13. Appendix
    1. Tensions triage
    2. Integrative decision making

Foreword and licensing

This document constitutes version 1.0 of the Self Management rule set designed by Leapfrog (www.leapfrog.team) for Agile Lab (www.agilelab.it)

The document is subject to the following Creative Commons license: https://creativecommons.org/licenses/by-nc-nd/4.0/

This preface is considered an integral part of the document and should be included in any further releases of the document.

This document is inspired by Leapfrog's translated version of the Holacracy Constitution 4.1

• visible on the HolacracyOne github account at the following link: https://github.com/holacracyone/Holacracy-Constitution-4.1-ITALIAN/blob/master/HolacracyCostituzione-IT.md
• contains some insights derived from the work of Frederik Fleischmann https://blog.holacracy.org/how-to-survive-and-flourish-in-holacracy-a45ab112c80f

Adoption

This Constitution may be adopted at the level of individual teams (circles) or the entire organization and applies only to those circles for which explicit ratification occurs according to the process that the organization will want to define through specific policies created within the outermost circle in the hierarchy itself.

Changes

Subject to the criteria set forth in the license, any amendments to the following rules should be drafted by the ratifiers of the Constitution, i.e., those in the company who decided on its initial adoption, and made available to the entire organization.

Principles

The Constitution constitutes a set of rules that are intended to make practical application of the following principles that are accepted and made explicit by the organization that decides to adopt it.

• Purpose: The purpose and responsibilities of your team and your roles are the beacon that guides you in operating, prioritizing, accepting for you, and suggesting activities for others to perform

• Distributed authority: You hold one or more roles whose description in itself defines a mandate to perform and a set of things that other team members expect you to do. In the interest of the team's purpose and your responsibilities, you are authorized to do whatever you see fit and which is not expressly forbidden to us.

• Transparency: There are no (implicit) expectations among people beyond those we explicitly codify in roles, so we make them visible to everyone so they can clearly interact. Make deliverables, relative priority judgments, completion estimates, actions and projects in charge, relevant to the activities you do, visible to every other team members (either by explicit request or by making them available a priori).

• Peer collaboration: We do not give orders to each other, but we hold each other accountable to the responsibilities under our roles, accepting and prioritizing appropriately, when we are engaged, whatever requests come our way if we judge them to be in line with the expectations of our purpose. You have a duty to identify and process the tensions you feel when operating in your roles to solve problems and seize new opportunities.

• Evolutionary learning: We have periodic moments of collective reflection and alignment to review in-progress the organization of roles, provide clarification on specific activities, and assign additional activities.

How we organize ourselves

We are people who, united by a common purpose, wish to collaborate in teams (also called "Circles") to achieve it.

Purpose represents the beacon that guides us, the kind of positive contribution our organization intends to introduce into the context in which it operates. To achieve it, we mutually assign work to each other by distributing it among well-defined organizational roles, to which we give positive energy through our intelligence and initiative. Roles in Agile Lab are not titles or indications of status, but simply "hats" that we wear at our discretion and that represent the different types of work that the organization sees fit to do; we, therefore, organize the work and not the people.

Each circle contains a set of roles, and is itself a role within the circle that contains it thus giving rise to a hierarchy of containment and specialization.

Each person may be assigned one or more roles in different circles; thus, each person may find himself or herself playing multiple roles. Each person may find herself playing multiple roles at once; it will be up to her to choose to devote her attention, from time to time, to the one in which at any given time it will make the most sense to dress for the good of the team or the entire organization.

All roles are created, changed, and deleted independently by us in dedicated meetings (called Governance meetings), but each circle must mandatorily contain 3 that are predetermined and necessary for the smooth functioning of the team itself regardless of the work it is to perform:

• the Circle Lead (appointed by the Circle Lead of the upper circle, if any) with liaison functions between the team and the rest of the organization,
• the Secretary (elected) and the Facilitator (elected), who instead have the function of chairing the meetings and governance.

It is not possible to add responsibilities to the Circle Lead beyond those initially prescribed (but they can be taken away through governance proposals and assigned to other roles or processes). It is possible to add responsibilities to all other predefined roles, but not remove their native responsibilities. The responsibilities of these roles are detailed in the "PREDEFINED ROLES" section.

The team has two collective meeting times called the Governance Meeting and the Tactical Meeting, these are scheduled periodically by the secretary and facilitated by the facilitator.

• The Tactical Meeting is a time for monitoring and assigning activities and projects, which has the goal of engaging each other to the goal by working IN THE team
• The Governance Meeting is a time devoted to redefining rules and responsibilities, it is a time when we come together to reflect on the way we work, that is we work ON THE team

How we work and evolve together

Any initiative of a role is determined by the presence of a tension: the perception, on the part of the person filling it, of a difference between the current state of things and a future state which is valued as better.

This need to resolve tensions can give rise to an initiative to change the state of things in three ways:

• Engaging ourselves or others in their respective roles, on timely outcomes that we deem worthwhile obtain,
• Creating/changing ongoing expectations (roles and responsibilities) through appropriate proposals for change,
• By placing constraints on our mutual freedom of action.

We prioritize actions (the timely-tactical results), but every now and then we pause to reflect together to try to make even clearer the mutual expectations on the basis of which we engage (the ongoing expectations, governance of roles and responsibilities), while at the same time trying to minimize the limits we place on our freedom (governance of constraints)

When we act, or propose changes to expectations and limits we are guided by two principles:

• Good enough for now: to all-encompassing changes based on theory, we prefer proposals that aim for a tangible benefit on the basis of which new further proposals, building on a newly acquired base of awareness
• Safe enough to try: We prefer to prioritize changes that do not involve irreversible risks or too difficult to mitigate, waiting for new awareness to allows us to pursue the other options more clearly.

Point results

They are expectations that have an 'anticipable definition of outcome and thus a finite time duration (but not necessarily known in advance) on which we engage from time to time, bind us to an output but not to the manner in which we will obtain it nor to the time we consider necessary to obtain it, we call them actions and projects (tactical expectations), they can be requested, created and assigned at any time. And that is why everything that is done in the Tactical Meeting can also be done outside outside of it.

Our results are of three kinds:

• Project assigned to a role: it represents an outcome for which a "definition of done" expressed in the past participle (this is the condition we will test to see if it has actually been concluded), even if we do not know in advance what actions it will require to be achieved. (Ex: "software version 2.0 released"), is created by mutual engagement between roles
• Action assigned to a role: any atomic activity we might undertake in any of our roles, even immediately in the absence of different priorities, and that does not need further clarification/reflection on what that is to be done, nor to be broken down into further actions (e.g., "contact supplier xyz to ask him for a 10% discount"-for a hypothetical "Contract Management" role), like the project, it too is created by mutual engagement between roles.
• Action/Project assigned to individuals: an action or project that in the absence of natural attribution to an existing role is undertaken by a person to serve the purpose of his or her team or organization (e.g., "buying paper for the printer"- by any person on the team in the absence of a role responsible for supplying the team with stationery). Where repeated or recurrent, it will be our care to take to the appropriate venues the tensions that will allow us to give dignity organizational dignity to such actions, so that they occur within the framework of the organization itself (and thus are attributable to a role) and are not intentional on a purely personal level (ex: in this case, we need a role that regularly presides over stationery supplies?)

Continuous expectations

These are expectations that do not have a limited time duration, but are valid indefinitely, at least until they change. Continuous expectations allow us to make clear how and to whom we need to address the requests for discrete results -> these are the roles themselves and their responsibilities. Continuous expectations can be created or modified only during the Governance meetings. Continuous expectations are divided into: Responsibilities: an activity with some form of periodicity that our team has a need for over time (example: “keep document xyz up to date”) Roles: every role is a collection of synergic and homogeneous responsibilities that are assigned to one or more people such that they make the associated actions part of their daily operation.

Constraints

Constraints are the tools we use when we want to constrain the modes through which we obtain the discrete results or generate continuous expectations. These are “specific ways of doing things” with which we want to limit our freedom of operation. Constraints are of two types: Domains: are the property of a physical or abstract asset (also procedures, processes, interactions), that we want to assign exclusively to a specific role. The assignee of a domain manages it as they see fit, but they are bound to take into consideration the requests from colleagues to access the domain. Policies: are rules that: Limit the authority of one or more roles Defines the way in which the role governing a domain grants or restricts access to other roles Determines that some condition must trigger a specific action (or start a process) In the same way as continuous expectations, constraints may only be created/modified during governance meetings. Nothing that is done in a governance meeting can be done outside of it.

How we operate individually

Rules

1. If it is not forbidden then it is allowed: anything that has not been explicitly forbidden (through appropriate constraints) is allowed, even when out of the scope of the roles assigned to us, as long as it is aligned with the purpose of the team and the whole organisation.
2. If it is not explicit then nobody can expect it from a role or a person: no implicit expectation (unwritten) has any value for us besides that which governance prescribes, we use governance to gain better clarity over that which we expect to be done by others.
3. Nobody manages the others: no role or person has power over other roles or people, it is for this reason that activities are generated from the intersection of needs, attention, availability and action capabilities rather than because someone order it to be done.
4. All previous rules are valid until overwritten: any explicit rule pre dating the adoption of this document remains valid unless: It contradicts the contents and principles of this document (example: “the people in the team report to manager x” is automatically voided by the new ways of collaboration prescribed by this self management document) It is overwritten by a new rule produced by acts of governance following the processes described in this document

Responsibilities

We abide by 4 responsibilities towards our colleagues: “listen and reply”, “transparency”, “processing requests”, “traceability” Below we illustrate a more detailed explanation:

1. Duty to listen and to reply

   1. We have the duty to continuously reflect on our work, to identify new tensions towards improvement and attempt to solve them by triggering actions/projects/changes of expectations.
   2. We resolve tensions through direct personal initiative or by interacting with other roles or by taking them to a tactical or governance meeting so that they can be resolved.

2. Duty of transparency Every member of the team can expect from others (and vice versa):

   1. Transparency about projects and actions undertaken
   2. Our personal judgement about the relative importance we give to the projects assigned to us
   3. An estimate of completion given our priorities

   Useful questions: “Which next step have you identified to achieve this result?” “What other priorities do you have now?”

3. Processing requests:

   1. We have the duty to take charge of the requests from those who engage us in our roles, adding the suggested actions or projects in our personal or company system of traceability. When we disagree with an engagement we cannot simply refuse it, instead we have to suggest alternative paths to resolve the tension that generated the engagement.
   2. Accepting does not mean executing immediately, it means assigning a relative priority for handling these new requests. The duty of transparency will resolve emerging doubts and the Circle Lead may ask us to modify the priorities we assign to the tasks we are engaged in.
   3. If our roles have domains, we have the duty to take into consideration the requests from other roles to act on those domains. Useful questions: “Would taking charge of this action or project be in service of your role given its purpose and responsibilities?” “Which project or next action have you identified for that responsibility?” “Are you able to process this responsibility? What is blocking you?”

4. Traceability

   1. We keep track of every action/project we take on in our team at least until it has been completed.
   2. We use a computer tool accessible to the entire team (example: holaspirit) for projects and actions which we think are useful to make visible to other roles. For tracing all other activities, each one of us can choose the tool they prefer that will be instrumental in accomplishing the duties of transparency, processing and traceability.

Metrics and checklists

We adopt two transparency tools for increasing the visibility of the progress in our activities. These are metrics and checklists.

A metric represents a measure that can be assigned or removed from a role by the circle lead. The task of the role that is assigned a metric is to curate it and share it with a determined regularity (example: "number of active clients in the past month"). It is up to the role to choose the proper tools to aggregate and present the data. The assignment of a metric does not need to be accompanied by the creation of new role responsibilities. A metric implicitly assumes the expectation to periodically execute all the actions necessary to produce it.

A checklist is a binary check (check / no check) on all responsibilities over a given time frame, verifying whether they were executed or not (example: "monthly backup of database executed"). Since a checklist does not involve any additional work with respect to what is already assumed by our responsibilities it can be requested by/to any role.

Predefined roles

Facilitator

Purpose: ensure that the governance of the circle and the activities conducted in it are aligned to the constitution.

Responsibilities:

• Facilitate the circle meetings mandated by the constitution
• On request, conduct auditing of sub-circle practices

Secretary:

Purpose: manage the acts of governance of the circle guaranteeing the process of registering and conserving

Responsibilities:

• Schedule the circle meetings and notify all circle members about the time and place
• Verbalise and publish some output for the circle meetings mandated by the constitution; maintain a high level view over circle governance, check lists and metrics
• Interpret acts of governance and the constitution on request

Domain: All circle data whose conservation is mandated by the constitution.

Circle lead

Purpose: to be guarantor of the circle's purpose

Responsibilities:

• Assign colleagues to circle roles; monitor the assignee's level of fit to the role they cover; provide feedback aimed at improving the partner's fit to their role; reassign the role when necessary to guarantee the best fit.
• Allocate circle resources to projects and roles.
• Decide priorities and strategies for the circle.
• Define the circle's metrics.

Domain: Assignment of roles within the circle.

Assignment of people to roles

The roles of secretary and facilitator are elected while the role of circle lead and all the roles defined by the circle through governance activities are assigned (the default mechanism is that the circle lead assigned persons to the roles within the circle, including the circle leads of subordinate circles). These mechanisms of role assignment may be changed by creating relevant policies.

Whoever is assigned the role of circle lead can not hold the role of facilitator at the same time.

The elected roles are assigned through the following process, which is triggered at the expiration of a mandate or by an explicit request during governance meetings from any participant.

1. The facilitator in charge describes the characteristics of the role for which the election is required (responsibilities and duration of the mandate)
2. Each voter fills out the election forms with their name and the name of the chosen candidate (it is possible to vote for yourself)
3. The facilitator gathers and reads the forms.
4. The facilitator asks each voter for the reason of their choice and if they want to change it given the reasons given by the others.
5. The facilitator announces the person who gathered the most votes and proposes that they be elected.
6. Round of objections
7. In case of objections the facilitator can decide to repeat the election or to propose a second candidate.

In case of a tie the facilitator can choose the person who brought forth their own candidacy, if any. Alternatively they can choose a name at their discretion.

TIPS

To make it easier to apply the principle and rules listed here are some personal reflection/decision cards that can help to handle common cases:

1. I would like to attempt an action, can I do it?
2. I am asked to do some actions, do I have to do them?
3. I would like somebody else to do something, how can I ask them?

Agilelab meeting structure

We have two moments of synchronization and collective decision-making where we process all tensions that cannot be resolved through role to role interaction.

Tactical meeting: serves to process operational tensions by monitoring checklists, metrics and projects and to mutually engage each other by assigning actions and projects. Everything done in the tactical meeting can also be done outside of this meeting.

Governance meeting: serves to process organisational tensions and to create/modify/eliminate roles/circles/domains/policies. Everything done in the governance meeting cannot be done outside this meeting (example: it is not possible to modify the organization except in a governance meeting).

Below is the structure of the tactical meeting, including a drill-down on the more detailed phases:

1. Check in
   • Get everyone's attention and eliminate distractions.
   • One at a time, no discussions.
2. Checklist review
   • Bring transparency to recurring actions.
   • The facilitator reads the checklists of recurring actions and participants to whom those were assigned respond "check" or "no check"
3. Metrics review
   • Paint a picture of the current state.
   • Each role who is in charge of a metric briefly presents the most recent data.
4. Project updates
   • Updates on the key projects in the circle.
   • The facilitator reads the projects and asks "Are there updates?"
   • Who is in charge of the project answers "No updates" or presents the changes since the last meeting.
   • Clarifying questions are allowed, but no discussion.
5. Build agenda
   • Create in real-time an agenda of the tensions to be processed.
   • A few words to define the tension that needs to be processed.
6. Tensions triage (details in appendix)
   • The facilitator works one tension at a time. For each tension the facilitator supports the owner in identifying its type and processing it.
7. Closing round
   • Sum up what has been learned during the meeting.
   • Each participant may share their thoughts about the meeting; no discussions in this phase.

Below the structure of the governance meeting:

1. Check in
   • Get everyone's attention and eliminate distractions.
   • One at a time, no discussions.
2. Build agenda
   • Create in real-time an agenda of the tensions to be processed.
   • A few words to define the tension that needs to be processed.
3. IDM(Integrative Decision-Making) of the governance tensions (details in appendix)
   • The facilitator works one tension at a time. For each tension the facilitator supports the owner in identifying its type and solving it through a process of integrative decision-making.
4. Closing round
   • Sum up what has been learned during the meeting.
   • Each participant may share their thoughts about the meeting; no discussions in this phase.

Appendix

Tensions triage

A) The facilitator asks: "what do you need?" B)

• Request a next action
  • It is a single practical and visible action that makes a step towards the resolution of the tension.
• Request a result/project
  • The project is a clear final result that requires multiple steps to accomplish
• Request information/opinions
  • Ask for data, opinions, idea to clarify an issue or to help you make a decision.
• Offer information
  • Announce or share anything you deep the circle should know.
• Create an expectation/responsibility
  • Capture a tension to process later during the IDM(integrative decision making) phase where the expectation might lead to organisational changes. C) The facilitator asks "did you get what you needed?"

Integrative decision making

• Proposal presentation
  • The proponent formulates an initial proposal regarding the logged tension
• Clarifying questions
  • Those who need clarification on about the problem or the proposal formulation can ask questions
• Reactions round
  • One by one everybody expresses their reaction to the proposal
• Editing and clarification
  • The proponent can decide to improve their proposal taking cues from the reactions or to leave it unchanged
• Objections round
  • Every objection is integrated through a dialogue between proponent and objector and modifies the proposal until there is no objection.

Testing an objection

New proposals can generate concerns from other roles and stakeholders in the circle. A concern becomes an objection when it is determined to satisfy the validity criteria, then it must be resolved before the new proposal can be adopted. An objection is a stated logical reason why the proposal causes harm, it must satisfy the validity criteria in order to maintain the integrity of the scope of governance. It is never wrong to raise invalid objections.

The role of the objector is to provide arguments for why their concern meets the validity criteria. The role of the facilitator is to capture the objections in the same way as they capture proposals: they do not have to fact-check, but to judge the structure of the reasoning. An objection is like a tension, the objector determines whether it is validated or not.

Following are some examples of tests for a concern:

• Does the proposal damage the circle's ability to express its purpose?
  1. If adopting this proposal damages a team, the concern could be an objection, ask the next question
  2. If you think that the proposal is incomplete or useless, the concern is not a valid objection
• Does this proposal generate new tensions?
  1. If the tension comes directly from this proposal, the concern could be an objection, ask the next question
  2. If your preoccupation would persist even if the proposal were abandoned, the concern is not a valid objection
• Is the impact that you are anticipating certain or hypothetical?
  1. If you know for sure that this proposal would generate an impact, the concern could be an objection, ask the next question
  2. If you are anticipating that there could be an impact, but there isn't enough information yet, ask the follow-up question: : If the proposal doesn't go as planned and creates harm, will it be too late to fix it?
     1. If it would be too late to avoid damage by the time we gather enough information, the concern could be an objection, ask the next question
     2. If we can give this proposal a try knowing that we can revisit it anytime in the future, the concern is not a valid objection
• Does this proposal limit one of your roles?
  1. If this proposal would limit a role that you cover, the concern could be an objection, ask the next question
  2. If you are trying to help another role or a team member with your objection, the concern is not a valid objection

In any case an objection is automatically valid if the proposal violates the rules of the constitution.