We were at DOES (the DevOps Enterprise Summit) last week in London and it was no surprise to hear many of the speakers cite culture as a cornerstone of change in their devops journeys. Jonathan Smart of Barclays had a stand out slide in his keynote presentation that simply said: "Culture is HUGE". In the years that we have been using devops principles to drive transformation in the organisations we work with, it's something we've heard over and over again and we have developed tools and practices to help tackle what is commonly seen as the trickiest devops angle to address. That's why we chose to speak about the correlations between devops and Holacracy at the event, and were delighted to be joined by our customer LEGO who also shared their thoughts and experiences on their devops journey through this lens. In this blog post I'm going to pinpoint 8 areas of principle Holacracy and devops share as outlined in our talk.
I first came across Holacracy when I read a book, 'Reinventing Organisations' and was immediately struck by the synergy between its and devops' desired outcomes. I was also drawn to the structured approach it offers as tackling cultural change can often feel a bit vague and 'wishy-washy' and having practical steps and a well-designed framework to work within is very appealing. Holacracy is still relatively new and readers may well not have come across the concept as yet, so I hope this will also serve as a useful introduction to the subject. These are the 8 areas that we spoke about last week at DOES:
1. Self-organising Teams
Agile is one of the three evolutionary drivers we cite that 'cause' devops (the other two being ITSM and Lean) and pushes hard to have fluidity in the way people are able to choose what work to do rather than being directed by those given managerial authority. Holacracy has the same principle - it wants the doers to decide what to do when and how.
Watch the Spotify video for more on how this can work.
2. No Job Titles - Focus on Roles
Yes we know there is a massive market at the moment for 'DevOps Engineers' (in fact we've got a webcast coming up tackling "What is a DevOps Engineer?") but in devops we don't like job titles, we prefer roles. Why? Because an individual can carry multiple roles and pick up and drop them as movement becomes appropriate. I'm going to say fluidity again - but this time I'm going to link it to velocity. We can move faster when we have the autonomy and authority to choose the work we do.
3. Flattened Hierarchies and Distributed Authority
This is a great article from the Harvard Business Review that gives a really balanced view about what works well and not so well when taking a Holacratic approach. And I think this sums this up nicely: "If traditional organizations strive to be machines governed by Newtonian physics, precisely predicting and controlling the paths of individual particles, then self-managing structures are akin to biological organisms, with their rapid proliferation and evolution."
Around the time I was introducing myself to this subject last year, I was talking to Patrick Debois when we were both speaking at the AppsWorld conference in London and he mentioned horizontal authority as a thing he was getting into. Holacracy and devops both move towards a place where a culture allows the people doing the work to choose the work and how and when to do it. Scary stuff if you've been into command and control your whole life, but check out the turnaround Waterstones saw when Jeremy Daunt took over and did pretty much that.
4. Peer-based Reviews
This is a big thing underpinning Holacracy and if you think about how Scrum works, it's Agile too. A great example of how to use this in a devops journey to increase velocity is by tackling the bottlenecks in a change process - most organisations we work with have CABs - Change Approval Boards who meet regularly and review changes and decide whether they can happen or not. It's onerous, it's time consuming, often the approvers don't really understand the changes they are approving, sometimes we seek to standardise change or reduce the number of CABs, but some organisations, notably LEGO, don't have CABs. They peer-review change. And no, it doesn't come at the cost of quality or reliability.
5. Amplified Feedback Loops
If you're familiar with devops, you'll be familiar with the Three Ways. The Second Way, is about amplifying feedback loops; hearing the customer or user more frequently, more clearly allowing business decisions on what to do next to be better informed, more timely, more frequent. This all leads to business agility.
In Holacracy, the talk is of 'processing tensions' and allowing doers to sense problems and opportunities and work through them. Same thing?
6. Continuous Funding
So let's move from a waterfall development model where we spend 18 months delivering a bit of software and do a small batch of features every two weeks instead. Finance - you down with that? Unfortunately not in most cases, but they are starting to be woken up. This is a useful article on how to address this disconnect, and here's where one of our biggest banks is at:
Here's a 'Teal' practice as described in 'Reinventing Organisations': "No or radically simplified budgets, no tracking of variance".
7. Incremental, Iterative Improvement
This is a quote I gathered on a Holacracy workshop I attended a couple of months ago: "Holacracy structures your organisation for evolution." We talk about devops as an evolutionary, transformational journey. Agile is about smaller iterations of change and making incremental improvements. We have Agile development being embraced in every organisation we work with and it's a principle fundamental to devops as described earlier. But what about the ops teams? They can benefit from next generation service management - Agile Service Management. I think of Holacracy as Agile Organisational Management.
8. Persistence and Constant Sensing
Holacracy and devops both promote constancy and continuousness. The Third Way is about continuous experimentation and learning and using those feedback loops to make continual improvement. I mentioned Lean earlier and it's worth noting here that those principles, like the improvement kata, are key to making devops thinking stick.
Whilst writing this blog, I came up with a couple more areas of interest that devops and Holacracy share:
- Transparency: If you implement Holacracy in your organisation, you'll probably want to use a tool called GlassFrog to manage your manifesto, roles, projects and tensions. Holacracy demands this to be transparent to all in the organisation in the same way that devops calls for transparency to build trust and surface constraints fast.
- Automation: The people who founded Holacracy have a technology background - they often refer to Holacracy as an organisational operating system. The constitution resides in Git - you can branch off it. I've already mentioned Glassfrog. In the HBR article I linked to earlier, it says that Zappos: "...developed a Slack bot to run governance meetings according to holacratic rules." Readers familiar with devops will have heard the CALMS acronym to describe what devops is about - the C being Culture and the A being Automation. Many organisations are working towards and improving continuous delivery and deployment models and whilst acceptance may be limited if the culture isn't ready, these automation approaches support devops goals of making better software faster and more safely.
So, I offered you 8 correlations and am leaving you with 10. Here they are in summary:
- Self-organising teams
- No job titles - focus on roles
- Flattened hierarchies and distributed authority
- Peer-based reviews
- Amplified feedback loops / processing tensions
- Continuous funding
- Incremental, iterative improvement
- Persistence and constant sensing
Can you add any more?
If you would like to know more about how to change culture or a Holacracy taster workshop, email me at firstname.lastname@example.org. Stay DevOpstastic.