Chaos bei McBurger – Was Hamburger mit Lean Production zu tun haben

Bob: Genau. Offensichtlich ist die Verarbeitungskapazität der Hamburger-Brater zu klein im Gegensatz zur Verarbeitungskapazität der Verkäufer. Und da hat es überhaupt keinen Sinn, dass beide Gruppen unter Volldampf arbeiten. Stattdessen muss man die Verarbeitungskapazitäten beider Gruppen aneinander angleichen, im Zweifel durch das Verschieben von Ressourcen.

Jens: Cool. Da haben wir beide in den paar Minuten aber echt viel über Lean Production gelernt und darüber, wie McBurger seinen Laden besser organisieren kann.

Bob: Ich stimme dir zu, dass wir viel über Lean Production gelernt haben. Ob wir jetzt aber die großen McBurger-Experten sind, weiß ich nicht. Schließlich wissen wir nicht, was den Engpass an Hamburgern verursacht hat.

Jens: Stimmt. Wir sind schon ein wenig ins Spekulieren abgedriftet. Aber unsere „Erkenntnisse“ über Lean Production und Lagerhaltung stimmen trotzdem, oder?

Bob: Klar. Es kann ja gut sein, dass es genau so war, wie wir es angenommen haben.

Jens: Ah, da kommt mein Zug. Ich muss los. Mach’s gut.

Bob: Ich wünsche dir auch alles Gute. Das nächste Mal können wir ja mal drüber philosophieren, warum immer meine Bahn Verspätung hat.
Perspektivenwechsel

Was hat das alles mit Softwareentwicklung zu tun? Viel mehr als man auf den ersten Blick glaubt! Tatsächlich sind wir ständig von Lagern umgeben. Wir haben vielleicht hunderte von Bugs im Life-System, die wir im Bugtracker lagern. Oder dutzende Feature Requests unserer Kunden, die wir auch fein säuberlich dokumentieren und in immer länger werdenden Listen führen. Und Supportanfragen und Refactorings, die man mal machen sollte, und Doku, die wir noch schreiben müssen und, und, und. Wir schaffen Lager für Aufgaben im weitesten Sinne. Dabei haben wir häufig mit ähnlichen Problemen zu kämpfen wie McBurger. Das Gesamtsystem zur Aufgabenbearbeitung arbeitet nicht in einem gleichmäßigen Flow. Stattdessen nehmen wir z. B. Feature Requests der Kunden schneller an, als wir sie dauerhaft abarbeiten können. Konsequenz: Die Liste der Feature Requests wird immer länger. Und dann kommt der Burger, der wirklich schwer zu schlucken ist: Es ergibt keinen Sinn, diese ganzen Feature Requests vom Entwicklungsteam verwalten zu lassen. Sie werden sie wahrscheinlich sowieso niemals abarbeiten können. Und selbst wenn das tatsächlich mal passiert, hat sich bei den Feature Requests inzwischen soviel geändert, dass die Welt schon wieder ganz anders aussieht.

Stattdessen gehört das Lager für abzuarbeitende Features im Entwicklungsteam beschränkt, z. B. auf zehn Stück. Die konkrete Zahl für die Beschränkung hängt davon ab, wie stark Ankunftswahrscheinlichkeit neuer Feature Requests und Entwicklungsgeschwindigkeit des Teams schwanken. Bei großen Schwankungen benötigt man ein größeres Lager. Wenn das Lager voll ist und ein elfter Feature Request hereinkommt, kann er nur dann aufgenommen werden, wenn ein anderer Feature Request aus dem Lager geworfen wird.

„Super-Idee. Da reißt mir mein Chef doch direkt den Kopf ab. Wir können doch nicht einfach Feature Requests der Kunden wegwerfen.“ Das können wir vielleicht nicht als Unternehmen, als Team aber sehr wohl. Wir bauen dann eben ein zusätzliches Lager für Feature Requests auf, z. B. im Vertrieb oder in den Fachabteilungen selbst. Das wirkt vielleicht zunächst wie ein Taschenspielertrick (wir verschieben ja nur von einem Lager in ein anderes). Das zweite Lager bringt aber eine Reihe von Vorteilen:

  • Subjektiv hat das Entwicklungsteam weniger Stress. Es wird nicht mehr von tausenden Feature Requests „erschlagen“, die es sowieso niemals schaffen kann.
  • Der „Besitzer“ des Feature Requests wird explizit gemacht und damit auch die Verantwortung für die Verwaltung und gegebenenfalls Aktualisierung. Solange die Features im ersten Lager sind, ist der Kunde oder Vertrieb oder sonstwer verantwortlich, aber nicht das Team.
  • Damit ist auch gleichzeitig klar, dass der Feature Request nach Übergabe in das Lager des Entwicklungsteams nicht mehr vom Autor (z. B. Kunde) geändert werden darf.
  • Diesem Besitzer des Lagers wird explizit Bescheid gegeben, wenn das Team überlastet ist. Er sieht, dass sein Lager schneller wächst als es abgearbeitet werden kann. Das bringt ihm wichtige Informationen und er kann auf dieser Basis bessere Entscheidungen fällen. Er könnte sich z. B. bei der Formulierung neuer Feature Requests zurückhalten und nur die wirklich wichtigen Dinge im Detail ausformulieren. Das spart ihm Arbeit.

Wer Scrum richtig betreibt, wird hier viele Ähnlichkeiten feststellen. Das Lager bei den Entwicklern ist das Sprint Backlog, das beim Kunden das Product Backlog. Allerdings sind die beschriebenen Techniken auch ohne Scrum anwendbar.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.