Darwin doesnt justify change

monkeyI heard this one again recently: "survival of the most adaptable". To be clear: Darwin did NOT ever say "It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Because it is NOT true. Change is not essential and it certainly isn't always a good thing.

Agile is an excuse for chaos?

I tweeted a while ago "Agile is an excuse for chaos in the same way ITSM is an excuse for bureaucracy", i.e. it isn't. But if it's done badly it is, and that's how opponents unfairly characterise it (equally true for Agile chaos or ITSM bureaucracy).

DevOps Unicorns Horses and Mules

DevOps folk use the terms "unicorns" and "horses" as if everybody understands what they mean. Quite possibly you don't. So here's the gist:

Axelos announces a new level of ITIL certification: Practitioner

After my dark forebodings about a potential squeeze on ITIL in 2015, Axelos' first(?) ITIL announcement of the year seems a good idea: yet another level of ITIl certification, the Practitioner.

Windows vs cars

Here's an oldie but a goodie, made particularly salient as I wrestle with my first experience of Windows 8 on my new laptop (what a howling dog it is: a clumsy kludge of a skin, shoehorned onto Windows 7) .

At a COMDEX, Bill Gates reportedly compared the computer industry with the auto industry and stated,

In praise of ITSM engagement models

When establishing the relationship with an external service provider (outsourcer), why do we document a whole operating model spanning both organisations? The whole point of outsourcing is that the supplier should be a black box, with inputs, outputs and performance requirements. What we need to define is the interface between the two entities, to ensure the operating models of each one mesh properly together. Define the connecting cogs, or the plug-and-socket - choose your analogy.

This is more efficient: we don't redundantly document processes which already exist, and are documented elsewhere. It is more effective: we focus on the gaps, specifying the requirements for change in each organisation in order to connect their operating models.

It seems this is pioneering stuff: there is very little published on what an engagement model should look like or how to develop and use it. So I built one.

The design police at Google say they'll push this site down the search rankings

This website has been told if I don't redesign it I will be punished by Google's search engine. #mobilegeddon

what makes a successful blog

While The IT Skeptic is not a hugely popular site I think it's fair to say it is a successful one. Certainly some people seem to think so: I'm often asked to comment on others' blogs or advise how to go about one.

The first question is why you blog; and hence what defines success for the blogger.

A blog serves any of three purposes:
To communicate/share.
To record ideas.

DevOpsRun: DevOps is great but what about Run?

Is there a bigger picture than DevOps? (I defined it here). In theory no, it encompasses the whole IT lifecycle of services. But in practice it seems to me much DevOps discourse is still Build- and Transition-centric. We can expand thinking to all of DevOpsRun.

Service Portfolio Management is more important than programme or project portfolio

There is a wonderful insight in ITIL that is seldom noticed and even less often understood

It is Service Portfolio Management (SPM).

Syndicate content