DevOps as the Afterburner for Agile Organizations

The basic idea behind the DevOps principle is to bridge the gaps between different disciplines of IT and speeding up delivery cycles. You can easily imagine what this means for one as a person and for whole teams. It becomes more difficult when discussing the impact of DevOps for entire organizations and their ways of working. The DevOps transformation has some similarities with the agile transformation most companies are working on. However, DevOps transformation goes further than agile approaches.I will introduce our approach to applying DevOps principles at Hermes Germany and how we are trying to get things right.In my talk I’ll discuss how we aligned business and IT. I will also introduce our approach to developing our people and transforming our organization to make use of the new possibilities both DevOps principles and new technology offers. For example, at the current state of our journey, our organization looks completely different than at the start. And like all journeys, our journey comes with its own obstacles and pitfalls that we needed to solve. I address some of these and show potential solutions.

Transcript

2. My name is Stephan and I work as a Head of Development at Hermes Germany. E-Mail: stephan.stapel@hermesword.com Twitter: @StephanStapel Presentations: https://speakerdeck.com/hermes Hi! I’m Stephan.
3. Content 01 Setting the scene. 02Technology disruption to the rescue. 03 Phase 2: Scaling out. 04 The impact. 05 Our Challenges.
4. Hermes Germany is the largest Post- independent parcel company in Germany. We deliver about 450 million parcels per year.
5. History of agility at Hermes We started in 2011. We started with Scrum as our framework. Motivation: Speed-up delivery of features.
6. Dev department QA department Ops department
7. 8 Dev Test Business Ops Image adopted from © apnews.com
8. Devs Testers Ops
9. What did we achieve? Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ✓ NO to some degree NO Business and IT
10. 12 Why didn‘t we improve on delivery and readiness for change?
11. Why didn‘t we improve on delivery and readiness for change? Besides culture, our technology just didn’t allow us. Hardware ordering took months. Effort for infrastructure and deployment automation was too high, products were not mature. Ops capacity was always scarce.
12. 14 The first crisis of agility at Hermes.
13. Do agile ideas make sense or is it just commodity and feel good? We had no idea how we could work iteratively. ‘Potentially shippable product’ became just a ‘showcase’. We asked ourselves: Why do we work in sprints when we don’t deliver? How do we know if the customer will love what we do?
14. Black hole Ops
15. 17 The next step was obvious. It simply wasn’t accessible for us yet.
16. 02 Technology disruption to the rescue.
17. Technologies like virtual machines and Puppet were already available for a long time. However, Kubernetes and Terraform were the real killer apps for DevOps. Together with moving into the public cloud, this laid the ground for successful implementation of Continuous Delivery and DevOps culture. Technology disruption to the rescue.
18. Perspective #1: Ops There aren‘t servers to operate any more. What about the Ops role? Perspective #2: Dev teams Freedom. Responsibility for day to day availability. Change. again. Fear. Horror stories. Disruption causes fear.
19. 21 But: most things turned out to work well.
20. Instead of higher risk, the risk was severely reduced. New understanding of dev role which led to a culture change. Self-confidence to deploy any time. Prerequisite: psychological safety. What we found.
21. 1. Gain knowledge – gain confidence. 2. Allow freedom to create a safe environment. 3. Expect failure – prepare for it. Psychological safety.
22. Teams quickly learn from failure. They understand that immature code might hurt. Teams learn to estimate which risk to avoid and which to accept. Teams love immediate customer feedback. Speaking about failure. Getting skin in the game. Skin in the Game - Nassim Nicholas Taleb
23. 03 Phase 2: Scaling out
24. Hammer DevOps edition 49,99 € Now with DevOps included The one and only tool for DevOps implementation in your company.
25. 27 Don’t loose the focus!
26. We should never forget why we are establishing DevOps culture. The three principles. First Way Systems thinking. Fast flow of work. Second Way Amplify feedback loops. Allow to improve product, tech, process. Third Way Culture of continual experimentation and learning. Try things, take risk, learn. The DevOps Handbook -Gene Kim, Jez Humble, Patrick Debois, John Willis
27. 04 The impact
28. Continuous Delivery allows us (forces us) to plan and implement small increments. We start shipping within sprints. Review meetings turn from ‘showing potentially shippable product’ to ‘show the customer impact on the delivered features’. Lots of moving parts: Need for good collaboration and good coordination. The impact of DevOps to our approach to agility.
29. This transformation has an impact for the entire organization.
30. The book ‘Team Topologies’ contains great reference models. We are using a combination: Dev DevOps Ops Type 8: Container-driven Collaboration Type 3: Ops as Infrastructure-as-a-Service (Platform) DevOps team (platform team) shares expertise throughout the entire IT organization to empower dev teams to efficiently use the PaaS (and IaaS) offerings. Container technology allows dev teams to work with little dependency on Ops. Dev teams need to have operational considerations in mind. Team Topologies: Organizing Business and Technology Teams for Fast Flow - Matthew Skelton , Manuel Pais
31. We shifted our tech organization from function orientation to value streams. Dev QA Ops Customer dev teams Logistics dev teams Corporate dev teams From: To:
32. Value streams are supported by both Platform team and Governance functions. Customer dev teams Logistics dev teams Corporate dev teams Platform Team Governance (Finance, Architecture Management etc.) Public Cloud Provider(s)
33. Focusing the teams on delivering value allows for better interaction with the business. Customer dev teams Feedback loops. Measure value. Learn. Improve product. Business units Learn that one-off requirements aren’t necessary any more. Request small increments since this eases delivery. Connect with the team to answer questions.
34. We are regularly shipping features! We turned from black hole ops to white box ops. Telemetry is key. We learned that monitoring features ‘Checkout’ or ‘Label creation’ says a lot about customer adoption but also about stability. Remember the ‘NO’ on the guiding principle ‚Working Software‘? Here is how did we improved.
35. Checking against the Manifesto – where are we now? Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ✓ ✓ Way better Business and IT Way better
36. 05 Our challenges.
37. Maybe one of the most underestimated topics in agile adoption is Architecture. Speeding up implementation and thinking in stories and sprints often yields into forgetting conception. But: Design a proper architecture dramatically increases parameters like robustness and really speed up implementation. Challenge 1 Architecture.
38. For facilitating collaboration between teams, we introduced the Flight Level Model where we discuss dependencies and necessary interactions on level 2. By using concept of consumer-driven contracts, we ease negotiation and interaction between teams on a technical level. Shifting the focus from team performance to organizational performance. Challenge 2 Interaction between teams.
39. DevOps is the missing piece of the puzzle. It adds great to Agile Methodology. DevOps is „the normal“. Teams feel responsible – day to day operations is natural for the teams. DevOps culture is the key driver for developing our tech organization. Conclusion
40. If you want to connect with me: E-Mail: stephan.stapel@hermesword.com Twitter: @StephanStapel Presentations: https://speakerdeck.com/hermes Thanks for listening. I hope you enjoyed the presentation.