The IT Skeptic - Comments for "Agile ITSM"

Growing list of free Tipu resources for all the ITSM philosopher

skeptic — Fri, 28 Oct 2011 05:24:00 +0000

There are now a number of free resources available on my Tipu website including

Executive summary
Why Tipu?
The Tipu Framework

All the ITSM philosophers who follow this blog will be interested in the last one: the Framework attempts to be more complete than ITIL or COBIT. I started a new post so you can all comment there

A Tipu book will be out before Christmas!

Like any social science, IT

skeptic — Thu, 15 Sep 2011 19:12:04 +0000

Like any social science, IT is hard to empirically measure.

Companies are performing the experiment but both sides will claim success

After 20 years we still can't agree ITSM is a good idea.

good subject to empirical testing

Charles T. Betz — Thu, 15 Sep 2011 17:42:33 +0000

Well, this would all be quite suitable for empirical testing, if we could get at the data we need. Either change is perfectly negatively correlated with stability, or it isn't. If it isn't, perhaps there is a dynamic model that would bear further elaboration.

I didn't feel you misquoted me.

Charles T. Betz
http://www.erp4it.com

cute phrase

skeptic — Wed, 14 Sep 2011 19:58:00 +0000

I'm aware of that principle "to reduce the risk from change, you should practice it more.". I'm reminded of some of the ~~exciting new discoveries and principles~~ cute phrases from other ~~radical movements~~ bubbles which all boil down to "the old rules don't apply any more". Almost invariably they do and a crash ensues.

One old rule is that the faster the rate of change the harder to keep the system stable. Think automatic trading systems.

And in all those bubbles, there are case studies that apparently defy gravity. Like all magician's levitations, there is more to them than meets the eye and they don't stand close examination which is not provided. I wrote vendor case studies and business cases for years. I know how easy it is to create an illusion, especially one that the audience want to believe.

P.S. sorry Charles I didn't mean to misquote you - I should have read down the comments. What I do in that case is [update] the original post to flag the comment.

bad habits

skeptic — Wed, 14 Sep 2011 19:49:22 +0000

Good point. It depends what you mean by "change". Yes you cannot readily transform a culture but you can make minor adjustments - as you say, correcting bad habits.

Coda to that post

Charles T. Betz — Wed, 14 Sep 2011 15:26:57 +0000

Hi Rob,

That post generated some discussion

http://www.lean4it.com/2010/01/agile-it-service-management-why-its-an-ox...

and I've had some second thoughts about it as noted in the comments. In particular I'm thinking a lot about the DevOps challenge that change and stability are not zero sum and to reduce the risk from change, you should practice it more.

Charles T. Betz
http://www.erp4it.com

Don't try to change the culture

aroos — Wed, 14 Sep 2011 12:49:27 +0000

Tipu's #2 is unrealistic. One consulting project will not change the culture. That will not work and I don't think you really mean it. Companies have their culture and that will not change even if you change the way they work. A successful, cheerful, creative company will have successful, cheerful and creative processes. A pedantic, careful, formal company will have pedantic, careful and formal processes. Both solutions may work quite well but they will be different.

I suppose you really mean that you need to try to change some bad habits. That is a hard but realistic goal. For example; many countries have banned smoking in public places. It has worked surprisingly well and many people have quit smoking but it has not changed the culture of the countries or of the people.

Aale

Agile ITSM

skeptic — Wed, 14 Sep 2011 10:17:07 +0000

I don't know why I didn't search "Agile ITSM" when I first wrote this post, but I didn't. I'm not trying to "own" that phrase. Anyway I finally did, and found a DITY newsletter I had missed first time round, from David Nicholl, where he has this to say

Adapted for ITSM, its guiding principles are:

Continuous delivery of improved processes
Working processes are delivered frequently (weeks rather than months)
Working processes are measured by achievement of desired outcomes
Changes are incorporated as they come up
Communication is primarily face-to-face
Process implementations are built around motivated individuals who are proven to be trustworthy
Continuous attention to good design and professional capabilities
Simplicity
Self-organized teams
Regular adaptation to changing circumstances

Yup, exact match to Tipu!

And I found a post from Charles Betz on his ERP4IT site which had me worried that we were going to agree to disagree again when he said

Agile IT Service Management: Why it's an oxymoron

uh oh! But in fact he was not writing about implementing ITSM using agile methods. He was referring to ITSM used to manage agile software development, where he and I are in complete agreement

Complex systems are prone to emergent chaotic dynamics, and change is the enemy (whether labeled "Agile" or not). That is invariant in any systems engineering, with theoretical foundation in Turing's proof of the insolubility of the Halting Problem along with much other math & science. Test-first development, while an excellent practice, does not solve the Halting Problem. You cannot test all paths, and the more extensive the testing harness, the more invested in it, the less the agility. Re-factoring, while another excellent practice, cannot be construed as risk-free. Any new execution path has increased probability of failure. And no reliability, no service, no Agile ITSM.

With respect it is... agree to differ

ianclayton — Thu, 21 Jul 2011 21:49:53 +0000

If you are focused on the service, process, practice, infrastructure, procedures, policies and so on - you ARE inside-out - period.

Outside-in thinking STARTS and stays with the customer/consumer side of things.

So doing less of anything I listed and any other words generally NOT in the customer lexicon, is inside-out unless it has been previously determined it will improve the customer's lot and is driven by a customer reason. To your equation...

The customer wants to achieve outcome "A"
The customer performs an activity in pursuit of A, termed "B"
In performing the activity the customer uses products and services provided by "C"
The customer interacts with the product/service and/or "C" and drives work effort within "C"
The customer experience interacting heavily influences their level of satisfaction regardless of the result "D"

Problems define issues with any and all of the above, improvements recognizable to customers must affect "A", "B", "D"
Improvements that are positioned against "C" alone are vulnerable.

CSI is inside-out as it has the word service embedded within in and by the widest of ITIL definitions is focused on the service lifecycle stages.

What we need to focus on is generic continuous improvement principles, more in line with 70 year old concepts and methods well known to the business rather than introduce an IT (ITIL) sponsored term...

process vs practice

skeptic — Thu, 21 Jul 2011 05:16:18 +0000

We are just talking semantics. I hate the word "process". A process has inputs, outputs and a defined repeatable sequence of tasks. The outputs are predictable given the inputs. That describes a tiny subset of service management activities. ITIL and COBIT abuse the word horribly.

I unilaterally use the term "practice", as in Incident Management Practice (and as in "best practice" and "good practice" and...). A practice includes policy, plans, goals, roles, responsibilities, activities, yes processes sometimes, metrics, tools...

but

Tom Rankin — Thu, 21 Jul 2011 04:47:12 +0000

I agree that the process is the cart, not the horse, but Good Process can underpin/support good Work Practice. Process should connect work practices. Maybe we're just talking about semantics here - violent agreement...

Quite the opposite

skeptic — Thu, 21 Jul 2011 03:03:58 +0000

"Doing fewer processes or less of each process are both inside-out. " Not they're not. Quite the opposite.

The value we are asked (or propose) to produce is A
Therefore the business goals are B
Therefore the IT outcomes required are C
Therefore the outputs to be produced are D. These outputs come from ~~processes~~practices E F and G, specifically the following bits of those practices....

By breaking it down into ONLY the bits that compose a solution to deliver to a customer-focused business value, rather than working on a whole practice for its own sake, we are doing exactly what you preach: starting on the outside and drilling in, focus on demonstrable value.

"abandon ITSM/ITIL 'projects' and move gently to a continuous improvement program" what's that if it isn't CSI?

Might still be inside-out

ianclayton — Thu, 21 Jul 2011 01:15:25 +0000

Tom, Skep, correct me if I have misread the program. But using CSI and focusing on dismantling 'processes' into bite size chunks both invite inside-out thinking. As I commented below - I encourage everyone to abandon ITSM/ITIL 'projects' and move gently to a continuous improvement program approach with as Tom suggests problem management SKILLS at the core. Not ITIL's problem management - it does not work, subject to Edition 2011 updates. There are three major flaws I will not go into here. Forget processes - they are offline specifications to reference. Focus on customer situations and your response.

Find out how you help customers succeed and what they do that causes your work effort. Enough said, else I'll be basically doing an advert and explanation of my six step program for Enable Outside-In Service Management! Doing fewer processes or less of each process are both inside-out. Good luck Skep - steps in right direction.

Makes perfect sense

Tom Rankin — Thu, 21 Jul 2011 00:30:28 +0000

First thing I thought of when reading this was "try something different to get a different result / definition of insanity thing".

This seems really well thought out, but you're (we're) going to have detractors who are threatened by the accountability that is implied or directly stated in the outline. Do ITSM SW vendors really want their customers putting some science & accountability behind value, risk and return? Do ITSM consultants want customers taking charge of their own destiny and chip away gradually?

The 12 principles are excellent.

For what it's worth, I think that CMM measurement isn't completely useless. It can provide some common language, ask some pointy questions, get some discussion happening and should flesh out where the focus is on the "usual suspect processes" (Incident, Problem, Change) and reset towards a more balanced view - with the business at the centre of the ITSM universe. Maturity improvement is not a bad thing in itself, so long as some arbitrary CMM score is not the end game. How "mature" is mature enough? Well I guess revert back to value/risk/return as your non-negotiables.

I'm a firm believer that CSI drives a better culture and vice versa - funny that it is a bookend on what most people learn on their ITIL training. Presenting on that belief @ ITSMFA in Perth next month. Curiously, one way I've tried to get this moving is to draw on Problem Mgt techniques and focus on human issues/opportunities, with customer at the centre. Am glad that some threads of thought in the other comments are in the same ballpark as mine.

But, goodness, it is very hard work. Kotter's "Buy-in" book/blogs are good sources of encouragement with the occasional "Oh crap - I went about that the wrong way". Live & learn.

Welcome

ianclayton — Wed, 20 Jul 2011 20:25:29 +0000

Rob

Welcome. For a while now I have been using a very simple customer focused program to help IT organizations define a problem, and make it go away. Timeboxed to a 30 -day cycle as Jim endorsed, it forces IT folks to think customer, and respond in bite size responses.. The problem management skillset if vital in defining the problem in such a way as to get support for change. I too regard smaller silo/process styled 'implementations as flawed and naive. They are inside-out and will fail the customer.

The more of us that trumpet the need to focus on what the customer recognizes and places value in - their ability to perform vital mission activities (USMBOK), and for a service provider to unde3rstand how they support that effort, and to apply improvements where these two meet, is vital to the very survival of the ITSM brand name.

Good luck with your program.

Agile ITSM

Marek Ujma — Wed, 20 Jul 2011 11:40:04 +0000

I have been working in IT for more years than I care to remember! My father was a programmer in the 1950s and in the latter part of his career he was an Ops Manager. He was one of the first to write Ops Procedures that really worked for his computer centre. I have been working in the area that is now called ITSM since the mid-1980s and developed lots of good practice way before ITIL appeared. I kind of liked the first publications (although too focused on public sector, rightly so as that was the first thrust). The second version was really getting there and so were its associated qualifications. V3 and probably ITIL TNG encompassed not just ITSM, which is primarily operating/managing services, but also the Strategic and Tactical layers of the service lifecycle. V3 (and its qualifications) was flawed as it did not focus on realworld needs. It has lots of detractors but a lot of the stuff in it has survived since the first publications because it works.

Preamble over!

I basically agree, from all my experience, with what you say. Ultimately KISS, focus on real needs and real business (not just IT) benefits, work with your customers and suppliers in an open and constructive way. Also deliver in manageable chunks (time boxing) and checking that what is delivered means requirements, tweak where needed. So use bits of ITIL (incidentally it's a library of publications so is already implemented), MOF (nicely written and copyright free), COBIT, Lean, Six Sigma and all the other methodologies as needed. Finally, key for me is clear, committed, persistent leadership at all levels (walk the talk). Also required is an appropriate level of skills to deliver and operate so training is key, not just technical but also in general management techniques. Always aim for perfection so continuous (not continual) improvement must be part of the culture of the organisation.

Maybe 'Agile ITSM' should be called 'Nimble ITSM', but that could be confused with a brand of bread!

Nothing new under the sun

JamesFinister — Wed, 20 Jul 2011 10:18:12 +0000

Rob,

To be honest, that is just what some of us have been doing for years. You can even trace it back to the Stadia model used by Quint Wellington Redwood when I was with them many many years ago

In my experience timeboxing is the critical thing to enforce.

The missing element needed to make it work is the management of the stakeholders and, for goodness sake, don't let a conventional project manager anywhere near it.

But I heartily agree it is the most effective approach to take.

BTW I presume sheer coincicdence that TIPU = The Invisible Pink Unicorn and it isn't meant as a comment on the number of ITIL "implementations" seen in the real world ?
James Finister
www.tcs.com
http://coreitsm.blogspot.com/