Effective Organization

Enabling Self-Organization using Holacracy™

I spoke at this month’s Agile Denver meeting about using Holacracy in an Agile Team to power-up the Team’s self-organization. I also explained how Holacracy can be used to remove the communication gap between Agile Teams and their surrounding tradition organizations.

As is often the case with an introductory Holacracy talk, there were a lot of scrunched up faces and questioning looks at the beginning – until we got to Integrative Decision Making. Then it really clicked and the lights came on. We did a half-hour Q&A right there on the spot!

Here are the slides from the talk.

Here’s the synopsis from the talk:

Self-organizing teams are one of the core principles of Agile software
development. However, when it comes to exactly how to self-organize,
Agile is uncomfortably silent.

Scrum states that team must hold a Sprint Retrospective but give little
concrete advice about what a good retrospective looks like and what its
outputs should be. As a result, many teams let retrospectives fall by
the way side, failing to capitalize on opportunities for learning and
optimization.

Holacracy, an agile-like practice for the whole organization, provides
clear instructions for self-organization. Holacratic practices like
Integrative Decision-Making, Named Roles and Accountabilities,
Governance Meetings and Double Linking complement existing Agile
practices. They also have the potential to extend the Agile mindset out
from Engineering Teams to the core of an organization.

"The Disturbed", Holacracy & Self-Organization

Have a quick watch of this 2:30 minute video from Atlassian. It is a great example of a self-organizing team discovering and applying a useful organizational pattern to their context.

“The Disturbed” is an instantiation of the Sacrifice One Person (4.1.22) [1][2] pattern with a unique spin from the specific team that (re)discovered it.

How was this team able reorganize itself and achieve this discovery? Agile offers substantial improvement in many areas, but when it comes to exactly how to self-organize, Agile is uncomfortably silent. Scrum states that team must hold a Sprint Retrospective but give little concrete advice about what a good retrospective looks like and what its outputs should be. As a result, many teams let retrospectives fall by the way side, failing to capitalize on opportunities for learning and optimization.

Holacracy [3], an agile-like practice for the whole organization, provides clear instructions for self-organization. Holacratic practices like Integrative Decision-Making, Named Roles and Accountabilities, Governance Meetings and Double Linking complement existing Agile practices. They also have the potential to extend the Agile mindset out from Engineering Teams to the core of an organization.

[1] - Organizational Patterns of Agile Software Development. Coplein, J., and Harrison, N., Pearson/Prentice Hall. 2005.

[2] - The pattern is also known as Sacrificial Lamb

[3] - For more information about Holacracy please visit, http://www.holacracy.org

Basic Agile Vocabulary

I wrote this up as a pre-amble to a backlog document to help level-set the readers’ understanding of the language used through the document. I thought it might be useful to share:

• Work item - an arbitrary unit of work.

• Epic - a large work item that cannot possibly be estimated accurately due to its shear size.

• User story - a work item small enough to be estimated. Usually articulated in the form “As a (role), I would like (feature), so that (purpose).” Always accompanied by one or more conditions of satisfaction

• Condition of satisfaction - A requirement that Testers can use to write tests and that Development must either meet or renegotiate in order to consider a work item to be done.

• Done - the state a work item must be in to be considered complete. This state is negotiated between the product owner and Team and usually includes automated tests written and passing, as well as code being refactored and maintainable. Only Done work items are counted toward a Team’s velocity.

• Story point - a unit of measurement for the size of a work item. There is no absolute conversion from story points to man-days or hours. Schedule projections are done using velocity

• Velocity - an empirically derived rate of work. The velocity is typically calculated by averaging the number of points the Team completed in the last 5 iterations.

• Iteration - a fixed period of time. Usually 1, 2 or 4 weeks. At the beginning of each iteration the Team selects stories they will work on. At the end they track how many stories they got Done.