Organizations struggle with their processes; the search for the most optimal process seems more a quest than a feasible goal. Implementing self-organization implies additional challenges; tensions between proven best practices and a disruptive ‘management’ paradigm. Within our company — a Managed Service Provider — we found out that introducing a new form of organization does not mean that you should cast away practices from the past and international standards. On the contrary, standards and best practices provide a basis for giving shape to self-organization.
This article describes the way in which we use international standards and best practices (ITIL, Scrum) within a (transition to) self-organization (Holacracy) and how both systems reinforce each other.
The current market is a bipolar phenomenon of, on the one hand, hard to fathom technology (although from the perspective of the end-user) and on the other hand commoditization. To increase user experience and convenience, more and complex technology is required, which at the same time entails less transparency and insight into the way the desired functionality is created. IT as ‘tap water’!
In order to streamline our operations, we’ve adopted two frameworks;
- ITIL (v3) for service management (delivering managed services and service operations);
- SCRUM for developing products (i.e. SaaS products)
Within these frameworks we use Kanban as a visual planning tool to cope with a continuous stream of work requests.
ITIL encompasses experience from IT staff from all over the world; dealing with the same issues we find in daily activities, and therefore, we benefit from the fact that we share a common reference framework and that the wheel does not have to be reinvented.
Scrum and Kanban are built on the agile principles and describe how to collaborate, learn, and get stuff done.
Our north star
Smooth operational processes are one side of the coin; we have to proactively impact and govern the context in which we serve our customers and address the needs of professionals we’re working with. For instance, operational excellence doesn’t necessarily address labor market demands and the aspirations/ambitions of professionals. Decentralization and distributing (decision) power throughout the company is key to be able to adapt fast and at the same time govern the context in which we collaborate with each other and with customers. That’s why we recently adopted Holacracy as the ‘operating system’ for our organization.
Holacracy is a set of ideals and principles that serve as our north star;
- Workability (instead of perfection);
- Consent (instead of consensus);
- Managing roles (instead of people);
- Tension driven change (instead of avoiding problems);
- Entrepreneur within your roles (instead of employee with a job title);
- Rules (instead of power).
Holacracy elaborates on an important agile principle; getting things done! The Scrum method fits perfectly within a Holacracy operating system. For example, a retrospective (Scrum process) evaluates what went well and what could have been done better (which is a tension). Scrum itself doesn’t give pathways to resolve this tension, Holacracy does — on operational as well as on governance level (f.i. integrated decision making).
What both systems also have in common is the focus on progress.
Holacracy and Scrum/Kanban is a relationship ‘made in heaven’. But what about the relationship with ITIL? Can Holacracy be a north star for ITIL as well?
And going gets tough
At the start of implementing Holacracy (i.e. developing an initial structure to begin with), some advanced practitioners advised to ‘forget about ITIL’ — at least for the time being; it would bias the perspective on how the organization really works. That’s easily said than done; we’ve seriously invested in ITIL and adjusted our tooling and systems. ITIL has shaped our reality and it’s difficult to see it otherwise. To us, the way in which the best practices of ITIL can be applied within a Holacracy is a more relevant question.
I’ll elaborate on this by referring to concepts such as transparency (accountabilities), goal orientation, domains (processes), metrics and strategy. We’re still in a learning-by-doing process and I would appreciate to hear from your experiences and to learn from your insights.
ITIL as well as Holacracy are striving for transparency and clarity. The RACI (Responsible, Accountable, Consulted, Informed) model is a central piece of the ITIL foundation; it aims to bring clarity to organizations’ functions and roles. Roles are also the key elements of a Holacracy and roles are defined by its purpose, domain(s) and accountabilities.
The difference is that the RACI model is more prescriptive, while the role concept within Holacracy is more descriptive. Within ITIL, the resolution of a tension has a prescribed desired state (indifferent to the opinion of the role fulfiller). But ITIL does not offer pathways to get there (other than the change management process).
Holacracy offers pathways as well on tactical as on governance level. A Holacracy is driven by tensions (the difference between now and a desired state) and it offers a ruleset (the constitution) to process these tensions in order to move to a desired situation (as described/desired by the accountable role itself).
Although the RACI model of ITIL does offer clarity, it’s a best practice difficult to maintain in practice. It looks great on paper, but you still have to actually make the process, project, or task work. Ideally, everyone performs in their role with an optimum level of dedication, thoroughness, and efficiency. People by their very nature are not capable of this level of ideal perfection. Holacracy offers a more dynamic model for dealing with roles and responsibilities that better connects to daily practice because it is more focused on workability in a specific situation (instead of striving for a perfect solution).
Both systems are goal oriented. Within ITIL, a process has an objective and is pronounced with verbs (to manage, to assess, to maintain, to understand etc.). An objective is more or less an ‘if-then’ direction; for example, ‘manage the lifecycle of all incidents to return the IT service to users as quickly as possible’. In other words, if you manage (..) then you’ll get (…). The objective must be feasible and the mission is accomplished when you’ve reached that goal.
Within a Holacracy a role has a purpose which refers to a ‘reason of being’ and is merely pronounced as ‘future perfect’. A purpose is by definition unreachable (Big Hairy Audacious Goal); it has to inspire the role to do everything within his/her power to pursue that ‘future’.
An objective is like signage, purpose is fuel; a capacity, potential the role will express.
Characteristic is the fact that ITIL sees continuous improvement as an explicit and separate process. Within Holacracy, continuous improvement is an implicit strategic and operational intent; a role is constantly looking for opportunities to improve.
A domain specifies something a role (or circle) has the exclusive authority to control on behalf of the organization — in other words, this role’s ‘property’, where no other role can mess with. A domain can be anything; it can be a process, an application, a physical object an authority. A domain entails a lot of ambiguity. For example, ‘role assignments within the circle’ is a domain of the Lead Link role — which pretty much sounds like an accountability (and that’s it too).
A domain as a property implies also its boundaries. If you look at processes as domains; most of the time, more than one role is active (has accountabilities and/or carries out activities) in a certain domain and sometimes it is difficult to see who ‘really’ regulates or controls the domain. Using the concept of ‘domain policies’ the owner of a domain controls the influence of others. ITIL comes in very handy in determining the domain; using the standard ITIL processes for domains.
Let me give an example of how we’ve used the ITIL framework for our domains within our Holacracy organization; the incident management process (an ITIL process).
We started with the incident lifecycle as one process, and therefor as one domain and property of the Delivery circle. Delivery made domain policies with its sub circles to get the work done, specifying which roles are allowed to act on this domain.
After a while, delivery circle concluded that the purpose and transparency would be better served by splitting up the domain in separate domains (events, standard incidents and referred incidents) and transferring the ownership to three sub circles, respectively Operations Control, Customer Service and Engineering.
In this new situation, fewer domain policies are needed and there is more clarity of who owns the domain. The super circle will be informed about the entire incident lifecycle (likewise change lifecycle and other operational and transitional ITIL processes).
Holacracy is using metrics to get a picture of the role/circle health: a quantitated status of how a role or circle is doing in fulfilling its purpose and accountabilities. In a tactical meeting, circle members are informed about these measures. Holacracy can benefit from ITIL; metrics are closely related to processes and ITIL offers an extensive library of key performance indicators that can be used as metrics for processes (input, throughput and output);
- Number of repeated Incidents
- Number of Escalations
- Number of Incidents
- Average Initial Response Time
- Incident Resolution Time
- Resolution within SLA
Too often, strategy is associated with extensive discourses about the future and it’s often the domain of higher hierarchy in a company — deciding the right goals and then lay out a path for getting there. Of course, predicting the future is based on a fallacy. But apparently, we can’t do without it — looking at the number of strategists, evangelists and futurists.
Within the library of ITIL, strategy is a separate ‘book’ with as main goal to decide on a strategy to serve customers. Starting from an assessment of customer needs and the market place, the strategy process determines which services the organization is to offer and what capabilities need to be developed. Its ultimate goal is to make the organization think and act in a strategic manner. This strongly corresponds with the classic management paradigm and the responsibilities are strongly reserved to strategic management.
In a Holacracy, the main goal of strategy is to give orienting principles (f.e. a guiding theme) and to aid and support circles and individual roles to align their work and decision making. Strategy takes the form of navigation; easy-to-remember rules of thumb that aids moment-to-moment decision making and prioritization.
Our global guiding theme is ‘trustworthy-ness’ and we defined ‘strategy’ as a process to figure out useful rules of thumb. F.e. within the process of incident resolution, the rule of thumb is; emphasize speed, even over diligence (due care). Users must resume their work as soon as possible.
Within the process of planning and implementing changes, the rule of thumb is; emphasize diligence and due care, even over speed. Changes may not hamper business operations.
To summarize the aforementioned;
The north star for ITIL
Holacracy can be the north star for ITIL as well. Like Agile/Scrum, ITIL concepts and artefacts can be useful for an operational implementation of self-organization;
- ITIL is a comprehensive framework of processes you ultimately want to have in place. It’s very likely that domains will change when you’re moving forward towards more clarity and transparency. But with the ITIL framework, you’ll keep the overview.
- The practical and dynamic role model of Holacracy fulfills more the objectives of clarity and transparency in the context of responsibilities and accountabilities. The Holacracy rules guarantee the fit with reality better than the RACI model of ITIL.
- The ITIL KPI library is very useful as metrics for processes/domains and you can use this as a source of inspiration for defining key success factors for roles.
- The heuristic format for strategy (emphasize X, even above Y — where X and Y are both positive) supports decision-making and prioritization on all levels. This goes beyond Holacracy and is powerful for any organizational ‘operating system’.
 ITIL is a registered trade mark of AXELOS Limited.