Practitioner Radio 40 - Using Agile / SCRUM for ITSM Projects

Troy DuMoulin, VP Research & Development | April 18, 2013 | 4 comments

Sometimes Rapid Incremental Improvement is More Important Than Game Changing Transformation At Pink my team and I have the privilege of having several conversations a week with customers who want to improve their ability to deliver customer value via improved practices. However, before offering advice we have learned that it is important to ask questions and listen carefully to how organizations want to improve. For example: In many cases the company we are talking to has a time sensitive goal of moving everyone in IT off a current tool or should I say collections of processes and tools onto a common process and 1 new ITSM tool in as short a time as possible. No matter how you look at this type of goal it represents a Major Transformation that will mean significant and rapid change for everyone within the scope of the project. However, there are times where the focus is on achieving rapid incremental improvements (Quick Wins) focused and prioritized based on the "Customer Value Perspective" not internal IT efficiencies or major systems upgrades. In the latter example a more Agile approach to change is perhaps a better fit. In fact the this scenario is a perfect fit for an AGILE / SCRUM approach to Process Improvement. Join Chris and I in this episode of PR Radio where we look how organization's can leverage this popular development and project methodology in respect to ITSM Projects.

 

NOTES:

  • Pink-washed: overwhelmed, fun
  • Scrum in 10 minutes video
  • Scrum is a development methodology
  • Agile is a principle in product development that looks at short sprints to get small packages print or production ready
  • TLC told us in the 90's - don't go chasing Waterfalls!
  • Prince2 says check back every big block but Scrum focuses on even smaller sets of tasks — sprints and releases
  • Figure out your release then evaluate
  • User stories drive product backlog and wish list
  • Daily meetings — Kanban /scrum meetings
  • Easier to measure success - quantifiable
  • Focus on value — outcome for customer. What have you done for me lately?
  • Prioritize tasks by customer need / pains
  • Voice of customer is not usually a natural skill for IT people
  • Outside-In thinking
  • Assessment and recommendations should be written with customer in mind
  • Look at short term, mid-term and long term releases
  • Transformation is very different to incremental improvement — transformation is about fast, over-arching change, whereas incremental improvement is about getting better by making small changes
  • Design, build & deploy in pieces rather than all at once
  • Suits our ‘distracted' society. We're all in constant change
  • Different people suit different methodologies — not necessarily either / or
  • A sprinty spark (or a sparky sprint) can get you moving
  • If it's not about the customer it's a waste of money
  • See book Run, Go, Transform
  • Dev and Ops aren't used to thinking about end customer value — more asset optimization
  • Could apply Scrum to personal human objectives
  • Do we consider ourselves when putting customer first?
  • Moving the family across the country is a transformation — moving schools, new house, address changes, insurance, jobs etc everything pretty much has to be done all at once. It would be possible to do it incrementally but it would take a lot longer. Some things are not suited to scrum approach.
  • Scrum is good when you have little budget — make small changes you can do yourself, bit by bit, build momentum as it proves value and get buy in

Troy's Thunder Bolt Tip of The Day: consider using an agile scrum methodology to achieve your continual service improvement goals, especially when you're after incremental improvement Troy's and Chris's Thoughts What Are Yours? We must not, in trying to think about how we can make a big difference, ignore the small daily differences we can make which, over time, add up to big differences that we often cannot foresee. ~Mariam Wright To subscribe to Pink's Podcasts on iTunes

Like this article? Like

View Comments (4)

Comments

Hi Troy

You’ve inspired me to do Tipu 2.0, to more strongly align it with Agile/Scrum terminology.  Tipu is exactly this: an agile ITSM improvement methodology.

A couple of thoughts: 

1) the key to Agile is being able to deploy.  Banging out the code is the easy bit, testing and rolling it out is harder.  Hence DevOps.
A critical success factor for DevOps is automation.  You can’t automate change to people and process.
The human rate of change is way way longer than the technology rate of change, and it can’t be sped up by automation.  So beqware of settign expectation that the success of Agile can be translated to ITSM.  My experience with Tipu was that a human “sprint” is about 3 months, especially if you are going to do them repeatedly, which is kinda the point of it. 
IOt’s not the issue of how long it takes to dream up the improvements; it is the group’s capacity to absorb constant iterative change.

2) I don’t think customer value is a valid metric for planning what we do.
http://www.itskeptic.org/content/its-not-anti-customer-realise-they-are-not-be-all-and-end-all-it
Tipu uses ORGANISATIONAL value and risk as the two key metrics driving decision-making.  If I ever do a 2.0, I’ll peel compliance off from risk as a third metric.

Rob England

Rob England (IT Skeptic) | April 18, 2013 at 9:04pm

Hello Rob, I acknowledge that your Tipu model is indeed focused on getting value quickly thus a great candidate to use to flesh out Scrum Sprints for specific areas of practice.

http://www.basicsm.com/tipu

Rather than “Customer Value” the concept of SCRUM User Stories would also cover things such as the need to achieve compliance or mitigate risk. These are basic User Stories like the Herzberg’s Motivators.

Troy DuMoulin, VP Research & Development | April 22, 2013 at 4:31pm

Comment on Rob’s comment - Agile tends to fail if deployed stand alone.  My experience is that its a useful element in a blended improvement approach.  It doesn’t need ITSM - in fact the issue here is Management 101 disciplines within IT.  No magic in Agile - we used 30/60/90 day rule in product management - the actual origin of agile thinking…

Troy - thanks for the prompt to post a connection to the Lockheed Outside-In experiences.  readers interested in more information can download two articles at my website here:

http://www.servicemanagement101.com/index.php/easyblog/entry/the-lockheed-outside-in-experience

The reactions within Lockheed’s itSM office were a result of the tabletop ‘simulations’ we run when exploring universal service management, outside-in, performance management, agile/lean continuous improvement and service experience design…. quite a combo but a throughly enjoyable gamification of things…

Ian Clayton | May 3, 2013 at 8:02pm

There are situations where organizations have time-sensitive goals of transitioning their entire IT team from current tools and processes to a common process and a new ITSM tool as quickly as possible. This represents a major transformation that requires significant and rapid change for everyone involved. However, there are also times when the focus is on achieving rapid incremental improvements, prioritized based on the customer value perspective rather than internal IT efficiencies or major system upgrades. In such cases, an agile approach, specifically Agile/Scrum, can be a better fit for process improvement.

Victor Patrick | June 8, 2023 at 9:25pm

Post a comment