Wednesday, 30 March 2016 08:21

When Antiquated ISO 9000 Standards Impede Agility

Written by
Rate this item
(1 Vote)

In the 1990s, many companies felt pressured to become certified because 'everyone else was doing it.'  Many companies failed to evaluate fully the reasons for becoming certified.  

One primary driver for certification was to be able to acquire new business by being able to tout their "ISO 9000 Certification", especially when seeking European business. Many customers preferred or even required the certification before signing contracts.

The ISO 9000 logo, therefore, became a tremendous marketing advantage with a belief that the company with this logo had improved operations and processes. "ISO 9000 is supposed to make sure your business is run in an orderly manner that will assure success." Governance was seen as a sign of consistency and maturity.

When Agile runs into Dogmatic Compliance Rules

Many experienced professionals have worked in certified companies; perhaps some were very successful companies. Many were not so successful. But certainly it can be said that many companies sought ISO 9000 certifications a decade or more before Agile software development practices were common. The effort was often championed by a traditional Waterfall PMO, which, in turn, created a complex solution that followed the SDLC processes documented in the PMBOK.

Very often, this solution was simply a governance model to ensure that the Waterfall methodologies detailed in the PMBOK were followed dogmatically. Numerous analytical approaches were required, emphasis was given to complex and time-consuming documentation, and numerous gates were specified. Decision points required broad buy-in and often signatures for approval were critical before work could continue.

In the early stages of my career, I was a business analyst working for different well-known corporations that were proud of their ISO 9000 certification. And, like most employees, I accepted without question that this was an important improvement. We knew we had a well-defined process and, darn it, we followed that process.

Of course, I also realized that the majority of our projects were abject failures. Many of them languished in the analysis phase after many months of conversations, without a single line of code being written. I saw numerous cases where nearly everyone had signed off on the requirements documents, but there was always one or two directors or managers who simply refused to sign the document even though the client had approved; they didn't want to have their name on the project in case later it was a failure. It was not uncommon that after receiving sign off and completing our development, the client was not pleased with the end result which (for some 'mysterious' reason) did not meet their business needs.

The process had been followed, but the project failed anyway.



Years later, executive management realized that they needed to change and improve, and this was the impetus for a transformation to Agile.

This is where things often get very interesting. Whereas the original analysis of ISO 9000 involved a rather holistic approach to software development throughout the entire SDLC, all too often the implementation of Agile only took place "down at the team level".

That shiver-provoking phrase has been heard many times. There was a belief that Agile (most often based on the Scrum framework) was a process that could be implemented for the Dev teams only and would not impact the rest of the enterprise. Agilists understand that this is a false belief. For Scrum to work, the enterprise must strive to alter its culture and ways of thinking. Failing to do so can create two or more layers of incompatible processes. "Down at the team level" is a dangerous phrase which reveals a myopic, compartmentalized, and hierarchical mindset that believes a failed development effort is the result of a failed development team. This mindset fails to recognize that the enterprise as a whole is suffering from dysfunction.

It would be a little like a losing Formula racing team owner believing that in order to start winning, they only need better tire changers, completely ignoring management, powertrain, suspension, or aerodynamics.

So what is the result? This approach often results in a two-tiered PMO that operates with a business-as-usual SDLC model superimposed over 1-n agile teams. The processes that were outlined and accepted years earlier for certification remain, even though many of them are now mostly meaningless or, even worse, have become a hindrance.

For clarity, here are few possible scenarios:

1. Project estimation is sometimes performed early on in a project lifecycle by a limited group of individuals such as a VP, directors, and an architect. The result of that SWAG is used to plan the rest of the project and may even be used to communicate a 'target release date.'

Note that insufficient information may be used, the team was not involved, and overly ambitious dates of completion were communicated that were unrealistic from the start! As you can imagine, when the team finally has the chance to look at the project and the timelines, they are very uncomfortable with the situation. This process is often done because legacy rules demand that this is done in order to acquire budgeting.

2. Long-standing rules about documentation remain, so analysts often have to go through a process of creating requirements documents, getting sign-off, etc, even though the team is now structured as a Scrum team, and will create stories. Or perhaps they require design documentation, or requirements traceability, efforts that seem entirely unnecessary for many

3. Delivery efforts conducted in Scrum. But these legacy requirements remain because "that's how we've always done it" and "we need that for the auditors".

4. Complex, time-consuming rules about deploying code to production remain in place and make releasing code so difficult that the teams dread deployments and, therefore, tend to aim for infrequent big-bang releases, rather than employing continuous integration and iterative releases.

5. Change management is dogmatically enforced, requiring difficult and time-consuming meetings to communicate changes and receive approvals. This is antithetical to an agile approach where discovery is expected, and teams respond to new information through constant communication and re-negotiation with business, led by the Product Owner and client.

There are, of course, many other examples.

Many scrum masters note these impediments and quite often complain about them to the PMO, and to no one's surprise there are statements of sympathy, but no change seems possible because of the perceived immovability of auditing standards.

While upper management will often trumpet the need to increase efficiency and "speed to value", while always wishing to reduce cost, they often are intransigent regarding contemplating altering the long-established (and now outdated) processes. It would be worthwhile to perform an industry-wide survey of opinions among executive leadership to explore the real reasons for this. While risky to draw broad conclusions from limited interactions, it may be worth the risk to state that some individuals in leadership cling to their former governance rules out of habit, or out of a perceived comfort and safety, or because of misconceptions about whether or not they can actually make changes to documented procedures, and what the benefits would mean in real dollars.

The irony is that, according to Perry Johnson Registrars (PJR), a global authority on quality and on certifications, ISO compliance does not have to be a hindrance on agility.

PJR describes ISO 9000 as "a quality management standard that presents guidelines intended to increase business efficiency and customer satisfaction. The goal ...is to embed a quality management system within an organization, increasing productivity, reducing unnecessary costs, and ensuring quality of processes and products."

What's more, reading the ISO Principles seems to echo many of Lean or Agile principles:

1. Customer Focus: Keep the customer as the primary focus of business in order to understand and respond to the customers' needs, and allocate resources appropriately and efficiently. This, in turn, will generate customer loyalty.

2. Good leadership: Quality leadership can foster unity and direction and provide motivation by facilitating excellent communication.

3. Involvement of people: By including all of the people involved in a project and respecting their input, the result will create a motivated team of committed workers. In turn, this will help drive the innovation and creativity of the team. Everyone needs to have a "vested interested", otherwise known as; skin in the game.

4. Process approach to quality management: Activities and people need to be managed together, which can lower costs by effectively using resources, personnel, and time.

5. Management system approach: Combining management groups is encouraged to create an efficient system. Leaders need to be aligned to the organization's goals. A management system will generate a recognizable consistency, effectiveness, and efficiency to gain everyone's confidence.

6. Continual Improvement: Every organization needs to make continual improvement a "permanent objective". With this objective, the enterprise should strive for increased performance if they wish to gain profits and an advantage over competitors.

7. Factual approach to decision making: Information and data about performance are crucial to being able to make informed decisions. This empirical approach needs to be applied to past decisions which will build confidence in current and future decisions.

So if these compliance rules are intended actually to improve efficiency, reduce cost, and increase quality, why would any organization feel the need to cling to obsolete processes established a decade (or more) earlier?

Altering the processes may require hiring an ISO 9000 consultant to help with the change, but it should not be difficult to identify the inefficiencies and "wait times" created by the antiquated processes, estimate the time savings by updating them to match the new Agile processes, and then quantify the likely savings through efficiency and increased "speed to value" that the executives want.

The key is to identify those wins which can be translated into metrics leadership values, and present them in a way that gives leadership some wins they can brag about.

Resources:
Ron Kurtus "Reasons to seek ISO 9000."
Perry Johnson Registrars "Benefits of ISO 9000"
Dr. Sajeev Raman "Enterprise Transformation to Agile with ISO Compliance"

Read 2828 times
Curtis Reed

Curtis Reed's career in software development has spanned many areas of responsibility. Starting as a Technical Trainer for an international corporation, he trained clients on satellite technology and billing systems in English, Spanish and Portuguese. He later spent a decade as Business Analyst and transitioned to Project Manager in a Waterfall environment. Subsequent employment gave him experience in multiple Agile environments. He writes to share "lessons learned" over 15 years in the SDLC under multiple methodologies, in the hope that other budding analysts and project managers benefit from his experience.

Comments  

0 # Kupe 2016-03-31 09:14
Great stuff Curtis. I often say, don't do a process for process sake. That is how I interpreted the first half of your post. When people don't think through the reasons for a process and challenge the need/value that is when things go wrong. I actually like processes because it gives you an anchor of something to review. It gives you something to get clarity and something to consistently validate.

Thanks for highlighting this!
Reply | Reply with quote | Quote
0 # Curtis 2016-04-01 13:28
Thanks Kupe. Actually, I agree, I NEVER propose process for process' sake. My focus here is what happens when the process is already in place, formed prior to moving to an Agile framework, and becomes a major impediment to agility when the enterprise converts.
The point about ISO 9000 is that the process CAN CHANGE. "This is how we have always done it" is not an excuse. "We have to do this for the ISO auditors" is not an excuse.
If the process is inefficient, and if it is an obstacle to cost-effective development, then CHANGE the process!
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

Search Articles

© ProjectTimes.com 2016

DC canada 250