Die Hamburger Methode – technischen Umfang beschränken

Während das ständige Mantra guter ScrumMaster und Product Owner „Das muss kleiner gehen“ und „Wie könnten wir das in 2 – 3 funktionierende Unterversionen schneiden?“ lautet, gibt es immer wieder Herausforderungen, in denen die bekannten Werkzeuge versagen.

In einem Projekt durfte ich einmal zusammen mit Markus Fidelak arbeiten. Gemeinsam beschäftigten wir uns mit verschiedenen Methoden des Story-Schnitts und er brachte mir „Die Hamburger-Methode“ bei. In dieser Methode geht es nicht um einen Erfinder aus Hamburg, sondern schlicht und einfach das metaphorische Bild eines geschichteten Stückchen Brotes.

Weiter unten habe ich eine konkrete kurz gefasste Anleitung (Rezept :)) dieser Methode für euch und eure Teams zum Ausprobieren hinterlegt.

Grundgedanke

Bei der Hamburgermethode geht es darum, ein in den Köpfen vorhandenes Feature auf seine technischen Bestandteile herunterzuschneiden.

Man beginnt mit der Betrachtung der einzelnen Schichten. In unserem Bild eines saftigen Hamburgers also:

• Unter dem Deckel finden wir zuerst den Käse, also das UI.
• Direkt darunter ein saftiges Blatt Eisbergsalat, das im Client vorhandene Backend.
• Vielleicht haben wir Extra Bacon. Also eine Datenhaltung im Thin Client. Vielleicht ist die Datenhaltung aber auch komplett nicht vorhanden, sondern nur in der Cloud gesichert?
• Dann kommt das dicke Stück Fleisch. Das Herz der Anwendung, das Backend auf dem Server, welches die meisten Berechnungen übernimmt.
• und und und. Der freien Zutatengestaltung sind hier keine Grenzen gesetzt.

Um das ganze etwas detaillierter ansprechen und erklären zu können, bediene ich mich einem Beispiel: Nehmen wir an, unser Team soll eine Funktion erstellen, welche es Nutzern erlaubt, perfekte maßgenaue Schränke für die eigene Wohnungseinrichtung zu entwerfen.

Der Ablauf

Schritt 1 – Problem verstehen, Zutaten festlegen:

In einem gemeinsamen Workshop zwischen Anforderer, PO und Team könnte man also einmal versuchen, diese Anforderung in ihre Zutaten zu zerlegen. Irgendwo muss der Benutzer seine Informationen eingeben. Also welche Maße der Schrank braucht.
Damit der Schrank überhaupt baubar ist, müssen wir dann die eingegebenen Daten validieren. Ist dieser also überhaupt stabil, haben wir die erforderlichen Brettlängen, etc.
Um den Schrank anzufertigen, muss dieser Auftrag an den uns angebundenen Schreiner übergeben werden. Für diesen Prozessschritt benötigen wir also auch eine Lösung.
Ist der Auftrag im Gange, benötigt der Kunde noch eine Auftragsbestätigung.
Um den Kunden auf Dauer zu halten, Trends zu erkennen und besseres Marketing machen zu können, sollten wir über eine CRM Integration nachdenken.

Der grobe Aufbau, Welche Zutaten benötigt unser Burger?

Schritt 2 – Zutaten ausgestalten:

Im zweiten Schritt geht es um die konkrete Ausgestaltung der einzelnen Zutaten. Um den Fokus zu erhöhen, kann es sinnvoll sein, diesen Schritt in einzelnen kleinen Gruppen und bei Bedarf mit Fokus auf nur eine Zutat durchzuführen.
Ziel ist also sowohl in einem schnellen Time to Market schnelle Lösungen, gleichzeitig aber auch visionäre Ideen zu entwerfen. Je weiter rechts eine Idee steht, desto aufwändiger ist sie in der Umsetzung, aber desto wertvoller sollte sie dann auch für den Benutzer sein. Ganz links hingegen finden sich die Quick Wins oder Workarounds.

Welche Ausgestaltungen der einzelnen Zutaten können wir uns vorstellen?

Schritt 3 – Burgerversionen definieren:

Im dritten und letzten Schritt geht es nun darum, den PO bei der Ausgestaltung sinnvoller Versionen zu unterstützen. Selbstverständlich könnte man jeden einzelnen grauen Kasten nacheinander umsetzen. Ebenso selbstverständlich ist, dass auf diesem Wege auch sehr lange nicht nutzbarer Code entstehen könnte.
Welche Teile würden wir benötigen um das erste Mal mit dem Kunden in Kontakt zu treten? Damit finden wir dann auch heraus, ob das Produkt überhaupt eine Zielgruppe hat. Ob man diese Version dann einen MDP (Minimum Desirable Product), MVP oder Prototypen nennen möchte bleibt dann jedem selbst überlassen.
Angenommen wir haben diese V1 unseres Produktes gefunden, welchem Ziel sollten wir uns im 2. Fokus widmen?

Nun kann man seinen Fokus auf die einzelnen Versionen V1, V2, V3 setzen und daraufhin seine User Stories aufbauen. Einer Aufnahme in das Product Backlog steht dann also nichts mehr im Wege.

Konkrete Anleitung in 3 Schritten

1. Wie viele Schichten braucht der Burger
   1. Finde von oben nach untern heraus, wie viele Zutaten dein Burger haben wird
   2. Benenne die einzelnen Schichten
2. Welche Ausbaustufen haben unsere Zutaten?
   1. Von links nach rechts, welche Ausbaustufen fallen uns in der konkreten technischen Implementation ein?
   2. Ist ein „nicht umsetzen“ eine legitime Version?
3. Wie viele und welche Versionen können wir uns vorstellen?
   1. Versuche so viele Versionen wie möglich darzustellen
   2. Welche dieser Versionen erzeugen einen Wert (Risikoverringerung / Kundennutzen)

Noch mehr Werkzeuge wie diese würden euch in der täglichen Arbeit unterstützen? Unsere Advanced und Professional Product Owner und ScrumMaster Kurse zielen nicht auf Anfänger, sondern auf Personen, welche bereits Erfahrung haben, ihre Expertise und ihren Werkzeugkoffer erweitern wollen. Weitere Infos findest du unter: emendare.de/training/