Effective Organization

Oct 23 2009
Aug 26 2009

At the BAWB Global Forum, we were asked to imagine and design a new theory of the firm that goes beyond “the business of business is business” and expands the purpose of business to “do good” beyond providing products and services and creating wealth.

I agree with Peter Senge that, while we do need a new theory of the firm (starting with new governing ideals), any such theory will be incomplete and insufficient to change the business world without a set of structures and practices to go with it. That’s what Holacracy offers.

+

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.
Jul 01 2009

"The Disturbed", Holacracy & Self-Organization

Example Organizational Holarchy

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


May 22 2009

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.
May 18 2009
What do architecture and organizations have in common?

What do architecture and organizations have in common?

May 05 2009
May 04 2009

Impediments in the backlog?

  • I just answered this question via Aardvark:
  • Aardvark User: In scrum, when does an impediment (with tasks) become a story?
  • Evan: An impediment usually would never become a story, unless there is engineering work required by the team. The impediment list is owned by the ScrumMaster and is work on by the ScrumMaster and anyone else the ScrumMaster solicits help from. Any time that impediments take to work on should not be counted in the team's velocity. That time is simply part of the "drag" on the system. When the impediment is removed its drag can be measures by the increase in the teams velocity.
  • Aardvark User: Good info, thanks. This impediment required several hours of engineering work. Would you recommend this become a story if it's already been worked on and resolved?
  • Evan: There's two schools of thought on this. My take is that it depends on what you are trying to measure. Are you trying to measure the capability of your organization to deliver end-user functionality? Or are you trying to justify the existence of your team to higher level management? In the first situation you might add an item to the backlog but assign it zero value. In the later situation you might add it to the backlog with a positive value.
  • Aardvark User: We are probably somewhere in the middle. We want to establish an accurate average velocity and prove to management we are doing the work. I will probably go with creating the story and having the team determine the size. Thanks for the help!
  • Evan: You're welcome!
Page 1 of 1