In vielen Teams wird an zu vielen Dingen gleichzeitig gearbeitet. Problematisch ist das meist am Monatsende, denn hier ist wenig abgeschlossen. Lean geht anders an die Sache heran: wenige Aufgaben parallel, dafür schneller fertig.
Ein Teil der Lean-Prinzipien lässt sich mit Werkzeugen abbilden, die du vermutlich schon hast. Wenn in deinem Redmine eine aktuelle Reporting Plugin Version läuft, brauchst du dafür kein weiteres Tool.
Definition von Lean: James Womack und Daniel Jones haben Lean 1996 in Lean Thinking auf fünf Prinzipien gebracht: den Wert aus Kundensicht bestimmen, den Wertstrom analysieren, einen gleichmäßigen Fluss erzeugen, Arbeit ziehen statt zuteilen und den Ablauf laufend verbessern. Mit dem Ziel alles wegzulassen, was keinen Wert für den Kunden erzeugt.
Wer damit arbeitet und wann es sich lohnt
Lean stammt ursprünglich aus dem Toyota-Produktionssystem der 1950er Jahre. Die Arbeitsweise kam später in die Verwaltung, in Krankenhäuser, ins Bauwesen und in die Softwareentwicklung. Hier ist Dir sicherlich Kanban ein Begriff. Viele Teams arbeiten nach Lean-Prinzipien und nennen es Kanban.
Es lohnt sich bei wiederkehrender Arbeit mit laufendem Zulauf: Support und Service, Wartung und Betrieb, Verwaltungsvorgänge, Ticketarbeit in IT-Abteilungen. In der Regel überall dort, wo sich die Arbeit schlecht im Voraus planen lässt.
Bei einmaligen Vorhaben mit festem Termin und Umfang passt es weniger, etwa bei einer Migration oder einem Umzug. Dort planst du besser mit Terminen und Abhängigkeiten, in Redmine also mit dem Gantt-Diagramm.
Den Ablauf sichtbar machen
Das erste Prinzip ist eine Absprache im Team: Wofür bezahlt der Kunde? Dafür gibt es kein Werkzeug.
Beim zweiten hilft Redmine. Der Wertstrom ist hierbei die Abfolge der Schritte, die ein Auftrag durchläuft. Bilde diese Schritte als Status ab, auch die Wartestatus: Wartet auf Kunde, Wartet auf Freigabe, Wartet auf Zulieferung. Fehlen sie, tauchen die Liegezeiten nirgends auf.
Im Taskboard werden die Status zu Spalten. Eine Spalte Wartet auf Kunde zeigt, wie viele Tickets gerade nicht bei Dir liegen. Mit einer Gruppierung kommen Swimlanes dazu, also eine waagrechte Zeile je Gruppe, zum Beispiel je Person oder je Zielversion.
Angefangene Arbeit begrenzen
Ein WIP-Limit legt fest, wie viele Tickets in einer Status-Spalte gleichzeitig liegen sollen. WIP steht für Work in Progress, also angefangene Arbeit.
Im Taskboard trägst du das Limit pro Spalte ein, entweder beim Bearbeiten der gespeicherten Abfrage oder direkt am Spaltenkopf. Ist es überschritten, markiert das Board die Spalte. Verschieben kannst du ein Ticket trotzdem, das Limit blockiert nichts.
Volle Spalten zeigen den Engpass im Ablauf. Wie du die passende Zahl findest, steht im Beitrag über WIP-Limits.
Arbeit ziehen statt zuteilen
Pull heißt: Wer Kapazität hat, holt sich die nächste Aufgabe. Die Alternative ist die Zuteilung im Voraus. Dann hat jeder eine lange Liste und niemand weiß, was zuerst dran ist.
Am Board läuft das so: Eine Spalte (z.B. Backlog) enthält die freigegebenen Tickets. Wer fertig ist, nimmt sich das oberste Ticket und weist es sich zu, indem er seinen Avatar auf die Karte zieht. Das Ticket muss dafür nicht geöffnet werden.
Die Reihenfolge innerhalb der Spalte folgt der Sortierung deiner Abfrage, also zum Beispiel Priorität oder Abgabedatum.
Nacharbeit messen
Nacharbeit fällt in Auswertungen kaum auf. Ein Ticket geht von der Prüfung zurück in die Bearbeitung, wird erneut geprüft und geht wieder zurück. Es entsteht gebuchte Zeit, der Auftrag kommt aber nicht weiter.
Das Reporting Plugin zählt diese Schleifen als Round Trips. Ein Anwender mit Administrationsrechten legt in der Plugin-Konfiguration fest, welcher Statuswechsel gezählt wird, welcher Status als Vorstufe gilt und welcher den Zähler zurücksetzt. Dazu kommt ein Schwellwert, ab dem Redmine eine Warnung anzeigt.
Der Zähler steht danach als Spalte in der Ticketliste zur Verfügung und lässt sich als Summe über eine Abfrage anzeigen. Es gibt ihn zweimal: Round Trips zählt ab dem letzten Zurücksetzen, Round Trips (Gesamt) über die gesamte Laufzeit des Tickets.
Beide sind auch Filter. Du kannst dir die Ticketliste also auf alle Tickets ab drei Runden einschränken und das Ergebnis als Abfrage speichern.
Damit siehst du, welche Tickets mehrfach dieselbe Schleife drehen und bei welchem Tracker das häufiger vorkommt. Die Ursache liegt meist in einer unklaren Aufgabenbeschreibung oder in einer Abnahme ohne festgelegte Kriterien.
Wie lange Tickets schon liegen
Die zweite Kennzahl aus dem Reporting Plugin ist die Ticket Lebensdauer. Bei offenen Tickets ist das die Zeit seit dem Anlegen, bei geschlossenen die Zeit vom Anlegen bis zum Abschluss.
Es gibt sie als Spalte in der Ticketliste, als Feld auf der Board-Karte und als Filter mit festen Stufen von 30 Minuten bis zu 12 Monaten. Mit dem Operator ist nicht und der Stufe weniger als 2 Wochen bekommst du alle Tickets, die älter als zwei Wochen sind.
Diese Abfrage speicherst du und aktivierst dafür eine Zählerbox. Die Zahl der liegengebliebenen Tickets steht dann auf der Startseite oder in der Projektübersicht, ohne dass jemand danach suchen muss.
Regelmäßig nachsehen
Verbesserung braucht Zahlen aus dem Alltag. Zählerboxen auf der Startseite zeigen jedem Anwender, was offen ist und was auf ihn wartet.
Für Statusmeetings stellt sonst jemand die Zahlen von Hand zusammen. Ein Dashboard nimmt sie aus den laufenden Daten: offene Tickets je Status, überfällige Aufgaben, gebuchte Zeiten, Round Trips.
Im Support kommt das SLA-Modul dazu. Es misst Reaktions- und Lösungszeit und berücksichtigt dabei Geschäftszeiten und Feiertage.
Wo Redmine an Grenzen kommt
Zwei Auswertungen, die in Lean üblich sind, gibt es nicht fertig:
- Durchschnittswerte zur Durchlaufzeit. Die Lebensdauer steht je Ticket zur Verfügung, eine Auswertung über alle Tickets hinweg nicht. Wie sich die durchschnittliche Durchlaufzeit über die Monate entwickelt, musst du über einen Export ermitteln.
- Auswertung des Flusses über die Zeit. Ein Cumulative Flow Diagram, also die Entwicklung der Bestände je Status über Wochen, gibt es nicht. Ebenso wenig einen fertigen Chart für den Durchsatz, also die Anzahl abgeschlossener Tickets pro Woche. Über Zählerboxen mit passenden Abfragen kommst du an eine Näherung.
Wer diese Zahlen dauerhaft braucht, arbeitet mit einem Export in ein Auswertungswerkzeug oder mit einem spezialisierten Kanban-Tool.
Fazit
Für den operativen Teil von Lean ist das Reporting Plugin ein Hilfswerkzeug: Ablauf sichtbar machen, angefangene Arbeit begrenzen, Engpässe und Nacharbeit erkennen. Dafür brauchst du kein zweites System neben Redmine.
Bei der Auswertung des Arbeitsflusses über die Zeit hört es früher auf als bei spezialisierten Kanban-Werkzeugen. Nur wer diese Zahlen dauerhaft braucht, kommt um einen Export oder ein zusätzliches Werkzeug nicht herum.