Agility, ISO 9001 and Quality
We are an ISO 9001 accredited company (so that we can deal with government bodies, etc) and there seems to be this assumption that ISO 9001 implies quality.
In reality, this couldn't be further from the truth as the ISO standard is really just ensuring that the business processes of a company are documented and (importantly) followed. For a development environment this means there is documentation cover the process of request initiation, specification and design, development, testing, etc.
The process for design, development and testing must all be documented and followed for ISO accreditation. Because the QA methods are documented and followed there is an assumption that any product produced must be a quality product, free of defects and working beautifully. This is a bad assumption - all the ISO documents produce and enforce is that the process is followed, not that the process is correct.
I can still write bad tests, test the wrong things, make poor assumptions in the product design and produce the worst user interface history has even seen (except maybe for the Edsel or Microsoft Bob) but as long as I follow the documented processes to produce that disaster then my totally useless application will still be an ISO compliant piece of software and some people could still consider it a quality product.
So, let's say we now want to introduce agile methods into the development environment. Agile methods try to minimise documentation as excessive documentation means that a team spends more time documenting and less time responding to change. Does that mean Agile methods such as extreme programming and SCRUM cannot be ISO compliant?
There is an assumption at times that agile methods should mean no documentation. This is a stupid assumption. Documentation is neccessary, just not so much as to drown your dev team. Documentation that by it's very nature is destined to be shelfware should be avoided at all costs, however no documentation would make it very hard for new developers to get up to speed with a product, would make it hard to track change history or reasons, and would make it vary hard to product a meaningful users guide in a short space of time.
Where does ISO fit into the agile spectrum? I believe it ensures that teams follow the agile methods without deviating too much into a coding free for all where each developer does what they want, when they want. The ISO documentation should describe the agile methods used by your organisation and the way such methods should be applied.
Describing the method in which test driven development is performed is a good thing. Describing the methods in which business analysts and programmers flesh out the design of a new feature is a good thing. Describing the coding standards and how they relate to developers is a good thing.
Producing pages of documentation to fix a minor bug is a bad thing. It's not agile and it's not required for ISO accreditation. Don't do it.
Don't make the assumption that ISO compliance equals code quality. Use the agile methods, improve quality and improve productivity and don't mistake ISO compliance for prescriptive non agile methods.
Most of all, when applying or evaluating agile methodologies for your specific situation, engage the grey matter between your ears and do what is practical and appropriate for you.
In reality, this couldn't be further from the truth as the ISO standard is really just ensuring that the business processes of a company are documented and (importantly) followed. For a development environment this means there is documentation cover the process of request initiation, specification and design, development, testing, etc.
The process for design, development and testing must all be documented and followed for ISO accreditation. Because the QA methods are documented and followed there is an assumption that any product produced must be a quality product, free of defects and working beautifully. This is a bad assumption - all the ISO documents produce and enforce is that the process is followed, not that the process is correct.
I can still write bad tests, test the wrong things, make poor assumptions in the product design and produce the worst user interface history has even seen (except maybe for the Edsel or Microsoft Bob) but as long as I follow the documented processes to produce that disaster then my totally useless application will still be an ISO compliant piece of software and some people could still consider it a quality product.
So, let's say we now want to introduce agile methods into the development environment. Agile methods try to minimise documentation as excessive documentation means that a team spends more time documenting and less time responding to change. Does that mean Agile methods such as extreme programming and SCRUM cannot be ISO compliant?
There is an assumption at times that agile methods should mean no documentation. This is a stupid assumption. Documentation is neccessary, just not so much as to drown your dev team. Documentation that by it's very nature is destined to be shelfware should be avoided at all costs, however no documentation would make it very hard for new developers to get up to speed with a product, would make it hard to track change history or reasons, and would make it vary hard to product a meaningful users guide in a short space of time.
Where does ISO fit into the agile spectrum? I believe it ensures that teams follow the agile methods without deviating too much into a coding free for all where each developer does what they want, when they want. The ISO documentation should describe the agile methods used by your organisation and the way such methods should be applied.
Describing the method in which test driven development is performed is a good thing. Describing the methods in which business analysts and programmers flesh out the design of a new feature is a good thing. Describing the coding standards and how they relate to developers is a good thing.
Producing pages of documentation to fix a minor bug is a bad thing. It's not agile and it's not required for ISO accreditation. Don't do it.
Don't make the assumption that ISO compliance equals code quality. Use the agile methods, improve quality and improve productivity and don't mistake ISO compliance for prescriptive non agile methods.
Most of all, when applying or evaluating agile methodologies for your specific situation, engage the grey matter between your ears and do what is practical and appropriate for you.