Agile Methoden wie Scrum, Kanban und Design Thinking zählen zu den großen Trends der heutigen Unternehmenswelt.
Viele Organisationen konnten damit erstaunliche Erfolge erzielen und beginnen bereits, ihre Strukturen im Sinne einer agilen Transition komplett auf die neue Arbeitsweise umzustellen. Andere sind noch zurückhaltend: Sie fragen sich, ob Agilität in ihrem Unternehmen tatsächlich die gewünschten Vorteile bringt – oder ob es sich um einen Trend handelt, der in ihrem Fall keinen Mehrwert bringt.
Diese Frage ist verständlich, denn agile Methoden passen nicht zu jeder Organisation. Das verdeutlicht ein Blick auf die wichtigsten Verfahren und Konzepte, die Agilität beinhaltet.
„Für die agile Zusammenarbeit ist das Mindset, das jeder Beteiligte mitbringt, immens wichtig.“
Agiles Manifest und Prinzipien
Es entscheidet darüber, ob die agile Zusammenarbeit funktioniert oder nicht. Die Art zu denken ist oft Voraussetzung, sich auf ein Thema oder eine neue Arbeitsweise einzulassen. Bevor Sie sich also Gedanken über agile Methoden machen, sollten Sie zunächst die Prinzipien und Werte betrachten, die für alle agilen Methoden gelten:
- Kontinuierlich wertvolle Software auszuliefern und den Kunden/Auftraggeber zufrieden zu stellen, hat höchste Priorität.
- Um Wettbewerbsvorteile für den Auftraggeber zu generieren, kommen bei Veränderungen agile Prozesse zum Einsatz. Kritische Anforderungsänderungen sind daher auch spät in der Entwicklung willkommen.
- Der Kunde/Auftraggeber erhält regelmäßig und in kürzer werdenden Abständen funktionsfähige Software.
- Entwickler und fachliche Experten arbeiten täglich zusammen.
- Sie sollten das Projekt um die motivierten Personen herum einrichten. Diese benötigen einerseits jede Form der Unterstützung, andererseits aber auch das Vertrauen, dass sie ihre Aufgaben zuverlässig erledigen.
- Informationen sollten in direkten Gesprächen an das Entwicklungsteam übermittelt werden. Dies hat sich als effektiv und effizient erwiesen.
- Funktionsfähige Software zeigt den Fortschritt der Entwicklung. Daher ist dieses Maß das wichtigste.
- Für eine nachhaltige Entwicklung sollten Auftraggeber, Entwickler und Anwender gemeinsam ein gleichmäßiges Tempo aufrechterhalten. Dies fördert die agilen Prozesse.
- Förderlich für Agilität ist auch, wenn Sie auf gutes Design und technische Exzellenz achten.
- Einfachheit der Prozesse und Strukturen im Rahmen der Agilität ist dabei wesentlich.
- Agilität bedingt ein hohes Maß an Selbstorganisation. Nur so entstehen in den Teams die besten Architekturen, Anforderungen und Entwürfe.
- Selbstreflexion im Team steigert dessen Effektivität und führt dazu, dass die Mitglieder ihr Verhalten anpassen. Die Reflexion sollte regelmäßig erfolgen.
Werte
Mut:
Das Scrum-Team besitzt den Mut, Probleme zu bearbeiten und die richtigen Dinge zu tun.
Fokus:
Alle Teammitglieder arbeiten fokussiert an den vereinbarten Zielen.
Offenheit:
Scrum-Team und Stakeholder gehen offen mit Herausforderungen und allen Themen rund um den Projektfortschritt um.
Respekt:
Im Scrum-Team arbeiten alle respektvoll miteinander.
Selbstverpflichtung:
Jedes Mitglied des Scrum-Teams verpflichtet sich, die Ziele zu erreichen.
Auf Basis dieser Prinzipien und Werte sollten Führungskräfte ein Arbeitsumfeld schaffen, in dem die Beteiligten zielgerichtet arbeiten können.
Was sind agile Methoden?
Scrum:
Die vermutlich bekannteste agile Methode ist Scrum. Sie ist insbesondere bei Software-Entwicklungsprozessen weit verbreitet, kommt aber mittlerweile auch in zahlreichen anderen Unternehmensbereichen zum Einsatz.
Dieser iterative Prozess ist das Kernelement der Methode.
Wie funktioniert Scrum?
Scrum beginnt mit der Initialisierungsphase sowie dem Aufsetzen des Projekts. Hier werden die vertraglichen Aspekte des Projektauftrags, die Vision, der Business Case und die Teamaufstellung geklärt sowie die Stakeholder analysiert. Um eine optimale Zusammenarbeit zu gewährleisten, sollte das Scrum-Team aus drei bis maximal neun Personen bestehen. Der Product-Owner und der Scrum Master sind Teil dieses Teams und werden somit hinzugezählt.
„Der Kern von Scrum ist, dass kleine, selbstorganisierte Teams im Rahmen kurzer Entwicklungsschleifen (Sprints), meist unter einem Monat, an einem Projekt arbeiten.“
Im Anschluss geht der Arbeitsmodus des zusammengestellten Teams in die Sprint-Zyklen über. Nach dem Startschuss klärt der Scrum-Master mit dem übrigen Team die Rituale sowie weitere Rahmenbedingungen. Dazu zählen die Uhrzeiten der Meetings – zum Beispiel das Daily-Scrum – und die Techniken bei der Entwicklungsarbeit (z. B. Pair Programming).
In der Sprintplanung wählen das Entwicklungsteam (auch Development-Team oder Dev-Team genannt) und der Product-Owner zunächst die umzusetzenden Features für den nächsten Sprint aus. Der Product-Owner verantwortet das Product-Backlog und pflegt die darin aufgeführten fachlichen Anforderungen. Diese können sich bei Scrum permanent ändern, beispielsweise infolge von Absprachen mit Stakeholdern und Kunden. Der Backlog ist daher ein lebendiges Gebilde, das sich dynamisch verändert.
Der Product-Owner priorisiert die Anforderungen entsprechend seiner Kriterien wie Nutzen, Dringlichkeit und Risiko. Die Anforderungen mit der höchsten Priorität stehen ganz oben im Product-Backlog . Zudem erstellt der Product-Owner die User Stories mit zugehörigen Akzeptanzkriterien und bespricht sie mit dem Entwicklungsteam. Die abgestimmten Features oder User Stories werden in das Sprint-Backlog gezogen, das für den nächsten Sprint befüllt wird. Im Sprint-Backlog werden aus den User Stories einzelne Tasks erstellt.
DIE WICHTIGSTEN ROLLEN BEI SCRUM
In Ihrem Scrum-Team müssen Sie drei wesentliche Rollen besetzen:
Sie benötigen einen Product-Owner, der das zu entwickelnde Produkt fachlich verantwortet. Er spricht einerseits mit den Stakeholdern und andererseits mit dem Dev-Team. Dazu nimmt der Product-Owner die Anforderungen auf, analysiert sie, bringt sie in eine Struktur, klassifiziert sie und vergibt Prioritäten.
Das Dev-Team verantwortet die Entwicklung der funktionsfähigen Inkremente. Dazu sollte es alle notwendigen Kompetenzen erhalten. Durch das Einhalten des Scrum-Rahmenwerkes erkennt das Team aufkommende Risiken schneller und kann diesen entgegenwirken. Dabei organisiert sich das Dev-Team selbst.
Der Scrum Master fokussiert sich auf den Scrum-Prozess und ist dazu angehalten, Impediments (Behinderungen) vom Scrum-Team fernzuhalten. Damit wird das Dev-Team vor störenden Einflüssen geschützt und kann in Ruhe an der Entwicklung des Inkrements arbeiten. Der Scrum-Master ist jedoch nicht weisungsbefugt, sondern hilft dem Team bei der methodischen Umsetzung als Moderator und Coach.
Visualisierung und Rituale
Zur Visualisierung benutzt das Dev-Team ein Scrum-Board, das immer den aktuellen Stand der Entwicklungsarbeit zeigt. So wird der Restaufwand der Tasks täglich dokumentiert. Das Entwicklungsteam trifft sich jeden Tag zu einem Daily-Scrum-Meeting, das einer Timebox-Beschränkung unterliegt und auf 15 Minuten begrenzt ist. Am Daily-Scrum nehmen das Dev-Team, der Product-Owner und der Scrum-Master teil. In dem Meeting stellen die Mitarbeiter vor, welche Tasks sie gestern bearbeitet haben, an welchen sie heute arbeiten wollen und (ggf.) auf welche Probleme sie gestoßen sind.
Das Ergebnis eines Sprints wird als Increment oder Inkrement bezeichnet. Dies ist eine einsatzfähige Funktionalität, die auf Basis der Akzeptanzkriterien entwickelt wurde. Ob das entwickelte Inkrement vollständig ist, wird anhand der Definition-of-Done (auch DoD) festgestellt.
Am Ende jedes Sprints findet eine Retrospektive statt, die sich auf den vorhergehenden Sprint bezieht. Dabei werden die Zusammenarbeit, das Ergebnis und der Prozess besprochen. Bei bestehenden Problemen entwickelt und vereinbart das Team weitere Maßnahmen. Diese fließen in die tägliche agile Zusammenarbeit ein und werden anschließend umgesetzt.
DIE WICHTIGSTEN RITUALE BEI SCRUM
Charakteristisch für Scrum sind Rituale, die im Rahmen des Scrum-Prozesses regelmäßig stattfinden:
Zu Beginn des Sprints findet das Sprint-Planning statt. Es dauert einen Arbeitstag und ist „timeboxed“ auf acht Stunden. Hier wählt das Team gemeinsam mit dem Product-Owner die User-Stories aus dem Product-Backlog entsprechend ihrer Priorität aus, zieht sie in das Sprint-Backlog und bricht sie in einzelne Tasks herunter. Das gesamte Scrum-Team verpflichtet („committet“) sich auf den Umsetzungsplan des Sprints und arbeitet selbstorganisiert an den Tasks. Wenn das Dev-Team es wünscht, kann der Scrum Master diesen Termin moderieren.
Das Daily-Scrum ist auf maximal 15 Minuten begrenzt. Für gewöhnlich findet das Meeting morgens statt, da besprochen wird, woran jedes Teammitglied gestern gearbeitet hat und woran es heute arbeiten will. Probleme werden so frühzeitig besprochen und die Entwickler können mit neuen Lösungsvorschlägen an ihren Aufgaben weiterarbeiten.
Das Sprint-Review findet am Ende jedes Sprints statt. In diesem Meeting präsentiert das Dev-Team dem Product-Owner (und eventuell weiteren Stakeholdern) die Ergebnisse des Inkrements. Hieraus ergibt sich Feedback, welches das Dev-Team im nächsten Sprint berücksichtigen kann. Notwendige Verbesserungen werden als neue Arbeitspakete geschnürt und sind Teil des nächsten Sprint-Plannings.
Ebenfalls am Ende eines Sprints wird eine Retrospektive eingeplant. Hier geht es darum, den Scrum-Prozess insgesamt zu verbessern. Jedes Teammitglied teilt mit, was aus seiner Sicht positiv und negativ gelaufen ist. Daraus werden Maßnahmen zur Verbesserung abgeleitet. An der Retrospektive nehmen das Dev-Team, der Product-Owner und der Scrum Master teil.
Kanban
Das Kanban-Framework stammt aus dem Bereich Lean Production und hat seine Ursprünge in der japanischen Automobilindustrie. Mithilfe von Tafeln, auf denen Arbeitsaufgaben anhand ihres Status visualisiert werden (Kan = Visualisierung; Ban = Tafel, Karten), entsteht ein Work-in-Progress-Modus, in dem das Team arbeitet.
Aufgaben lassen sich dadurch schneller erledigen, denn es gibt einen klaren Fokus und der gesamte Entwicklungszyklus ist auf dem Kanban-Board transparent dargestellt. Mit Hilfe der Visualisierung, aber auch dem Limitieren der zu erledigenden Aufgaben auf dem Board lassen sich Engpässe und daraus resultierende Probleme schnell identifizieren. Dies mündet in einen kontinuierlichen Verbesserungsprozess (KVP), der den Kern von Kanban darstellt.
Wie funktioniert Kanban?
Die Team-Mitglieder schreiben die Anforderungen auf physische oder digitale Karten, die sie dann entsprechend des Fortschritts über das Kanban-Board schieben. Jede Karte startet im Backlog und durchläuft die Phasen „To-Do“ und „Doing“. Sobald die Aufgabe fertiggestellt ist, wird die Karte in den Status „Done“ gesetzt.
Die Anzahl parallel zu bearbeitender Tasks wird in jeder Phase mit einem sogenannten Work-in-Progress-Limit (auch WIP-Limit) begrenzt. Das Team kann keine weiteren Tasks in eine Phase ziehen, bevor andere Aufgaben nicht in die nächste Phase gerutscht sind. Aus dieser Arbeitsweise können Anwender schließen, an welcher Stelle ein Engpass besteht und wo die Arbeit sich staut. Ebenso zeigt das Board, ob Team-Mitglieder auf Tasks warten. Diese Engpässe müssen aufgehoben werden, um den Durchsatz an Tasks nicht zu gefährden.
Der Kanban-Prozess basiert auf dem Pull-Prinzip. Tasks werden erst dann gezogen, wenn das WIP-Limit der nächsten Phase dies erlaubt. Wie bei Scrum ist auch bei Kanban das Team für seine Arbeit verantwortlich; es bedarf keiner Instanz, die den Prozess überwacht.
Auch im Kanban Framework gibt es einfache Regeln, die in der Zusammenarbeit beachtet werden sollten:
- Der Arbeitsfluss wird auf einem physischen oder digitalen Kanban-Board visualisiert.
- Ein Teammitglied startet erst mit einem Task, wenn der vorherige erledigt ist.
- Es gilt das Pull-Prinzip.
- Das WIP-Limit ist immer zu beachten.
- Die Durchlaufzeit sollte gemessen und durch geeignete Maßnahmen verringert werden.
- Jedes Teammitglied sollte Prozessverbesserungen unterstützen.
- Ebenso sollten Feedback-Prozesse implementiert werden.
Indem die Teammitglieder Regeln einhalten sowie Verbesserungsvorschläge erarbeiten, abschätzen und umsetzen (z. B. zu Durchlaufzeiten, Engpässen sowie der Überlastung von Teammitgliedern), verbessert sich der Kanban-Prozess. Dadurch können sie die gewünschten Ziele schneller erreichen. Wichtig ist, darauf zu achten, dass die Teammitglieder so wenig wie möglich Kontextwechseln ausgesetzt sind.
Folgende Techniken unterstützen das Kanban Framework:
- Im Kanban trifft sich das Team täglich zu einem Standup-Meeting. Hierbei handelt es sich eher um ein Feedback-Meeting, bei dem sich das Team vor das Kanban-Board stellt und dessen Inhalte bespricht. Sie tauschen sich über die Tasks oder Tickets auf dem Board aus, damit alle den gleichen Stand haben und evtl. aufkommende Probleme abstimmen können. Auch dieses Meeting sollte nicht länger als ca. 15 Minuten dauern. Längere Abstimmungen sollten nicht in diesem Meeting erfolgen.
- Beim Arbeits-Review wird der aktuelle Prozess reflektiert. Das Team diskutiert über Probleme und identifiziert Verbesserungspotenziale. Die Arbeits-Reviews sind zwar vergleichbar mit Retrospektiven, finden jedoch unregelmäßig statt.
- Darüber hinaus gibt es Steuerungsinstrumente, mit denen das Team die Termine, Fehler und Durchlaufzeiten erfassen kann. Ein Beispiel ist die Messung der durchschnittlichen Durchlaufzeit eines Tickets. Dabei ist dies die Zeit, die ein Ticket benötigt, um ein Mal die gesamten Phasen des Kanban-Boards zu durchlaufen.
Grundsätzlich versuchen Anwender im Kanban, die Durchlaufzeiten und die Qualität der Ergebnisse zu verbessern oder zu optimieren. Engpässe können weitere Defizite im Team sichtbar machen, zum Beispiel fehlendes Know-how zu einer Technologie. Aufgrund dieser Erkenntnis können Maßnahmen wie Code-Reviews und Pair Programming erfolgen.
Der größte Vorteil von Kanban ist, dass es sehr einfach ist. Das Board kann direkt als Kommunikationsgrundlage im Team dienen und visuell den aktuellen Stand zeigen. Weiterhin können die Entwicklung, Wartung oder der IT-Betrieb Kanban einsetzen. Auch das persönliche Zeitmanagement können Sie mit einem Kanban-Board unterstützen.
Für gewöhnlich gibt es bei Kanban die Phasen Entwicklung, Test, Release und Done. Jedoch ist der Workflow an die eigenen Bedürfnisse anpassbar. Im Produkt-Backlog werden die Tickets ebenso wie im Scrum priorisiert. Ein Teammitglied nimmt sich ein Ticket, nachdem es das vorherige abgeschlossen hat.
„Ein Ticket enthält eine Beschreibung, eine Schätzung und weitere Informationen, beispielsweise Verantwortlichkeiten, technische Details und Screenshots, wenn diese hilfreich sind.“
Weitere Agile Techniken
Burn-Down-Chart
Burn-Down-Charts sind für das Dev-Team eine Alternative zur Fortschrittskontrolle. Die Übersicht zeigt die Relation zwischen dem, was noch offen ist, und der Zeit, die noch verbleibt. Damit werden Abweichungen vom Plan identifiziert und es ergibt sich die Velocity des Teams (Umsetzungsgeschwindigkeit von Tickets), auf der die weitere Planung aufsetzt. Entsprechend wird mit jeder Schätzung die Planung genauer.
Das Burn-Down-Chart kann sehr gut in Sprints zum Einsatz kommen und sollte täglich aktualisiert werden. Auf der Waagerechten trägt das Team die Länge des Sprints ab, so dass für alle ersichtlich wird, wieviel im Zeitablauf noch zu tun ist. Da die Menge der Tasks abnimmt, verläuft der abgetragene Graph nach unten.
Neben dem tatsächlichen Verlauf des Graphen sollten Teams auch einen Graph für die Planung eintragen. Auf diese Weise können sie Abweichungen früh erkennen und rechtzeitig passende Maßnahmen ergreifen. Für gewöhnlich sollten die Mitarbeiter das Chart in jedem Daily besprechen, damit sie Restaufwände direkt dort berücksichtigen können.
Um den Fortschritt zu kontrollieren, steht dem Product-Owner beispielsweise das Release-Burn-Down-Chart zur Verfügung. Hier kann er die Fertigstellung von User-Stories messen und Abweichungen von der Release-Planung frühzeitig erkennen. Das erleichtert es dem Product-Owner, den Projektfortschritt zu kontrollieren und nachzusteuern.
Definiton-of-Done
Diese kann als Checkliste dienen und muss vom gesamten Scrum-Team vereinbart und kommuniziert werden, um Missverständnissen entgegenzuwirken. Die Definition der DoD sollte demzufolge ebenfalls im Team stattfinden.
Die Kriterien können sehr unterschiedlich sein und sollten funktionale und nicht-funktionale Anforderungen beinhalten. Die DoD gewährleistet demzufolge auch die Softwarequalität. Daher sollte die DoD (neben den bereits genannten Kriterien) auch Faktoren wie Testabdeckung und Refactoring berücksichtigen.
„Bei der Definition-of-Done (DoD) handelt sich um eine Liste von Kriterien, die erfüllt sein müssen, damit eine User-Story als fertig gilt.“
Planungstechniken
Die relative Schätzung wird vorwiegend in der agilen Zusammenarbeit genutzt, da sie trivialer abzuschätzen sind. Aber auch Schätzungen mit absoluten Werten sind in der agilen Zusammenarbeit möglich. Die Schätzmethode sollte jedoch zu Beginn eines Projekts vereinbart werden.
Story Points sind eine Möglichkeit, um eine User-Story zu bewerten. Eine weitere Option zur relativen Schätzung ist das Schätzen in T-Shirt-Größen. Je nach Planungshorizont kann eine grobe Planung bei einem längerfristigen Zeithorizont ausreichen. Je kurzfristiger die Planung wird (zum Beispiel die Vorbereitung des nächsten Sprints), desto genauer sollte die Schätzung ausfallen.
Mehr zum Thema „Einschätzen mit T-Shirt Größen“ auf Agile Academy & „Agiles Schätzen“ auf it-agile.de.
Planning Poker
- Planning Poker ist eine Alternative, mit der sich das Team auf einen Schätzwert für eine Anforderung einigen kann. Dabei wird in regelmäßigen Abständen jede User-Story geschätzt. Wie beim Poker verwenden die Teilnehmer Karten mit entsprechenden Ziffern. Oft nutzen sie dabei die Fibonacci-Folge. Darunter versteht man eine unendliche Zahlenfolge natürlicher Zahlen. Im Planning Poker fängt man mit der 1 an und geht weiter mit 2 (1+1), 3 (2+1), 5 (3+2), 8 (5+3), 13 (8+5) usw. Je komplexer das Ticket, umso höher die Zahl. Jedes Teammitglied zeigt den anderen zur gleichen Zeit die eigene Schätzung, die der Komplexität der User-Story entsprechen sollte. Wichtig ist, dass dies gleichzeitig geschieht, damit sich die Teilnehmer nicht untereinander beeinflussen. Unterscheiden sich die Schätzungen, wird über die geringste sowie die höchste Schätzung diskutiert. Dabei erläutert das jeweilige Teammitglied die Gründe für seine Einschätzung. Nach der Diskussion wird ein weiteres Mal geschätzt. Meist einigt sich das Team dann bereits auf einen Wert.
- User Stories und Akzeptanzkriterien
- Die fachlichen Anforderungen werden in der agilen Zusammenarbeit meist als User-Stories beschrieben. Hiermit rückt der Kundennutzen in den Fokus, was eventuell bei einem anderen Format abhandenkommen könnte. Zu den User-Stories gehören Akzeptanzkriterien, die beschreiben, wann eine User-Story vom Team annehmbar ist. Der Umfang einer Story sollte so gering wie möglich bleiben, gleichzeitig aber auch die Funktionalität der Anforderungen genau beschreiben. Eine User-Story ist wie folgt aufgebaut:
- Der Kundennutzen muss klar erkennbar sein. Da die User-Story erst abgenommen werden kann, wenn alle Akzeptanzkriterien umgesetzt sind, sollten die DoD die Akzeptanzkriterien beinhalten. Darauf aufbauend können Testfälle generiert werden, die der Testdurchführung und der Beurteilung der Testabdeckung dienen. Folgende Qualitätskriterien, auch INVEST-Kriterien genannt, sollten bei der Erstellung der User-Stories beachtet werden:
- Eine User-Story muss unabhängig von anderen Stories sein (Independent).
- Eine User-Story wird in Abstimmung mit Stakeholdern und dem Dev-Team präzisiert (Negotiable).
- Jede User-Story generiert einen Mehrwert für den Kunden (Valuable).
- Jede User-Story muss geschätzt sein. Sie muss so verständlich und einfach sein, dass die Entwickler den Aufwand schätzen können. Ist dies nicht möglich, muss die User-Story präzisiert werden. Sollte die User-Story zu groß sein, können die Teammitglieder sie ggf. sinnvoll zerlegen (Estimable).
- Die User-Story muss so klein sein, dass sie in einem Sprint oder einer Iteration fertigstellbar ist (Small).
- Die User-Story muss testbar sein. Dies dient später auch der DoD (Testable).
- Anhand dieser Kriterien kann (und sollte, wenn notwendig) eine Definition-of-Ready (DoR) vereinbart werden. Ähnlich zur DoD definiert diese Checklisten, mit denen das Team prüfen kann, ob etwas fertig ist und abgenommen werden kann. Im Fall der DoR werden die User-Stories betrachtet und bewertet. Die Checkliste kann auch aus verschiedenen Kriterien bestehen. Solange nicht alle Kriterien zu einer User-Story erfüllt sind, muss diese präzisiert werden. Sind diese erfüllt, kann die User-Story für den nächsten Sprint vorgesehen werden. Die Vereinbarung der DoR geschieht zwischen dem Dev-Team und dem Product-Owner, wobei der Scrum Master hier wieder unterstützen und beraten kann. Die Prüfung, ob eine User-Story entsprechend der DoR annehmbar ist, geschieht im Refinement. An diesem sollte das gesamte Scrum-Team teilnehmen, damit Verständnis auf allen Seiten gewährleistet wird.
- Die User-Stories schreibt das Team auf Story Cards mit entsprechenden Kennzeichen (zum Beispiel ID, Titel, Priorität des Product Owner, Schätzung sowie Akzeptanzkriterien), die sie auf der Rückseite aufführen. Beim Einsatz eines Tools bringt dieses die entsprechenden Felder oft mit
- User Story Mapping – Den Kunden besser verstehen – Den Kunden besser verstehen
Fazit
Charakteristisch für agile Methoden ist, dass kleine, selbstorganisierte Teams eigenständig an einem Projekt arbeiten und dabei in regelmäßigen Abständen Feedback von Stakeholdern und Kunden erhalten. Im Vergleich zur klassisch-linearen Projektplanung mit festen Meilensteinen und Anforderungen entsteht ein wesentlich flexiblerer Projektplan, der es insbesondere in komplexen Situationen erleichtert, Kundenanforderungen und Marktentwicklungen zu berücksichtigen.
„Agil“ ist also alles andere als ein Modewort“
Die Vorteile, die sich Unternehmen davon versprechen, sind tatsächlich erreichbar. Allerdings ist Agilität niemals ein Selbstzweck. Entscheidern, die sich dafür interessieren, muss bewusst sein, dass Agilität sich auf die Strukturen und Hierarchien ihres Unternehmens auswirkt. Sie erfordert einen modernen, persönlicheren Führungsstil in Form einer „Shared Leadership“, bei der Führungskräfte mehr als Mentor, Vermittler und Koordinator wirken, die dem Team zur Seite stehen. Das ist eine der wesentlichsten Voraussetzung für den erfolgreichen Einsatz agiler Methoden.