Am Flughafen kann man lernen, Fluss herzustellen. So geschehen, als ich gestern von Hamburg nach Köln geflogen bin. Und gleich wird es wohl wieder geschehen, wenn ich zurückfliege.
Beim Boarding sollen ja in kürzester Zeit hunderte Passagiere durch ein Nadelöhr in die Maschine fließen. Da Nadelöhr ist die Prüfung der Bordkarte. Heute passiert das durch assistiertes Scannen.
Je Fluggast dauert das 4-5 Sekunden, schätze ich mal. Von Durchgehen kann da keine Rede sein. Und so entsteht ein ausgewachsener Stau vor den Scannern.
Das ist ok, die Passagiere murren nicht. Man fließt zwar nicht schnell, aber man fließt. Es ist absehbar, wann man drankommt, weil es vorwärts geht. Dafür sorgt das Flugsteigpersonal auch, indem es Variationen in der Durchschleusungsdauer von vornherein bedenkt. Menschen, die langsamer sind (Ältere, Behinderte, Kinder), werden gesondert zu Beginn durchgeschleust. Für die ist die Bearbeitungszeit länger oder gar unbestimmt lang, jenachdem, welche Hilfe sie benötigen. Damit will man den Fluss der Masse nicht aufhalten. Ein guter Gedanke.
Trotz dieser Maßnahme kann es jedoch passieren, dass die Prüfung bei den restlichen Passagieren unterschiedlich lange dauert. Mal 3 Sekunden, mal 6 Sekunden. Aber das ist ok. Die Variationen halten sich in Grenzen. Fluss entsteht.
Bis, ja, bis es zu einem Sonderfall kommt. Da rückt ein Passagier vor, der immer noch nicht seine Bordkarte gefunden hat. Da steht plötzlich ein Passagier am Scanner, der auf dem Smartphone seine Bordkarte nicht findet. Oder was auch immer. Es kann passieren, dass die Verarbeitungszeit für plötzlich und unerwartet stark ansteigt. Der langsame, jedoch stetige Fluss kommt zum Erliegen. Nach spätestens 20 Sekunden wir Murren laut. Köpfe recken sich. Was ist da los?
Solche Sonderfälle kann man nicht vermeiden. Trotz Vorsichtsmaßnahmen, trotz weitgehend homogenen Aufwands kann es immer zu Ausreißern kommen. Und das merkt man erst, wenn man die Verarbeitung schon begonnen hat. Was dann?
Bis zu einer gewissen Grenze muss das keine besondere Konsequenz haben. Shit happens. Also bleibt man ruhig und gibt dem Fluggast 10 Sekunden, um sich zu sortieren. Oder 12 Sekunden. Danach geht es wieder flüssig wie erwartet weiter.
Jenseits dieser Grenze jedoch, ist es klug, Maßnahmen zu ergreifen. Dann ist es klug, den "Störenfried" auszusondern. Raus mit ihm aus dem normalen Verarbeitungsfluss! Er muss den Weg freimachen für die anderen. Wer seine Bordkarte sucht, muss dafür nicht beim Scanner stehen. "Bitte treten Sie zur Seite!" Dort hat man dann alle Zeit der Welt oder kann sogar Hilfe in Anspruch nehmen.
Und genauso sollte es im Fluss der Softwareentwicklung sein. Um eine Homogenisierung der Größe von Features/User Stories sollte man sich bemühen. Dann kann Fluss entstehen. Für mich liegt diese Größe im Bereich von 0,5 bis 2 Tagen.
Bei aller Mühe gibt es jedoch keine Garantie, dass die Features/User Stories dann aber auch wirklich nur diesen Aufwand benötigen. Es kann mal schneller gehen - sehr schön, aber wohl eher selten. Es kann mal langsamer gehen - macht nichts, solange es im Rahmen ist. Dieser Rahmen ist vielleicht 0,5 Tage bei einer Aufgabe von geschätzten 2 Tagen.
Wird der Variationspuffer jedoch überschritten, gilt es, eine Konsequenz zu ziehen. Die lautet für mich: Raus aus dem Fluss!
Wenn eine Blockade auftritt, sollte das Feature/die User Story nicht einfach im Fluss belassen werden, um dort an ihr herumzudoktern. Stattdessen gilt es, den Weg für andere zu machen. Dann kann man abseits überlegen, wie das Problem gelöst werden kann.
Wer mit einem Taskboard arbeitet (oder einem Kanban-Brett), der sollte dafür eine eigene Schwimmbahn "Notaufnahme" oder so vorsehen. (Genauso, wie es eine für "Forschungsaufgaben" geben sollte.)
Dann wird deutlich, wo Hilfe nötig ist, ohne den Fluss zu behindern. Dann kann auch eine Repriorisierung stattfinden: Ist es jetzt wichtig, auf diesen Sonderfall weitere Ressourcen zu werfen? Oder ist es wichtig, andere Features/User Stories am Fließen zu halten?
Solange so ein Sonderfall einfach nur einen Platz des WIP-Limits im Hauptfluss belegt, stört er das ganze System. Klar, dann würde dieses Vorkommnis in einem CFD irgendwann zu sehen sein - aber das ist spät. In der Zwischenzeit ist es zu einem unnötigen Stau gekommen. Als würde ein liegengebliebener Wagen nicht von der Fahrbahn genommen.
Shit happens. Darauf sollte möglichst zeitnah reagiert werden, um nicht noch Folge-Shit entstehen zu lassen. Wie das geht, zeigt die Behandlung von unvorhersehbaren Variationen in der Passagierabfertigung am Flugsteig sehr schön, finde ich.
Keine Kommentare:
Kommentar veröffentlichen