Recommended
More Related Content
What's hot
What's hot (13)
Viewers also liked
Viewers also liked (18)
Similar to ITIL for Agile
Similar to ITIL for Agile (20)
Recently uploaded
Recently uploaded (20)
ITIL for Agile
- 1. Talking ITIL for Agile Folks(learning Standard Change) R1 robin.slomkowski@nokia.com
- 2. Talk the Right Language! Stop Fighting, they are just requirements! They have a big book that defines their language, but that is because it is complicated.
- 3. Talk the Right Language! Kaizen == CSI CI != CI
- 4. Standard Change Service Change ‘The addition, modification or removal of authorized, planned or supportedservice or service component and its associated documentation.’
- 5. Standard Change Standard changes A standard change is a change to a service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement.
- 6. Standard Change Standard changes, there are some simple requirements that I am going to translate into user-stories for you.
- 7. There is a defined trigger to initiate the RFC As a deployment team we want a standard RFC document for our change board that outlines our release procedure and risks for releasing software so that our company quickly figure out what happened and has an easy way to resolve problems that may arise.
- 8. There is a defined trigger to initiate the RFC As a product owner I want a procedure document for a standards change on file with my change board so my company knows how to audit changes of my product in order to stay in legal compliance and can for possible interactions with other systems.
- 9. The tasks are well known, documented and proven As a deployment team we want releases automated to the point that they are always repeatable, simple, fast and tested, so that the documentation of a release is really simple and the same no matter what happens to the code.
- 10. The tasks are well known, documented and proven As a deployment team we want releases automated to the point that they are always repeatable, simple, fast and tested, so that the documentation of a release is really simple and the same no matter what happens to the code.
- 11. The tasks are well known, documented and proven As a deployment team we want integration and testing code that is written and/or commented to be human readable and understandable so that our code is our documentation even for change and business analysts (not to mention new team members and support teams).
- 12. Authority is effectively given in advance As a product owner I want a document that defines me as Accountable for the service registered with the change board so that there is no question of who has the ultimate authority for this product.
- 13. Authority is effectively given in advance As a product owner I want a document that shows that my release processes meet my company’s process, legal, and/or other restrictions so that there can be no question or delays about doing business as usual and getting the code out.
- 14. Budgetary approval will typically be preordained or within the control of the change requester As a product owner I want tools to allow me to monitor the resource use or cost of my releases so that I can keep my company’s budget predictable.
- 15. The risk is usually low, and always well understood As a deployment team we want frequent small releases so that we can know that the risks are low and we don’t have difficulty fixing the things that will break.
- 16. The risk is usually low, and always well understood As a deployment team we want tools that check everything that has ever gone wrong before so that we don’t make the same mistake twice.
- 17. The risk is usually low, and always well understood As a deployment team we want an automated production deployment system that is just like our automated testing deployment system so that know our systems are well understood before customers see them.
- 18. What about WHEN it goes wrong? Your penalty for poor testing is bureaucracy, you lose your standard change when it causes your users a poor experience.
- 19. What about WHEN it goes wrong? Your answer is that you willcreate a new test and integrate it all the way through your integration pipeline so you never make the same mistake twice and everybody learns to love your releases!
- 20. Compliance & Agile as Friends!
Editor's Notes
- Translate ITIL Language to User StoriesThis focuses on Change Management because it is both the most implemented ITIL process and the most frustrating one for Devops teams.The Standard Change is the way to minimize ITIL process
- Stop Fighting! I won’t go into the ideology but ITIL and agile can work together.You can just treat them as requirements.They have a big book that defines their language, but that is because it is complicated. By understanding their language you can work with them.Attribution: http://www.flickr.com/photos/tambako/5461233647/
- Sometimes we have different words for the same thing:Kaizen == CSISometimes we have same word for different things:CI == Change Item rather than CI == Continuous IntegrationAttribution: http://www.flickr.com/photos/tambako/5461233647/
- ITIL does view changewith fear, they assume you already have is really GREAT/IMPORTANT (their word is “Value”)and you are NOT allowed to make it worse.Service Change‘The addition, modification or removal of authorized, planned or supportedservice or service component and its associated documentation.’Based on: http://www.flickr.com/photos/cristinabe/4635930677/
- They protect that GREATNESS or “Value” with process & procedure, but not all changes are equally procedure-heavy.Standard changesA standard change is a change to a service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement.Based on: http://www.flickr.com/photos/cristinabe/4635930677/
- The loophole to the constant heavy process is the standard change.There are some simple requirements that I am going to translate into user-stories for you.Based on: http://www.flickr.com/photos/cristinabe/4635930677/
- “RFC” is a request for change, but the trigger can be anything as long as it leaves an audit trail.As a deployment team we want a standard RFC document for our change board that outlines our release procedure and risks for releasing software so that our company quickly figure out what happened and has an easy way to resolve problems that may arise. Created by: http://www.flickr.com/photos/driph/2782864671
- As a product owner I want a procedure document for a standards change on file with my change board so my company knows how to audit changes of my product in order to stay in legal compliance and can for possible interactions with other systems.Attribution: http://www.flickr.com/photos/driph/2782864671
- As a deployment team we want releases automated to the point that they are always repeatable, simple, fast and tested, so that the documentation of a release is really simple and the same no matter what happens to the code.Attribution: http://www.flickr.com/photos/torley/2970973450/
- As a deployment team we want a continuous integration system that tests our deployment process and production monitors to minimizesurprises in production and so thatour test report and CI code becomes our documentation.Attribution: http://www.flickr.com/photos/torley/2970973450/
- As a deployment team we want integration and testing code that is written and/or commented to be human readable and understandable so that our code is our documentation even for change and business analysts (not to mention new team members and support teams).- Cucumber is a cool tool for this.Attribution: http://www.flickr.com/photos/torley/2970973450/
- As a product owner I want a documentthat defines me as Accountable for the service registered with the change board so that there is no question of who has the ultimate authority for this product.In ITIL Language: Responsible-Accountable-Consulted-Informed; this is a cultural issue. In ITIL there must be 1 and only 1 individual accountable. If you are a hard core agile group you can rotate the role regularly between people (but you will need to list that in your change audit trail if you do).Attribution: http://www.flickr.com/photos/lumaxart/2137729430/
- As a product owner I want a document that shows that my release processes meet my company’s process, legal, and/or other restrictions so that there can be no question or delays about doing business as usual and getting the code out.Attribution: http://www.flickr.com/photos/lumaxart/2137729430/
- As a product owner I want tools to allow me to monitor the resource use or cost of my releases so that I can keep my company’s budget predictable.- This gets a bit more complicated in public clouds, where a software release really can have serious financial impact to a company.Attribution: http://www.flickr.com/photos/hikingartist/3000884104
- As a deployment team we want frequent small releases so that we can know that the risks are low and we don’t have difficulty fixing the things that will break.Getting over the notion of frequency is a bit of a hurdle with some change boards, but you have to be determined! Just go through the hoops a couple of times.Attribution: http://www.flickr.com/photos/klg19/4572410674/
- As a deployment team wewant tools that check everything that has ever gone wrong before so that we don’t make the same mistake twice.Attribution: http://www.flickr.com/photos/klg19/4572410674/
- As a deployment team we want an automated production deployment system that is just like our automated testing deployment system so that know our systems are well understood before customers see them.Attribution: http://www.flickr.com/photos/klg19/4572410674/
- Your penalty for poor testing is bureaucracy, you lose your standard change when it causes your users a poor experience.I know we hate filling out forms but it happens. Your forms just need to be references to your code that is well commented and human readable ;)Attribution: http://www.flickr.com/photos/e-strategycom/1053256971/
- Your answer is that you willcreate a new test and integrate it all the way through your integration pipeline so you never make the same mistake twice and everybody learns to love your releases!This new test is something real and important! I even like to categorize them separately as important to users/customers.Attribution: http://www.flickr.com/photos/e-strategycom/1053256971/
- ITIL was designed to explain to Margaret Thatcher why the British government was givingIBM so much money and to make sure they were accountablefor what they delivered. At this point the main reason to implement ITIL is to maintain legal or organizational compliance (SOX is often used a justification; another is process alignment with outsourcers). As we know there is no problem with regulatory compliance and Agile; it just involves both sides speaking to each other more clearly.Attribution:http://www.flickr.com/photos/stuseeger/226628124/