Kolumne

DevOps Stories: Viel hilft nicht immer viel: Über den richtigen Umgang mit Engpässen

Konstantin Diener

Das MusicStore-Team steht vor seinem Taskboard und diskutiert die Arbeit für die kommenden Tage.

  • Ruben (Scrum Master): „In der letzten Retrospektive ist euch aufgefallen, dass die Arbeit im Moment nur sehr schleppend vorangeht. Ihr wolltet diesen Punkt untersuchen und herausfinden, woran es liegt. Wisst ihr mittlerweile mehr?“
  • Lukas: „Die Tasks haben sich an unserem Board immer in der Spalte „Entwicklung“ gesammelt. Das kam uns komisch vor, weil wir eigentlich der Meinung sind, dass die Softwareentwicklung gut vorangeht.“
  • Martin: „Wir haben den Schritt in die verschiedenen Tätigkeiten zerlegt, die darin zusammengefasst waren …“
  • Christian: „… und sehen jetzt, dass das UX- und Grafikdesign das Problem ist. Ian ist völlig überlastet und kommt mit den Tasks gar nicht mehr hinterher. Oder, Ian?“
  • Ian: „Ja, so ist es. Ich bin aber auch oft blockiert, weil meine Fragen zu Entwürfen von Erik gar nicht oder sehr spät beantwortet werden. Außerdem bekomme ich die Aufgaben immer als Päckchen und nicht kontinuierlich.“
  • Ruben: „Das heißt, es gibt Zeiten, in denen du dann einfach untätig warten musst?“
  • Ian: „Nee, das kommt nicht vor. Dann kümmere ich mich um meine anderen Themen.“
  • Ruben: „Was sind das für andere Themen?“
  • Ian: „Erik hat im Moment wenig Zeit, weil er an einem Pitch Deck für MusicStore arbeitet – und dafür mache ich das Design der Folien. Außerdem haben mich Gordon und Lars gebeten, ihnen ein Logo für ihr Meetup zu bauen. Und Jessica aus dem Marketing bereitet gerade die Fotos der letzten Firmenveranstaltung auf und hat immer wieder Fragen zu Photoshop.“
  • Lukas: „Mir war gar nicht klar, dass du so viele Themen nebenher hast!“
  • Ruben: „Sind das alle „Nebentätigkeiten“?“
  • Ian: „Im Großen und Ganzen. Vielleicht noch einige Kleinigkeiten hier und da …“
  • Christian: „Wir müssen einfach mehr Designer einstellen!“
  • Ruben: „Mir erscheint es wichtiger, dass Ian sich erst einmal auf seine eigentliche Aufgabe konzentrieren kann. Außerdem braucht die Einarbeitung eines weiteren Kollegen auch ihre Zeit, wenn wir einen gefunden haben …“
Abb. 1: Ian berichtet dem Team von seinen Nebentätigkeiten

Abb. 1: Ian berichtet dem Team von seinen Nebentätigkeiten

Es gibt immer einen Engpass!

Das MusicStore-Team beginnt, intensiver mit seinem Taskboard zu arbeiten, um seine Arbeit und deren Fluss besser zu „begreifen“ (siehe [1], warum sich physische Boards hierfür besonders gut eignen). Vorher hatten sie allenfalls ein vages Gefühl, warum die Entwicklung so langsam verläuft. Jetzt sehen sie es auf einen Blick an ihrem Board (Abb. 2 und Abb. 3).

Abb. 2: Das Board vor der Änderung

Abb. 2: Das Board vor der Änderung

Abb. 3: Die Visualisierung deckt den Engpass auf

Abb. 3: Die Visualisierung deckt den Engpass auf

Was sie hier erleben, ist durch die Engpasstheorie (Theory of Constraints) [2], [3] beschrieben. Sie besagt, dass es in einem System immer mindestens einen Engpass gibt, der den Durchsatz des Systems beschränkt. Das ganze System kann nur so schnell produzieren, wie es dieser Engpass tut. Wenn man den Durchsatz des gesamten Systems erhöhen möchte, sind also alle Optimierungen abseits des Engpasses sinnlos. Einzig Veränderungen am Engpass sorgen für eine Verbesserung. Zu beachten ist dabei, dass ein System immer einen Engpass haben wird, weil sonst der Durchsatz unendlich und die Arbeit in dem Moment erledigt wäre, in dem sie begonnen worden ist. Nichtsdestotrotz lohnt es sich in der Regel, Arbeit in die Optimierung bzw. Eliminierung des aktuellen Engpasses zu investieren. Dazu muss man ihn allerdings zunächst einmal finden!

Erst den aktuellen Engpass im Arbeitsfluss aufdecken …

Die Visualisierung des Arbeitsflusses in Form eines (Kanban-)Boards hilft dabei, den Engpass zu finden. Gibt es am Board Pufferspalten [3], [4], die sich zunehmend füllen? Führt die Einhaltung von WIP-Limits (Work in Progress) zu einem „Rückstau“ in den vorherigen Spalten am Board?

Lukas und seine Kollegen haben die Visualisierung gezielt darauf angepasst, damit sie den Engpass besser identifizieren können. Diese Änderung hat sich bezahlt gemacht, weil sie dadurch nun genau wissen, dass im Moment das Grafik- und UX-Design ihren Engpass darstellen. Vermutlich haben sich am neu gestalteten Board die Post-its wie in Abbildung 2 in dem Puffer vor dem entsprechenden Schritt angesammelt. Und im Gespräch mit Ian stellt sich ebenfalls heraus, dass er mit der Arbeit im Moment nicht wirklich nachkommt.

Da der Engpass nun bekannt ist, kann das Team daran arbeiten.

… und dann an diesem Engpass arbeiten

Christian zeigt dabei eine verbreitete Reaktion: Lasst uns einfach mehr Designer einstellen! Zunächst einmal gilt hier Brooks’ Law: „Adding human resources to a late software project makes it later“ [5]. Tatsächlich ergeben sich aus dem Gespräch des Teams einige Ansatzpunkte, wie der Durchsatz des Engpasses verbessert werden kann.

In der Engpasstheorie gibt es eine Art Anleitung, wie Lukas und seine Kollegen strukturiert mit der Situation umgehen sollten, dass Ian sehr oft überlastet ist (Kasten: „Die fünf Fokussierungsschritte“). Der erste Schritt, den Engpass zu identifizieren, ist bereits erledigt. Der nächste Schritt versucht nicht, den Engpass zu vergrößern/erweitern – was Christian vorschlägt – sondern optimal auszunutzen. Das klingt zunächst einmal unsinnig. Ian ist im Moment bereits völlig überlastet, wie soll er noch besser ausgenutzt werden? Es geht aber nicht darum, ihn noch mehr auszunutzen, sondern optimal im Hinblick auf seine Fähigkeiten, die den Engpass für das Produkt bedeuten. Er ist der einzige, der das Grafik- und UX-Design für MusicStore machen kann. Deshalb sollte er sich in seiner kompletten Arbeitszeit ausschließlich mit dieser Tätigkeit beschäftigen.

In Schritt 3 geht es dann darum, Ian genau diese Fokussierung zu ermöglichen. Zunächst einmal müssen Ian, das Team und Ruben, der Scrum Master, dafür sorgen, dass er keine Nebentätigkeiten mehr hat, die ihn von seiner „eigentlichen“ Arbeit abhalten.

Er kam überhaupt erst in die Versuchung, diese Tätigkeiten anzunehmen, weil die Arbeitsabläufe im Team bei ihm immer wieder zu Leerlauf geführt haben. Im Sinne der fünf Fokussierungsschritte aus der Engpasstheorie muss das Team seinen Arbeitsablauf so umstellen, dass bei Ian im Hinblick auf Grafik- und UX-Design kein Leerlauf entsteht, sondern immer genug Arbeit da ist. Dafür muss die von ihm beschriebene Lieferung in Form von Arbeitspäckchen aufhören.

Erst wenn der Engpass optimal ausgenutzt ist, kann sich das Team damit beschäftigen, ihn zu erweitern und z. B. einen weiteren Designer einstellen und ins Team aufnehmen. Wird der Engpass dann erweitert, entwickelt sich eine andere Stelle im Arbeitsablauf zum neuen Engpass und die Fokussierungsschritte beginnen von vorne.

Die fünf Fokussierungsschritte

Für jeden Engpass sollten die folgenden Schritte durchlaufen werden [4]:

  1. Finde den Engpass.
  2. Entscheide, wie dieser Engpass optimal ausgenutzt werden kann.
  3. Ordne alles andere im System der Entscheidung aus Schritt 2 unter.
  4. Erweitere den Engpass.
  5. Bleibe nicht untätig, sondern finde direkt den nächsten Engpass und fahre mit Schritt 2 fort.

Das Team ist wie oben beschrieben vorgegangen. Sie haben es gemeinsam mit Ruben geschafft, dass Ian alle Nebentätigkeiten einstellen und sich auf seine Hauptaufgabe konzentrieren kann. Mit Erik, dem Product Owner, haben sie außerdem ein Vorgehen abgestimmt, das sicherstellt, dass Ian nicht mehr auf Arbeitspäckchen warten muss. Allein diese Maßnahmen haben bereits für eine deutliche Verbesserung gesorgt.

Da viele der Nebentätigkeiten ja richtig und wichtig für die Firma sind, soll der nächste Schritt sein, einen weiteren Designer einzustellen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "DevOps Stories: Viel hilft nicht immer viel: Über den richtigen Umgang mit Engpässen"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Rainer
Gast

Jo geil und wer genau macht jetzt die „Nebentätigkeit“? Aus gesamter Firmensicht ist es ja nicht so dass die unnötig waren. Das ist alles so ein Wir=das Team only denken.