Devops and the ITIL framework

[James Bailey]

Hello all,

Having a series of conversations with a friend about a new business
venture he is setting up offering IT managed services, he is non
technical ITIL certified and very keen on using it's framework. My
questions are does it play nicely with the devops model or are the two
mutually incompatible?

My personal experiences of ITIL is it is a management tool to bring
"order and control" to IT help desks and is rigid, bureaucratic and
support centric. However the companies where I have used it have not
been paragons of organisational efficiency.

Regards Jim

[patrick.debois]

I've did some research a while on that, and I have no reason to find
ITIL blocking for the devops model. (if there is one ;-)
As ITIL is a set of guidelines, to make them work they need to be
interpreted. My personal experience with ITIL is also one of rigid
'order and control'. My assumption is that is a result of the
traditional 'Waterfall' and Silo based approach of organization. There
is nothing wrong with concepts as a Change Advisory Board, as long
everybody can have its saying. CMDB is a good idea to keep a good
inventory on everything running. Or doing risk analysis to see the
impact on things. A good practical guide for change management is the
visible ops book. http://www.itpi.org/home/visibleops.php

ITIL v3 is also evolving to handle more frequent releases, based on many
of the Lean/Agile concepts introduced by Toyota. It feels the need to
come closer to the applications and take an inspect and adapt approach
to do continuous improvement. Still I see ITIL v3 being introduced as an
upgrade to ITIL v2 without the mindset change. So what if you think CAB
as kind of group decision, or CMDB evolving towards a declarative way to
define your systems instead of the traditional out of sync inventory way.

I know there is more to ITIL then just these aspects. For a sceptical
view on ITIL you might want to look at http://www.itskeptic.org/

In summary:

"It Ain't what you do (be it ITIL or something else) , It's the way that
you do it (small changes, communicate about them , group participation)"

Patrick

P.S. You can find some more reading links I've collected:
http://delicious.com/jedi4ever/collection-devops+itil?setcount=50

[Alexis Lê-Quôc]

I see ITIL as a common vocabulary and a way to make sure that all areas of sysadmin'ing are covered (incidents, change, problem, etc.) The problem that I have with it is that, because it tries to be a comprehensive taxonomy of IT Ops it promotes a culture where using the right lingo is viewed as more important than solving real problems; a bit like the XML craze of the late 90s.

--
Alexis Le-Quoc

[Marcel Wegermann]

James Bailey schrieb:

Hi Jim,

If I understand ITIL right it means "no ticket - no service". This would
be against "agile" thinking.
"Individual and interaction over process and tools" of the agile
manifest means that I do (comminicate) all that is necessary to solve a
problem/task.

As a agile admin I try to see the whole problem and focus on getting the
things done, not managed in a bug tracking tool.

If ITIL makes me slower I try to find a better way to hold the system
stabil and running.

Easy to say, hard to do in real life :-)

Cheers,
Marcel
> Regards Jim
>
>

--
F�r Texte mit Stil! www.stilversprechend.de
F�r Terminabstimmungen! www.werkannwann.de

[Scott Smith]

Marcel Wegermann wrote:
> If I understand ITIL right it means "no ticket - no service". This would
> be against "agile" thinking.
> "Individual and interaction over process and tools" of the agile
> manifest means that I do (comminicate) all that is necessary to solve a
> problem/task.
>
> As a agile admin I try to see the whole problem and focus on getting the
> things done, not managed in a bug tracking tool.
>

Hm. In agile development the bug tracking system is tightly coupled with
the project management process itself. I see no reason as to why this
should not be the case when implementing any "agile" methodologies as a
sysadmin. Without tracking the amount of interrupt-driven work I am
doing, how can I measure the velocity of my project-based work?

I must say also that using a ticketing system with Scrum or Kanban gives
my management and peers a lot more visibility into not only the amount
of work I am doing but also the exact amount of time it requires. No
more underestimating the time or resource requirements. :)

Personally, I'm in an ~20 person IT team composed of sysadmins, neteng
and DBAs, and also a member of two functional product-based teams. Not
tracking my work through a ticketing system would be a nightmare!

-scott

[Andrew Hodgson]

Absolutely agree with this. We've recently started implementing scrum
and the difference is amazing. More visibility for the biz, and
discrete stories really help break down the "amorphous ball of work"
feeling endemic to ops. Even with issue tracking the feeling
persisted, for us anyway.

It's funny this thread came up, because just today I was advocating
Visible Ops to my manager. I picked it up about 3 years ago, thought
it was a great read, but found it hard to get into company practice.
As we grow this kind of structure is essential to be an effective
operation. I mean, this stuff has been pulled out of real-world teams
that deliver great service, so it's probably worth at least being
aware of.

Perhaps the most scary part of VO for business stakeholders the first
step - "stabilising the patient". All changes are frozen outside of
maintenance windows until a clear change policy is established.
Perhaps a biz equivalent of cold turkey. :)

Cheers,
Andrew

[Marcel Wegermann]

Scott Smith schrieb:

> Marcel Wegermann wrote:
>> If I understand ITIL right it means "no ticket - no service". This
>> would be against "agile" thinking.
>> "Individual and interaction over process and tools" of the agile
>> manifest means that I do (comminicate) all that is necessary to solve
>> a problem/task.
>>
>> As a agile admin I try to see the whole problem and focus on getting
>> the things done, not managed in a bug tracking tool.
>>
>
> Hm. In agile development the bug tracking system is tightly coupled
> with the project management process itself. I see no reason as to why
> this should not be the case when implementing any "agile"
> methodologies as a sysadmin. Without tracking the amount of
> interrupt-driven work I am doing, how can I measure the velocity of my
> project-based work?
> I must say also that using a ticketing system with Scrum or Kanban
> gives my management and peers a lot more visibility into not only the
> amount of work I am doing but also the exact amount of time it
> requires. No more underestimating the time or resource requirements. :)

No tool not means "no tracking". We offen use a flip chart letter to
track the progress. But I didn't mean no tool at all - If you are faster
or have a better throuput by using a bug tracking tool or your team is
located on several locations - of course use it.

But, I meant with my post "not to lay back" if you have no ticket for a
issue.

Cheers,
Marcel

>
> Personally, I'm in an ~20 person IT team composed of sysadmins, neteng
> and DBAs, and also a member of two functional product-based teams. Not
> tracking my work through a ticketing system would be a nightmare!

Yes, true.
> -scott
>

--
Dipl.-Wirt.Inform. Marcel Wegermann
Softwareentwickler

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Gesch�ftsf�hrer: Henning Wolf, Jens Coldewey
Handelsregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon: +49 40 88173-300
Fax: +49 40 88173-333
Mobil: +49 172 410 64 49
E-Mail: marcel.w...@it-agile.de

http://www.it-agile.de

[Carlos Villela]

> If I understand ITIL right it means "no ticket - no service". This would be
> against "agile" thinking.
> "Individual and interaction over process and tools" of the agile manifest
> means that I do (comminicate) all that is necessary to solve a problem/task.

That is to say "tools and processes are less important than
individuals and interactions"; I always found that the right approach
is somewhere around _enough_ tools and _enough_ processes to ENABLE
individuals to interact meaningfully and effectively.

I agree with the rest of the thread, tracking and visibility are super
important when it comes to ensure everyone is interacting and getting
their stuff done as best as possible. What's wrong with a "no ticket,
no service" policy if the overhead of creating and tracking a ticket
is negligible?

- cv

[Scott Smith]

Andrew Hodgson wrote:
> Perhaps the most scary part of VO for business stakeholders the first
> step - "stabilising the patient". All changes are frozen outside of
> maintenance windows until a clear change policy is established.
> Perhaps a biz equivalent of cold turkey. :)

Ha! Yeah, it can seem really freaky. My current job is the first place
that truly enforced such a rule, and I was worried that I wouldn't have
enough to do otherwise.

I found that the proper enforcement of change control procedures (all
changes go through "development" and staging phases, even our own)
actually made my concerns a non-issue. Not only did I have to perform
the work multiple times, but I sometimes found flaws in the
deployment/change plan. (BTW, this is where we can benefit from some of
the ITIL concepts--my understanding of them, anyway.)

On top of that, I think I spend most of my time and focus on the
supporting environments.

Marcel Wegermann wrote:
> But, I meant with my post "not to lay back" if you have no ticket for a
> issue.

Ah, yes :) In that case I typically open the ticket for/with them as
they are standing next to me, or ask them to open and assign directly to
me (if it's not super urgent).

I believe people shy away from ticketing systems because they are used
as a heavy abstraction layer. They don't like to open tickets because
the request will get lost in a sea of other work, etc.

Do you share a similar experience?

(I think Tom Limoncelli's book _Time Management for System
Administrators_ covers this portion of the topic fairly well.)

Also, here's a good related blog post if you haven't read it yet:
http://dev2ops.org/blog/2010/2/23/people-over-process-over-tools.html

-scott

[Scott Wilson]

I actually find ITIL to be helpful in implementing more agile
practices in IT departments, but perhaps that's because I have never
viewed or used it as a rigid framework... I have no problem mixing and
matching, using what's useful and discarding pieces or borrowing them
from other related frameworks. I think it's useful to have a
conceptual framework of operations to be agile _with_. A common
objection to AD has always been that it can simply devolve into a sort
of uncontrolled chaos without some adherence to the basics, and I find
the same is true for operations. You have to stake out your territory
and identify what is important to accomplish at some point. Iterating
and being flexible are of little benefit if you don't understand what
you're iterating toward or flexing for. A lot of IT departments have
their eye off the ball, ITIL helps put it back in play.

That said, I'm well aware that certain sorts of minds are eager to
take any sort of process and turn it into an unthinking bludgeon in
the service of bureaucracy and lockstep order, and ITIL is no less
susceptible to this than any framework. But it needn't be used that
way, and IMHO it can be a good tool to use with agile methods.

I personally think that this becomes a little more obvious to see if
you look at MOF, which is a somewhat simplified ITIL variant with
prettier pictures. It makes the lifecycle aspects of the framework
more clear, and with that it becomes a little more obvious how well it
can work with the iterative aspects of devops.

Cheers,

Scott

[James Bailey]

I find that a ticket will help to keep things visible, I often just do
"quickies" for certain developers. the problem is that quickies often
grow into something bigger or turn out to be a difficult long term
problem. The tickets helps me to keep track of work.

>
> (I think Tom Limoncelli's book _Time Management for System Administrators_
> covers this portion of the topic fairly well.)

He co-wrote "The Practice of System and Network Administration" which
I have used to beat managers and co-workers into something approaching
competence.

I think what I am getting from this conversation is that ITIL and
devops aren't incompatible, just the way it is implemented and the
mindset of certain colleges and managers. I still feel however that
ITIL appeals to a certain kind of corporate bureaucrat. We have had
ITIL service management "imposed" and it is seen as the holy grail by
our central services managers. I have attempted to bring devops and
agile practices into the conversation but the suits are not
interested. However they love the way I work and interact with the
developers and QA team to get the job done. I am praised for my
productivity and they like the tools I have brought to the mix such as
Cobbler and my recent "Cucumber" like monitoring of the site
performance.

Many thanks to all for such an excellent reading list and serious food
for thought.

Peace Jim :)

[Christian Zunker]

Hi everyone,

On Wed, Feb 24, 2010 at 7:37 PM, Marcel Wegermann <mar...@wegermann.com> wrote:

James Bailey schrieb:

...

My questions are does it play nicely with the devops model or are the two
mutually incompatible?

 ...

If I understand ITIL right it means "no ticket - no service". This would be against "agile" thinking.

in my opinion ITIL and devops/agile principles are not incompatible.
ITIL are just some suggestions about processes, it is up to you to do the right implementation in your environment.
So when you keep devops/agile principles in your mind while implementing ITIL it will even be possible to bring service to the customer without tickets.
Just make the service running and after that you can document it in a ticket, or the customer can write a ticket while you are brining the service back to life.
You could even tell your customer to open a ticket with two sentences: Service xyz is not reachable. <Your Name> knows what I mean.
You'll find an example in the book "The Practice of System and Network Administration".

regards
Christian

[twitter.com/nfma]

Hi,

One of the companies I worked for decided to implement ITIL. I had a feeling that it wasn't as agile as we were at the time so I read loads about it.

And some employees (myself included) tried to convince the management that we were happy as we were.

But they still imposed it on us. So, I quit and my experience is only limited to what my ex workmates told me about the changes.

But I think that ITIL is a top down approach with emphasis on command and control, which some people in the list already mentioned, and I think this is downright against the agile principles, specially the ones on self organising teams, trust and communication.

From Wikipedia:

     "CSI needs to be treated just like any other service practice. There needs to be upfront planning, training and awareness, ongoing scheduling, roles created, ownership assigned,and activities identified to be successful. CSI must be planned and scheduled as process with defined activities, inputs, outputs, roles and reporting."

This does not seem any agile to me.

Taking one of your examples, at my current company, we don't use *any* ticketing system. The close we get is to use a Kanban board that *helps* us improve the way we do stuff. We don't follow any _methodology_.

We are just continuously searching for ways to solve our biggest problems and fix them for good (we don't usually do quickies) and I can tell that we are far far away from what ITIL is.

What we state really clearly are the short term and long term *goals*, which can change at any time, and they did this year because there were not enough demand for what we were building.

The team self manages itself. We hold retrospectives every two weeks to see how we are doing and what problems we want to address in the next two weeks that are preventing us from attaining the goals.

We do gather metrics from loads of places but they are only used in a need by need basis and when they stop providing value, we drop them.

When people look at the way we work, people can see caos but we see flexibility and we deliver. We release features almost every day (3 this week, 4 last week).

My biggest _problem_ with ITIL is mostly that it emphasises more on rigid practices (even the CSI process is rigid) and gives you this nice looking framework instead of focusing on principles and values and letting people figure out what works for them.

One thing that is a bit counter intuitive but it somehow streamlined the delivery of stories is pairing all the time, including writing blog posts, documentation, writing database or server scripts and configurations or even searching for tools.

Cheers,

Nuno

--
You received this message because you are subscribed to the Google Groups "Agile System Administration" group.
To post to this group, send email to agile-system-...@googlegroups.com.
To unsubscribe from this group, send email to agile-system-admini...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-system-administration?hl=en.

[Scott Wilson]

I think this may be one of those things it's better not to rely on
Wikipedia for a definitive perspective of (in fact, the section you
quote has "citation needed" plastered on it) and I, at least, wouldn't
agree with that characterization of CSI. In fact, I think you can
view it as an iterative process just like agile development releases,
and it doesn't have to have waterfall planning behind it anymore than
those do.

If what you are doing is working well for you, great, but I don't
think ticketing systems are an anathema to DevOps, and I have seen
many operations shops much improved with the addition of flexible,
properly run change management and ticket systems. I don't think you
can necessarily take agile practices from development and simply drop
them wholesale into the operations environment; accommodations to the
different environment and requirements are necessary, and a bit more
regimentation might be one of those necessary accommodations. After
all, ops still has to make the trains run on time. Sometimes quick
fixes are what you need; sometimes a little discipline keeps things
from falling through the cracks. I don't see those things as counter
to agile; I see agile as how you implement the stuff, not the stuff
itself.

I think few people would describe agile as being no methodology, or
imagine that it doesn't involve any process framework.

Cheers,

Scott

On Feb 26, 12:40 pm, "twitter.com/nfma"

> > agile-system-admini...@googlegroups.com<agile-system-admin istration%2Bunsu...@googlegroups.com>

[twitter.com/nfma]

On 27 February 2010 20:31, Scott Wilson <sc...@indigomoonsystems.com> wrote:

I think this may be one of those things it's better not to rely on
Wikipedia for a definitive perspective of (in fact, the section you
quote has "citation needed" plastered on it) and I, at least, wouldn't
agree with that characterization of CSI.  In fact, I think you can
view it as an iterative process just like agile development releases,
and it doesn't have to have waterfall planning behind it anymore than
those do.

Ok, let's forget that citation. I just posted it because it reflected what I felt like after reading on the books I borrowed.

But notice that iterative development and agile are not the same thing. Though agile development delivers things incrementally, you can (and lots of teams I've seen) do smaller waterfall releases...

I still think that the ITIL _processes_ are downright against agility because they're pushed down into the teams.

 

If what you are doing is working well for you, great, but I don't
think ticketing systems are an anathema to DevOps, and I have seen
many operations shops much improved with the addition of flexible,
properly run change management and ticket systems.  

My intension was not to say that ticketing systems were inherently bad to DevOps, but it stroke me again, as the _process_ of CSI did, that this is just another _tool_. And that more emphasis is placed on processes and tools then it is on agile (and I would say good) principles and values, like good communication.

 

I don't think you
can necessarily take agile practices from development and simply drop
them wholesale into the operations environment; accommodations to the
different environment and requirements are necessary, and a bit more
regimentation might be one of those necessary accommodations.  

I never wanted to imply anything the like. I even said that we don't use any _methodology_ but try to work out what works for us.

We do get practices from other methodologies, we didn't invent anything, what we do is inspect and adapt all the time.

Though most people, with a lot of experience in agile, will tell you to blindly use the practices until you understand them enough to know its pros and cons, and then decide on what to keep and what to drop.

 

After
all, ops still has to make the trains run on time.  Sometimes quick
fixes are what you need; sometimes a little discipline keeps things
from falling through the cracks.

This doesn't sound good to me. Not sure I understand your point but by what I read it makes remember the devs that push untested code to the repo because they are already under time pressure. 

 

I don't see those things as counter
to agile; I see agile as how you implement the stuff, not the stuff
itself.

Agreed. But when I said we don't do quickies, it's just because we tend to reason about the root cause of the necessity of the quicky and address it, then and there. And it doesn't need a committee, just two people.

 

I think few people would describe agile as being no methodology, or
imagine that it doesn't involve any process framework.

I've never heard of an agile framework... and being agile doesn't have to have a trade mark like Scrum, XP, DSDM, Crystal or anything attached to it.

Also the agile manifesto states clearly:

"Individuals and interactions over processes and tools"

It wouldn't make any sense if it was then presented with a _process framework_, right?

In the end I think everything boils down to people and trust (or the lack of it).

Cheers,

Nuno

To unsubscribe from this group, send email to agile-system-admini...@googlegroups.com.