Agile Werte

Basis des agilen PM sind die Agilen Werte:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Funktionierendes Produkt ist wichtiger als umfassende Dokumentation.
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung.

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Auf diesen Werten basieren also die agilen Prinzipien und agilen Techniken, die in ihrer Summe das Agile Projektmanagement ausmachen. Eine wichtige Aussage im Manifest ist vor allem diejenige, dass auch die rechte Seite „geschätzt“ wird. Es geht also darum, eine angemessene Balance zwischen den beiden Seiten zu finden. Letztlich benötigt man jeweils beide Seiten.

Beispiel: Nehmen wir das Wertepaar „Funktionierende Software mehr als umfassende Dokumentation“. Auch wenn man dem agilen Wert „Funktionierende Software“ folgt, muss man trotzdem noch ein Handbuch für den Kunden erstellen und die Software so dokumentieren, dass eine Erweiterung der Funktionalität durch neue Mitarbeiter möglich ist.

Wie wichtig dieser Gedanke einer Balance zwischen „agil“ und „klassisch“ gerade im klassischen Projektumfeld ist, zeigt das folgende Beispiel aus der Praxis. 

Beispiel: In einem großen, internationalen Konzern gibt es einen Bereich, der seinen Kunden als Produkt das Outsourcing ihrer IT-Systeme anbietet. Für diese Kunden werden beispielsweise Webseiten, Webshops und zugehörige Prozesse betrieben. Bemerkt der Kunde ein Problem, beispielsweise, dass sein Webshop nur sehr langsam reagiert, so ruft er einfach eine Service-Hotline an. Der Hotline-Mitarbeiter stuft das Problem dann ein und eröffnet ein sogenanntes Ticket in einem Vorgangssystem. Anschließend weist er das Ticket demjenigen Mitarbeiter zu, der für den Kunden verantwortlich ist. Das Vorgangssystem erzeugt automatisch eine E-Mail an den entsprechenden Mitarbeiter, so dass dieser über seine neue Aufgabe informiert ist. Vermutlich werden Sie solche Systeme aus der eigenen Berufspraxis kennen. 

Im Konzern kommt es rund um das Ticket-System nun zu folgenden typischen Abläufen: Der Mitarbeiter, der für das Ticket verantwortlich ist, schaut es sich an. Stellt er fest, dass es vermutlich ein Datenbankproblem ist, sendet er das Ticket mit einem kurzen Vermerk an einen Datenbankexperten weiter.  Dieser wiederum wirft einen kurzen Blick auf den Vorgang, denn so richtig Zeit hat er natürlich gerade nicht dafür. Er kommt zu dem Schluss, dass es sich eher um ein Problem in der Benutzeroberfläche handelt und schickt das Ticket an den entsprechenden Experten weiter. Wenn dieser allerdings gerade im Urlaub oder anderweitig nicht verfügbar ist, bekommt es ein Vertreter, der sich mit der Applikation des Kunden nicht gut auskennt. Er untersucht das Ganze kurz, findet keinen Anhaltspunkt für die Ursache des Problems und schickt das Ticket daher wieder an den Datenbankexperten zurück. Der Kunde, der nach wie vor Probleme mit seinem Webshop hat, ruft ein zweites Mal an, jetzt schon ziemlich unter Dampf. Er besteht darauf, dass das Problem „eskaliert“ wird. Auf Seiten des Konzerns wird jetzt der sogenannte Escalation-Manager eingeschaltet. 

Die Zahl der Eskalationen durch Kunden ist irgendwann so hoch, dass das Management davon Wind bekommt und der Sache nachgeht. Es stellt sich heraus, dass es auf Ebene der Mitarbeiter bereits ein geflügeltes Wort für die Kernproblematik gibt: Ticket-Ping-Pong. Um diese Situation zu ändern, wird seitens des Managements ein mehrstufiges Programm von Kommunikationstrainings aufgesetzt, das alle Mitarbeiter durchlaufen müssen. Dieses Programm zieht sich über drei Jahre hin. Das Ergebnis liefern Messungen: Mit den Kommunikationstrainings ist eine deutliche Abnahme des Ticket-Ping-Pongs und eine erhöhte Kundenzufriedenheit verbunden. 

Das interessante an diesem Beispiel ist, dass alle Mitarbeiter die Prozesse korrekt befolgen und das Werkzeug (Ticket-Tool) auch korrekt verwenden, und trotzdem nichts erreicht wird, was dem Kunden etwas bringt. Im Wesentlichen ging es bei der Lösung des Ticket-Ping-Pong-Problems also darum, den Fokus von „Prozesse und Werkzeuge“ zu verschieben auf „Individuen und Interaktionen“.  In den Kommunikationstrainings wurden dazu unter anderem die folgenden Lösungen erarbeitet:

• „Wenn der Kunde anruft, versuchen wir schon beim ersten Telefonat möglichst viel Detailinformation zu bekommen.“
• „Wir informieren den Kunden zwischendurch aktiv über den Stand der Fehlersuche und -behebung.“
• „Wenn der Experte, dem wir das Ticket zuweisen, im nächsten Raum sitzt, gehen wir einfach mal vorbei und sehen, ob wir das Problem kurz gemeinsam besprechen können. Wenn er weiter weg sitzt, versuchen wir ihn kurz anzurufen.“

Für alle agilen Werte lassen sich zahlreiche solcher Praxisbeispiele finden, insbesondere im Kontext von Konzernen. Allgemein lässt sich die These aufstellen, dass Konzerne die Effizienz ihrer Strukturen teils vor allem dem systematischen Ausbau der rechten Seite verdanken. Denn die rechte Seite der Werte (also Prozesse und Werkzeuge, umfassende Dokumentation, Vertragsverhandlung und Befolgen eines Plans) sorgt für Struktur und Sicherheit. Dies wiederum sind Werte, die im Konzernumfeld viel gelten.

Durch die zunehmende Dynamik im wirtschaftlichen Umfeld reichen diese klassischen Werte häufig jedoch nicht mehr aus, um sich schnell genug den Marktveränderungen anzupassen. Deswegen kommen manche Konzerne auf die Idee, „agiler“ zu werden. Wichtig ist es dann, eine neue und gute Balance zwischen den beiden Seiten „agil“ und „klassisch“ zu finden. Wo genau dieser optimale Ausgleich liegt, ist für jedes Produkt und für jedes Unternehmen individuell anders zu beurteilen. Hier ist es ganz sicher nicht seriös, von außen generelle Ratschläge à la „Nehmt einfach Scrum!“ zu geben. Eine solche Denkweise greift in den allermeisten Fällen definitiv zu kurz.