Man arbeitet oder denkt nicht agil, sondern man ist agil. Agile ist eine Herangehensweise selbst und kein Tool, das im Projektmanagement oder in der Unternehmensführung angewandt wird. Agile ist viel mehr die Arbeitseinstellung, die mein Team und ich an den Tag legen. Agile ist also eine Einstellung, eine Denkweise, eine eigene Mentalität. Als Beispiel, es ist meine Einstellung, dass ich physisch fit sein möchte. Joggen gehen oder einem Fitnessstudio beitreten sind wiederum die „Tools“, mit denen ich meiner Einstellung nachkomme.
Woher kommt die „agile Mentalität“?
Im Jahr 2001 trafen sich 17 Softwareentwickler in einem Skiresort in Snowbird, Utah. Sie arbeiteten alle samt in einer Branche in der Veränderungen und Ungewissheiten zur Tagesordnung gehörten. Alle hatten einen Weg für sich gefunden in einem solchen Umfeld erfolgreich zu sein. Doch diese Ansätze waren unterschiedlich und teils nicht kompatibel. Nun hatten sie das Ziel eine Mentalität zu schaffen, mit der es nicht nur möglich war auf Veränderungen in kürzester Zeit zu reagieren, sondern diese auch anzutreiben. So entstand eine Mentalität, eine Denkweise, die nicht nur dabei half mit Veränderungen und Ungewissheiten umzugehen, sondern in ihr zu florieren.
Der Leitfaden für Agile wurde in einem Manifest und 12 Prinzipien festgehalten.
Agile Manifesto
Individuen und Interaktionen stehen über Prozesse und Werkzeuge
Funktionierende Software steht über umfassender Dokumentation
Zusammenarbeit mit dem Kunden steht über Vertragsverhandlung
Reagieren auf Veränderung steht über dem Befolgen eines Plans
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.
Zwölf Prinzipien der agilen Softwareentwicklung
Der Agile Mindset wird meist mit Softwareentwicklung in Verbindung gebracht und hat auch in dieser Branche seinen Ursprung. Nichtsdestotrotz lässt sich diese Mentalität auch auf viele andere Branchen und Berufe außerhalb der Softwareentwicklung anwenden.
Agile in der Praxis
In den meisten Unternehmen gibt es eine klar strukturierte Hierarchie. Diese Hierarchie beschreibt nicht nur wer welchen Vorgesetzten hat, sondern auch wer in welchem Funktionsbereich mit welchen Verantwortungen tätig ist.
Bild 1: Vereinfachte Darstellung einer Unternehmenshierarchie
Mit einer solchen Hierarchie geht auch meist eine Organisationsmatrix herbei. Diese Matrix lässt erkennen, in welcher Position sich welcher Experte befindet. So finden wir schnell den Produktentwickler, bis hin zum Marketingexperten. Klassisch betrachtet, wenn nun ein neues Produkt entwickelt werden soll, durchläuft es alle nötigen Abteilungen bis hin zur Fertigstellung.
Bild 2: Vereinfachte Darstellung einer Matrixorganisation
Bekannte Vorteile sind ein geordneter Ablauf mit den jeweiligen Experten in der jeweiligen Produktionsphase. Hier wird auch oft von „Silos“ gesprochen, in denen das gesamte Wissen zu einem bestimmten Fachgebiet in einem Funktionsbereich, „gesammelt“ wird. Herausforderungen entstehen jedoch dann, wenn in einer beliebigen Produktionsphase Änderungen seitens des Kunden gewünscht werden. In einem solchen Fall kann es passieren, dass der eine Funktionsbereich erneut auf die Unterstützung eines anderen warten muss. Diese Problematik versucht Agile zu eliminieren, in dem funktions- und bereichsübergreifende Teams mit Generalisten, anstatt Experten, eingesetzt werden. Unter Generalisten versteht man hier Mitarbeiter, die zwar Experten in ihren eigenen Funktionsbereichen sind, allerdings im Agile Team, aktiv zu jeder Funktion beitragen können. Ein solcher Ansatz setzt voraus, dass in einem Agile Team ein sogenanntes Cross-Training stattfindet. Jedes Teammitglied bildet die anderen Mitglieder in seinem Fachgebiet aus. Dieses Cross-Training ist meist ein kontinuierlicher Bestandteil des Agile Teams.
Bild 3: Unterschied zwischen Silos (einzelne Arbeitsfunktionen) und funktionsübergreifende Teams.
Der Vorteil eines funktions- und bereichsübergreifende Teams liegt darin, dass weniger „Handoffs“ geschehen und somit auch Abstand von Multitasking genommen werden kann. Betrachten wir mal das Prinzip von Handoffs anhand des Artikels, den ihr gerade lest. Eine erste Person plant und recherchiert diesen Artikel, eine zweite Person überprüft dann die Vorbereitung und gibt sie frei, ich verfasse als nächstes den Artikel und eine vierte Person liest in dann Korrektur, bevor er von einer fünften Person schlussendlich veröffentlicht wird. In diesem Beispiel gibt es nun vier Handoffs. Wenn allein der erste Revisor gerade verhindert ist, müssen meine anderen zwei Kollegen und ich mit unserer Arbeit warten. Der Vorteil eines Agile Teams besteht darin, dass ein Generalist im Team möglichst viele Schritte ohne Handoff bewerkstelligen kann. Sind Handoffs nicht zu vermeiden, dann sollte die Arbeit die „durchgeschleust“ wird möglichst gering sein, damit sich kein Rückstau bildet. Denn umso umfangreicher die weitergereichte Arbeit, desto größer die Wahrscheinlichkeit, dass die Bearbeitungszeit zwischen Mitarbeitern variiert. Dies lässt sich am bestem am Beispiel des „Penny Games“ illustrieren.
Penny Game by Doug Rose https://www.lynda.com/Project-Management-tutorials/Penny-Game/761929/5011075-4.html
Das Video zeigt sehr schön, dass selbst wenn, die einzelnen Teammitglieder nicht effizienter erscheinen, das gesamte Team auf Grund der geringen „batch size“ deutlich effizienter ist. So kann auch Prinzip 8 gewährleistet werden: Nachhaltige Entwicklung (berechenbar) in gleichmäßigem Tempo. Multitasking bedeutet, dass wir zwischen zwei oder mehreren Aufgaben hin und her wechseln. Dieser Aufgabenwechsel führt dazu, dass wir uns jedes Mal wieder in die andere Aufgabe hineindenken müssen, was wiederum den zeitlichen Anspruch erhöht. Doch der Fokus von Agile liegt darin das wertvolle Software in kurzen Zeitspannen geliefert wird (Prinzipien 1 & 3). Solche kurzen Zeitspannen werden oft „Sprints“ genannt.
Sprints bedienen Prinzip 3 von Agile in dem sie funktionierende Software in kurzen Zeitspannen liefern. Diese Zeitspannen haben in der Regel eine Dauer von zwei Wochen. Wie auch in einem „normalen“ Projekt, wird in diesen Sprints geplant, analysiert, designed, codiert, getestet und ausgerollt, bevor der Prozess erneut beginnt. Der Unterschied bei Agile ist, dass Prinzip 1 oberste Priorität hat. Und zwar fragt das Team stets nach dem Wert, der für den Kunden an erster Stelle steht. Dies führt dazu, dass das Team am Ende eines Sprints seinem Kunden stets ein funktionierendes Produkt präsentieren kann. Während ein Autobauer, zum Beispiel das Auto erst dann dem Kunden ausliefern kann, wenn es fertiggestellt ist, fragt das Agile Team welcher Aspekt für den Kunden am wichtigsten ist. In unserem Auto-Beispiel ist dem Kunden der Faktor „Bewegung“ am bedeutsamsten. So entwickelt das Team im ersten Sprint vielleicht ein Skateboard, im zweiten Sprint ein Fahrrad, im nächsten Sprint ein Motorrad und im darauffolgenden Sprint ein Auto. Der Kunde erhält somit alle zwei Wochen ein fertiges Produkt, welches seiner höchsten Priorität entspricht. Ein weiterer Vorteil dieser agilen Mentalität ist es, dass der Kunde die Flexibilität besitzt, sich umentscheiden zu können und sich gegebenenfalls für eines der Produkte entscheidet, das in einem der vorherigen Sprints entstanden ist. Um Fragen nach der bedeutendsten Funktion zu beantworten, arbeiten Agile Teams oft mit User Stories.
Als Alternative für die vom Projektmanager formulierten Produktanforderungen, wird anhand einer User Story, der für den Kunden größtmöglichen Nutzen erfragt. Denn laut Manifest stehen Interaktion und Individuen, über Prozessen und Werkzeugen. Eine User Story folgt einem ganz einfachen Format:
„Als [Rolle] möchte ich [Funktion] um [Nutzen].“
„Als [Gründer] möchte ich mich bei [startkrefeld.de informieren], um [mich für meinen Pitch vorzubereiten].“
Die User Story schafft keine konkreten Antworten wie Produktanforderungen, aber sie erlaubt uns die richtigen Fragen zu stellen, um die Funktionen zu identifizieren, die unserem Kunden den größtmöglichen Nutzen bringen (Prinzip 1).
User Stories helfen uns stets im Auge zu haben, was dem Kunden am wichtigsten ist, während Sprints dem Team dazu verhelfen funktionierende Software in kurzen Zeitspannen zu liefern. Gleichzeit erlaubt die Arbeit in kurzen zeitlichen Intervallen einen Kurswechsel, der genauso schnell zu realisieren ist. Zudem ist jedes Teammitglied im Stande selbstorganisierend zu arbeiten und ist nicht stets auf die Arbeit anderer angewiesen.
Das Agile Team
In einem Agile Team stechen zwei Positionen besonders hervor. Die eine ist die des Scrum Masters und die andere ist die des Product Owners. Hier gilt es anzumerken, dass Scrum als eine eigenständige Herangehensweise gesehen werden kann, um Agile umzusetzen. Scrum ist die wohl am meist verbreitete Herangehensweise. Der Scrum Master ist derjenige im Team, der die besten Agile-Kenntnisse hat. Er ist also nicht der Manager der Gruppe, sondern er fungiert vielmehr als Coach und sorgt für die notwendige Kommunikation im Team. Der Product Owner, auf der anderen Seite, ist meist ein Teammitglied, das den Kunden und somit den gewünschten Nutzen am besten kennt. Er priorisiert die Arbeit und steuert das Team in die richtige Richtung.
Autor: Nils Michaelis
Quellen:
https://www.agilealliance.org/
https://www.business-wissen.de/artikel/scrum-so-erstellen-sie-gute-user-stories/
Doug Rose, Doug Enterprises (https://dougenterprises.com/)
