Continuous Improvement with Agile, ITIL & Lean.


In this article, I'll lightly explore continuous improvement using Agile, ITIL and Lean.

Continuous improvement with Agile
Agile is more than just a modern software development process, it is having an agile mindset (or to demonstrate agility for your customers' dynamic needs). While the Agile Manifesto outlines four (4) values, it is principle 12 that highlights Agile's focus on continuous improvement. Principle 12 states "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" (Principles behind the Agile Manifesto, n.d.). 

 Retrospectives are one instrument that Agile provides to check the health of your service delivery and identify improvement opportunities. Held at the end of a sprint (time boxed interval of enhanced product delivery), the retrospective gives stakeholders an opportunity to reflect on:
- what went well for the sprint (to repeat it again),
- what didn't go well (to address issues),
- what still puzzles me (to address what confuses and hampers people).

 Typically when a retrospective is held, action items or recommendations for continuous improvement are identified and registered as future story cards in the product backlog. These improvement story cards can later be selected for an upcoming sprint for action.

 Further to this, Smith and Sidky (2009, p30) state that showcases (end of sprint product demonstrations to customers) are a form of continuous risk management (proactive improvement) since "the customer gets a feel for how requirements are translated into an application before the project is complete".   

 Continuous improvement with ITIL
The IT Process Maps website (ITIL V3 CSI - Continual Service Improvement, n.d.) provides a good summary of ITIL CSI by presenting it as four (4) processes:

  1. Service Review: regular reviews of the services provided.
  2. Process Evaluation: regular reviews of tactical and operational processes used to support the services.
  3. Definition of CSI Initiatives: Defining initiatives based on the above two regular reviews.
  4. Monitoring of CSI Initiatives: Monitor these defined initiatives and implement corrective actions. 
In the ITIL text (Cabinet Office, 2011, p.53), continuous improvement is based on a more detailed seven (7) step process:
  1. Define what you should measure: Use the information about your services to define what should be measured to gauge improvement.
  2. Define what you can measure: identify what can be measured with your available budget, resources and technologies.
  3. Gather the data: Gather data based on identified goals and objectives.
  4. Process the data: process data from various sources for an 'apple to apple' comparison.
  5. Analyse the data: Transform the data into information.
  6. Present the information: Show the results to key stakeholders.
  7. Implement corrective action: Identify and register actions to address any gaps or opportunities for improvement. 
Continuous improvement with Lean
Central to Lean manufacturing (based on the Toyota Production System) is the concept of Kaizen (which is Japanese for continuous improvement). Toyota using a seven (7) step process which relies on the existence of a problem. Liker (2004, p. 256) outlined Toyota's problem solving process as follows:
  1. Document initial problem perception.
  2. Clarify the problem.
  3. Locate area or point of cause.
  4. Investigate root cause.
  5. Identify countermeasure(s).
  6. Evaluate the effectiveness of the countermeasures, and if successful.
  7. Standardise the new approach/work process.  
In their book "Lean IT", Bell and Ozen (2011, p40) outlined that there are two kinds of kaizen - System kaizen and Process kaizen. They state "system kaizen attempts to improve the overall value stream by enhancing material and information flow, and it is the focus of management. Process kaizen, performed by teams and individuals, concentrates on reducing waste in specific focus area within the value stream. Improvement in one type of kaizen positively impacts the other". Further to this, using kaizen can be categorised by the activity's duration. Large scale kaizen initiatives can be managed as projects. Smaller, focused mutli-day events as known as kaizen events, and smaller improvements is known as daily kaizen or kaizen blitz (Bell & Ozen, 2011, p.41). 

 Extending on Bell and Orzen's ideas further, I suggest that these kaizen events appear in Agile and ITIL as well.  The table below illustrates examples of how the three methodologies support continuous improvement with their specific instruments:

Event
Agile
ITIL
Lean
Large scale improvement
Project
CSI Project
Project, A3, 7 step problem solving
Medium scale improvement
Retrospective, Showcase, Feature
CSI, Problem investigation, Change request
Kaizen event, A3, 7 step problem solving
Small scale improvement
Fedex Day, Story card
Problem investigation, Service Request, Incident
Daily kaizen, 7 step problem solving


Summary
In this article, I have lightly covered continuous improvement in Agile, ITIL and Lean. Please use the references provided to learn more about these approaches in greater detail. As shown immediately above, each of the three (3) methodologies provide instruments to scale for the size of the continuous improvement event. 

 ITIL and Lean both utilise a systematic approach to continual improvement and problem solving based on Deming's Plan, Do, Check, Act cycle and therefore it is not surprising that Lean and ITIL compliment each other and are similar in this area. Agile does not appear to have the same systematic approach to continuous improvement but the problems or opportunities for improvement identified in sprint retrospectives could easily become the inputs to ITIL's/Lean's seven (7) step problem solving process. 

For large IT organisation's, the decision is not ‘Which one should I choose?’ but rather 'How can I integrate these approaches to provide the most effective and efficient continuous improvement service for my customers?'
References
Bell, S., and Orzen, M. (2011). Lean IT, New York: CRC Press.

 Cabinet Office (2011). Continual Service Improvement. London, UK: TSO.

 ITIL V3 CSI - Continual Service Improvement (n.d.). Retrieved January 28, 2013 from
http://wiki.en.it-processmaps.com/index.php/ITIL_V3_CSI_- _Continual_Service_Improvement

 Liker, J. (2004). The Toyota Way, New York: McGraw-Hill.

 Principles behind the Agile Manifesto (n.d.). Retrieved January 28, 2013 from http://agilemanifesto.org/principles.html

 Smith, G., and Sidky, A. (2009). Becoming Agile in an imperfect world, Greenwich:Manning.

Popular posts from this blog

Employing value streams in Enterprise Service Management

Image
Introduction Enterprise Service Management (ESM) is the technical extension of pre-existing Information Technology Service Management (ITSM) to other areas of an enterprise (e.g. Corporate or Shared Services). Successful ESM balances efficiencies gained from employing standardised process management, tooling and reporting with the nuances of organisational capabilities such as Finance, HR, Facilities and so forth. ESM leverages the industry proven service management concepts from ITSM that have been available for more than 20 years. Further to this, ESM operations implement similar concepts as ITSM including a service desk for 1st level support, end to end process management, request/issue management software, self-service knowledge bases and more recently chatbots and AI. Value streams are born from Lean manufacturing and comprise of a series of steps an organisation undertakes to create and deliver value to customers, typically in the forms of products and services. In the IT co
Read more

Using the Lean Canvas for an IT solution proof of concept

Image
I was assisting a client with sourcing some new IT solutions. For one particular IT need, the client had shortlisted a potential solution with a trusted vendor but they needed to explore the potential solution further to understand its capabilities in more detail. They were unclear as to whether they should directly source with this vendor or go to the wider market (with a Request for Proposal (RFP)) to address this particular need. Further to this, it was unclear how long this project would run for so it was important to understand the time and effort that may be involved without consuming too many resources.  The client was seeking to employ a specific approach for this potential solution, where a “fail fast” lean Proof of Concept (PoC) would be conducted to rapidly test whether the potential solution was fit for purpose without spending unnecessary time and effort required to conduct a RFP. To start, we confirmed the following principles to guide the PoC: Do not develop
Read more

Seamless and scalable IT major incident management

Image
As digital transformations continue to be implemented and business value chains become even more dependent on IT services, the impact on businesses and communities arising from unplanned outages continues to rise. In conjunction with this, organisations are experiencing a rise in cybersecurity attacks (Seals, 2017) placing further pressure on the availability of services and endangering the customer experience and loyalty.  IT organisations are seeking to understand how significant, wide-ranging business impacting incidents (especially cyber-security incidents) can be better managed and in particular what the role of the IT Major Incident Management (MIM), Security Operations and IT delivery teams should be during such incidents. To further complicate this setting, enterprises may employ numerous incident management processes including Risk Management, MIM, Information Security Management, Crisis Management, and Business Continuity Management. Each of these processes employs varyi
Read more