So why do Holacracy Practitioner Training in the first place? It certainly wasn’t because I had client that had an appetite. It was because I wanted more depth on the logistics of how it worked after reading the book a few years ago and after hearing a few people from zappos and other institutions talk about their implementations. I wanted to hear the tips and tricks from the expert and creator, Brian Robertson. I also wanted to do it because I felt that it would be the logical next step for organisations after or mid Agile transformation, especially those that had tried self selection, so I wanted to prepare myself for the future.

What I got was all my desires and more. For the logistics of how it works, the five day practitioner course really is practice focused, with a complex simulation that enables multiple opportunities for everyone to fulfill the facilitator and secretary roles in a very safe to fail environment. As for hearing about zappos and other institutions, well I haven’t heard much about Zappos yet, but I have heard from a lot of people on the course about how it is going in their organisations. The number of attendees already doing Holacracy somewhat surprised me and some of them already had a few months experience up as facilitators (and it showed). I have found that I have gotten as much value out of the people attending the course as those running it. I have enjoyed watching some of these people who have had honest concerns that they are still on the fence about the value of Holacracy change over the course of a few days – often because they didn’t understand the purpose of a particular activity, but more commonly because it was being implemented incorrectly (because this never also happens in Agile transformations right?).

As for Holacracy being the next logical step past Agile, well I am really not sure about that now and probably need more processing time on that one. It certainly isn’t a pre-requisite (though I never thought it was), but I don’t think people early in the Agile journey have to rule it out either (where I once thought maybe mindsets may not have been progressed enough for this leap).

So for some more detailed thoughts on the course, in a somewhat time based progression format feel free to read on:

Day 1

• Introduction of theory was expected but felt long taking up most of the first morning.
• Brian really is as engaging in person over a long duration as he is talking in videos. His energy is quite infectious.
• Afternoon session – simulation. Now I build games for my training so I know the value of a good simulation and this simulation is the second most complicated one I have ever experienced (Lean car factory being the most complicated one I have). As we went through the simulation I guess I had the unique perspective of not just doing the activity but also analyzing at the same time the simulation itself for the outcomes expected, the constraints and the rules. Now when I build games I build them so they fail first, which this does. But I don’t build them with so much failure that the goal  is 100% unachievable – that is, if you are a master, you might still succeed. The Hygean game – well it was built with a 100% failure rate. I could tell very early on what the constraints were, I also had a good background in the simulated value chain so I knew that well. From minute zero of the game I began working to the roadblock of the delays in the value chain. But when the constraint never responded in the first round at all it meant that value was never a possibility. Now I realised in the evening of Day 1 that I had made two incorrect assumptions about the simulation – that value was important (ie the business not running out of money). Lean thinkers will see very quickly that the business is about to run out of money, but it is a bit of a red herring, in some ways the simulation doesn’t reflect reality because people would care a lot about this information. The second assumption was that it mattered to win (ie successfully deliver value). It doesn’t, the point of simulation is to arm yourself with enough ammunition to run through the governance and tactical meetings, nothing more.
• Checkins. They feel really clunky. I’ve never been a huge fan of them because I have seen them abused in the past but they did feel authentic in the meetings we had.
• Building agenda items – the usage of only one or two words for an agenda frustrated me. I can see the similarities of the activity to lean coffee, but unlike lean coffee, where you spend fifteen to thirty seconds talking about your agenda item, in holacracy there is zero time spent on what the agenda item means. The consequence is that no one actually understands the agenda. This felt incredibly uncomfortable, mainly because I wasn’t quite sure if someone else’s agenda item was similar to my own as the two words were the same and so I didn’t know whether I should raise my agenda item. What I subsequently resolved that evening was that it didn’t matter. It was my responsibility to put my agenda item up regardless. The agenda item is only a refresher for the single individual that created it and nothing more.
• Reaction round – the process in a lot of respects feels like the Cynefin Ritual Dissent activity – in that it creates space for a proposer talk without interruption, that respondees can ask questions, respond emotionally without interruption (with a small element on Non Violent Communication) and with dissent. After that it is more like a facilitated processing activity with similar restrictions on who can talk when. In the scenarios that we went through I found this activity at first incredibly frustrating, not because of the process, but because it felt that there were gaps in the structure of the process. As an example, in our simulation with the financials running out a proposal was put forward to make the financial runway visible to the organisation so that we didn’t go out of business. The proposal was opposed because of a concern that people would leave the organisation if they thought it was about to be bankrupt. This was based upon an assumption that was perceived, but was not rooted in metrics and because the objector felt that the information wasn’t safe to test, it was considered a valid objection. My main concern with this outcome was that the assumption was statistically invalid, just that the objector was not aware of it, but importantly that I had no ability to even say this, that the falsehood of information was allowed to continue unabated. Now in fairness, I now know that if we had time it would have gone to integration and that hopefully that information would have come out then, but it felt like time was being wasted.

Day 2

• The feeling of a lot of time wasting in these governance meetings continued as I pondered time and again where lean elements of root cause analysis and value stream analysis fit in. People changing roles and accountabilities without any understanding of the value chain seemed inane. But what I realised by the evening of Day 2 was that it didn’t matter – because the value chain would be discovered over time through continual incremental refinement. In essence, getting roles, accountabilities and the value chain right occurs over time (and isn’t ever right). It is like Agile, the software will never be right by the first sprint, but through continual build, reflect and adaption it will get good enough in the end.
• Proposal tension analysis takes a lot of time when the change is a large merge/refactor. It felt slow waiting for everything to be typed in, but then I found out afterwards that you can propose items in advance and write up all the proposed changes beforehand. This made me feel comfortable that corporates would balk less at the time waste if they knew information could be processed asynchronously (which was demonstrated to me afterwards by someone doing holacracy already).
• It really hit home to me by the end of this day that tensions are best when they are micro and are frequently worked on. Weekly governance over monthly would be the best way to start, much like short Sprints allow more frequent adaptation. My favorite quote of the day – “Design the org, just in time, for what you need not what you might need.”
• Not a huge fan of the ’cause harm’ language, prefer the longer language of ‘can impact delivery of the circle’s purpose’.
• The term ‘project’ also feels like the wrong language to use. Many corporates have a deep tie to this word and I feel it would be better changed.
• A comment was made (either this day or day 1) that an example of an outcome for a project would be ‘Product page redesigned’ – I would argue that that is not an outcome, an outcome would be the why – ie “Provide a more user friendly experience to increase customer clickthroughs”
• How to prioritise tensions – strength of tension, first in first out, shared tension or time criticality. The answer is it depends on your needs and almost all options can be used at the discretion of the facilitator.
• Can the facilitator and secretary be the same person? Yes, but it is not generally recommended. I can see through the simulation why for beginning teams this is not recommended.
• How do you balance workload if you are working in multiple roles? The answer is holacracy doesn’t specify a solution for this.

Day 3

• Root cause analysis can happen, but only if the proposer asks for help/it. So if, as a respondee, I am needing root cause analysis to get onboard with the change then it isn’t the proposers problem, it is mine. Consequently the proposers change should go through without objection and if I care about root cause analysis then I need to raise the tension (proposal). Processing tensions is all about processing the tension for the proposer, not for opinionated people.
• Back to the earlier quote – ‘what might happen’ objections which are invalidated result in only a 10% new proposal rate. This isn’t due to people feeling petulant that their objection was invalidated, but that when it comes down to it, the concerns aren’t really that big of a deal, we are just so used to providing opinions that we can’t help ourselves.
• Feeling very comfortable with the process and its micro adaptation of the organisation.

Day 4

• If you are the sort of person (like me) that likes to help someone refine their need (ie paraphrase) then you would feel frustrated with the experience of the governance meeting as you cannot help the person get there. You have to be more patient and accept it will take more time.
• Tactical meetings – not a lot of new content or concepts in here for Agile folk.
• Use lead in narratives about the current step so that people understand what they are allowed to do (or not). If people get off track (out of process) guide via “We have space for that comment in the next step,” and then return to the current step.
• “It is not a valid objection, but it sounds like you have an item that you may want to add to the agenda.”
•  Today reminded me a lot of Kanban’s rules – start with what you do now, know your constraints, your policies, respect.
• Tactical tipsheet – if the action is volunteered by a person and there is no role accountable then the action is classified as “individual action”
• Domain – full ownership for that thing, it no other roles can meddle with it without the express authorization of the domain role owner.

Governance Tipsheet

Present Proposal – proposer can ask for help or root cause, but normally will just be proposer.

Clarifying Questions – NOT a round robin, only people who have questions. Can have multiple questions. Ensure questions aren’t leading or an alternative solution is being presented. Stop people quickly if the question doesn’t start with a “what, how, why, when, or who…” Does not include proposer.  Facilitator can ask questions.

Reaction Round – Does not include proposer (even responding). One by one go around, including facilitator.

Amend & clarify – Proposer only. They can choose to change things based on the reactions and clarifying questions. They can also choose to not change.

Objection round – Have proposer last, includes facilitator. Ask “Do you see any reason why adopting this proposal causes harm or moves us backward. As a facilitator you can jump around the objection questions if you feel there is a hint in what is said as to which objection it may fail on. The goal is to facilitate the process, not have emotions. Ask both sides of the question sheet. Anyone can ask in the integration round for an objection to be re-tested if they felt it wasn’t done.

Integration round – In integration, anyone can contribute as long as the facilitator has no objections and as long as the proposer and objector have opened it up. Ask the objector if they have an alternative proposal that will meet the need of the tension. Once done, confirm with objector if this meets their needs. If both are happy then it is integrated, otherwise it goes back for resolution. Another round of objections occurs after accepted integration.

Day 5

• Just because you have a need from someone doesn’t mean you can’t talk to someone and ask them to do it. Use the governance process for tensions were expectations are NOT being met…. otherwise you will have dozens of accountabilities.
• We seem to try to get agreement on the tension before we process it (consensus build). Holacracy accepts the tension regardless in order to process it. In this respect, you transition the time in an organisation spent consensus building outside of meetings to tension processing in governance. The time is likely to be less in the later.
• Can use ‘curator’ rather than ‘secretary’
• For Agile areas – keep your retros, have them feed straight into governance. Sprint Planning is often combined with tactical meetings, especially if the circle is the Scrum Team. If the circle has a few extra people outside of the Scrum Team then you may want to split the two.
• Have governance straight after a tactical meeting as tactical meetings are likely to drive desire for change.
• Address what happens with compensation early in the selling of holacracy discussions.
• Existing policies get moved across into the appropriate circle.
• Use the habit support program in Glassfrog
• Don’t over do the setup at the start. Don’t be tempted to fix tensions as you breakdown job titles into roles.
• Don’t give roles very status titles
• Don’t try both (ie management and holacracy) at the same time
• Developer role with a focus on product X is better when multiple products need to be supported in an area.
• Have a role for guild lead, otherwise don’t have circles for tribes.
• Be clear on how meetings relate to holacracy – stop doing or cut out the parts that are covered by tactical and governance meetings.
• And for meetings that you keep, be clear on holacracy links – ie what roles are invited, tracking, actions, projects, tensions etc.

Outstanding questions:

• How is this going in Zappos?
• Why aren’t there any values/principles in holacracy?
• How does the constitution change over time?

The presentation was video taped so when that is released I will update and provide a link.

Because it was a presentation on Visual Management I felt that it was quite important that visually it looked slick. I spent almost two hours a night, most nights for almost two months to get the 70-odd slides in the presentation. Some slides were cut due to the time constraints of keeping to 35 mins. Also due to time constraints we didn’t get the opportunity to cover items in more depth, in essence it was a slidefest of ideas and concepts, enough to say “hey, that’s a good idea, I could use that” but armed with the information to be able to seek out more.

To this extent I wanted to add to the slide deck some bullet points of thoughts that we didn’t have time to cover or extend further on. For those who were unable to attend I also wanted to iterate some key elements of the slides.

• Firstly, I would like to thank a few people who made this slide deck happen. Four pictures were taken from @craigstrong and one from @caza_no7 (Ian Carroll’s) work. The Usability section of these slides was worked on with Usability expert, Matthew Hodgson @magia3e of ZenExMachima fame. Some photos were taken from the Dandelion and Driftwood cafe in Brisbane with the approval of Penny and Peter Wolff. Lastly, a number of pictures have been taken from where I am currently working at Superchoice, I am thankful to Ian Gibson for his permission to use them.
• Slide 14, which discusses Value trees is an extension of Luke Hohmann’s Product Tree work. I have been using Value trees for a little while now to represent backlogs and am finding them more useful then a standard backlog, especially for identifying critical paths. Compared to a normal backlog they allow for recognition of the existence of dependencies and parallel processing. I am currently working on a whitepaper for these and with Luke Hohmann’s help should have it released fairly soon. The whitepaper will go into a lot more detail about what they are and how they work, so stay tuned!
• Slide 16, the Timeline Board is sometimes considered an anti-pattern in Agile circles. It is an advanced form of a Gantt chart, but unlike a Gantt chart it is quite adaptable to real time change and exists for the whole team to have transparency and ownership of the work. I don’t use this type of board often but I do tend to use it for complex move sequences and have done so a few times. The x-axis and headers represent time. Usually this is done as a two way exponential timeline. The key milestone sits roughly 2/3 of the way across the x-axis. From that date it logarithmically goes forward in time. It also reverses logarithmicaly in time as well. For example, the headers could be 3.5 months, 2 months, 1 month, 2 weeks, 1 week, milestone -4 days, milestone – 2 days, milestone -1 day, milestone, milestone + 1 day, milestone + 2 days, milestone + 4 days, etc. Once the wall is constructed items generally don’t move. Cards do have a tendency to be added. The main thing that moves is the current time point. Anything behind it should be crossed off done, anything on it is in focus for the standup and anything in front is visibility of what is coming up.
• Visual management isn’t just about software development. I have spent a good amount of time in my career applying it to other knowledge work areas.
• Visual management’s audience isn’t just the team. It is about re-enforcing everything visually – for both the team, managers and customers.
• Visual management isn’t just about a flow zone, it also incorporates many facets of other information.
• There is a direct relationship between the level of complexity of the type of work that you are doing and the manner in which it is visually managed – generally the visual management is one degree of complexity less than the work itself. This is a new concept that has not been previously explored.
• The application of software usability rules and how they apply to Visual Management is also a new concept that has not had a considerable depth of exploration. I am sure we will hear more from Matthew on this in the future (he felt it could have easily taken up the full 35 mins and I would tend to agree).
• There is a misconception about the purpose of the readability of cards on the flow zone. Most think that the information needs to be retained. The key purpose of usability relating to cards is to be able to find it quickly and to be able to read it easily, not retain it. You want to be able to find it with little thought in stand ups. You want to be able to find the right card quickly when talking to the Product Owner. This is where usability and Visual Management becomes highly important. We don’t spend enough time being consistent and writing clearly when writing cards. As Lynne Cazaly beautifully mentioned in her presentation, if you don’t take the time to write neatly what someone else has told you then you are not showing respect for their thoughts that they have given you.
• Achievements – I have mentioned them a few times on this blog. As part of this exercise of getting a slide up I somewhat simplified the generation of the tokens and the Agile Achievements playbook. If you are interested just send me a tweet and I can DM you a direct link to the content if you want to re-use it.

Lastly I want to thank Craig Smith for his help and support in doing the presentation.  I may be the Penny to his Brains (check Craig’s uploaded slide deck for the in-joke), but he is really the Will MacAvoy to my Mackenzie Mchale.

Firstly, this is an odd sort of post for what I normally write. It is more a brain dump of a concept or idea I have and not necessarily a well formed one.

The audience was for Dave Snowden or anyone else who considers themselves a Cynefin or complexity thinking specialist.

I openly profess I am not. I am trying to learn and so some of the concepts I have within may be wrong. Please forgive me if I haven’t gotten a concept right. I am here to learn, be challenged/corrected and think differently.

These ideas and thoughts were generated from trying to extend the boundaries of a new movement called “Visual Management”.

Coffee and Cynefin

Coffee at home

When we make a coffee at home it is a very easy affair. We choose the coffee type from the store (probably your hardest decision), add it to a cup, add sugar if you desire, add boiling water, stir, add milk if desired and Bob is your Uncle.

In terms of complexity of the task it is Simple. The outcome is predictable. The process requires no domain specialisation. In likelihood the home “barista” is also the customer. The quality is…. less than desirable. I know that quality is in the eye of the beholder, but having been privy to some of the worlds top coffee makers and blends and I can say, in my experience, that a Nespresso machine coffee pales to a good barista produced cafe coffee.

Cafe coffee

When we go to a cafe for a coffee the domain expert, the barista, should be able to do a better job of producing a coffee from the commercial quality machines than the average person.

In terms of the complexity of the task it is Complicated. The outcome is still predictable. The process now requires domain specialisation. The barista is no longer the customer. The quality is dependent on the experience of the barista, the process they use, the quality and freshness of the coffee  itself, the roasting process applied, the milk and lastly the quality of the tools (machine, grinder, milk jug).

World Barista Championships

Last year my husband was Australia’s 5th top Barista (I am very proud of him). His passion and energy for a good cup of coffee has enabled me to learn a lot about the coffee industry. In order to be a rated barista in both Australia and the world there are competitions that are run each year. These competitions are very arduous and time consuming. This year’s barista champion for Australia spent three months, full time, training for the competition event. In essence, he was sponsored, ie paid for three months, to do nothing but ensure that he was ready for a fifteen minute performance. Judges go through a similarly arduous process. Technical, taste and presentation standards exist and are assessed against.

Baristas at this level are highly passionate, highly educated and use the best tools and equipment that money can buy. To be on top of their game they conduct a lot of experiments. For their twelve coffees in fifteen minutes they would make hundreds of bases, cappuccinos, and try dozens of experiments for their signature drink. Dozens of blends would be tested and a variety of roasting conditions tested. Baristas have to work closely with roasters because, in essence, their coffee is also showcasing the roaster’s ability too. The roaster’s domain experience can greatly affect the barista’s outcome.

All in all, a barista, when they start their journey, would certainly not be able to predict the type of the coffee, the roasting elements, the milk to be used and their signature drink. In terms of complexity of the task it is Complex. The outcome is not predictable. The process requires several domain specialists. Experts are now the customer. The quality is high and graded within clear and defined guidelines.

How does this relate to Visual Management?

When we make a coffee at home there is no value in visually managing this work. Simple work will happen with such predictability and ease that the effort to do visual management would be considered an overhead or waste.

When a coffee is made at a cafe there is some value in visually managing this work – value for both the customer and producer. Complicated work has the simplest of visual management techniques applied – the flow is usually limited to “To do”, “Doing” and “Done”. The variability of items inside of the flow is constrained to a subset of possible conditions,that is, a barista is not going to make you a smoothie or sandwich.

When a coffee is produced for the world barista championships the process to deliver that coffee would benefit from a more complicated visual management system. Complex work has complicated visual management techniques applied – the flow may additionally have a “Wait” column. The variability of items inside the flow are no longer constrained to a subset of possible conditions. Work may now become easily blocked. Work may now have dependencies and relationships to other work items. Work may now need specialization outside of the barista’s capabilities – ie other domain experts are likely required. All of these things can be visually managed. You don’t have to have a visual management zone for doing the world barista championships, but speaking from experience it certainly does help.

Conclusion

For coffee making (and maybe more?):

• There is a relationship between the complexity category and quality
• There is a relationship between the complexity category and process specialised relationships required to produce the work value or outcomes
• There is a relationship between the complexity category and variability of work items within the flow
• There is a relationship between the complexity category and the predictability of the end outcome (known)
• The visual management techniques applied sit one category of complexity below the actual work within the system