Einen eklatanten Bedarf für neue Methoden oder “Typen” im Softwareentwicklungs-Projektbereich gibt es schon seit Jahrzehnten. Denn was uns die Vergangenheit lehrt ist, dass die Wasserfall-Entwicklung nicht nur oft schlechte, sondern fast immer zu späte Ergebnisse liefert. Die Mischform Scrumban schafft dabei erste Abhilfe.

Wasserfall kommt zu spät

Gerade bei schnelllebigen Web-Plattformen ist es notwendig, innerhalb weniger Tage Änderungen oder Weiterentwicklungen vornehmen zu können. Scrum ist dabei meist der erste Schritt und eine einfache Methode, um mit dem Thema Agilität zu starten. Es gibt aber immer ein Gerüst von Regeln und Prozeduren (Planning, Estimation, Daily Standup usw.), mit der das Team zwar die gewünschte Eigenverantwortung übernimmt, dies aber innerhalb eines Rahmenwerkes praktiziert und somit wieder abhängig und nicht völlig frei agieren kann.

Praktikabler Kompromiss: Scrumban

Eine Mischung aus Scrum und Kanban funktioniert da schon besser: Man nutzt Kanban-Tafeln und Task-Zettel und vereinbart eigene Regeln (Policies), an die sich alle im Team halten müssen. Es werden regelmäßige Meetings abgehalten und ein Board aufgebaut (ToDo • Doing • Done – wobei Doing meist mehrere Phasen hat). Solche Regeln können zB sein:

• Tägliches Meeting beginnt immer pünktlich um 09:00 Uhr vor dem Kanban-Board
• Ein Entwicklertask der Klasse “S” sollte innerhalb eines Tages von “ToDo” bis “Done” vordringen
• Große User Stories müssen auf kleine Tasks heruntergebrochen werden
• Alle Stories werden in Aufgabenbereiche unterteilt, sodass diese jeweils von unterschiedlichen Personen erledigt werden können
• Mehr als drei Zettel gleichzeitig darf niemand am Board bearbeiten (WiP Limits)

Damit bleiben Abhängigkeiten erkennbar, Flaschenhälse werden sichtbar und Ineffizienzen bzw. Hindernisse lassen sich schneller identifizieren und beseitigen, was wiederum zum gewünschten “Flow” führt.

Continuous Flow

Um kontinuierliches Fließen zu gewährleisten, kann sogar Leerlauf an einer Arbeitsstation in Kauf genommen werden. ZB wenn ein Mitarbeiter kein neues Ticket öffnen kann, weil die nachfolgenden Stationen ihre Tickets noch nicht abgearbeitet haben. Und das ist in Kanban auch keineswegs ein Problem, denn: eine 100 %ige Auslastung ist selten optimal!

Denken wir an eine Autobahn: Ist diese zu 100 % ausgelastet, entsteht Stau. Aktuelles Beispiel: bei Tunneleinfahrten. Fährt jemand mit 120 km/h in einen Tunnel ein, nur um daraufhin gleich wieder abzubremsen, entsteht für die dahinter Stau. Für einen gleichbleibenden Verkehrsfluss ist es also vernünftiger, die Geschwindigkeit gleich auf 80 km/h zu reduzieren und mit gleichbleibender Geschwindigkeit durch den Tunnel zu fahren. Und was auf der Autobahn funktioniert, lässt sich auch im Arbeitsumfeld meist durchsetzen.

Natürlich erfordert dies ein Umdenken. Vor allem bei den Team- und Projektleitern, von denen noch viele nach wie vor der alten, taylorischen Meinung sind, dass nur voll ausgelastete Mitarbeiter gute Arbeitskräfte sind. Doch um Rückstaus zu vermeiden, müsse sich ab und an ein Mitarbeiter mit anderen, eventuell fremden Themen beschäftigen, zB:

• Einem Kollegen helfen (Pair Programming)
• Den Engpass dokumentieren, damit andere daraus lernen können (Lessons learned, “avoid late learning”)
• An der Optimierung des Gesamtsystem arbeiten
• Fachbuch lesen (auch von zu Hause aus) und durch Lernen die Kapazität erhöhen

Und wenn es trotzdem staut?

Bildet sich trotz ausreichend (kleiner) Skalierung und strikter Begrenzung des Work in Progress doch mal ein Rückstau, muss eine Team-Entscheidung her:

• Darf/soll die Aufgabe fallen gelassen werden?
• Gibt es alternative Lösungen?
• Muss man diese eventuell (noch mal) aufteilen?
• Benötigt man mehr Personalressourcen (was selten eine gute Idee ist, denn mehr Leute im Projekt bedeuten immer auch mehr Reibungsverluste!)?

Als praktikable Lösung könnte man hingegen die Automatisierung bestimmter Prozesse sowie die bessere Qualifizierung der Mitarbeiter in Erwägung ziehen.

Und mit all diesen Ansätzen ist man Kanban schon näher als man denkt.

Was Kanban genau ist und was Kanban mit “Kaizen” und einem “KVP” zu tun hat, lest Ihr in unserem nächsten Beitrag “Kanban in der IT”