Saturday, October 24, 2015

Holacracy - notes from a taster workshop


Instead of structuring a company around the people, as we do in traditional management hierarchy, holacracy says you should structure the company around the work that the company needs to do to express its purpose.

If there is nothing that makes you skeptical about holacracy then you're probably missing something. It is a radical shift from traditional management hierarchy.

Holacarcy is a replacement, not something that can be added or incorporated within traditional hierarchies.

One of the ways holacracy encourages process improvement is that it acts as a mindfulness exercise for the whole organization.

Traditional management hierarchy is the unconscious choice of business. You should at least consider if it was the correct choice.

In holacracy power is not held by a CEO -- all power rests in the constitution (which itself is a definition of the process). The way you enter into holacracy is by the CEO ceding all of their power, much like the way in history kings would decide to dissolve a monarchy for a new system like democracy. There are a lot of interesting observations to be made about holacracy and traditional management hierarchy when comparing the strengths and weaknesses of a monarchy versus a constitutional democracy.

While you might expect diffusion of responsibility as a result of placing power into groups, there is actually a structure to who makes which decisions. There are point people who have specific responsibilities. Who are those people? Everyone decides that as part of the process.

The most unintuitive thing for me about holacracy is that even though there is a huge focus on autonomy, there is actually a lot of highly structured process. It is not anarchy. What one could say is that instead of using the unspoken rules of politics and power dynamics, holacracy asks you to make all of the rules transparent and gives you the power to change those rules in order to make the business function better.

Another common misunderstanding is to think that without hierarchy you do not have structure. There is a well defined structure in holacracy which places everyone into circles. A circle is a group of people based on a part of the work that needs to be done. In a small company you would have a finance, marketing, advertising  and other circles that roughly correspond to departments of today. However in a large company you would have many circles that handled finance activity. A circle (much like a meeting) really can't function well once it starts growing above a dozen people. Once circles get too large they should be divided in two -- much like a cell dividing in an animal.

Each circle in a company defines someone as the "lead link". This is a position that can rotate and acts as a liaison to other circles. The lead link also has the responsibility of speaking for people who are unable to attend meetings.

Speaking of cells in animals, to continue the metaphor for holacracy circles,  every circle is a cell and even though there is no boss or master cell that tells the other cells what to do, cells organize as organs and then as animals and are fully functioning. What is nice about his model is that it explains how a really large organization can remain as flexible and adaptive as when it was a small organization.

There is no one definition for how to fire people in Holacracy. One company handles it by having a circle responsible for it. If you are honest about it though the traditional system does not have a great solution -- it is always a difficult thing. What holacracy does say is that you should define your process and that's an important thing. We often leave difficult things vague, but holacracy gives you a tool and responsibility for defining the process.

Another difficult topic can be compensation. How much should you pay employees should be something you have a defined policy for and holacracy again asks that you figure that out for yourself. There are "apps" in holacracy which are basically optional add-ins to the process and there is an app for compensation.

Of course one consideration in firing people and compensation is employment law. One way to avoid this is to declare that everyone in the company is a partner (they have a K1 not a W2). This way there are no employees, just partners. While this is how Holacracy One handles the challenge, it has yet to be tested in court.

Normally in a status meeting how much you say is inversely proportional to how much you got done. If you're done you just list what is complete. If you are not done you spend a lot of time explaining the reasons you are not done. Unless you are asking for a solution to what keeps you from finishing, this process is a waist of time. This is why in holacracy you say "done" or "not done" at a status meeting which saves a lot of time.

Holacracy starts by empowering everyone equally. Instead of saying here is a small set of things you can do, it says we are all empowered to handle whatever needs doing. Before we run straight into chaos with that though we do define some requirements of certain people and do place some constraints on who can do what. This is an evolved process however and everyone has the ability to call the requirements and constraints into question and the expectation is that they will change a lot at first. The advantage is that there is a built in system for process improvement. Holacracy may start out worse than traditional systems, but because it can evolve through process improvement it allows an organization to constantly get better. A traditional system tends to live with its problems and consider them facts of life instead of solvable things.

We are not always asked to be self actualized people. We grow up in a hierarchy of parents, teachers, and various authority figures. Breaking from our parents and becoming adults is a difficult process, but it is not always a complete process. Some people jump from that straight to having a boss and never learn to be their own person. It is difficult to do this, but it makes for better psychological health and in holacracy better employees. The great difficulty it takes for individuals to do this underscores the challenge in transitioning from traditional management hierarchy to holacracy.

The process for integrative decision making is very structured. It has the following steps:

0. Before the process begins everyone goes around the room and voices what is bothering them. This can be something that is irrelevant to the meeting, like "my shoulder hurts" or something like "I don't want to be here -- I have a fire that I need to put out." The idea is that we all have things that are distracting us from being present and the mere act of voicing them can silence them in our minds and allow us to focus.

1. present proposal - At this time only the presenter speaks. The proposal is captured and displayed so everyone can see it.

2. clarifying questions - The participants may ask questions of the presenter, but they can only get data out of the presenter. They will be silenced if they are trying to voice their opinion or influence the presenter to change the proposal. It is just for understanding the proposal.

3. reactions - Each participant gets a moment to speak honestly about what they think of the proposal. There is no discussion -- each person takes a turn and should be speaking independently. The idea here (much like step zero) is that we can feel compelled to voice certain opinions, but sometimes all we really want is to get the idea off our chest. It acknowledges that we are emotional creatures and gives us a chance to succumb momentarily to the emotions so we can then move on and get something done.

4. amend/clarify - The presenter is allowed to change the proposal at this time. This is not allowed in the previous steps because that would let the participants quibble about wording and get into an endless wordsmithing exercise. The point is not to have an eloquent or perfect proposal, but instead to have something that works. So at this time the presenter may choose to change the proposal based on the input up to this point. Only the presenter speaks during this step.

5. objection round - Each participant is asked if they have an objection or no objection. If they say they object then there is a highly structured way of dealing with those objections.
* If you object because you have a concern, then you are asked if that concern is something known or an assumption. We often voice concerns as if they are known facts when they are actually just something we fear will happen. It is important to be honest whether the objection is fact or assumption. 
* If the objection is an assumption then the question is if that is true would that be something we can adapt to later and fix. If we can adapt and rectify the issue then it's not really and issue. Knowing that we are in a system of process improvement we know mistakes will be fixed. Of course some risks are of things you could never repair and if that is the case then it is a valid objection.
* Another way to judge the validity of an objection is whether the objection is about something not directly related to the proposal. For instance if I needed an assistant and the proposal was to spend more money I might object to the proposal because it would take away money that could otherwise go to highering an assistant for me. When I voiced that objection I would be asked if my concern would still exist even if the proposal was not on the table. Since I still need an assistant regardless of the proposal, the objection is not valid.
* Holacracy does a good job of finding solutions by keeping a sharp focus on the question at hand and not allowing everyone's concerns to muddy the conversation.

6. integration - If there are no objections then the proposal is carried out. If there are objections then step 4 and 5 are repeated until the proposal is carried out or withdrawn.


Since I think invalidating objections is a really important part of the process, here are some more examples:

-- "Is that objection based on a concern you are feeling that would still be there if the proposal didn't happen?"
-- "Yes."
-- "Then that's not a valid objection."

-- "Is there any reason this proposal would hurt the company or our way forward? If not then it is not a valid objection."


What I called a "concern" above is referred to in holacracy as a "tension" which can refer to concerns, but also interpersonal tensions and it extends to what you might call a "difficulty". In traditional hierarchical management tension is not handled well. We tend to avoid dealing with tension and do our best to steer clear of it because it is difficult and often has political implications. In my experience tension resolution only comes from a person of power dictating something which tends to create new tensions. However instead of tension resolution we usually ignore the problem or make decisions that make no sense except that they allow us to work around the tension.

Resolving tension is hard work. It is not easy and it can be awkward and uncomfortable. That is just a reality of any system; however, holacracy gives you tools like the integrative decision making process that allow you to dehumanize the process and find real solutions. The idea is that it will be hard, but as you repeatedly address tensions you will get better and better at it and soon find you are solving tensions instead of avoiding them.


Instead of saying "I'm too busy" the thing you should say is "that's not a priority to me." Maybe there is a need for a discussion on the priorities, but there is always a lot of work to do and we can be very busy but not doing anything important. We should stay focused on the idea that we need to work on priorities. Having autonomy empowers people to do that.


If there is a conflict (disagreement) over priorities then the "lead link" (a special role in holacracy, see above) makes the decision. For the long term though there is a process of governance that lets you set requirements of people.


We get in our way so often in our own organizations by trying to be smart or clever. Our minds are not always our friends. We say things in meetings for this reason and we are not adding much value to the actual work that needs to get done. This is especially true in policy formation. The idea is do something, learn from it, adapt. You'll wind up with something that works well because it is based on the real world and not how clever you are.


The above was from my experience at the Holacracy Taster Workshop and much of what is above comes directly from what Brian Robertson (the primary developer of holacracy) said at the workshop. 

Agile Scrum - a few important points

Empirical process control says we should observe what happens in the world, learn from that, apply the knowledge, and repeat the cycle.

In generic terms: Plan --> Do --> Asses (test) --> Act (adapt) --> repeat

In Agile Scrum terms: Adapt --> Scrum --> Inspect --> Scrum --> repeat

At the center of both of these cycles is transparency.

What can be useful is to send a tracer through the concept. A tracer is like a tracer bullet -- it is something that can mover through all of the complexity of your process and be seen within each step.


Build / Run
The build / run concept says have one team totally focused on new development (build) and one team totally focused on operational issues, help, day-to-day (run). The problem with this is that most developers want to be on the build team and the run team doesn't encourage growth. The solution is to rotate members in and out of both teams. Being on the run team should always be a temporary condition.


When does the traditional waterfall method work?
1. when you are working with known technology
2. when the components are stable and standardized
3. when the requirements are complete and unchanging
4. when the process is highly repeatable (you do it a lot)


Velocity
In agile scrum velocity means the average number of story points divided by sprints. In other words: on average how many stories do you cover per sprint?


Refactoring
Rewriting code without changing the functionality. This lets you clean up the inefficient code that results from constantly adding new functionality. It allows the developer to redesign without input from the business as the functionality must remain the same. "Rework is better than no work"

User Stories
The 3Cs of user stories:

Card - the story should fit on an index card
Conversation - the story is a commitment to a conversation/negotiation
Confirmation - you need to know the acceptance criteria for the solution

Saturday, October 10, 2015

Color

Here are a couple references on color. Copyright info is within the images.