Agil arbeiten, ohne es agil zu nennen

Wie kann ein Projektmanager von agilen Projektinstrumenten profitieren, ohne gleich in der ganzen Organisation eine agile Kultur zu implementieren? Das ist meine Ausgangsfrage für diesen Blogbeitrag. In gewisser Weise ist dies auch ein autobiografischer Artikel, denn ich stand im letzten Jahr als Projektcoach genau vor dieser Herausforderung. Ein neu zusammengewürfeltes Team brauchte für ein Projekt einen klassischen Planungsansatz, der Projektmanager wollte dennoch agil arbeiten. Lesen Sie selbst, wie auch Sie eine solche Situation meistern können.

Der Konflikt zwischen klassisch und agil

Wie in jedem Auftrag für das Coaching eines Projektes stand ein erstes Briefing mit dem Projektmanager ‘Frank’ an. Darin erfuhr ich vieles über ihn und den Konflikt, in dem er sich befand:
Frank ist Projektmanager. Ein sehr erfahrener Projektmanager. 20 Jahre lang hat er schon Projekte gemacht. Er kann stolz auf seine Leistung sein. Kein Projekt war ein Misserfolg. Ok, manchmal haben sein Team und er keine Punktlandung hingelegt. Doch die Rahmenbedingungen waren auch oft nicht leicht. Frank hat eine solide Ausbildung. Er kennt viele  Projektmanagement-Methoden, hat ein vielfältiges Repertoire an Instrumenten und kennt viele nützliche Tools. Vor einigen Jahren kam dann Agile in seine Projektwelt. Er besuchte mehrere Seminare für agiles Projektmanagement und ist seitdem fasziniert von der Art, wie Projekte auch leicht und flexibel ablaufen können. Er ist zudem von den Vorteilen agiler Instrumente und Vorgehensweisen überzeugt. Leider ist seine Organisation genau das Gegenteil von dem, was er über agile Kultur gelernt hat. Mit agilem Management braucht er seinem Chef nicht zu kommen. Immer wenn seine Berufskollegen aus seinem Netzwerk über ihre agilen Projekte berichten, fühlt er sich irgendwie auf ein Abstellgleis geschoben. Agile scheint an ihm vorbei zu rauschen. Gerne würde er es in seinen Projekten auch anwenden.

Eine spannende Aufgabenstellung! Wie kann es gelingen, dass Projekt erfolgreich zu begleiten und gleichzeitig Frank darin zu unterstützen, in seinem Projekt agile Elemente einzubauen?

Achtung, agil ist keine Methode

Bevor wir uns anschauen, wie wir Frank helfen können, ist eine Erkenntnis wichtig: Wer Agile verinnerlicht hat, weiß, dass es gefährlich ist, diesen Ansatz wie eine neue Methode einfach sklavisch anzuwenden. Denn dahinter steckt ein Mindset, also eine Art zu denken. Um eine über Jahre eingefahrene Projektorganisation zu einem geänderten Mindset zu bringen, ist ein Veränderungsprozess erforderlich, der Jahre dauern kann. Dennoch braucht Frank in seiner klassischen Projektumgebung nicht gänzlich auf die Vorteile agiler Instrumente zu verzichten.

Die fünf besten agilen Instrumente

Bei unserem nächsten Meeting entwickelten Frank und ich eine Liste mit agilen Instrumenten für die operative Projektebene. Solche, die wir einsetzen konnten, ohne gleich am Mindset seiner Kollegen schrauben zu müssen. Folgende fünf Tools haben wir identifiziert und eingeführt:

1. Definition of Done

Für das Setup des Projektes wählten wir die Implementierung des Definition of Done (DoD). Was klassische Projektansätze wie PRINCE2 als Abnahmekriterien für das Endergebnis eines Projekts benennen, wird bei Definition of Done auf ein grundsätzliches Prinzip erweitert. Für alles, was das Projektteam an wichtigen Fortschritten erzielt, gibt es eine Definition, wann es fertig ist. Im Kickoff erläuterte ich den Sinn von DoD und das Team diskutierte, wo eine Anwendung am nützlichsten sein konnte. Man einigte sich darauf, grundsätzlich die Fertigstellung eines Arbeitspakets zu definieren. Das Ergebnis lautete so:

Ein Arbeitspaket ist fertig, wenn

• der Abnehmende die „Fitness for Purpose“ erklärt hat,
• ein Test die Übereinstimmung mit den Abnahmekriterien bestätigt hat,
• der Ersteller die Dokumentation im Projekt-Workspace freigegeben hat,
• der Status einvernehmlich mit dem Team auf “Done” gesetzt wurde.

Das Team machte es sich zueigen, für jedes abgeschlossene Arbeitspaket diese DoD als Checkliste heranzuziehen und mehr als einmal stellten sie fest, dass ein Arbeitspaket doch nicht vollständig abgeschlossen war. Nutzen erfüllt!

2. User Stories

Für die Anforderungsphase führten Frank und ich User Stories ein. Mit der Anwendung dieses Konzeptes kann jedes Lastenheft und jeder Anforderungskatalog gravierend angereichert werden. Mit dem dreigliedrigen Format „Ich als User, möchte folgende Funktion haben, um diesen Nutzen zu erreichen“ wird eine Anforderung ganz leicht zu einer User Story. Damit schafften wir es, die kundenseitigen Teammitglieder auf eine klare Rollensicht und eine Zweckorientierung zu fokussieren. Ein kleiner Perspektivwechsel mit großer Wirkung.

3. Task Boards

Das dritte Instrument unterstützte die Kommunikation im Projekt. Kommunikation ist eine essenzielle Stärke agiler Projekte. Frank schilderte mir, wie schleppend und mühselig der Austausch von Informationen in seinen bisherigen Projekten war. Statusberichte wurden als lästige Pflicht angesehen und wenig beachtet. Agile Projekte bringen mit Visualisierung und Transparenz die Kommunikation auf Trab. Mit einem einfachen Task Board, das wir für Arbeitspakete der aktuellen Projektphase einrichteten, schafften wir es, dass jedes Teammitglied auf einen Blick wusste, wo das Projekt gerade steht. Ich empfahl ihm eine ganz einfache „haptische“ Variante des Task Boards. Dafür brauchte er lediglich 2 m² freie Wandfläche, Test-Krepp zur Gestaltung von Spalten und ein paar Blöcke verschiedenfarbiger Post-Its.

Agil arbeiten, ohne es agil zu nennen

4. Daily Standups

Wenn es ein agiles Instrument gibt, das eine sofortige Effizienzsteigerung herbeiführen kann, dann ist es das Daily Standup. Ich konnte mir vorher leibhaftig ein Bild von einem 3-stündigen Projektstatusmeeting machen. In großer Runde waren alle Beteiligten vertreten. Es gab weder Agenda, noch eine strukturgebende Moderation. Die Sitzung war geprägt durch lange Statements und hitzige Detaildiskussionen. Die Veränderungsbereitschaft war groß, als wir knackige, 15minütige, tägliche Abstimmungen einführten, die nur einem Zweck dienten: dem Sicherstellen der Arbeitsfähigkeit. Das gelingt im Daily Standup durch eine feste Agenda aus 3 Punkten:

• Was habe ich gestern gemacht?
• Was tue ich heute?
• Wen brauche ich, um meine Arbeit machen zu können?

Problemlösungen, fachliche Diskussionen und Meinungsaustausch wurden bewusst ausgeklammert und an anderer Stelle bilateral besprochen. Neben der Arbeitsfähigkeit aller Teammitglieder führten die Daily Standups zum regelmäßigen, inhaltlichen Austausch und belebten die Kommunikation und Zusammenarbeit im Team.

5. Retrospektiven

Zum Ende der ersten Phase führten wir das letzte agile Tool ein: die aus Scrum bekannte Retrospektive. Die aus klassischen Projekten bekannten Lessons Learned-Meetings am Ende eines Projektes haben nämlich einen gravierenden Nachteil: Die im Workshop gefundenen Lessons führen im aktuellen Projekt zu keiner Verbesserung. Bei der ersten Retrospektive übernahm ich noch die Moderation und folgte einer klaren Agenda. In einer 90-minütigen Session schafften wir nicht nur den Anstoß hin zu einer höheren Projekteffizienz, sondern sorgten auch für eine höhere Motivation der Mitarbeiter. Frank plante fortan am Ende jeder Phase und zusätzlich – wenn eine Phase länger dauerte – spätestens alle sechs Wochen eine weitere Retrospektive ein. Die Moderation der nachfolgenden „Retros“ konnte er selbst übernehmen. Er erzählte mir später stolz, dass er sich erstmals wie ein Scrum Master fühlte.

Mit diesem Set aus nur fünf agilen Instrumenten belebten und verbesserten Frank und ich die Umgebung seines Projekts. Wir machten nicht viel Aufhebens, um die neuen Ansätze. Wir nannten sie noch nicht einmal „agil“. Damit gingen wir möglicher Kritik aus der Organisation einfach aus dem Weg. Wir bezeichneten sie einfach als wirkungsvolle Instrumente aus dem Projektmanagement.

Do it the Agile Way

So weit zum inhaltlichen Teil. Kommen wir nun zu der Art und Weise des WIE, also in welcher Form wir die Instrumente einführten. Weil ich Frank nicht von der Bedeutung agiler Prinzipien bei der Implementierung von Veränderungen überzeugen musste, beherzigten wir einige Dinge, die dabei helfen, diesen „subversiven” Ansatz erfolgreich umzusetzen. Bei der Anreicherung der
klassischen Projektumgebung griffen wir auf unser Wissen über grundsätzliche agile Ansätze zurück:

Inkrementelles Vorgehen

Jedes neue agile Instrument, das wir in der klassischen Projektumgebung implementierten, führten wir in Schritten ein. Erst eine ganz simple Ausführung. Klappte dies, fügten wir noch etwas hinzu. So wurden die Teamkollegen nicht mit komplizierten neuen Dingen konfrontiert, sondern konnten sich Schritt für Schritt mit dem Neuen vertraut machen. Beispielsweise hatte unser Task Board zu Beginn nur drei Spalten (Backlog, Doing, Done) und die User Stories wurden zunächst nur auf funktionale Anforderungen angewendet.

Iteratives Arbeiten

Die neuen Instrumente waren für uns nicht so angelegt, dass sie von Beginn an perfekt sein sollten. Wir wussten, dass dafür einige Schleifen benötigt würden. Wir waren bereit, die Erfahrungen aus der Anwendung immer wieder in eine Optimierung einfließen zu lassen. Und wenn ein Instrument auf überhaupt keine Akzeptanz und damit auch auf keinen Nutzen gestoßen wäre, hätten wir dieses auch wieder eingestampft.

Experimentieren

Manche der besten Lösungen entstehen per Zufall. Und so unterstützten wir es, wenn die Projektteammitglieder an den Projektinstrumenten herumprobierten, sie für andere Zwecke einsetzten oder sich etwas ganz neues einfallen ließen. Beispielsweise werden die Standups mittlerweile auch virtuell von einem über mehrere Standorte verteilten Serviceteam angewendet. Einfach, weil ein Kollege unseres Projektes dies in einem Meeting vorgeschlagen und ausprobiert hatte.

Kurze Feedbackschleifen

Wir unterstützten aktiv Rückmeldungen zur Anwendung der neuen Instrumente. Wir richteten eine separate Emailadresse für Kommentare ein. Auch nutzten wir immer wieder Meetings und Gespräche, um Rückmeldungen zu den genutzten Werkzeugen zu erhalten. Natürlich nahmen wir jedes Feedback ernst und gingen stets auf die Kommentare ein.

So kann es ausgehen

Die Projektkollegen hatten es nicht einmal bemerkt, dass wir Franks Projekt ein wenig Agilität eingehaucht haben. Das ist auch nicht das Entscheidende. Wichtig ist, dass wir mit neuen Instrumenten eine wirkungsvollere Kommunikation ermöglicht und die Teamarbeit erleichtert haben. So entwickelte unser Projekt einen Schwung und eine Dynamik, die Frank bisher nicht erlebt hatte. In seinem Unternehmen gilt dieses Projekt mittlerweile als positives Beispiel für die engagierte Zusammenarbeit eines Projektteams. Unsere “subversiv“ eingeführten Tools breiten sich nun munter in anderen Projekten aus.

Hinweis

Wenn Sie sich mit Projektmanagern wie Frank über diese und ähnliche Themen austauschen möchten, wenn Sie innovative Ansätze für neuen Schwung in Ihren Projekten kennenlernen möchten, dann ist der Community Day von COPARGO die ideale Veranstaltung. Am 27. April 2017 findet in Frankfurt das diesjährige Event statt. Die Teilnehmer erwartet ein Tag voll mit Vorträgen renommierter Referenten, mit Workshops – moderiert von erfahrenen Projektmanagern – und Barcamps, die Teilnehmer mit eigenen Themen selbst gestalten. COPARGO gewährt Lesern des microTOOL Blogs einen Nachlass von 10% auf den Eintrittspreis. Der Rabattcode lautet mt0304.  Informationen zum Community Day finden Sie unter http://cday.copargo.de/.