Autorin: Lea Wüst
Dieser Artikel wurde zuerst auf den „Musterwandlern in Hochschulen“ veröffentlicht (https://musterwandler-hochschulen.org/).
Wie man aus Fehlern lernen und wo Agilität wirklich nützen kann
Heute schildere ich eine Situation, die bei uns recht ähnlich abgelaufen ist, die aber viele Personen bestimmt genau so kennen und zeige auf, was man hätte vielleicht besser machen können.
Worum gehts?
In der Abteilung ABC sind Fachadministratoren eingesetzt, die für spezielle Produktbereiche einer Software zuständig sind. Als man die Software eingeführt hatte, war man davon ausgegangen, dass nur minimale Anpassungen vorgenommen werden müssen und man sich daher den Aufwand sparen könnte, eine wirkliche „Testumgebung“ aufzubauen. Mit den Jahren entstanden aber immer mehr Ideen und Anforderungen seitens der unterschiedlichen Nutzer und der Wunsch wurde lauter, doch auch eine Umgebung für fachliche Tests zu installieren: Der Wunsch wurde nun also vielfach geäußert und nur in vereinzelten Protokollen festgehalten.
Was hätte man mit einem agilen Vorgehen besser machen können?
Die Idee/Anforderung frühzeitig mit einer möglichst konkreten aber leicht und vor allem für alle verständlichen Geschichte beschreiben: Wer, Was und Wozu? (Epic/User Story)
„Als Fachadministrator möchte ich mindestens eine Testversion mit aktuellen Daten für mich zur Verfügung haben, um entwickelte Anforderungen zu testen, Qualität zu sichern und nach erfolgreicher Qualitätssicherung auf das Produktivsystem übertragen zu können.“
Vor circa einem halben Jahr gab es dann einen neuen Aufschlag mit einem Gespräch zwischen zwei Teamleitungen, die jeweils versucht haben, die Interessen ihrer Teams zu vertreten. Beide schrieben ihre Notizen nieder und gingen mit einem guten Gefühl aus dem Gespräch heraus, dass nun alle Fragen geklärt wurden und nun endlich die Testinstanz(en) aufgebaut werden konnte.
Was hätte man mit einem agilen Vorgehen besser machen können?
Gemeinsam mit ALLEN „Betroffenen“ die Geschichte durchsprechen, alle Punkte klären und falls schon bekannt, Akzeptanzkriterien festlegen.
Wichtig hierbei ist, dass allen Beteiligten zu diesem Zeitpunkt klar ist, dass es bei diesem Gespräch noch offene Punkte geben kann. Auch können sich im Laufe der Zeit noch Änderungen der Anforderungen geben.
In unserem Fall haben die Fachadministratoren bisher nicht mit einem Testsystem gearbeitet. Sie wissen noch nicht, wie genau ihr Arbeitsalltag aussehen wird, wenn sie selber Dinge ausprobieren können. Sie haben sich bisher noch keine Testszenarien ausgedacht, können also noch nicht genau beschreiben, was sie benötigen. Gemeinsam gilt es das herauszufinden – vielleicht können die technischen Administratoren Hinweise geben – welche Möglichkeiten der Architektur gegeben sind oder wie in anderen Bereichen Testinstanzen genutzt werden.
Ein Mitarbeiter wurde nun mit der Aufgabe betraut. Er fing auch gleich mit der Konzeption und der Umsetzung an. Hierfür benötigte es viele einzelne Abstimmungen mit unterschiedlichen Personen, die nicht von Anfang an beteiligt waren. Es kam ständig zu neuen Verschiebungen, weil neue Aufgaben auf dem Schreibtisch des technischen Administrators oder auch den anderen involvierten Personen flatterten, die wichtiger oder auch nur schneller erledigbar schienen und die Entwicklung der Testinstanz verschob sich weiter und weiter.
Was hätte man mit einem agilen Vorgehen besser machen können?
Es ist die Priorisierung der Anforderung, die auch gemeinsam erarbeitet werden sollte in Hinblick auf z.B. folgende Faktoren: Basis, Leistung und Begeisterung (KANO-Modell: ein Videoerklärung, welches sehr einfach und anschaulich es erklärt: findet sich hier: https://www.youtube.com/watch?v=_cvjgOFmEnA ). Dieses Modell wird in der Regel im Marketing-Bereich angewendet, um abzuschätzen, welche Faktoren oder beispielsweise Funktionen eines Produkts sollten zwingend umgesetzt werden und welche wären eher das Sahnehäubchen des Produkts. Diese Anforderungen können dann in Relation mit dem zu erwartbaren Aufwand gesetzt werden. Hierbei ist wichtig, dass der Aufwand noch nicht explizit beschrieben werden muss, es eignet sich zu diesem Punkt den Aufwand in Relation zu setzen, z.B. für den Aufbau des Testsystems XY habe ich drei Tage gebraucht, hier erwarte ich einen doppelten Aufwand (Eine genaue Beschreibung der Methode findet sich hier: https://agile-verwaltung.org/2017/03/16/aus-der-agilen-methodenkiste-aufwand-schaetzen/ ).
Für unsere Geschichte hätte dies bedeutet, dass wir zunächst einmal die Funktionen, die eine Testumgebung mitbringen soll, in das KANO-Modell einordnen: z.B. der Zugriff für das Testsystem muss limitiert sein (Rechte-und-Rollenmodell), um den Datenschutzbedingungen zu entsprechen (Basisfunktion); mehrere Personen müssen gleichzeitig im Testsystem arbeiten (Leistungsfaktor), Absprachen untereinander wären möglich, aber sehr aufwändig und daher ineffizient; ein Nachbau aller Schnittstellen zu angebundenen Systemen des Produktivsystems wären wünschenswert aber nicht notwendig (Begeisterungsfaktor). Auch eine Bewertung der Anforderung, dass eine Testumgebung überhaupt notwendig ist, hätte so durchgeführt werden. Dies in Kombination mit der Aufwansschätzung hätte dazu geführt, dass bestimmte Entscheidungen vorab getroffen werden können.
Nachdem nun wieder einige Monate ins Land gegangen waren, hatte es unser technischer Administrator nun endlich geschafft, er hatte sich ein paar Stunden freigeschaufelt und die Testumgebung fertig gebaut und präsentierte sie nun stolz den Fachadministratoren. Der Termin fand statt und es kam wie es kommen musste: die Fachadministratoren stellten fest, dass das, was sie dort bekommen haben, gar nicht wollten und es dauerte gar nicht lang bis die Frage los ging, wer Schuld an der Misere war.
Was hätte man mit einem agilen Vorgehen besser machen können?
Feedbackschleifen einbauen, ob nach der Scrum-Methode in einem festen Entwicklungszyklus oder mit der Design-Thinking-Methode mit Entwicklung von Prototypen sich der Anforderung nähern und sich ganz nah mit den Stakeholdern und den Usern abstimmen.
In unserem Falle, hätte man beispielsweise erst einmal ein Bild aufmalen können, wie man das Testsystem aufbauen will, wann und wie es mit Echtdaten aus dem Produktivsystem gefüttert wird, wie welcher Nutzer sich wann anmelden kann und vieles mehr. Dann hätte man dieses Bild weiter ausdifferenzieren und irgendwann einen Prototypen zur Verfügung stellen können.
Fazit
Wenn wir uns an einige Instrumente aus dem agilen Methoden-Koffer gehalten hätten, hätten wir uns vermutlich viel Enttäuschung, Ärger, Arbeit und vor allem Zeit gespart. Es zeigt sich, dass es schon sehr einfache Mittel gegeben hätte, die geholfen hätten, schnell und einfach die Bedürfnisse zu erfassen und in eine gemeinsame Sprache zu kommen. Agilität ist nicht schwer, man muss es nur machen und sich kurz gemeinsam besinnen, sodass nicht viele Personen zeitgleich in verschiedene Richtungen laufen.
Agile Verwaltung 