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
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
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
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
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
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
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
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
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
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 :)
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.
--
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.
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>
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.
To unsubscribe from this group, send email to agile-system-admini...@googlegroups.com.