Whenever we present how we release features and deploy our code in one of OTTOs core functional teams, we are met with a certain set of questions, e.g..: “Why do you want to deploy more than once a week?”, “If you automate release and test management, what are the release and test managers doing?”, “How can we prevent major bugs to enter the shop?”, “Where is the final control instance to decide if something goes live?”, or the typical question “Who is responsible if something breaks?” or simply “Why the heck would someone want to do this?”

Let us answer those questions. Let us guide you through our way of working. Let us show you what processes we have (and which ones we do not have) and give you a hint on how to increase productivity and quality at the same time (without firing the test manager). All you have to do is to sit back, relax and let go of your concerns to lose control. Don’t worry, you won’t lose it.

Having successfully reimplemented our e-commerce website www.otto.de in a highly decentralised, agile project approach, we currently face the challenge of establishing an agile mindset outside the cosy cheese dome of a well-protected and well-specified project. During this project we felt like living on a separate planet. Business and technology work entwined, scope was managed by ourselves, we had the liberty to change and adapt our processes and methodologies, introduced an agile management framework, implemented Scrum, built autonomous and cross-functional product development teams and closed feed-back loops with continuous integration and delivery. Or putting it a different way: we learned how to change into a learning matrix organisation. This process was thrilling, demanding to all of us and we are proud of having mastered this challenge. After leaving our project “Lhotse” behind and literally lifting our project cheese dome, we are now facing an urge to change management culture and improve our capability in inter-organisational collaboration.