Skip to main content

ITSM and Agile

Last post 07:00 pm March 13, 2018 by Ian Mitchell
6 replies
05:40 pm March 11, 2018

We currently (or are attempting to follow) and ITSM based method of IT delivery.  There seem to a LOT of tollgates, documentation and processes involved here....to me this seems to against the spirit of Agile.

How do people feel about this? One of the differences is that our organisation does little in the way of internal development but more 3rd party products that integrate into our systems. But I'm not sure how that makes a difference.

Can Agile and ITIL/ITSM co-exist?

 

 


06:16 pm March 11, 2018

What service improvements would you hope to achieve by doing so?

Agility could improve responsiveness in a rapidly changing situation, while a reduction in lead times might make the case for increasing lean efficiencies.


08:02 pm March 11, 2018

Our current environment is *very* document and process heavy. The irony of the situation being that most people don't read any of the documentation and it's seldom kept up to date Likewise the process tollgates we have a 'tick the box' exercises IMO. We also employee an army of service delivery managers, technical writers etc to compile this stuff,

I like the agile mentality of working software of comprehensive documentation. I'm not sure where Agile sits in relation to the over use of process tollgates and such,


08:22 pm March 11, 2018

@Jason Pearce, which industry are you in? Any external regulations around it?


09:08 pm March 11, 2018

Hello

I am in pharma. Yes, we do have certain tollgates we must/should pass through, but surely over documenting is bad? I read this article here;

https://www.cio.com.au/article/465436/can_infrastructure_agile_/

Seems what they did there to make themselves more agile was reduce hefty documentation requirements


06:48 pm March 13, 2018

Our current environment is *very* document and process heavy. The irony of the situation being that most people don't read any of the documentation and it's seldom kept up to date 

Perhaps there should be a review of the extensive documentation you are producing:

  1. Why is such documentation rarely referenced by others?   Is it truly valuable?
  2. What would be the benefit of keeping documentation up-to-date if it is rarely referenced?   If it were maintained, would it be referenced more?
  3. Are there any alternatives to producing mounds of documentation?   What could be produced/maintained in its place that would be current and usable by others?

 


07:00 pm March 13, 2018

I like the agile mentality of working software of comprehensive documentation. I'm not sure where Agile sits in relation to the over use of process tollgates and such,

The critical consideration is what can gates and documentation guarantee which a provably “Done” increment of release quality cannot.

Regulatory frameworks notwithstanding, usually the more quality assurance is built into and around the product itself, the fewer promissary notes and gates will be required.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.