Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

My name is Stephan and I work as a Head of Development at Hermes Germany. E-Mail: [email protected] Twitter: @StephanStapel Presentations: https://speakerdeck.com/hermes Hi! I’m Stephan.

Slide 3

Slide 3 text

Content 01 Setting the scene. 02Technology disruption to the rescue. 03 Phase 2: Scaling out. 04 The impact. 05 Our Challenges.

Slide 4

Slide 4 text

Hermes Germany is the largest Post- independent parcel company in Germany. We deliver about 450 million parcels per year.

Slide 5

Slide 5 text

History of agility at Hermes We started in 2011. We started with Scrum as our framework. Motivation: Speed-up delivery of features.

Slide 6

Slide 6 text

Dev department QA department Ops department

Slide 7

Slide 7 text

8 Dev Test Business Ops Image adopted from © apnews.com

Slide 8

Slide 8 text

Devs Testers Ops

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

12 Why didn‘t we improve on delivery and readiness for change?

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

14 The first crisis of agility at Hermes.

Slide 13

Slide 13 text

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?

Slide 14

Slide 14 text

Black hole Ops

Slide 15

Slide 15 text

17 The next step was obvious. It simply wasn’t accessible for us yet.

Slide 16

Slide 16 text

02 Technology disruption to the rescue.

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

21 But: most things turned out to work well.

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

1. Gain knowledge – gain confidence. 2. Allow freedom to create a safe environment. 3. Expect failure – prepare for it. Psychological safety.

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

03 Phase 2: Scaling out

Slide 24

Slide 24 text

Hammer DevOps edition 49,99 € Now with DevOps included The one and only tool for DevOps implementation in your company.

Slide 25

Slide 25 text

27 Don’t loose the focus!

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

04 The impact

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

This transformation has an impact for the entire organization.

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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:

Slide 32

Slide 32 text

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)

Slide 33

Slide 33 text

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.

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

05 Our challenges.

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

If you want to connect with me: E-Mail: [email protected] Twitter: @StephanStapel Presentations: https://speakerdeck.com/hermes Thanks for listening. I hope you enjoyed the presentation.

Slide 41

Slide 41 text

No content