Systems and standards with good intentions are naught without proper execution. Unfortunately this is where most people get let down. People adopting agile fall into the same traps, but at least the Agile Manifesto guides people in terms of values.
Here’s how I’ve seen ISO9001 being communicated at various clients:
- ISO9001 is a quality management system
- A core part of ISO9001 is about control and documenting processes
- ISO9001 is about continuous improvement
Seems harmless right? Unfortunately the way that people interpret this is as the following. ISO9001 is a quality management system. Quality management system = control and documenting processes. Control and documenting processes = continuous improvement.
Unfortunately most people never escape out of the control and documentation requirements, and the fear of failing and audit that leads to a micro-optimisation. This is why the manifesto talks about “uncovering better ways of developing software by doing it and helping others do it” and prioritising “individuals and interactions over processes and tools“.
That’s true for ISO9001 – but ISO90003 is better since it expects you to define the process (showing how you cover various areas of the SDLC) and then follow the process.
You can even take a process like SCRUM and map it to ISO90003 and be compliant (I have in the past)
Arnon
Arnon, ISO90003 is even worse – the actual worst part of the ISO9001 process is certification.
We can not document a process that describes everything we do in software development. By trying, you stifle creativity and innovation.
It works in other industries – where the key to success is rigidly following a process, and the best process wins. It doesn’t work in software development.
The old memory is failing me, so the name escapes me (not Toyota – starts with S, I think) – but there was one Japanese firm which had all their processes fully documented. However, every project and initiative was told to take at least one aspect of the process and deliberately deviate from it (recording the result). This allowed the firm to refine and improve their processes, because at least some of the deviations were positive.
You can’t have improvement without change. Spending too much time on documenting what you do now prevents you doing what you need to do differently next.
Hi Arnon,
Thanks for the comment. I don’t have any problems with mapping processes, defining it and capturing that as knowledge. What I do have is treating that as “gospel” and moving from a “do what’s right” culture to a “do what’s written down and follow orders” culture.
I think most “standards” are inherently at risk of this, driven by the fear of failing an audit. The focus then leads to, “you didn’t do as you defined” which, as Robert mentioned, stifles creativity and innovation. It frustrates me that the intent behind these processes (clearly stating how you work to capture *some* level of repeatability *and* to continuously improve) fails to come through in execution.