Veröffentlicht in Erfahrungen

Ich schaue durch den Rückspiegel in die Zukunft

Vor ca. eineinhalb Jahren hatte ich die Gelegenheit, bei der Firma sipgate an einem Santa-Maria-Workshop teilzunehmen. Dieser Workshop richtet sich vor allem an neue Mitarbeiter*innen im Telekommunikationsunternehmen, um sie mit der agilen Arbeitsweise vertraut zu machen – noch freie Plätze werden gern an externe Interessierte wie mich vergeben. Auf die Frage, was an der Arbeitsweise bei sipgate so besonders sei, antwortete mir damals ein Softwareentwickler: Die regelmäßigen Retrospektiven. Ich war erstaunt, erlebe ich in meinem Hochschul-IT-und-Medien-Umfeld Reflexionen als eher lästig und unsinnig. Nichtsdestotrotz bin ich fest von der Kraft des zielgerichteten Rückblicks überzeugt und erprobe immer wieder mal, wie sich eine Retrospektive auch bei uns etablieren lässt. Der Impuls, einfach zu machen, steht dabei für mich im Vordergrund.

Die Retrospektive als ein Scrum-Ereignis

Bei Retrospektiven handelt es sich klassicherweise um ein Element im Scrum Sprint. Während das Review seinen Fokus auf das Arbeitsergebnis legt, wird in der Retrospektive die Zusammenarbeit betrachtet – immer mit den Blick darauf, wie diese im nächsten Sprint verbessert werden kann. Nach dem Buch von Diana Larsen und Esther Derby teilt sich eine Retro dabei in fünf Phasen auf.

  1. Set Stage (Gesprächsklima schaffen)
  2. Gather Data (Themen sammeln)
  3. Generate Insights (Erkenntnisse gewinnen)
  4. Decide What to Do (Entscheidungen treffen)
  5. Close the Retrospective (Abschluss)

Tobi Baier, Agile Coach bei Adobe, hat im Rahmen eines Facilitator Workshops einen guten Überblick über diese fünf Stufen gegeben. Wer hier gern in die Tiefe gehen mag, dem sei die zweistündige Aufzeichnung empfohlen.

Retro im homogenen Team

Anders als bei sipgate – oder vielleicht auch bei Adobe – ist es bei uns in der Hochschule nicht üblich, in crossfunktionalen Teams Scrum in Reinform umzusetzen. Viele von uns arbeiten gleichzeitig in verschiedenen kleineren und größeren Projekten mit, übernehmen parallel den Second Level Support und sind in homogenen Teams organisiert. Es gibt keine dreiwöchigen Sprints, an deren Ende ein Ergebnis steht und sich die Zusammenarbeit im Team reflektieren lässt bzw., wenn es das gibt, dann gleich für mehrere Teams, so dass man von Review zu Retro zu Review zu Retro usw. springen würde, was widerum weder effektiv noch zielführend wäre. Wie also lässt sich dennoch eine Retro durchführen?

In meinem (tendenziell homogenen) Team haben wir das als Jahres-Retro gemacht. Auch wenn wir uns mit unterschiedlichen Themen und Projekten beschäftigen, wir arbeiten dennoch gemeinsam als Team zusammen, halten uns gegenseitig über die Themen der anderen auf dem Laufenden, ergänzen und unterstützen uns durch die jeweils anderen Perspektiven. Für diese Retro haben wir uns insgesamt vier Stunden Zeit genommen. Der Ablauf orientierte sich dabei an den fünf oben genannten Stufen. Passende Methoden hierfür liefert der Retromat von Corinna Baldauf. Leider fehlen uns die finanziellen bzw. personellen Ressourcen, um eine Retro durch eine externe Person moderieren zu lassen. Als Führungskraft definiere ich meine Rolle allerdings als Moderatorin bzw. Coachin des Teams. Aus dieser Rolle heraus kann eine Retro durchaus gelingen, zumindest solange ich selbst in keine schwierige bis konflikthafte Situation mit Teammitgliedern involviert bin.

Teambuilding durch Innehalten

Im Rückblick betrachte ich diese vier Stunden als Innehalten und Zeit nehmen für uns als Team. Durch die einzelnen Schritte der Retro haben wir erarbeitet, was uns an unserer Zusammenarbeit gefällt, aber auch, wo es noch hakt. Wir haben konkret diskutiert, was wir zukünftig optimieren wollen und welche Impulse wir in andere Bereiche weitergeben wollen, um unseren Spirit zu verbreiten. Letztlich haben wir uns bewusst gemacht, was unsere Zusammenarbeit so wertvoll macht.

Zu guter Letzt haben wir auch besprochen, wann wir uns wieder Zeit für eine solche Retrospektive nehmen wollen. Innehalten ist wichtig, aber da sich bei uns der Handlungsbedarf vor allem auf die Impulse in angrenzende Bereiche konzentrierte, war für uns auch klar, das braucht etwas Zeit. Wir haben uns daher auf eine jährliche Retro (oder ein jährliches Innehalten) geeinigt. Ob wir uns dabei auch zukünftig immer am fünf-stufigen Ablauf einer Retro orientieren, ist noch unklar. Letztlich ist das aber auch gar nicht das Entscheidende. Die fünf Phasen bieten ein wunderbares Grundgerüst, an dem man sich sehr gut orientieren kann und welches Raum gibt, sich erstmal der Aspekte bewusst zu werden, die Zusammenarbeit ausmachen, bevor man direkt in die Lösungssuche einsteigt. Nichtsdestotrotz erachte ich in unserer Organisationsstruktur das Innehalten für den wesentlichen Moment – und dafür lassen sich durchaus auch andere Methoden wie klassische Teambuildungmaßnahmen einsetzen.

Veröffentlicht in Ausprobieren, Erfahrungen, Herausforderungen

Lessons learned

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.

Veröffentlicht in Erfahrungen

Lean Coffee für Teambesprechungen

Wir treffen uns einmal wöchentlich, jeder erzählt ein wenig von dem, woran er gerade sitzt, wir erhalten Informationen von der Abteilungsleitung. Die Besprechung geht reihum, sind Langredner*innen vor einem dran, bleibt eventuell für einen selbst nur noch wenig Zeit. Wir arbeiten in unterschiedlichen Teams zu unterschiedlichen Themen, nicht alles davon interessiert jede*n. So liefen unsere Teambesprechungen früher ab. In meiner Wahrnehmung war es unstrukturiert, langatmig und wenig ergiebig.

Dann habe ich in einem Workshop die Methode Lean Coffee kennengelernt, welche in anderen Teams auch für eine wöchentliche Besprechung eingesetzt wird. Ich habe die Methode unserem Team vorgestellt und wir haben eine vierwöchige Testphase vereinbart. Gestartet sind wir mit der klassischen Umsetzung, wie sie hier beschrieben ist. Nach den vier Wochen haben wir ausgewertet, wie das neue Format für uns passte und haben einige Änderungen beschlossen. In der Form, wie sie gleich beschrieben wird, wenden wir die Methoden mittlerweile mit sehr guten Erfahrungen seit 1,5 Jahren an.

Das Original passte nicht so ganz

Im Vorfeld zu einer Teamsitzung sammeln wir meist schon digital unsere Themen. Dennoch besteht auch zu Beginn der Sitzung noch die Möglichkeit, Themen ad hoc nachzureichen. Ergänzend zur Kurzvorstellung der einzelnen Themen, geben wir immer auch eine Zeiteinschätzung ab. Wir haben festgestellt, dass manche Themen mehr als die klassischen 10 Minuten benötigen und eine Zeitverlängerung fast schon von vornherein klar ist. Anschließend nehmen wir die Priorisierung vor, bereiten unser Kanban-Board vor, stellen den Wecker und starten. Zum Schluss folgt noch die sogenannte Speedrunde. In dieser bekommt jede*r von uns zwei Minuten, um die anderen über die aktuellen Tätigkeiten zu informieren. Während der Testphase haben wir festgestellt, dass dieser Teil aus unserem alten Format verloren gegangen ist und uns fehlte.

Welche Vorteile sehen wir in dieser Umsetzung?

Der Fokus der Besprechung hat sich geändert. Vorher glich es eher einer Informationsveranstaltung, jetzt besprechen wir die für uns relevanten Themen. Wir beraten uns gegenseitig, wenn wir nicht weiter wissen. Wir sammeln gemeinsam Themen für unsere unterschiedlichen Tätigkeitsfelder (z.B. Themen für unseren Blog, Unterstützungsangebote für Studierende …). Wir informieren uns ausführlich über die Themen, die auch für die anderen von Interesse sind. Außerdem ist unser Zeitmanagement – trotz der Abwandlungen – deutlich besser geworden. Die zeitlichen Vorgaben und auch der visuelle Wecker helfen uns allen, uns zu disziplinieren und nicht abzuschweifen und vereinfachen damit auch die Moderation. Wir haben nicht eine Teamsitzung seit der Einführung des Lean Coffees mehr überzogen. Ganz im Gegenteil – häufig sind wir deutlich schneller.

Fazit

Bei uns hat sich die Lean Coffee Methode voll und ganz etabliert. Mittlerweile wenden wir sie auch in vielen anderen Sitzungen – dann meist recht klassisch – an, weil insbesondere das Priorisieren der Themen für uns einen absoluten Mehrwert darstellt. Nichtsdestotrotz – für unsere Teamsitzungen waren die Anpassungen erforderlich, was für mich persönlich bedeutet, bei jeder Methode genau hinzuschauen, auszuprobieren, zu reflektieren und zu verändern. Frei nach Samuel Beckett:

"Try. Fail. Try again. Fail again. Fail better."
Veröffentlicht in Allgemein, Erfahrungen, Herausforderungen

Personal gesucht

One person with passion is better, than forty persons merely interested.

E.M. Forster

Vor einiger Zeit war ich Teilnehmerin eines Führungskräfteforums mit fast 300 Teilnehmern aus den unterschiedlichsten öffentlichen Verwaltungen. Die Veranstaltung stand unter dem Motto „Wie kann die Verwaltung den digitalen Wandel managen?“ und wurde initiiert von der MACH AG.

Unter anderem gab es einen Impulsvortrag zum Thema „Generation Y – Ansprüche an die Arbeitswelt“ (von Dr. Steffi Burkhardt). Die fortschreitende Digitalisierung verändert die Ansprüche der neuen Mitarbeiterschaft. Das Mindset der Generation Y, der jetzigen Ende-20- bis Mitte-30-Jährigen und insbesondere der Generation Z hat sich dahingehend gewandelt, dass zwei grundlegende Prinzipien diesem zu Grunde liegen: „Me first“ „Purpose – Impact – Education“. Dies bedeutet, dass bei diesen Generationen ein hoher Grad an Individualisierung vorherrscht und diese beiden Generationen oftmals nur bereit sind zu investieren, wenn sie die direkte Vision der Arbeit verstehen, das Veränderungsresultat ihrer Arbeit spüren können und entsprechend motiviert werden, sich weiterzubilden. Dieser Kulturwandel wird durch die Digitalisierung extrem beschleunigt und die öffentliche Verwaltung – quasi gezwungen zu reagieren und Wege zu finden, diesen sich schnell verändernden Ansprüchen und schnell verändernden Technologien gerecht zu werden und flexibel auf Wandel reagieren zu können.

Nun bin ich auf einen Artikel gestoßen von Anja Förster (https://www.xing.com/news/insiders/articles/wenn-potenzial-mehr-zahlt-als-erfahrung-2073513) der den Titel trägt „Wenn Potential mehr zählt als Erfahrung“. Dieser Artikel zeigt, dass das was Frau Dr. Burkhardt als Herausforderung beschreibt in Wirklichkeit ein Erfolgskriterium für Organisationen und Unternehmen sein kann. Sie beruft sich dabei auf eine Argumentation von
Fernández-Aráoz , der sagt, dass „das Potential das Schlüsselkriterium sein sollte für die Suche und Ausbildung von Führungskräften. Noch vor Erfahrung und Fähigkeiten.“ Fünf Indikatoren seien hierfür ausschlaggebend 1. Motivation 2. Neugier 3. Scharfblick 4. Engagement und 5. Entschlossenheit.

Seit zwei Wochen hat nun eine neue Mitarbeiterin in unserem Team angefangen, die genau nach diesen Kriterien ausgesucht wurde. Es fehlt ihr an Erfahrungen und Fähigkeiten für das doch sehr spezielle Aufgabengebiet, aber ich ich kann jetzt schon beobachten wie sie sich mit Elan in das neue Arbeitsfeld einarbeitet und hoch motiviert ist sich in kürzester Zeit die Fähigkeiten anzueignen. Ich habe den Eindruck, wir sind auf dem richtigen Weg.