Skip to main content

Single to Double Loop Learning

Chris Argyris is one of the most important and influential thinkers in the last 100 years. Yet, few people are aware of his efforts in organizational development and human behavior. Argyris wrote about a number of different areas of organizational change management. Perhaps one of his most important contributions has been in the area of Single-loop and Double-loop learning for individuals and organizations.
Single-loop learning is when an individual or group undertakes an action and the result is not what they expect or believe be the result should be. So they go about “correcting” their approach on the assumption that they must have done something “wrong” the first time. As a result of the “correction” they expect a different result. Some of you may recognize this as the classic definition of “insanity”. Others have called these “self-fulfilling” prophecies. Doing the same kinds of things over and over and expecting different results. Single-loop Learning results from creating what Argyris called “governing variables”: boundaries or limits that an individual or group creates that stifle creativity and ways of thinking to within known environments.
Double-loop Learning (also known as causal-feedback loop learning) is when an individual or group undertakes an action and gets a result, and then reflects immediately on both the action and the result to see if a completely new, innovative and creative approach is needed to achieve a different result. There is no “correction” needed or desired. Rather the “governing variables” must be changed or eliminated to allow for a new way of thinking or seeing how to achieve the result. Double-loop Learning makes little or no assumptions that the expected or desired results we originally set are the right or correct results. Double-loop Learning lets the action-results-reflection loop determine the appropriate result.
So how does the work of Argyris help us with ITIL and ITSM? It helps us to see that we first need to put in place Monitor-Control Loops (Single-loop Learning) to ensure our processes and stages work according to expectation. More importantly we need to move beyond Monitor-Control Loops to Double-loop Learning. Once we have a Monitor-Control Loop in place we no longer have to “correct” a process to improve it. We have to ensure that the “norms” (“governing variables”) that we establish for our Monitor-Control Loops are the best, most creative and innovative they can be to achieve optimal results, value and quality for our customers. The “norms” are the measures and metrics we put in place against which we compare a process, stage or ITSM as whole to see if it is producing the expected result. If a process is not meeting the norm we can improve it or we can alter the norm to achieve a different result.
Let’s use a typical measure as an example: Availability. If the availability of a service is not what we expect, we could undertake all sorts of efforts to “correct” our actions.  These could include redundancy, failover, more procedures, etc. Or (using Double-loop Learning) we could look at the desired result (the “norm”) and determine if that level of availability is really possible or if the customer even needs that level of availability. Thus by changing the “norm” or “governing variables” under which we work, we could see that we are already providing the desired or best level of availability for our customers.
If we want to make ITSM and ITIL work for us, sometimes we need to take a look at the way we think about our approach to ensuring the expected and desired results that our customers desire. This includes making a shift from Single-Loop Learning to Double-Loop Learning.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…