|Devops and the ITIL framework||James Bailey||2/24/10 2:19 AM|
Having a series of conversations with a friend about a new business
My personal experiences of ITIL is it is a management tool to bring
|Re: Devops and the ITIL framework||Patrick Debois||2/24/10 2:47 AM|
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
I know there is more to ITIL then just these aspects. For a sceptical
"It Ain't what you do (be it ITIL or something else) , It's the way that
|Re: Devops and the ITIL framework||Alexis Lê-Quôc||2/24/10 8:28 AM|
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.
|Re: Devops and the ITIL framework||Marcel van Hove||2/24/10 10:37 AM|
James Bailey schrieb:Hi Jim,
If I understand ITIL right it means "no ticket - no service". This would
As a agile admin I try to see the whole problem and focus on getting the
If ITIL makes me slower I try to find a better way to hold the system
Easy to say, hard to do in real life :-)
|Re: Devops and the ITIL framework||ohlol||2/24/10 10:48 AM|
Marcel Wegermann wrote:
Hm. In agile development the bug tracking system is tightly coupled with
I must say also that using a ticketing system with Scrum or Kanban gives
Personally, I'm in an ~20 person IT team composed of sysadmins, neteng
|Re: Devops and the ITIL framework||Andrew Hodgson||2/24/10 11:20 AM|
Absolutely agree with this. We've recently started implementing scrum
It's funny this thread came up, because just today I was advocating
Perhaps the most scary part of VO for business stakeholders the first
|Re: Devops and the ITIL framework||Marcel Wegermann||2/24/10 12:24 PM|
Scott Smith schrieb:
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
Gesch�ftsf�hrer: Henning Wolf, Jens Coldewey
Fon: +49 40 88173-300
|Re: Devops and the ITIL framework||Carlos Villela||2/24/10 12:34 PM|
> If I understand ITIL right it means "no ticket - no service". This would be
That is to say "tools and processes are less important than
I agree with the rest of the thread, tracking and visibility are super
|Re: Devops and the ITIL framework||ohlol||2/24/10 12:58 PM|
Andrew Hodgson wrote:
Ha! Yeah, it can seem really freaky. My current job is the first place
I found that the proper enforcement of change control procedures (all
On top of that, I think I spend most of my time and focus on the
Marcel Wegermann wrote:
Ah, yes :) In that case I typically open the ticket for/with them as
I believe people shy away from ticketing systems because they are used
Do you share a similar experience?
(I think Tom Limoncelli's book _Time Management for System
Also, here's a good related blog post if you haven't read it yet:
|Re: Devops and the ITIL framework||Scott Wilson||2/24/10 5:55 PM|
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
I personally think that this becomes a little more obvious to see if
|Re: Devops and the ITIL framework||James Bailey||2/25/10 3:47 AM|
I find that a ticket will help to keep things visible, I often just do
He co-wrote "The Practice of System and Network Administration" which
I think what I am getting from this conversation is that ITIL and
Many thanks to all for such an excellent reading list and serious food
Peace Jim :)
|Re: Devops and the ITIL framework||Christian Zunker||2/26/10 7:43 AM|
On Wed, Feb 24, 2010 at 7:37 PM, Marcel Wegermann <mar...@wegermann.com> wrote:
James Bailey schrieb:
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".
|Re: Devops and the ITIL framework||twitter.com/nfma||2/26/10 12:40 PM|
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.
"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.
|Re: Devops and the ITIL framework||Scott Wilson||2/27/10 11:31 AM|
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
If what you are doing is working well for you, great, but I don't
I think few people would describe agile as being no methodology, or
On Feb 26, 12:40 pm, "twitter.com/nfma"> > email@example.com<agile-system-admin istration%2...@googlegroups.com>
|Re: Devops and the ITIL framework||twitter.com/nfma||2/27/10 4:37 PM|
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
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.
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 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.
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.
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'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).