An Agile Not-for-Profit Organization

Guidelines that Encourage Action

1. If you feel that work needs to be done – it probably does. So, go ahead with it.
2. If you feel responsible for something, you probably have the authority.
3. If you act with authority, be prepared to be responsible.
4. If you don’t have authority to do something, and feel that is an impediment, talk with whomever has the authority.
5. If you feel authority for something but don’t yet have access to act upon it, ask to gain access from whomever currently has access.
6. You do not require permission to act. Though peer-review is encouraged.

I wrote the statements above in 2017. I had recently incorporated a not-for-profit company to produce the first-ever Regional Scrum Gathering^® in Canada. I had invited some colleagues to help direct the corporation and to organize the conference. I recognized that my colleagues were volunteering their spare time (as was I) and we needed some basic agreements between us that would enable fast decision-making, unified and autonomous action, and a bias toward action.

As founder, I felt it was appropriate to propose an initial set of guiding principles — so I included the statements above in a lightweight document I called the “Committee Handbook” and I proposed it to my fellow corporate directors and those who volunteered to be part of the conference organizing committee.

I was apprehensive at first. I thought “perhaps it goes without saying” and “these colleagues are all Agilists and very smart, surely they don’t need this list” — nonetheless, I presented the list to the group in mid-2017 and the impact/feedback was extremely positive.

Prompted by my friend, Paul Menezes, I’ve decided to share key excerpts from the handbook. If you are starting a team, a new company (in particular one that relies on volunteers), perhaps consider the statements above and the related material below. Comment below if you have questions or contributions.

The Handbook

Protocols & Guides

Principles

The following principles, and probably others, guide our decisions and help us strive to work better as a collective community:

• If you feel that work needs to be done – it probably does. So, go ahead with it.
• If you feel responsible for something, you probably have the authority.
• If you act with authority, be prepared to be responsible.
• If you don’t have authority to do something, and feel that is an impediment, talk with whomever has the authority.
• If you feel authority for something but don’t yet have access to act upon it, ask to gain access from whomever currently has access.
• You do not require permission to act. Though peer-review is encouraged.

Inherited Values & Ideas

The following 3 documents, and probably others, inform our behaviors and help to describe how decisions are made and how work gets done.

• Our corporation and its committees practice, but are new to the practice of, The Core Protocols
• Our corporation and its committees inherit the Manifesto for Agile Software Development
• Our corporation and its committees inherit The Cult of Done Manifesto

Those three documents assert that some behaviors are more effective than others to enable productive flow and enjoyable work in a self-organizing team. I, as founder, like the assertions made in those documents and hope others will enjoy being in a team which embodies such values & principles.

Examples how those documents show up in our actions:

I commit to engage when present. To know and disclose what I want, what I think, and what I feel. — From the Core Protocols (on Commitment)

That implies that it is our individual responsibility to engage and express our thoughts and feelings so they may be known to our teammates. Our teammates are not, cannot, be responsible for “checking for buy-in”. The statement above does not, however, force anyone to participate if they aren’t capable or ready to do so. Anyone can ‘pass’ or ‘check out’ and any time. Though, doing so does not prevent others from continuing.

Likewise, the Cult of Done Manifesto encourages action and asserts that attitudes toward perfection, editing, not-taking-risks is antithetical to getting things done. As expressed in:

1. There are three states of being. Not knowing, action and completion.

2. Accept that everything is a draft. It helps to get done.

3. There is no editing stage.

9. People without dirty hands are wrong. Doing something makes you right.

10. Failure counts as done. So do mistakes.

All the while, the Manifesto for Agile Software Development reminds us that quality need not suffer — neither in terms of work environment nor work product. As in these principles:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress. Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Emergent Patterns

These patterns have emerged by doing work together. These patterns may be useful in future work. These patterns are all changeable when better ideas and proposals emerge.

• We use [insert medium/tool here] internally for chat and announcements.

• We use [insert medium/tool here] for Backlog.

• Our two most important business partners use [insert medium/tool here] for sharing documents. Therefore, so do we.

Policies

Few activities need to be “policed” – however activities that must be compliant with known laws are described below.

Business Expenses

Contracts

No committee is authorized to negotiate or enter into contracts on behalf of the corporation. Any of the three directors of the corporation may do so on the committee’s recommendation and behalf.

Committees

Committees operate as ad-hoc workgroups under the authority of and with responsibility to the corporation.

The following committees are thought to be necessary:

Appendix

System Behaviours

Our “system” consists of public interfaces, customer services, and internal tooling (I.T.). Features of our system are described in this section — this section is kept up-to-date and is intended to reflect our system accurately even as our work causes evolutionary changes.

We strive to deploy iterative and incremental changes to our system as frequently as possible. Every decision and action manifests, somehow, in the artifacts which make our system visible to ourselves or to our public. Together, we frequently make decisions and exert effort that show up as adjustments or additions to our publicly-visible artifacts. (If our work does not cause changes to our public-visible artifacts for long periods, we are likely stalling as a company.)

Backlog

Our backlog (the “work to be done”) consists of two streams.

One stream of work to be done consists of “planned features” for our system. Generally, these are known to be desirable in advance of implementation. Implementation is often the subject of group decision. Generally, these items relate to how Ontario Scrum Community or its committees interact financially, legally, or contractually with others and therefore, prioritization of these items is the responsibility of the Executive Director.

Another stream of work to be done consists of emergent tasks, or planned “anytime-tasks” which individuals perform at their sole discretion and convenience. At times, these items may relate to “planned features” but not necessarily. Examples:

1. A planned feature might be: “Early Birds can register for the event with 15% discount.”

2. An emergent task related to that feature might be discovered during implementation, such as: “Typeform calculation on ‘price’ to change $580 to $493.” (This is likely discovered during implementation by the person or people implementing said feature.)

3. And an anytime-task related to that feature might become apparent to any member internal or otherwise, such as: “Team member announces the discount code via their social networks.” (This is likely done autonomously by any individual at any time.)

Tests

Registrants from sponsoring organizations can register up to X complementary seats.

Organizers can message each other & send email.

Early birds can register for the event and receive 15% off.

Registrants can book a hotel room.

Public can follow us on Twitter: @CanadaScrum.

The event we produced is archived here:

• scrumgathering.ca