The IT Skeptic - Comments for "Six Tactics for ITSM to Deal with Agile "

a matter of policy

skeptic — Tue, 05 Jun 2012 07:21:06 +0000

As I keep saying I don't mind if the new models win. But the competition should be judged by the governors of the organisation as a matter of policy. It is not some business unit's or dev team's call.

The number of nines are diminishing

aroos — Tue, 05 Jun 2012 06:15:52 +0000

Like Kaimar, I have seen these new models working. I have also worked in a corporation where IT wanted to control the corporate information. The problem was that the information was not where the corporate IT wanted it to be.

If a new model is significantly more efficient, it will win. The new support number is 1 million customers per one support person.

Aale

we can still learn

kaimar — Tue, 05 Jun 2012 05:34:54 +0000

Both of the real assets you mention are taken care of - and much more so - in the new model. Cloud is not about the technology (well, it is, but this is just one side of it) but about the way the reliability, availability and consistency of *real* assets can be increased. Agile is not about technology but about how to meet the business needs in a more flexible manner while the data is protected and the ability to interact with it is kept at a high level.

I'm not saying all companies should move to the new model - it is not mature enough yet. But - it probably makes sense to take a look at the new model and think about why it works for those using it. And then take some of its elements and apply it to the *traditional* model, which for many consultants is ITIL + Cobit + various other sources of good information. Agile and Devops provide concepts that can, after a proper carwash, be added to this list.

the other 99.999%

skeptic — Mon, 04 Jun 2012 21:58:35 +0000

Sorry but I address this blog to the other 99.999% of organisations. The future is all very exciting but we have a job to do right now. Attempting to structure the other millions of sites to have open walls right now just because a tiny tiny minority have decided to take that risk is irresponsible in the extreme.

We appear to be talking about different assets. IT technical people need to wake up to the fact that all our technology is not the real asset: the corproate information and the corparate ability to interact with that information in transactions - those are the only assets that matter. Cloud is just twiddling with the underlying layer we build to look after the data and enable the transactions. it has little significance for the assets that matter.

new castles without walls

kaimar — Mon, 04 Jun 2012 21:07:31 +0000

In some companies, there really is no wall. Never has been. There is no Dev and Ops, there is not even a DevOps. There is Continuous Deployment with Test in Production. Yep, there is no stable production environment anymore. And the customers are happy.

Some companies are moving towards this.

And in others - in most, I would agree with you - the wall is still there. Cloud is making the transition to wall-less world somewhat easier, a long list of 'traditional' IT assets can be replaced with a shorter one, of which a big part is "I don't really care as long as it works" type of assets.

Configuration Management is less and less about the attributes of the hardware used, while more and more about auto-discovery and relationships. One might argue that this is exactly what CM was intended to be, in relation to asset management.

I find that a lot of the "ITIL does not work in the new era" discussion is based on these examples. The % of companies living and breathing Agile is perhaps 0.001% and I might be mistaken a thousand-fold. But they are there and they have shown it can work. On the orders of the king, i.e. the Business. Which is sort of an obsolete distinction as everything is Business there. Except maybe for the ... no, everything.

One of our tasks, as I see it, is to ease the transition, while accepting that not all that has been was the preferred end state, but rather a step in between.

the fort walls are still there.

skeptic — Mon, 04 Jun 2012 17:48:00 +0000

To continue your analogy, the wall has not gone. Most organisations still have a stable and secure production environment. Small wild hordes have managed to pull a few stones out. Certainly they are plotting more concerted assaults in some companies, but mostly no.
And they are certainly not acting under instructions of the king. The governors in many organisations are fiddling in a remote tower, oblivious to the risk or the needs of IT. Hence my other analogy, the failing parent.
I tire of this apocalyptic view that all the foreseeable consequences of SoMoClAg* have already happened: no they bloody haven't. The effects are just starting to show and there is an awful lot we can do before (and if) the world changes. Your personal in-hand IT experience may have been transformed but don't confuse that with the business IT condition, which is much slower to change because of my favourite point: we own the existing legacy assets, which contain value and must return that value on their investment. I'm amazed the number of people who don't get that simple business principle.

*I got SoMoCl off ITSMWP, I think it is Matt Hopper's. SOcial, MObile, CLoud. I just added the "Ag".

Everyone holds up the

skeptic — Mon, 04 Jun 2012 17:34:11 +0000

Everyone holds up the bogieman threat of outsourcing. I think the world is slowly maturing to understand that outsourcing is no cure for dysfunction.
And if tactics 4,5 and 6 aren't Operations being responsive, I dunno what is.

If we are going to accommodate Agile we certainly are going to risk our operations, or more precisely we aRe going to risk what operations has stewardship of: the organisation's informational assets. Increased volatility and decreased planning and testing must increase risk. It is fundamental. All I ask is that that risk taking be an informed decision by the governors, not by a bunch of idealistic code hackers and a service owner in a business unit.

Balance

Ben Vaughan — Mon, 04 Jun 2012 13:07:50 +0000

The balance is being lost on both sides.

Yes, developers don't see the need for operational stability, but Operations doesn't see that a business standing still is a dead business.

IT can't be the stick in the mud that drowns the business when the tide comes in, all in the name of operational stability.

The Agile and DevOps movements are an attempt to respond to the ever-increasing pace of business and economic innovation. They have the right of it, just as much as those of us who adhere to ITIL/ITSM philosophies.

We had better have a good, long look at what is happening over in Agile-land and attempt to move in that direction. We do not need to risk our operations, but we do need to figure out how to be more responsive to the needs of our business partners.

Or... we will find ourselves outsourced.

There is no wall

kaimar — Mon, 04 Jun 2012 12:53:48 +0000

Some to many to all controls, depending on the specifics of the business, are outdated. Defending the fort from the watchtowers when the walls have been removed by the king. Ask the king for renewed instructions.

no accountability without authority

skeptic — Mon, 04 Jun 2012 12:15:46 +0000

David Moskowitz made a good point to me on twitter:
This isn't about Agile per se. It's about any attempt to wrest away the controls we have put in place to protect the corporates assets that we have been entrusted with. It's our job dammit. We in operations are paid to protect the existing value of information and technology, as much as we are paid to empower new value from it. Developers lose sight of that balance.

automation

kaimar — Mon, 04 Jun 2012 04:46:00 +0000

Automation in today's continuous deployment / agile / devops world is not "just a tool". It is a mindset, adopted by all parties involved, supported by tools. At least if done properly. Manual meddling with the prod environment is an exception.

The same way as ITSM is not just a tool, but if it is treated so, the results will be less than impressive.

bridging the gap

skeptic — Sun, 03 Jun 2012 21:52:56 +0000

Dunbar's Number tells us you can't have one group of humans in a large organisation: they will always self-organise into groups. There will always be divisions. We can't all be one big happy peace-love-dope family. In most communities we take advantage of this to get people organised into specialist sub-groups: companies, departments, teams. We leverage it. Trying to get all of IT into one Agile-based team is not going to work above a certain size. You won't be able to find the multi-skilled people, and you won't be able to hold the team together. "You guys work on the code, we'll look after the infrastructure" is only weeks away from reverting to the status quo.

hence Operatinal Readiness as an essential practice: it bridges the gap. And it does it in a formalised managed manner.

Human nature being what it is, I see no problem with being defensive as well as collaborative. There is no place for blind trust or assuming the best in people in any effective risk management.

We shouldn't approach Agile too defensive

Dave van Herpen — Sun, 03 Jun 2012 06:43:31 +0000

Thanks for this essential blog post, Rob.The reason this topic is on my mind is two-fold. First, I see lots of organizations struggle with aligning their operations to agile development teams. Second, I strongly believe we (whether we are responsible for operations, or IT management, or application management) can benefit greatly from agile methodologies and principles. I see your tactics 4, 5 and 6 appeal to the required, more intensive collaboration between operations and development. I very much agree with this need. We can no longer treat dev and ops as two separate entities. I believe we even should envision shared agile teams across development AND (application) operations and maintenance. I think visual management tools and techniques ( eg. Kanban) can be of significant value in achieving this collaboration.

Your first 3 tactics, however, are too defensive in my view. They origin from a lack of trust in the quality of the IT deliverables resulting from the agile teams. Ring-fencing and getting waivers are only bandaids. Instead we should learn from the best practices which have succesfully increased the quality of the agile products. Key is to focus on customer requirements (product owner), but also include operations' insights from the early start of agile projects, so essential requirements from "our" perspective (stability, performance, maintainability, etc) are included in the design and eventual products. After all, it may be crucial for operations to enable fast delivery and short time-to-market, it is still our job as well to keep the lights on......