Agile ISO: A Holistic Business Process Management Framework
Writing for Process Street, I outlined my concept of Agile ISO.
That article was targeted at a broader audience and intended to function as training material, so the article spent a lot of time explaining concepts and helping the reader understand what ISO 9000 is and how it functions.
If you’re interested in Agile ISO and feel you need those concepts explaining in detail, read that article.
If you’re interested in Agile ISO and already understand what it is and just want to get started, use the templates in that article.
If you’re interested in a more specialised discussion of Agile ISO — what it means for practitioners and how it could impact on more focused aspects of internal organisation, then this is the article for you.
Before we jump in, here is a round up of the Process Street materials we’ve created so far to help explain or facilitate Agile ISO:
- ISO 9000 Structure Template
- ISO 9000 Marketing Procedures
- What is a Quality Management System?
- What is an ISO Audit?
- ISO 9004:2018 Self-Audit Checklist
- How to write a Policy and Procedure Template
Between those above articles, there are about +40,000 words. Most of it you won’t need to read. The ISO 9000 Marketing Procedures, for instance, is an example ISO 9001:2015 QMS MiniManual filled in to tell the story of a fictional company called Brightstar Marketing. It’s a text to jump through to find example copy when you get stuck with your own mini manual content. No one needs to read the 20,000 words from start to finish.
Nonetheless, the materials are there for you.
In this article, I’m going to look briefly at a couple of key questions and considerations pertaining to Agile ISO and how it could be implemented, developed, and improved.
- What is Agile ISO?
- How I think Agile ISO should be implemented
- What could Agile ISO do to a company’s organisational structure?
- What are the limitations of Agile ISO?
What is Agile ISO?
Agile ISO refers to the use of agile methods at the level of the procedure, while enabled by software to retain ISO or equivalent compliance for the breadth and documentation of the overall quality management system.
Agile ISO is simply the recognition that ISO 9001:2015 allows for agile approaches and rapid process improvement at the base level of a QMS: the procedure. However, agility and process optimisation at the level of the procedure while retaining ISO compliance requires specific software features to be done effectively.
The point of Agile ISO is not to impose agile elements for their own sake, the point is to make a better system. One where a quality management system from mini manual down to each and every process, is stored in one system, interlinked, interactive, and actionable.
Moreover, being agile isn’t just about changing things and testing them and doing it quickly and breaking things and whatever. Being agile is about the careful application of testing new things out in the wild and trusting the expertise of the people involved to make judgement calls. Follow the process — but break the process and improve it, if you think that’s what it needs.
Trusting the individuals involved in actually running these processes on a day to day level requires a company to respect its staff and be willing to part with some of its hierarchically held power. But more on that later.
ISO isn’t really of super importance to Agile ISO. That sounds weird, but ISO 9000 is simply an internationally recognised framework for determining a good quality management system. What we want to do is take the agile theory and grow it up inside that framework until the two become entwined. ISO 9000 is the trellising and agile approaches are the climbing plants.
How I think Agile ISO should be implemented
I’ll come out and say it straight off the bat: I don’t like hierarchy in general.
I don’t feel like it’s particularly productive. I think it creates significant incentive for people to leave roles they’re good at for roles they’re not good at. I think it damages specialisation and craftsmanship. I think it creates unnecessary divides within an organisation. I think it removes accountability for decisions and promotes inaction.
The world of software development is doing great work in challenging how we think about hierarchy.
“Why is my manager above me? Why am I above those I manage?” — These are the kinds of questions most organisations implicitly cause their employees to ask.
Think instead about the set up of a team in a Scrum system.
You have a team of specialists. You have one specialist who isn’t focusing on the work, they’re focusing on removing obstacles faced by their colleagues. Then you have another specialist who determines what is required in regards to output and has measures to determine whether or not those criteria were met.
The scum team, the scrum master, and the product owner.
The product owner is not the boss of the scrum master, nor vice versa.
Nor, in a good system should the product owner or scrum master be considered the boss of the other members of the team.
You have specialists focusing on the task at hand, a generalist looking ahead to facilitate their work, and an organiser who links the actions of that team to a set of broader aims.
It is possible to run that team without having to practically call on hierarchy on a day to day level, at least.
Now, I’m not telling you to reorganise your entire company. But I feel the fastest and most effective way to implement agile ISO in your organisation is to take a leaf out of the above.
Treat the different members of your organisation as specialists and grant them not only the respect that comes with that, but the responsibility which comes hand in hand with that respect.
Get your teams to document their own process. It can be super simple at first. Any task they do more than twice should be recorded. It could be bulletpoints on the back of a fag-packet, just so long as they get the basic steps down.
The goal would be to then note these processes in Process Street (or another software or collaborative tool, I guess) and each time that employee starts that process in real life, they run the checklist for that process in the platform.
They follow the process and improve it if needed.
By doing this, simultaneously across the organisation, you can suddenly end up with documented processes by the bucketfull.
Of course, this won’t just happen in real life.
You’ll need to disperse materials explaining the importance of processes, talk about how we’re moving over to a process based system, and how that gives more control to each worker over their day to day job — gaining also the credits for the improvement of processes over which they hold singular or collective responsibility.
Your typical change management stuff, just specific to this particular scenario.
Practically, of course, it would help to build a folder structure inside Process Street with managed permissions so that you don’t create a chaotic mess of muddled documentation. I wrote about my recommended approach to that for large companies in my article here on process libraries — a combination of a live/staging folder hierarchy along with a Dewey Decimal tagging system.
After the point where your teams are operating with documented processes in place, you can start to make improvements.
Realistically, people may have documented the process but chosen not to bother following the process. That’s not a problem and you can fix that at the improvement stage.
If you create a mini-team of process specialists — it could be 1 person — then that process team can go along and meet with each team in the company and work with them to improve their (ownership is important) documented processes. In doing so, you improve output, reduce risk, and provide hands-on process improvement training to everyone.
Trust your teams and build out processes in an agile way starting from MVProcesses before building up toward your fancy automated options.
What could Agile ISO do to a company’s organisational structure?
Let’s keep this short.
Agile ISO might do nothing to a company’s organisational structure. You’d be perfectly capable of implementing much I’ve described without really changing anything.
However, if you really go for it and try to make your teams responsible for their own processes and adopt all the kinds of approaches I mentioned, then we’re looking at what we might call a modulated organisational structure.
Small independent teams with their own budgets and a sense of autonomy.
The knock on effect of this would be a reduction in the need for middle management — much management would be enabled by the delivery of the effective quality management system. That broadly monitors progress and performance for each and every team — rather than a bunch of people per department doing the same.
That doesn’t mean there would not need to be department heads, more that those department heads can focus on the quality of output, the strategic direction of their departments, and other extra added value activities.
A single internal process optimisation team providing consulting services alongside teams as equal specialists could serve to significantly improve internal organisation while also massively increasing the training of staff to maintain that performance and even deliver greater performance in future.
When all longstanding members of staff are process specialists as well as specialists in their day job, a lot of the tough work of management has been stripped away.
What are the limitations of Agile ISO?
It’s hard to clearly determine limitations of Agile ISO in advance.
Partly, because doing so with any concrete sense of assurance goes against the principles of agile approaches — we don’t have data to work with.
We do know that cooperative structures like Mondragon and others have been found to be more consistent and stable than their private-lead counterparts. So there isn’t much evidence to suggest a structure which provides greater distribution of power and decision making would suddenly flounder.
Plus, Agile ISO is an incredibly flexible notion. Much of what happens in an organisation which implements this will not be particularly agile. Think of a car manufacturer — there’s a limited amount of agile activity and organisation which they can utilise; cars have to be planned to the nth degree and MVP versions are not viable in this kind of industry.
Nonetheless, that kind of organisation can still implement these principles. A fully built out process library with employees taking responsibility over processes on a day to day basis can be attained either partially or fully across whole organisations or select departments.
Potential issues may arise when dealing with low-skilled labour where employee turnover is high and many employees are very young and working few hours.
There is a reluctance to provide ownership and responsibility to casual staff generally, but perhaps an organisation has more to gain in the added training and development of young or casual staff than they stand to lose.
Each organisation would have to implement these principles of business process management in tailored ways to accommodate the needs of their particular practices.
A practical issue organisations may face initially is the time-intensity or recording, implementing, and ensuring adherence of these processes. I believe the approach I described above regarding collective development of processes with iterative improvements over time with recourse to a responsible process specialist is the best approach for most.
However, that approach will be harder in industries where there are strict regulatory guidelines, and these industries may require a more top down approach to the development and iteration of core processes.
Even in industries like that, there are opportunities for the workforce to take control over certain processes. I recently wrote about the Japanese concept of 5S — made famous by Marie Kondo — which concerns keeping workspaces organised, tidy, and clean. Effective implementation of these principles via consistent processes boosts efficiency and provides a host of other benefits. These kinds of processes can be delegated to the teams which concern them in almost any line of work.
To make Agile ISO work in your industry or business you would need to assess carefully what can be delegated and what can’t. This presents certain limitations to the extent of implementation, but the core principle of centrally stored digital processes which workers themselves contribute to can be delivered almost universally.
The key questions which I feel remain, and would like feedback on, are:
- Agile ISO appears strong conceptually when discussing small teams, but how would it fare when faced with large teams? — call centres etc.
- To what extent might an organisation need to invest in technology to effectively deliver these aims depending on industry? Could this be a barrier?
- Are there significant limitations on the effectiveness of process management methodologies in general when faced with project work? When the activities are constantly shifting, repeatable processes may be used sparingly and not be the core means of organising or achieving outputs — in media production you might have a process for setting up the camera but not for shooting the scene, etc.
- Does the inclusion of ISO within the concept obscure the emphasis on large scale agile process management, or assist it?