With this brownbag session I intend to provide an excerpt of what I have learned at the conference that can be of value to us.
As some of you may know I will be attending ITx 2016 from July 11 to July 13 next week. I feel that ITx has great value...
Feel free to visit the ITx Site to learn about the details of the conference and the programme details: http://itx.nz/
Below is just a small part of the list of topics that I will attend at the conference. These specific topics can be of value to us:
Monday, 11th July 2016
10:50am Service Management 2 - Peter Doherty, Jaclyn Bell: DevOps, Agile and ITIL just don't work together - or do they?
11:30am Service Management 2 - Alex Leonov: Being agile and seeing the big picture: the challenge
2:20pm Tech Trends - Ray Cooke: Managing for DevOps and beyond
Tuesday, 12th July 2016
3:20pm Mark Smalley: Kill DevOps
Wednesday, 13th July 2016
10:40am (1) Rob England: How DevOps messes with your head
12:00pm (1) Karen Ferris, Rob England, Mark Smalley, Lou Hunnebeck, Matt Hooper: Panel session: Integrating ITIL with Agile and DevOps
Also please look at the details of each topic. If the topic has a Q&A I might be able to ask some questions for you.
Cheers and Regards,
Ritchie Grijaldo
.Net Technical Lead | Datacom Systems (Wellington) Ltd.
2. Introduction
• What is a “brownbag” session / meeting?
• What is ITx?
• DevOps, Agile and ITIL just don't work together - or do
they? - Peter Doherty
• Being agile and seeing the big picture: the challenge - Alex
Leonov
• Managing for DevOps and beyond - Ray Cooke
• Kill DevOps - Mark Smalley
• How DevOps messes with your head - Rob England
• Panel session: Integrating ITIL with Agile and DevOps
• Some Thoughts
3. What is a “brownbag” meeting?
• “A lunch meetings where people bring their own food…” -
www.businessdictionary.com/definition/brown-bag-meeting.html
• Familiarize the audience with a new concept or to share information.
• Casual or “informal” meeting. No one is an expert/hero.
*All images in this presentation were shamelessly downloaded from the Internet. I do not claim ownership of any of these images, nor intend to
plagiarize any literature owned by someone else.
8. Peter Doherty
• Ops influences Dev
• Dev drives Agile
• Agile reinvents Service Management
Ops
Dev
Agile
SM
9. Being agile and seeing the big picture:
the challenge
• Alex Leonov, Director, Knowledge Lab
• “Agile allows us to work faster.”
• “Agile methodology.”
11. Ritchie Grijaldo
• Look at how people “actually” work.
• Accept that you can never know everything about the business need.
• No dot restrict change. Embrace it and prepare for it.
• Align with common purpose.
12. Alex Leonov
• See the big picture.
• Recommendation 1: Traceability
• Recommendation 2: Disintermediation
• Recommendation 3: Immediate Feedback
13. Managing for DevOps and beyond
• Ray Cooke, Principal Consultant & Lean/Agile Business
Transformation Coach, Equinox IT
• Injecting DevOps into a business is like a “T” function.
• SM: In order to use (agile) DevOps, your system should already be of
high quality.
• Agile is “delivery-focused”.
• DevOps is “service-focused”.
24. How DevOps messes with your head
• Rob England, Managing Director, Two Hills Ltd.
• New Zealand's only certified DevOps Foundation instructor.
• DevOps ≠ Automation
• DevOps - Agile extended to Ops
• DevOps - Agile + Lean + ITSM
• DevOps wants to “fail fast”.
• DevOps wants to “fail forward”.
25. Rob England
• If it hurts, do it more. Also use andon cords.
• IAC: Dev team defines the environments especially Prod, not Ops.
• Challenge “ceremonies”: if you’re not delivering value, get out of the
way.
• DevOps transition: Dev is accountable to the software in Prod. Ops is
accountable to raising what Dev needs to be accountable to.
• Dead Cat Syndrome itskeptic.org/dead-cat-syndrome
• Canary Release: Test in Production (a.k.a. FB’s “silent go-live”).
26. Rob England
• Fully support & lead the mission of
DevOps direction.
• Mature DevOps: “Push Button Releases”
or CD.
• Phoenix Servers & Immutable Servers
• Self-healing capability – be mean to your
code. Antifragile.
(wikipedia.org/wiki/Chaos_Monkey)
• TDD – fundamentals of DevOps
(drdobbs.com/architecture-and-
design/test-driven-design/240168102)
27. Rob England
• Breaks the Iron Triangle.
• Chasing cost distorts behavior.
• ChatOps & Incident Management
29. Panel session: Integrating ITIL
with Agile and DevOps
• Karen Ferris, Director, Macanta Consulting Pty Ltd (Melbourne,
Australia)
• Lou Hunnebeck, Principal, Advisory Services at Fruition Partners (New
York, USA)
• Rob England & Mark Smalley
30. Rob, Mark, Karen, & Lou
• Who is handling organization change management in your company?
• ITIL tends to overprotect.
• Go back to “why?” and then answer “how?”
• Controlled Chaos
• Servant Leader: Empowerment is “supporting with freedom”.
32. Some Thoughts
• Fatigue: “extreme tiredness resulting from mental or physical exertion
or illness.” (Google.com)
• Fatigue: civil engineering: the weakening or breakdown of material
subjected to stress, especially a repeated series of stresses.
(Dictionary.com)
• Scrum Fatigue: “Scrum has silos”.
• Scrum Fatigue: “Loose” ideas and going back to basics.
• How could something meant to remove impediments and give value
to every task of every person be causing fatigue?
33. Some Thoughts
• Automation is key to enabling DevOps.
• Continuous…well, everything that can be automated.
• Step 1: Decide what slice of the system to do DevOps.
• Step 2: Automate everything that can be automated on that slice.
• Step 3: Foster the DevOps culture (a.k.a. stop Dev from putting a
barrier between Dev and Ops, and vice-versa).
• Step 4: Leverage effective DevOps-centric tools, disciplines, and
methodologies. Take your DevOps into maturity by following and
maintaining its core mission.
• Step 5: Add other slices of the system.
Notes de l'éditeur
3.5 hours compressed into 1 hour.
Attendees are expected to bring their lunch to the meeting room and eat while they listen to the presentation.
In general, the purpose of a brownbag is to familiarize the audience with a new concept or to share information with the rest of the team.
a.k.a. “no budget” meeting.
Meant to be an open discussion. Sharing of ideas. Free to agree or disagree.
ITx is where New Zealand’s digital technology sector comes together. ITx focuses on innovation, technology and education and brings IT professionals, decision-makers, leaders and academics together under one roof. This is a conference like no other: where industry, academia and government come together to network, learn and engage.
So many valuables sessions. Yet on top of that, there are even more beers.
Speaker: ITIL Manager (Distinction), ITIL V3 Expert - Practical service management implementations at many ASX 200 companies, presented many times at itSMFNZ and Australia as well as Korea, USA, HK, Singapore.
Topic: Do the words Agile and Dev Ops scare the heck out of you? Well they shouldn’t. Peter Doherty has always been a big fan of Agile methodologies and until a little while ago could not get his head around how they fitted within a governance structure. That was until he had a discussion with his co-presenter on how she very successfully uses Dev Ops to roll out daily releases. Daily releases – are you kidding! Doherty realised that it was all about the size, impact and risks of these daily releases. Once you start understanding that it becomes much less scary. Come to this session to demystify how Service Management can embrace and leverage Agile and Dev Ops to deliver enormous benefits to your organisation and deliver disruptive business innovation.
Reality: we will never cover all use scenarios within our testing approaches. The point of thorough testing is to cover “common” and “known” scenarios.
Speaker: Alex has more than 15 years of IT experience from network and service management, through to software development, business analysis and management. He has worked on amazing projects in companies around the world. His industry experience includes marketing, freight forwarding, telecommunications, postal services, and entertainment. After gaining experience in small, medium-sized, and large international companies, Alex believes that it is his duty to share his knowledge among other professionals.
Topic: The ability to see details of the service operations in a transparent way is one of the essential parts of being agile. At the same time, too much detail hides the big picture. It takes increasingly more energy to see one as services spread over different channels, and reaction times are expected to get lower and lower. But without the big picture steering the organisation is extremely hard. The challenge is to see operations as a whole, and seeing their details at the same time. Without some kind of a structured approach it seems to be a challenging, if not impossible, task. In this presentation, you will find the ways to deal with the problem: keep and expand agile operations, and maintain a steady overview of the whole at the same time. It has practical advice on dealing with typical problems, and guidelines on customising the ideas to your own environment.
Agile is not a methodology. Jeff Sutherland clarified that in his publications. He had an impression that people didn’t actually understand the mission of Agile Manifesto.
It will be difficult to effectively and regularly deliver in a team that does not understand agile.
This reality is represented by most “agile” projects.
Look at how people actually work, and base your actual velocity (the so-called working speed) from that.
Prepare for the unknowns in the system. This is where best practices and effective testing approaches comes in.
Embrace uncertainty and creativity.
For DevOps to work, teams need to be aligned with common purpose.
Speaker: Ray is a Principle Consultant working for Equinox IT in Wellington, New Zealand. He has been a Software Development Manager in one form or other for over ten years and is currently consulting under the title of Lean & Agile Business Transformation Coach. He has worked in organisations from start-ups through to global corporations in both the public and private sectors, and is accustomed to growing and managing teams delivering and supporting software using a variety of frameworks and delivery methodologies. As well as managing and delivering through existing teams, Ray is experienced in recruiting, setting up and improving teams of IT professionals and always undertakes this with a view to maximising their value to the organisation he's working for. Adding to this experience in project management, vendor management, policy creation and hardware and software procurement has given him a modern and broad applicability in the field of IT management. When not at work, Ray puts the same problem-solving skills to the test at the indoor climbing wall but he's more than happy to admit that he won’t be switching his career away from IT to mountain climbing any time soon! Ray is currently working with a number of New Zealand government departments helping them build on their existing software delivery capabilities and working to his personal goal of making the IT sector better at improving people’s lives.
Topic: Traditional and agile DevOps organisational models are on a spectrum, and there are advantages and disadvantages in traversing this spectrum. The disadvantages of traversing in different directions on the spectrum can be countered by organisational changes. Organisational change is tough and change instigators are often significantly further ahead than those taking part in the change. Find out how to make change in your organisation, and the vision behind a possible future state beyond DevOps.
In order to do DevOps, you need to be in the state that is ready to implement it.
It’s not easy, but the proposed value is also tremendous as you have already seen with large companies that successfully implemented it.
Bank of UK experience: Regimented hierarchy until they got "lucky" by having a mandate from the business because the stakes are so high in a trading division, which drove the push for DevOps.
The drive came from the development team, pulling resources from system administration and other teams.
Lesson: DevOps is always driven by key management. You can never have DevOps if you don't have customer buy-in and management support.
Traditional Management vs. Agile vs. DevOps
Controls: Change Control Board, Design Review Boards, etc.
Speaker: Mark Smalley, based in the Netherlands, is an IT Management Consultant at Smalley.IT and Ambassador at the non-profit ASL BiSL Foundation. He is also affiliated with AllThingsITSM, APMG International, BrightTALK, BRM Institute, GamingWorks, IT4IT Forum, ITPreneurs, Pink Elephant, Taking Service Forward, Topconf, and Van Haren Publishing. Mark is specialised in Application Management and Business Information Management and has reached out to thousands of IT professionals at more than 100 events in more than 20 countries. Connect with him @marksmalley & www.linkedin.com/in/marksmalley
Topic: "If you think that you’ve found it, think again, because you never will.“ This ancient Zen saying about a monk's journey towards enlightenment and awakening is the inspiration behind the presentation title ‘Kill DevOps’. DevOps is about continuous experimentation and learning. DevOps brought Agile’s value proposition closer to the users by speeding up deployment (and more!). However no value is realised until the users actually use well-conceived systems. This is often the weakest link, so we need to extend our reach, and the presentation will show you how to do this.
No, it’s not DevOps. Automation is NOT DevOps, it’s just the leg!
Automation is at the heart of DevOps, but it’s just the tools and processes, and not the culture.
Use your gut feeling. People love to sell the hype in a way that makes money.
John is frustrated that we focus on the tools, not the culture.
Gene Kim – leading author of DevOps publications, among other things.
Reluctant because Gene understands that DevOps is at its infancy so he wants it to evolve, to improve and develop further.
The Phoenix Project by Gene Kim
You can implement DevOps in 3 ways.
This is DevOps in real life.
Business is king.
Architecture is alien. Why? Architecturally Agile.
See AllThingsITSM for details.
His observation as DevOps being essentially a cycle.
Again: DevOps is always driven by key management (demand). You can never have DevOps if you don't have customer buy-in and management support (use).
Free eBook.
Let it evolve. So let’s not kill it…yet.
Speaker: Rob England is a self-employed IT commentator and consultant. He consults in New Zealand on IT governance, strategy and processes. Internationally, he is best known for his blog The IT Skeptic and half a dozen books on IT, and he speaks widely at conferences and online. Rob was the NZ IT Service Management Champion for 2010 and his blog was voted the best "IT consultant and analyst" blog in the UK's Computer Weekly IT Blog Awards for 2010. He is an acknowledged contributor to ITIL (2011 Service Strategy book).
Topic: Sooner or later we will all need to make the lateral shift in mindset required by challenging concepts borne out of DevOps. DevOps turns some fundamental principles of IT and ITSM on their heads, with new concepts such as high velocity change, fail fast, infrastructure as code, people over process, servers as cattle, and empowered developers. DevOps is a strong leading indicator of our IT future. Your IT fundamental axioms will be challenged.
Saying DevOps is just another term for automation is like saying your car is just an additional 5 seats.
Agile thinking extended from build extended to lifecycle of software.
DevOps ancestor: Agile + Lean + ITSM combined.
Agile principles are essentially DevOps principles. Agile Principle: individuals and interactions over processes and tools. Responding to change, etc.
“Fail Fast” is adopted from Agile. DevOps redefines “failure” by encouraging it to happen early and be fixed early…so the next time it happens it’s rather an “expected” scenario.
We need to “Fail Forward” especially on large complex systems. Put it on production as early as possible. Stop pretending rollback works for complex systems. The only way to find out is to see it in Prod.
Releases are painful, but the lesser the frequency, the more unknowns, the higher the risk, the more painful it gets. Just look at waterfall methodology.
“Infrastructure As Code” is an absolute necessity for successful DevOps. Translates “infrastructure provisioned via a controlled code”. Use tools like Ansible.
Emphasizes that dev defines final details of target environment, not Ops. Expected that they know their software best.
Removal of impediments such as unnecessary ceremonies.
Role is to make much changes to happen as fast as possible. If your blocking it, you’re not delivering value.
From position of high control and low trust, to position of high trust and high empowerment.
Let the Development Team own Production, let them have responsibility on building each of the production server, not only on the application they deploy there. CIOs who have done this in their company have said “you should have seen the change in the quality of code when dev handles Prod. It’s just so powerful when Dev becomes accountable when their applications goes live.”
MBIE Document Conversion Service. You know I’m a “lazy” developer. I made sure Infra and Support won’t bother me after go live. Imagine if every developer is afraid of Infra and App Support to the idea that it gives them nightmares. More so imagine if they are the ones responsible for Prod.
Remember IAC.
DevOps is currently at it’s infancy, so we need to move towards “push-button releases” or Continuous Delivery, in order to find the best approaches to fully mature the discipline.
Amazon made record changes to production every 11.6 seconds on average in May of 2011. Facebook releases to production twice a day. Many Google services see releases multiple times a week.
What if a chaos monkey randomly smashes your server, deleting bits of properties here and there…will your system be able to survive?
Good Read: Antifragile by Nassim Nicholas Taleb.
Test-driven design is one of the fundamentals of DevOps. Read more about this idea at Dr. Dobbs site.
Focus on quality not on chasing cost.
Incident Management aims to document, report, and control the flow of incident resolution.
ChatOps is a collaboration model that connects people, tools, process, and automation into a transparent workflow. IM can leverage chat history by being the incident management history. There is not much difference.
Since DevOps aim to deploy as soon as something has been constructed, it does not need TFS branches.
Think about it: no merge conflicts, functional integration risks are drastically reduced. You can immediately see the impact of your changes and have the capability to remove such changes just as fast as you deployed it!
Karen Ferris: Karen is a result focussed, self-motivated senior professional in IT Service Management. She is passionate about best practice as per ITIL across a breadth and range of industries including agriculture, education, import/export, finance, government, healthcare, ICT/technology, mining, retail and utilities. She is an experienced practitioner in Organisational Change Management. Karen has added value for a diverse range of companies including IBM, Telstra, NAB, Coles Myer, Deakin University, MMG, Department of Defence, Hazelwood Power, South East Sydney Area Health, Victorian Parliament, CSC Australia, Vodafone, NEC, Department of Health and Aging, and HP. Karen has experience to enable small, medium and large scale organisations to deliver commercial results to their internal clients and external customers. Karen has contributed extensively to Service Management publications, including ITIL Version 2 and 3. A sought after international keynote speaker and acclaimed author, Karen received the Lifetime Achievement Award from itSMF Australia in 2014 in recognition of her contribution to the ITSM industry.
Lou Hunnebeck: An ITIL Expert with over 30 years in service industries, Lou's passion for improving how we do what we do has led her to IT Service Management from a background of process consulting, training and Service Management systems consulting. Devoted to advancing the art and practice of Service Management, Lou served as the author of the ITIL Service Design publication, 2011 Edition. She is on the Senior Examination Panel for ITIL, and the Architect Team for the new ITIL Practitioner qualification, and speaks regularly at industry meetings to spread the message of ITSM.
Hosted by Matt Hooper, this panel of Karen Ferris, Rob England, Lou Hunnebeck & Mark Smalley will discuss how to integrate "traditional" frameworks (e.g. ITIL) with other approaches (e.g. DevOps & Agile).
Who is handling organization change management in your company? – ITIL controls and limits change to limit risks. DevOps promotes change.
One argument about ITIL is that it tends to overprotect, and with overprotection, innovation becomes limited if not fully hampered.
What happens to children if you always prevent them from getting hurt?
Recommendation: Why don’t we go back to “why?” and then answer “how?” in light of DevOps and Agile?
Revisit existing processes and ask ourselves “what value can DevOps and Agile bring us now?”
ITIL needs to give up some of its controls to give freedom to DevOps, giving the opportunity to prove that it is built to stand up and run better when it gets wounded (a.k.a. “fail fast”).
Up to you if you support these ideas or not because these has been an open discussion during that panel session.
“Gavin Coughlan: Battling Scrum Fatigue.”
Reaction: There seems to be so many ideas about scrum that just went awry…that's the risk of "loose" ideals. We need to go back to basics to avoid such things they call as "fatigue".
Application of scrum is definitely in an infant stage.