In fairness it depends how it is being deployed.
In our infrastructure it is being used without many of the lower end staff being aware of it. They don't need to know about the CMDB or the change practices. Still there though.
Agile and ITIL - what is it (in laymans terms!)
- Thread starter ~J~
- Start date
In fairness it depends how it is being deployed.
In our infrastructure it is being used without many of the lower end staff being aware of it. They don't need to know about the CMDB or the change practices. Still there though.
Soldato
- Joined
- 19 Apr 2004
- Posts
- 4,793
- Location
- London
hahaha, I can believe that.
Good book too, I'd also recommend "user stories applied" and "agile development with scrum" as a good background if anyone is involved in a startup Agile team.
![[DOD]Asprilla](/styles/overclockers/avatars/8.png){kind=avatar}
Soldato
- Joined
- 10 Nov 2003
- Posts
- 14,034
- Location
- Surrey, by the river
If you are talking about an agile development environment then basically it's a methodology for delivery projects just like Prince 2, which I guess you've heard of?
With Prince you collect all your requirements, develop your system or software and then deliver to the customer when it's finished.
With Agile you deliver in sprints, which tend to be about two weeks in lenght (although where I'm currently working we use 4 week sprints). The deveopers work much more closely wth the customer and rquirements get the chance to change as the project develops. New requirements are added to the backlog and are assessed for the lenght of time they will take and their importance and placed in the back log accordingly. If the length of time required to develop the requirement is longer than the sprint then the requirement needs to be broken up.
Agile is the latest buzz word, but I've rarely come across a really effective implementation of it and it's certainly not suitable for all development projects.
With Prince you collect all your requirements, develop your system or software and then deliver to the customer when it's finished.
With Agile you deliver in sprints, which tend to be about two weeks in lenght (although where I'm currently working we use 4 week sprints). The deveopers work much more closely wth the customer and rquirements get the chance to change as the project develops. New requirements are added to the backlog and are assessed for the lenght of time they will take and their importance and placed in the back log accordingly. If the length of time required to develop the requirement is longer than the sprint then the requirement needs to be broken up.
Agile is the latest buzz word, but I've rarely come across a really effective implementation of it and it's certainly not suitable for all development projects.
Soldato
- Joined
- 19 Apr 2004
- Posts
- 4,793
- Location
- London
[DOD]Asprilla;13805264 said:
Out of interest how far has your team gone with Agile practises? Are you cross-skilling? Do you have a coach? Do you keep a regular burndown chart and stuff?
Configuration Management Database 
It houses all components of an ITIL environment. Documentation, software, change management systems, each one is a Configuration Item, and the CMDB is a relational Db so can be queried against them all.
When fully involved and well deployed it's a wonderful tool.
It houses all components of an ITIL environment. Documentation, software, change management systems, each one is a Configuration Item, and the CMDB is a relational Db so can be queried against them all.When fully involved and well deployed it's a wonderful tool.
[DOD]Asprilla;13805264 said:
The company I work for uses Scrum, and only Scrum, for all of its IT development projects...and some of the non-IT projects too.
We have 4 week sprints, dedicated Scrum masters, CI processes, CD processes, TDD, burn down charts, velocity, etc etc...
All developers have to attend a 2 day Scrum training course, then a 5 day Agile Engineering course before doing any work in a Scrum.
It's not perfect, but in 6 months I've delivered more business benefit than approx. 6 years' worth of non-delivered effort where I worked before.
The trouble is, that it's easy to do it badly, and REALLY TOUGH to do it well. It takes a lot of effort. Trying to get developers to embrace TDD is a real pain...until they see the benefits...and once converted they never go back...
Configuration Management Database
When fully involved and well deployed it's a wonderful tool.
Sounds like you've done the same ITIL course I have
Mind you, our ITIL house is a bit flaky, we have no CMDB or SLA's
Soldato
- Joined
- 10 Nov 2003
- Posts
- 14,034
- Location
- Surrey, by the river
In my current role I have no idea, unfortunately.
We work on a 4 tier development model where relatively small changes that don't require funding approval (anything under £50k or 20 days effort) are added to the backlog of one of three agile development teams (tiers 2, 3 & 4).
Anything that does require funding approval beeds to go through various funding, design authority and business architecture approvals and so we have to collect requirements, design architecture and produce a budget. Since we usually also have to bring in external developers we deliver this kind of stuff in a traditional waterfall.
I'm about to start a massive programme of work that they intend to deliver using agile techniques, so hopefully I'll get more involved at that stage, but it remains to be seen.
Mind you, our ITIL house is a bit flaky, we have no CMDB or SLA's
That's a pretty common occurance I'm afraid.
Soldato
- Joined
- 19 Apr 2004
- Posts
- 4,793
- Location
- London
The company I work for uses Scrum, and only Scrum, for all of its IT development projects...and some of the non-IT projects too.
We have 4 week sprints, dedicated Scrum masters, CI processes, CD processes, TDD, burn down charts, velocity, etc etc...
All developers have to attend a 2 day Scrum training course, then a 5 day Agile Engineering course before doing any work in a Scrum.
It's not perfect, but in 6 months I've delivered more business benefit than approx. 6 years' worth of non-delivered effort where I worked before.
The trouble is, that it's easy to do it badly, and REALLY TOUGH to do it well. It takes a lot of effort. Trying to get developers to embrace TDD is a real pain...until they see the benefits...and once converted they never go back...
Sounds like a good setup
I did find one thing though.. once you've worked on a decent agile team you don't want to go back to the old waterfall ways!Sounds like a good setup
There's no reason why you can't take the concepts of agile and implement them for waterfall. You do the same thing as in Scrum, but call them "phases" instead of "sprints".
I did that to a Prince2 guy that I know, who still works in a waterfall environment. His response? "Oh, yeah, that's a great idea a series of very small, measurable delivery phases...I wonder why no-one thought of it before!"
I work in a Scrum team. Love it. We're also trying out Kanban as we have a new project about to start that is going to be difficult to settle in sprints.
All in all, Prince2 needs to die. Of a horrible death. ITIL, too.
All in all, Prince2 needs to die. Of a horrible death. ITIL, too.
What's wrong with Prince2? I was really pushing for that training course on my placement because it was a good award to have for anything related to PM. PM's with Price2 practitioner in our company were on far more than people without or just foundation!
ITIL while useful in some areas, I found to be generally just a waste of time as it's just a framework, the reality varies a lot from what you have learnt. Plus with things like SLA's ect were hardly ever met where I was because agreed SLA's were not agreed by everyone and totally unrealistic. Just caused conflicts.
Sure it works great when properly implemented and used though.
ITIL while useful in some areas, I found to be generally just a waste of time as it's just a framework, the reality varies a lot from what you have learnt. Plus with things like SLA's ect were hardly ever met where I was because agreed SLA's were not agreed by everyone and totally unrealistic. Just caused conflicts.
Sure it works great when properly implemented and used though.
Rigid, much room for error, but most importantly it's not responsive enough.
Prince 2/Waterfall methodology takes to darn long for software to go out the door, the clients' needs might have changed in the mean time.
Soldato
- Joined
- 10 Nov 2003
- Posts
- 14,034
- Location
- Surrey, by the river
Prince 2 has it's place, especially for large infrastructure projects because you won't be delivering functionality every two weeks. Prince 2 was designed for any project whereas Agile was designed specifically for software development and so I'm not convinced that it translates to all situations.
I work in a team that uses agile development methodologies for every development project. We haven't fully embraced TDD as I believe the management have decided it is far too expensive to implement at this stage. The teams in my office work in 2 week sprints and we have a dedicated scrum master in each team. Our source control and PBI/SBI tracking is done through a heavily modified Conchango process template running on Microsoft Visual Studio Team Foundation Server and Sharepoint.