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.
LHOTSE is the internal code name for our project to re-develop www.otto.de: in-house, based on open source software and using agile methodologies such as Scrum and XP. LHOTSE went live on 24th October 2013 – three months before schedule. Although it took us roughly two years to develop, with a team of more than 100 experts, getting LHOTSE live was practically a „non-event“. So, why did everything work out so well?
Fast feedback is a cornerstone of agile software development. When developing the LHOTSE project at Otto, we tried to be as agile as possible and many of our means and methods revolve around fast feedback. Here is a list of my favourite things we do to foster fast feedback. It does not at all cover everything we do in our daily work, let alone everything one possibly could do.
All methods have one thing in common: They try to let the development team know as early as possible when things are going into the wrong direction. The key hypothesis is: The sooner you recognize a mistake, the easier it is to fix it. If you introduce a bug in the software, it is easiest to fix it right away, when you still know what you where doing and when you can associate the bug with the small change you just did. When you learn about a bug later, you first have to identify the change that introduced it, then try to remember the intentions of that change. When adjusting the change, you have to be careful not to break anything that was built on top of it later.
Eines der Ziele, die wir uns für die Lhotse Plattform gesetzt haben ist Continous Delivery: Änderungen sollen nicht nur kontinuierlich integriert, sondern auch rasch in Produktion genommen werden, sobald die Abnahme erfolgt ist. Wie wir das in der Praxis erreichen wollen, ist ein anderes Thema. Damit wir aber prinzipiell in der Lage sind, jederzeit eine neue Version live zu stellen, muss das System in der Lage sein, ohne Unterbrechung auf ein neues Release umzuschalten.