Die Retrospektive: Quelle der Erkenntnisse
Nach zwei Wochen fand die erste Retrospektive statt und es geschah, worauf Theißen gehofft hatte:
Die Teammitglieder verstanden, dass jeder allein kämpfte. Wegen der personenbezogenen Tickets am Board fühlte sich immer nur der jeweilige Mitarbeiter verantwortlich und war er ausgelastet, ging nichts weiter. Es fehlte auch an Wissen, um Aufgaben anderer übernehmen und aushelfen zu können.
Das Team erkannte, dass das 15-minütige Daily den dreistündigen Jour Fixe ablösen konnte, der jeden Donnerstag stattfand. Das ergab für das gesamte Team einen Zeitgewinn von rund 16 Stunden pro Woche und trotzdem waren alle besser informiert als vorher.
Der Jour Fixe kehrte nach einer nächsten Retrospektive zurück. Allerdings trifft sich das Team nun für 45 Minuten zum Wissensaustausch über definierte Themen, die allen helfen, Vorgänge richtig abzuschließen. Zwar müssen die Juristen weiterhin mit dem Strom der Aufgaben leben, der jeden Tag in der Input Queue landet. Definierte Iterationen sind nicht möglich, weil oft nicht absehbar ist, wann etwas abgeschlossen werden kann. Aber das Kanban-Board und das tägliche Update machen die Prozesse transparenter, wiederkehrende Aufgaben werden sichtbar.
Damit jeder Anwalt wiederkehrende Vorgänge durchgängig bearbeiten kann, setzt das Team auf "Pair Contract Writing", bei dem zwei Anwälte an Verträgen arbeiten, um voneinander zu lernen. Dem Team wurde außerdem klar, dass viel Zeit auf nicht-juristische Aufgaben wie zum Beispiel Kostencontrolling verwendet wurde - das erledigt jetzt eine Betriebswirtin. Standardaufgaben durchlaufen so schneller den Arbeitsprozess und jeder spürt die Entlastung - etwa in Form ungestörter Urlaube.
- Prüfen von Anforderungen in agilen Projekten
Ohne die Priorisierung der Anforderungen des IT-Projekts drohen hohe Folgekosten in einzelnen Sprintphasen. - Verzögerungen durch exportierte Probleme
Neben dem Totalausfall eines Sprints gehören Verzögerungen zur Tagesordnung. Diese entstehen etwa bei unklar definierten Anforderungen, die eventuell im falschen Detaillierungsgrad vorliegen oder durch Überlastung des Product Owners verspätet priorisiert werden. - Zeitverluste durch fehlende Aufgabenzuordnung
Zunächst lassen sich nicht ausreichend gut definierte Anforderungen durch ohnehin erforderliche Routinearbeiten wie der Spezifikation technischer Anforderungen kompensieren. Später droht dagegen der Totalverlust ganzer Sprints. - Anforderungen treffen ungesteuert auf das Projektteam
Bei agilem Projektmanagement stehen viele Unternehmen noch immer auf der Bremse. Der Grund: Viele Projektverantwortliche müssen zusätzlich zu den Projektanforderungen weiterhin Aufgaben im Tagesgeschäft übernehmen. - Anforderungen laufen beim Product-Owner-Team zusammen
In einem Projektteam aus typischerweise sechs bis acht Mitarbeitern laufen alle Fäden beim Product Owner zusammen. Das Product-Owner-Team besteht aus maximal drei Personen. Der Product Owner managed alle an das Team herangetragenen Anforderungen. Das gilt sowohl vonseiten der Auftraggeber als auch der beteiligten Fach- und IT-Abteilungen sowie der Revision. Viele Unternehmen machen dabei den Fehler, Product Owner nicht ausreichend vom Tagesgeschäft freizuhalten.
Die zunächst farblich personalisierten Tickets sind weitgehend einer einheitlichen Farbe gewichen, sodass klar wird, dass nicht eine bestimmte Person die Aufgabe erledigen muss. Heute bringen alle die Aufträge ans Board, das Team priorisiert diese kurz und stellt die nicht personalisierten Tickets ins Backlog, bis sie jemand in die Bearbeitung zieht und mit seinem Button versieht.
Raus ins Business
Nun bemerkte Theißens Team: Wir müssen wissen, was in den Unternehmensbereichen der Holding passiert. Zunächst spontan und schließlich regelmäßig organisierte das Team ein Mal im Monat informelle Meetings mit Kollegen aus den drei großen Abteilungen der Holding. Das Unternehmen spendierte das Essen, der jeweilige Abteilungsleiter erklärte, woran gerade gearbeitet wurde und welche Projekte mit welchem Zweck und Ziel geplant waren. Allmählich verstanden die Anwälte die Anliegen hinter den Anfragen ihrer "Kunden" besser und mittlerweile wird die Zusammenarbeit proaktiv gestaltet.
So bietet das Team Workshops zu häufigen Fragen, etwa zu Bildrechten oder geänderten rechtlichen Anforderungen an Webshops und wie man diese geschäftsfördernd und pragmatisch umsetzen kann. Mit großer Wirkung: Der Ruf der Rechtsabteilung ändert sich. Das Team wird wieder als kompetenter Partner gesehen, die Kollegen suchen aktiv Rat und themenspezifische Schulungen.
Alle diese Veränderungen vollzogen sich innerhalb von 14 Monaten - angesichts der eingebrannten Silostrukturen eine bemerkenswert kurze Zeitspanne. Vieles erledigt das Team inzwischen völlig selbstorganisiert und es sucht laufend nach Verbesserungsmöglichkeiten. Und die Idee verbreitet sich. Auch die HR-Abteilung macht erste Gehversuche mit Kanban.
Tipps für Ihren eigenen Weg
Theißens Vorgehensweise hat große Ähnlichkeit mit der Fallstudie "Lehman Brothers (A): Rise of the Equity Research Department" der Harvard Business School. Sie beschreibt die Neuausrichtung dieses Departments durch Jack Rivkin in den Jahren 1990-1992. Diese Schritte haben sich auch bei agilen Transitionen bewährt:
Vision: Theißens Vision war es, die Rechtsabteilung als Serviceeinheit neu zu etablieren. Welche Vision haben Sie? Was genau wollen Sie erreichen?
Erlaubnis: Holen Sie sich vom Topmanagement die Erlaubnis für einen neuen Weg und das Commitment, dass nötige Ressourcen bereitgestellt werden. So minimieren Sie das Risiko von Querschüssen.
Unterstützung: Suchen Sie Verbündete für Ihr Vorhaben. Sascha Theißen fand sie auf drei Ebenen: bei seinen Mitarbeitern, in der HR-Abteilung und bei Robert Misch.
Sichtbarkeit: Man kann nur ändern, was man sieht. Die Visualisierung von Prozessen der Wissensarbeit hilft den Betroffenen, selbst etwas zu verändern.
Regeln: Ein System, das sich verändern soll, kann nicht nach alten Regeln funktionieren. Wenige, aber klare und unumstößliche neue Regeln sind meist der Hebel, der die Veränderungsbereitschaft anstößt.
Neue Kollegen: Es klingt hart, aber: Wer Veränderungen nicht mittragen will, muss gehen. Holen Sie Kollegen ins Team, die offen für die neue Kultur sind.
Wissenstransfer und Ausbildung: Pair-Techniken fördern den Wissenstransfer in vielen Bereichen. Sorgen Sie dafür, dass sich Kollegen gegenseitig ausbilden.
Investieren: Eine neue Kultur entsteht nicht am Reißbrett. Unternehmen Sie mit Ihrem Team etwas! Es muss kein teures Teambuilding sein - gemeinsame Abende oder Wanderungen sind wirksamer. Investitionskosten: Zeit und Herzblut.
Abschließend ist zu sagen: Das neue Arbeiten mit Scrum und Kanban ist nicht nur etwas für die Softwareentwicklung. (bw)