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.

Beim Pair Programming sitzt man also mit einem Paar (gewöhnlich 2) Programmierern an einem Rechner und bearbeitet den gleichen Code. Und das soll sinnvoll sein? … Wir Programmierer im Shopoffice-Team finden: Jawohl! Wir schreiben besseren Code, produzieren weniger Bugs, sind konzentrierter bei der Arbeit und am allerwichtigsten: Wir haben mehr Spaß bei der Arbeit. Klar verwenden wir Pair Programming hier im Team schon sehr ausgiebig – aber es gibt immer etwas zu verbessern. Warum also nicht mal jemanden ins Team holen, der über mehr Praxis in diesem Bereich verfügt und Erfahrungen mit Pairing in verschiedenen Projekten gemacht hat? Wir haben uns für Thomas Much entschieden, der uns für einen Sprint lang bei der Arbeit begleiten sollte. Thomas war als Java- und Pair Programming-Coach schon in zahlreichen Projekten unterwegs und genau davon wollten wir profitieren.

Auf unserem letzten Barcamp habe ich eine halbstündige Session „Pair-Programming for Non-Developers“ gehalten.

Warum das, …also, warum „for Non-Developers“?

Wir setzen hier bei Otto Pair Programming in der Softwareentwicklung ein und ich werde immer mal wieder gefragt warum wir das tun – vor allem auch von Nicht-Entwicklern. Deswegen habe ich mir eine Session überlegt, in der ich Pair Programming für Menschen fühlbar und erlebbar mache, die nicht aus der Softwareentwicklung stammen.