Logo
Navigation
  • Jobs
    Kein Job gleicht dem anderen. Schau dich in unserer Jobbörse um und finde deinen Traumjob.
    • JobsucheFinde deinen passenden Job bei OTTO
    • JobtickerErhalte passende Jobvorschläge
    • ProfilbereichLeg dir ein Profil an und profitiere von allen Vorteilen
  • Wir sind Otto
    Erfahre mehr über OTTO als Arbeitgeber - was uns ausmacht und wie wir ticken.
    • VisionWonach wir alle streben
    • BenefitsWovon wir alle profitieren
    • OnboardingWomit wir alle starten
    • KulturWas uns alle ausmacht
    • KarrierewegeWie wir uns gemeinsam weiterentwickeln
  • Deine Möglichkeiten
    Die Möglichkeiten, bei OTTO die Zukunft zu gestalten, sind grenzenlos. Entdecke die verschiedenen Einstiegsmöglichkeiten, die wir dir bieten.
    • EinstiegsbereicheUnsere Berufsfelder
    • Schüler*innenNach der Schule
    • StudierendeIm Studium
    • Berufseinsteiger*innenNach dem ersten Abschluss
    • BerufserfahreneMit mehreren Jahren Erfahrung
  • Technologie
    Wir lieben Technologien und setzen Methoden, Frameworks und Infrastruktur ein, die zu uns passen. OTTO Tech gibt dir einen Eindruck zu unseren Arbeitsweisen, Technologien und Menschen von OTTO.
    • Tech-HubVerschaffe dir einen Überblick über alle Tech-Themen
    • Tech-BlogLies dich in unsere Themen
    • Open Source ProjekteEntdecke offene Technologien
    • ArbeitsweisenFinde heraus, wie wir arbeiten
    • TeamsLerne unsere Teams kennen
    • Tech-Gespräche mit ProfisHören, wie wir ticken
  • Rund ums Bewerben
    In unserem Bewerbungsprozess steht der Mensch im Mittelpunkt. Daher möchten wir dich mit allen Informationen rund um deine Bewerbung bei uns versorgen.
    • BewerbungstippsErfahre hier alles rund um deine Bewerbung bei OTTO
    • KontaktErreiche immer die Richtigen
    • Hilfe und SupportFinde hier jede Antwort auf all deine Fragen
    • CampusVerschaffe dir einen Überblick
    • StandorteFinde OTTO in deiner Stadt
    • ServicesNutze die Features auf otto.jobs
  • Jobnews & Events
    Bei OTTO ist immer etwas los. Unsere Jobnews & Events verschaffen dir einen Überblick darüber, was bei OTTO passiert und welche Events du besuchen kannst.
    • JobnewsInformiere dich über Neuigkeiten
    • EventsNimm an spannenden Events teil
Finde, was du suchst.
X

Mein Profil. Hier einloggen oder registrieren.

09. Dezember 2013

Successful Mountaineering – Reaching the Summit of LHOTSE with Agile Software Development

Teilen
 
 
 
 
 
 
 
 
 
 
 
 
RSS
architecturedevelopment

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? I believe a lot of it has to do with how we do agile software development. Let’s dig into some of the Principles behind the Agile Manifesto to find answers:

"Working software is the primary measure of progress."

We delivered working software right from the beginning. We had a basic working version of our online shop very early in the project. In 2012 this version was available to all employees on campus to test and use. In February 2013 we decided to release an „alpha“ version for selected customers (see this article on etailment.de and our first blog post on LHOTSE In May 2013 we released our „beta“ version to a wider range of customers. From then on we gradually increased the automatic distribution of customers from our old platform to our new platform, always measuring and testing if the new platform is keeping its promises concerning our main KPI s. For example, to test the performance and stability of LHOTSE, we diverted 80% of our real users on a high traffic day to the new platform and added another 40% of artificial traffic from load test generators. We made sure under way that our requirements were met. Finally, on 24th October 2013 we switched all our customers to LHOTSE. Unsurprisingly, this was only a small step.

"Business people and developers must work together daily throughout the project."

One of the major organisational changes we introduced with LHOTSE are our „functional teams“, aka feature teams. Each functional team covers a certain domain, e.g. product or order management, and has all skills needed to deliver working software: project leads, product managers, lead engineers, usability experts, designers, devs, ops, QA, etc. All these people work and sit together. Questions, e.g. between developers and business or QA can and will be answered in seconds. Our functional teams are also considerably stable. We do rotate and change team members, but we also try to keep teams stable so that people get to know each other and learn to work really well together.

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Here’s a quote from one of my favourite songs:

„Technology made it easy for us to stay in touch while keeping a distance, 'til we just stayed distant and never touched. Now all we do is text too much.“ (Sage Francis – The Best Of Times)

Different context but certainly transferable. In LHOTSE the whole team of roughly 100 people sits together, in one building on one floor, reducing personal distance to a bare minimum of a few metres. Our internal developers as well as freelancers and other companies we work with, are required to be physically on campus, at OTTO, in Hamburg. Working from home is possible but it’s the exception not the rule. Having everybody in talking or walking distance makes decision making much easier, increases reaction times and team spirit. When talking about conveying information face-to-face, we also pay attention to team sizes. The ideal number of software developers in a team is 6 – my personal opinion. Less can make things tough if people are on holiday or on sick leave. More team members exponentially increases the communication path between team members and inverts the advantage to a disadvantage.

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale."

Our sprint length is two weeks. That’s the maximum time frame before we deliver a new product increment. And that’s where we started two years ago. Since then, we've considerably increased our ability to deliver software into production. On 24th October 2013, besides going live, we subsequently pushed 7 deployments live. That’s roughly one live deployment per hour. Quite a step, considering the monthly „feature releases“ we were used to and the two-week increments we started with. So, what in terms of software development did we do for that? Here’s ourrecipe for velocity:

  • Make sure you pay attention to quality. In the project management triangle of time, scope and budget, do not adjust quality, make quality a requirement.
  • Use the patterns and methods summed up under the term Continuous Delivery. Check our blog posts on Continuous Delivery with Feature Toggles and Blue-Green-Deployment for details on how we did it.
  • Encourage pair programming to spread knowledge and find bugs when you make them, not days or weeks later. Read our blog post on  14 friends of pair programming to find out more about how we learn and promote pair programming.
  • Introduce TDD/BDD to make sure what you've built is right - and that it stays like that! Our code base is almost equally distributed between (unit-) test code and production code.
  • Have dedicated QA experts in every team: to work with business and development, to get acceptance criteria and tests as early as story-writing, find bugs and ensure the definition of done is achieved.
  • Introduce a zero-bug policy to keep the software clean. In the short run, this will make you slower, because, a minor bug will be treated with higher priority than a major user story. In the long run, this makes you quicker as you don’t build up bug-backlogs with extra overhead such as „bug-fixing-teams“. You can concentrate on permanent feature development.

All these measures give us a lot of security that we can go fast without making a mess!

"Agile processes promote sustainable developent. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Did I mention that we've just finished sprint no. 56? Did I mention that going live was practically a “non-event”? Can you imagine what we are doing now. Correct: sprint no. 57. Constant pace is about two things. First, follow our recipe for velocity mentioned above. Second, don't try to reach your sprint goal by staying at work until 3am every two weeks before the end of the sprint. Constantly measure your average velocity of the past 5 sprints. Use the average velocity to forecast what you will be able to deliver next sprint and to plan ahead. Once the team is up and running, keep the velocity constant. If that's not enough, consider adding people to the team, but keep Brooks's Law in mind. If that's still not enough, consider setting up a further team, but make sure to do that early enough in the process to actually make that effective. And, last but not least, find those pain-points in your software and your process that make you slow. A good Scrum team will be quiet at the end of the sprint, working normally – not frantically bug fixing. And that will make people enjoy their work for a long time without needing a long recovery from a chaotic project. And that's what I would call constant pace.

BTW: I was wondering if “sprint” is the right word to use in this context?

"The best architectures, requirements, and designs emerge from self-organizing teams."

If you want to find out more about the architecture of LHOTSE, check out our previous blog post or our article published in OBJEKTspektrum In a nutshell, the main concept behind the architecture of LHOTSE and how we put business domains, corporate organisation and software architecture together, is “divide and conquer”. A very old and very new and very “en-vogue” concept – and a very powerful one. So how does that fit the principle heading this paragraph? Well, sort of semi. On the one hand we have a macro architecture designed up-front and imposed on all teams. Does not sound agile? OK, here's the pros: The macro architecture is very basic, very short and mainly focusses on loose coupling to make software modules, business domains and teams independent from each other. That's the law. That's not discussable. For each independent business domain and software module, however, there's maximum freedom. That's our micro architecture: Teams can chose their programming language, their data base system, their frameworks, their coding-style and design patterns. And why? Because the teams know best how to fit business and software together. OK, to be honest, we do have a rule that requires common base technologies, e.g. Java as programming language, git for version control, MongoDB as database, etc. We don't deliberatly make things as diverse and complicated as possible just for the sake of it. However, the point here is, that this is discussable.

Is that it?

That's it... at least from me in this post. Perhaps you've noticed that I only covered half of the Principles behind the Agile Manifesto. That's deliberate. It leaves room for further improvement. It leaves room for a sequel to this blog post. And it also symbolizes that it takes much more to make a project like LHOTSE successful.

6Kommentare

  • Ole
    14.12.2013 14:40 Uhr

    Nice article, Stephan. Regarding the word "sprint", in our project we dropped it in favor of "iteration". Well, and then we switched to Kanban, in order to achieve even higher agility.

  • Auf der Suche nach der perfekten Pattern Library (Bauanleitung für eine Pattern Library – Teil 2)
    10.06.2014 09:31 Uhr

    […] gedacht und erforderte viel Disziplin. Erschwerend kam hinzu, dass unsere Patterns während der agilen Entwicklung im Projekt Lhotse noch nicht stabil genug waren und oft noch mehrfach angepasst werden […]

  • Johannes Mainusch
    31.03.2014 17:02 Uhr

    cooler Artikel, werde ich in eine meiner Präsentationen einbauen :-)
    docjoe

  • Bauanleitung für eine Pattern Library – Teil 1: Warum braucht man eigentlich eine Pattern Library? | produktbezogen.de
    23.04.2014 09:15 Uhr

    […] ich als Interaction Designer im eCommerce von OTTO angeheuert. Zur gleichen Zeit nahm das interne Projekt „Lhotse“ Fahrt auf, in dem bis zum erfolgreichen Launch im Oktober 2013 die komplette eCommerce-Plattform […]

  • Null Toleranz für Fehler – Neuer Artikel im OBJEKTspektrum über Qualität auf otto.de | dev.otto.de
    18.12.2015 14:55 Uhr

    […] Successful Mountaineering – Reaching the Summit of LHOTSE with Agile Software Development http://dev.otto.de/2013/12/09/successful-mountaineering-reaching-the-summit-of-lhotse-with-agile-sof… […]

  • Warum braucht man eine Pattern Library? (Design Systems 101 – Teil 1)
    28.03.2018 06:00 Uhr

    […] ich Ende 2011 im eCommerce-Bereich von OTTO als Interaction Designer angeheuert habe, nahm dort das Projekt „Lhotse“ fahrt auf. In diesem wurde die vorher genutzte Intershop-Lösung durch eine komplett inhouse […]

Dein Kommentar
Antwort auf:  Direkt auf das Thema antworten
8223 + 3
Written by
Tech-Blogger
architecturedevelopment

Ähnliche Artikel

  • Frontends with Microservices
    16. Mär 2021
    André, Heiko

    Frontends with Microservices

    Over the past few years, microservices have grown into an established architectural approach. They are now so well established ...
    architecturedevelopment
    mehr erfahren
  • Personalizing product rankings for online retailers
    04. Feb 2021
    Andreas, Josefine

    Personalizing product rankings for online retailers

    Clustering shop visitors based on profile attributes (e.g., based on shopping behavior) can be used to provide personalized ...
    development
    mehr erfahren
  • SLIM: Hydrating cloud native CI/CD pipelines to securely access GCP projects
    04. Feb 2021
    Dr. Mahmoud Reza

    SLIM: Hydrating cloud native CI/CD pipelines to securely access GCP projects

    Only too often generating and copying keys around is the way to go to talk to APIs for example from inside a container. This ...
    architecturedevelopment
    mehr erfahren

Dein Profil - Deine Vorteile

In deinem personalisierten Dashboard kannst du deine Bewerbungen verfolgen, zwischenspeichern und abschicken. Finde leicht Jobs, lies die wichstigsten Jobnews und Eventvorschläge und verfolge den aktuellen Stand deiner Bewerbung.

Jobticker & Jobnews
Jobticker & Jobnews

Jobticker & Jobnews

Gespeicherte Jobs
Gespeicherte Jobs

Gespeicherte Jobs

Laufende Bewerbungen
Laufende Bewerbungen

Laufende Bewerbungen

Bewerberstatus
Bewerberstatus
Bewerber­status
Profil anlegen

Jobticker

Abonniere hier unseren Jobticker, um wöchentlich per E-Mail über neue Jobs informiert zu werden.

Wähle bitte aus für welche Jobs du benachrichtigt werden möchtest.
Wähle bitte aus für welche Jobs du benachrichtigt werden möchtest.
E-Mail-Adresse nicht gültig

Folge uns.

 
 
 
 
 
 
 
 
 
 
 
 

Jobs

  • Jobsuche
  • Jobticker
  • Profilbereich

Deine Möglichkeiten

  • Einstiegsbereiche
  • Schüler*innen
  • Studierende
  • Berufseinsteiger*innen
  • Berufserfahrene

Technologie

  • Tech-Hub
  • Tech-Blog
  • Open Source Projekte
  • Arbeitsweisen
  • Teams
  • Tech-Gespräche mit Profis
Otto
Otto Group Karriere
Otto Unternehmen
Otto Newsroom
www.otto.de
Kontakt

Kontaktiere uns

Otto Campus
Werner-Otto-Straße 1-7
22179 Hamburg
jbttd

© Otto (GmbH & Co KG), 22179 Hamburg
  • Impressum
  • Datenschutz
Wie kann ich dir helfen? 
Chatbot

Otto und Partner brauchen für einzelne Datennutzungen deine Einwilligung, um dir unter anderem Informationen zu deinen Interessen anzuzeigen. Mit Klick auf „OK“ gibst Du diese Einwilligung. Deine Einwilligung kannst Du hier ablehnen.