Kitabı oku: «Roadmap durch die VUCA-Welt», sayfa 5
Ursprünge der Agilität
Die ersten beobachteten Ansätze, die schon sehr viele der Prinzipien und Werte reflektierten, die auch heute als „agil“ gelten, gehen zurück bis in das Jahr 1976. In diesem Jahr forderte das Unternehmen Canon von seinen Mitarbeitern eine technisch auf dem neusten Stand befindliche Kamera herzustellen, die aber mindestens 30 % günstiger sein sollte als alle bisher auf dem Markt befindlichen Produkte. Und das mit massivem Zeitdruck, denn es war harter Überlebenskampf in einem stark umkämpften Wettbewerb. Um das Ende vorwegzunehmen, das Team war erfolgreich. Heute ist Canon ganz vorne mit dabei, wenn es um Digitalfotografie und entsprechende Kameras geht. Damals jedoch stand man vor einer großen Herausforderung, die man mit den vorherrschenden tayloristischen Strukturen nicht lösen konnte.
Wie die meisten anderen Unternehmen in dieser Zeit, war auch Canon sehr klassisch aufgestellt. Es gab spezialisierte Fachabteilungen, die für bestimmte Aufgaben zuständig waren. Hatten sie ihre Aufgabe erledigt, wurde diese ausführlich dokumentiert und an die Nachbarabteilung übergeben, die den folgenden Entwicklungsschritt ausführte und dann ebenfalls die Ergebnisse übergab. Um ein Produkt komplett zu revolutionieren, mussten neue Ideen her und schnelle Entscheidungen getroffen werden.
Das Erfolgsgeheimnis, wie es den Mitarbeitern bei Canon gelang, diese große Herausforderung zu meistern, kann man in einem populären Artikel von Hirotaka Takeuchi und Ikujiro Nonaka nachlesen (Takeuchi/Nonaka 1986). In ihrer Veröffentlichung mit dem Namen „The new new product development game“ beschreiben sie ihre gesammelten Beobachtungen aus verschiedenen Unternehmen. Neben dem Beispiel von Canon finden sich hier auch Beschreibungen des Vorgehens bei Honda, Fuji-Xerox und NEC. Takeuchi und Nonaka konnten dabei Muster erkennen, die sich durch alle Beispiele hindurchzogen. Diese verdichteten sie und verwendeten auch erstmals in einem Paper die Parallele zu Rugby. Dort gibt es eine Phase im Spiel, wo das Team die Köpfe zusammensteckt, ganz fokussiert ist, und die nächsten Schritte vorbereitet. Sie sprechen immer vom „Rugby-Ansatz“, aber auch das Wort „Scrum“ Scrumtaucht hier schon auf. Diese Bezeichnung sollte ein paar Jahre später von anderen Pionieren der Agilität wieder aufgegriffen werden.
Das Missverständnis mit dem Wasserfall
In vielen großen Unternehmen gibt es Fachabteilungen für bestimmte Aufgaben. Dies ergibt Sinn, weil es Fachleuten erlaubt, sich auf ihre Spezialgebiete zu konzentrieren. Ab einer bestimmten Größe braucht es noch Zwischenpositionen, also Manager, die darauf achten, dass die Zusammenarbeit zwischen den Abteilungen reibungslos funktioniert. Wie Sie eingangs schon gesehen haben, gibt es eine Reihe von Abteilungen, die Schnittstellen haben, an denen sie die Arbeit an die nächste Abteilung übergeben.
So geht zum Beispiel ein Vertreter der Verkaufsabteilung zum Kunden und fragt ihn, was er benötigt. Der Kunde erklärt ihm jetzt eine fixe Idee und der Verkäufer kehrt zurück mit einem Katalog von Anforderungen. Diesen übergibt er nun einem Kollegen aus der Analyseabteilung und er selbst geht wieder nach draußen und besucht einen anderen Kunden. Sein Job ist an dieser Stelle für dieses Projekt erledigt. Der Analyst aus der Analyseabteilung setzt sich nun mit seinen Kollegen zusammen und diskutiert die Anforderungen. Sie schauen, was alles in das vorherrschende Konzept passt und ob und wann es umgesetzt werden kann. Wenn die Pläne konkreter werden, schreiben sie ihre Anmerkungen in ein Dokument und lassen es per Hauspost den Kollegen aus der Spezifikationsabteilung zukommen. Dann setzen sie sich zusammen und schauen sich den Anforderungskatalog eines anderen Kunden an. Die Mitarbeiter aus der Spezifikationsabteilung sehen sich das übergebene Dokument an und fangen an, sich Gedanken über die konkrete Umsetzung zu machen. Am Ende haben sie eine sehr schöne Funktionsbeschreibung, die Antworten auf die meisten Fragen zu bieten hat. Dieses umfangreiche Dokument wird dann der Entwicklungsabteilung zukommen lassen. Hier sitzen die Experten für die Umsetzung zusammen. Sie lesen sich die Funktionsbeschreibung durch und schreiten zur Tat. Schnell entsteht ein richtig schönes Produkt, welches sie jetzt, zusammen mit ein paar Kommentaren, welche Besonderheiten beachtet werden müssen, an die Qualitätssicherung übergeben. Hier wird das neue Produkt auf Herz und Nieren getestet. Wenn alle Tests erfolgreich durchlaufen sind, dann erfolgt eine Übergabe an eine Verkaufsabteilung, die das Produkt zum Kunden transportiert.
Diese Abfolge mit all ihren Übergaben wird gerne stufenförmig wie eine Treppe dargestellt, was dann an einen Wasserfall erinnert. Daher hat diese Vorgehensweise den Namen Wasserfallmodell bekommen.
Besonders stark diskutiert wird dieses Modell im Bereich der Softwareentwicklung, auch wenn es bei weitem nicht nur dort auftaucht. Aber im Bereich der Softwareentwicklung war man zeitlich schon sehr früh in einem recht komplexen Umfeld, was gewisse Erkenntnisse hier beschleunigt hat. Daher wurden einige Diskussionen, die auch in den meisten anderen Branchen von Relevanz sind, in dieser Domäne losgetreten und zuerst geführt. Denn so einfach, wie oben dargestellt, ist der Weg von einem Kundenwunsch zu einem fertigen Produkt, das diesen Wunsch erfüllt, bei Weitem nicht.
Es beginnt schon damit, dass die meisten Schnittstellen zwischen den Abteilungen so gestaltet sind, dass wenig direkte Kommunikation stattfindet. Die meisten Prozesse sehen vor, dass die Übergabe in Form standardisierter, schriftlicher Dokumente stattfindet. Dieses Dokument als Ergebnis der einen Abteilung stellt dann den Startpunkt für die Arbeit der nächsten Abteilung dar. Allerdings kommt es hier nicht selten zu Missverständnissen oder Fehlinterpretationen. Und so schleichen sich, nach dem Prinzip der stillen Post, zunehmend mehr Fehler ein. Wenn man Glück hat, dann fallen die Fehler während der Entwicklung bereits auf. Daher spielt hier die Qualitätssicherung eine wichtige Rolle.
Die bekannteste Beschreibung des Wasserfallmodells stammt von Winston W. RoyceRoyce, Winston W. aus dem Jahr 1970 (Royce 1970). Das Wasserfallmodell ist aber schon deutlich älter und Royce hat in seinem oft herangezogenen Paper eher auf ein paar Schwachstellen verwiesen und vorgeschlagen, wie man sie beheben könnte.
Abb. 10 :
Schematische Darstellung des Wasserfallmodells mit Rückkopplung
Dabei hatte Royce früh darauf hingewiesen, dass das Wasserfallmodell um ein paar Elemente erweitert werden müsse, die schon in eine recht agile Richtung deuteten. Das genutzte Wasserfallmodell stellte sich nämlich für ihn zunehmend als problematisch dar. Waren die ersten Programme noch vorhersehbar, so wurden die gewünschten Funktionalitäten zunehmend komplexer. Royce bemängelte vor allem, dass am Ende mitunter sogar unbrauchbare Ergebnisse herauskamen, auch wenn alle Abteilungen ihren Job hervorragend erledigt hatten. Er plädierte dafür, dass man Rückkopplungen berücksichtigen müsse. Dies würde zwar die Effizienz senken und Kosten verursachen, ihm war aber klar, dass dies notwendig war, um am Ende auch das zu liefern, was dem Kunden wirklich weiterhilft. So plädierte er für eine frühzeitige Beteiligung des Kunden in den Entwicklungsprozess, was, wie wir noch sehen werden, ein Grundbestandteil agilen Arbeitens darstellt.
Im Gegensatz zu diesem sequenziellen Durchlaufen der verschiedenen Schritte und der Aufteilung der Arbeit unter mehreren Abteilungen, konnten Takeuchi und Nonaka bei ihrer Betrachtung im „New new product development game“ sehen, dass der Erfolg sich einstellte, wenn genau diese Abfolge aufgelöst wurde. Nicht nur Canon, sondern auch die anderen untersuchten Firmen hatten Teams gebildet, die interdisziplinär aufgestellt waren. Das heißt, aus allen Abteilungen, die an der Entstehung des Produktes beteiligt waren, war mindestens ein Vertreter in einem Projektteam zugegen. Dieses Projektteam konzentrierte sich auf nichts anderes, als das gewünschte Ergebnis zu erreichen. Vorher hatten die Mitarbeiter im Rahmen ihrer Abteilung nur die Verantwortung für einen bestimmten Arbeitsschritt getragen. Nun waren sie, zusammen mit den anderen Teammitgliedern, dafür verantwortlich, dass das Produkt insgesamt fertig wurde und erfolgreich war. Zwar konzentrierten sie sich immer noch auf ihre Spezialgebiete, aber sie waren in einem engen Austausch miteinander und unterstützten sich auch bei fachfremden Aufgaben so gut es ging.
Abb. 11:
Interdisziplinäre Teamsinterdisziplinäre Teams decken alle Fachrichtungen ab und arbeiten iterativ.
Durch die abteilungsübergreifende Teamaufstellung war es nun möglich, kleine Zwischenstände der Arbeit schon nach relativen kurzen Zeiträumen zu präsentieren und mit den Kunden zu testen. Durch die frühe Einbeziehung des Kunden war es auch möglich, dass er die Rückmeldung gab, dass ihm das Produkt in einem gewissen Zustand schon vollkommen ausreiche. Dann konnte das Team überflüssige Anforderungen einfach von der Liste streichen. Im Wasserfall zuvor wurde einfach der komplette Anforderungskatalog abgearbeitet.
Lyssa AdkinsAdkins, Lyssa, die eine Verfechterin der agilen Vorgehensweisen ist, stellt in einem YouTube-Video sehr schön dar, welche Vorteile es mit sich bringt, statt auf Wasserfall auf interdisziplinäre Teams und kurze Zyklen zu setzen.3 Dabei vergleicht sie die Abarbeitung mit Schichten einer Hochzeitstorte. Beim Wasserfallmodell isst man sozusagen Schicht für Schicht der mehrlagigen Hochzeitstorte. Zuerst die Sahne (und zwar komplett), dann Biskuit (und zwar ebenfalls komplett) und so weiter, bis man schließlich am Boden angelangt ist. Kein besonders reizvoller Ansatz, um einen Kuchen zu essen. Will man eine Torte „agil essen“, schneidet man sich hingegen einfach ein Stück aus der Torte heraus und isst es auf. Dabei entfaltet sich dann der Geschmack, der sich aus den Kombinationen der unterschiedlichen Lagen ergibt. Und wenn man satt ist, dann hört man einfach auf. So lange schneidet man sich einfach Stück für Stück aus der Torte heraus. Auf welche Art und Weise würden Sie lieber eine Torte genießen?
Das Agile Manifest
Im Jahr 2001 fanden sich einige Vertreter aus dem Bereich der Softwareentwicklung zusammen und unterzeichneten gemeinsam das Agile Manifestagiles Manifest4. Auch wenn es im Bereich der Softwareentwicklung seine Wurzeln hat, so ist es so universell, dass sein Einfluss deutlich darüber hinausreicht. Heutzutage gibt es einige Initiativen, die sich dafür stark machen, das ursprüngliche Manifest zu überarbeiten und die Verweise auf die Software zu ersetzen oder das komplette Manifest noch einmal zu modernisieren. Aber auch in der momentanen Form bietet das Agile Manifest einen Kern von dem, was als Agilität in unterschiedlichsten Bereichen, Branchen und Domänen verstanden wird.
Das Agile Manifest formuliert vier Werte und zwölf Prinzipien. Den Originaltext finden Sie in der Box. Die vier Werte, die im Agilen Manifest propagiert werden, werden ins Verhältnis gesetzt zu anderen Werten, die sich zumeist auf die gängigen Praktiken in der Realität der Unterzeichner wiedergefunden haben. Dabei wird der kleine Nachsatz, unterhalb dieser Werte, gerne einmal übersehen. Dieser weist darauf hin, dass die Unterzeichner durchaus einen Nutzen in den Werten auf der rechten Seite sehen, aber den Nutzen auf der linken Seite deutlich höher werten. Dies führt häufiger auch zu Missverständnissen, wenn über Werte im agilen Umfeld diskutiert wird. So hält sich zum Beispiel hartnäckig der Mythos, bei agilen Vorgehensweisen brauche man keine Dokumentation oder müsse nicht in die Zukunft planen. Dies ist natürlich nicht so, was die Verfasser durch den erwähnten Zusatz noch einmal unterstreichen wollten.
An oberster Stelle steht im Agilen Manifest, dass Individuen und Interaktionen höher zu gewichten sind als Prozesse und Werkzeuge. Man möchte nicht mehr schriftlich miteinander kommunizieren, sondern durch direkten Kontakt und Kollaboration. Dies zeigt sich auch in den agilen Prinzipien, zu denen wir später kommen.
| Manifest für Agile Softwareentwicklung | ||
| Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: | ||
| Individuen und Interaktionen mehr als Prozesse und Werkzeuge | ||
| Funktionierende Software mehr als umfassende Dokumentation | ||
| Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung | ||
| Reagieren auf Veränderung mehr als das 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. | ||
| Kent Beck | James Grenning | Robert C. Martin |
| Mike Beedle | Jim Highsmith | Steve Mellor |
| Arie van Bennekum | Andrew Hunt | Ken Schwaber |
| Alistair Cockburn | Ron Jeffries | Jeff Sutherland |
| Ward Cunningham | Jon Kern | Dave Thomas |
| Martin Fowler | Brian Marick | |
Abb. 12:
Das Agile Manifest (eigene Darstellung nach http://agilemanifesto.org)5
Den Ursprung aus dem Bereich der Softwareentwicklung sieht man sehr deutlich im zweiten Wertepaar, welches funktionierende Software über eine umfassende Dokumentation stellt. Hier kann Software ohne viel Fantasie durch ein begeisterndes Produkt, eine zufriedenstellende Dienstleistung oder was auch immer man liefern möchte, ersetzt werden. Den Autoren war dabei wichtig, darauf hinzuweisen, dass das Endprodukt im Fokus stehen sollte, nicht Dokumentation für interne Prozesse. Zwar kann man dadurch bei einem Fehlschlag sehr schön seinen Kopf aus der Schlinge ziehen (vielleicht kennen Sie auch das geflügelte Wort „Wer schreibt, der bleibt“), aber dem Kunden nutzt dies nur sehr wenig. In einer gesunden Kultur sollte immer der Kundennutzen im Mittelpunkt stehen, nicht der Selbstschutz.
Das wird auch aus dem dritten Wertepaar ersichtlich, das die Zusammenarbeit mit dem Kunden über die Vertragsverhandlungen stellt. Natürlich braucht man im Geschäftsleben Verträge, aber viel wichtiger ist es, den Kunden von einer wertschätzenden Partnerschaft zu überzeugen und ihn in den Entwicklungsprozess zu integrieren. Durch eine enge Zusammenarbeit kann man sehr schnell feststellen, ob man auf dem richtigen Weg ist. Kurskorrekturen können sofort vorgenommen werden und am Ende entsteht so hoffentlich ein Produkt, mit dem der Kunde glücklich ist. Das Abarbeiten ausführlicher Pflichtenhefte führt nicht unbedingt dazu, dass am Ende auch ein Produkt entsteht, das der Kunde so haben wollte.
Zuletzt betonen die Autoren noch, dass das Reagieren auf Veränderung deutlich wichtiger ist, als einem vorher festgelegten Plan zu folgen. Den Unterzeichnern war klar, dass man schnell auf Veränderungen in der Umwelt reagieren müsse, um erfolgreich zu sein. Um es auch noch mal in aller Deutlichkeit zu sagen: Auch in der agilen Welt spielen Pläne eine große Rolle. Allerdings hat nicht mehr, um die Zukunft vorherzusagen, sondern vielmehr um Transparenz herzustellen.
Lassen Sie uns auf den nächsten Seiten einen Blick auf die agilen Prinzipien werfen. Diese werden oftmals übersehen, dabei bilden sie das Rückgrat des agilen Arbeitens.
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Zum einen spiegelt sich hier die starke Fokussierung auf den Kunden wider. Alles, was getan wird, sollte das Ziel haben, den Kunden zufrieden zu stellen. Aber auch über die Art und Weise, wie dies erreicht wird, kann man hier etwas finden, nämlich durch frühe und kontinuierliche Lieferung. So sollte schon sehr frühzeitig und in regelmäßigen Abständen etwas an den Kunden übergeben werden. Im Fall von Software ist dies relativ einfach, denn man kann ja einfach Funktionen nachliefern. Das ist heute oft gelebte Realität. Es gibt viele Apps, die schon sehr früh erscheinen und dann nach und nach neue Funktionalitäten nachliefern. So können viele Menschen die App schon nutzen mit den Funktionalitäten, die vorhanden sind.
Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden! Anforderungsänderungen sind in der Regel ärgerlich. Denn in den allermeisten Fällen hat man schon Zeit investiert, um sie umzusetzen, oder sich zumindest Gedanken darüber gemacht, wie eine Umsetzung aussehen könnte. Aus Kundensicht wäre eine Änderung aber sehr vorteilhaft. Sei es, weil sich die Voraussetzungen verändert haben, oder dass der Kunde durch einen Zwischenstand neue Erkenntnisse gewonnen hat. In einer von Vertrauen geprägten Beziehung sollte man davon ausgehen, dass das Gegenüber gute Gründe für einen Änderungswunsch hat. Und aus diesem Grund sollte man auch diese Anforderungsänderungen willkommen heißen und als Chance sehen, ein noch besseres Endprodukt herauszubringen.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne! Hier wird noch etwas konkreter was es heißt, regelmäßig zu liefern, denn man sollte sich auf wenige Wochen oder Monate beziehen. In Zeiten formuliert, wo Software teilweise Veröffentlichungszyklen von Jahren hatte, ist dies eine sehr forsche Forderung. Aber nur, wenn man dieses Prinzip befolgt, wird man auch schnell auf Veränderungen reagieren können. Mit kurzen Zyklen kann man sehr schnell Hypothesen testen und bei Problemen eine Richtungsänderung vornehmen. Je länger eine Entwicklungsphase ohne Feedbackzyklus ist, desto teurer wird eine potenzielle Fehlentscheidung ausfallen.
Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten! Um kurze Zyklen und kontinuierliche Lieferung zu gewährleisten, braucht man ein anderes Konstrukt als ein auf dem Wasserfallmodell basierendes. Es benötigt interdisziplinär aufgestellte Teams, in denen unterschiedliche Perspektiven und Expertisen zusammenkommen. Diese sollten eng auf täglicher Basis miteinander arbeiten. So entsteht tiefes Verständnis für die Domäne des anderen und es kommt zu echter Kollaboration.
Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen! Hier werden sich eher die Organisationsgestalter angesprochen fühlen. Es geht darum, den interdisziplinären Teams einen geeigneten Rahmen zur Verfügung zu stellen, in dem sie sich entfalten können. Teams benötigen Freiheiten, selbst Entscheidungen treffen zu dürfen. Das setzt Vertrauen voraus, denn bisher wurden die meisten Entscheidungen traditionell an anderen Positionen in der Unternehmenshierarchie getroffen. Auch die Motivation spielt eine große Rolle. Was Menschen motiviert und welche grundlegenden Motive dabei eine Rolle spielen, werden wir uns noch im Detail ansehen.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Hier werden wahrscheinlich einige effizienzgetriebene Manager schlucken, denn mündliche Kommunikation mit Rückfragen und Diskussionen ist vieles, aber aus ihrer Sicht nur selten effizient. Aber was wäre die Alternative? Der klassische Weg über eine Vielzahl von Dokumenten und geschriebenen Worten vielleicht. Aber im Falle eines eng zusammenarbeitenden Teams sieht das vielleicht schon wieder anders aus. Bei schriftlicher Kommunikation besteht immer die Gefahr, dass etwas fehlinterpretiert wird, was dann im Nachgang mit deutlich höheren Kosten für Korrekturen verbunden ist.
Funktionierende Software ist das wichtigste Fortschrittsmaß. Am Ende zählt das Ergebnis. Und nicht, wie viele Stunden auf der Planansicht noch übrig sind, wie viel Budget noch zur Verfügung steht. Das sind alles wichtige und gute Anhaltspunkte, um ein Projekt zu planen und zu messen. Was bringt es Ihnen aber, wenn Sie in der Zeit und im Budget geblieben sind, der Kunde Ihnen aber sagt, dass er mit dem Produkt so leider nichts anfangen kann. Daher sollte der Fokus aller Beteiligten immer auf dem Produkt selbst liegen und alle anderen Metriken als Unterstützung aber nicht als Ziel ansehen.
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Alle bisher genannten Prinzipien bauen darauf, dass das Team und die Kunden eng zusammenarbeiten und kollaborieren. Wenn man ständig unter Strom steht und die Nerven blank liegen, dann ist das keine gute Voraussetzung für gute Zusammenarbeit. Daher wird Wert daraufgelegt, dass das Tempo dauerhaft gehalten werden kann. Durch das Arbeiten in kleinen Iterationen und Zwischenschritten, zu denen man sich Feedback einholen kann, wird dann auch verhindert, dass man eine große Deadline6 ansteuert und zum Ende hin Überstunden ohne Ende ansammeln muss.
Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Damit man auch kontinuierlich liefern kann und sich damit nicht dauerhaft unter Druck setzt, ist es sinnvoll, in Weiterbildung und technische Exzellenz zu investieren. So schafft man die Möglichkeit, mehr Arbeit in der gleichen Zeit zu schaffen. Dabei arbeitet das Team nicht härter sondern smarter. Dafür muss aber auch Zeit investiert werden, die von dem Rahmen gegeben werden muss. Sie sehen, dass die Balance von P (Produktion) und PK (Produktionskapazität) eine sehr wichtige Rolle spielt.
Einfachheit – die Kunst nicht getane Arbeit zu maximieren – ist essenziell. Einfachheit ist eine Kunst. Zugegebenermaßen fällt es nicht immer leicht, sich an dieses Prinzip zu halten. Wenn ein Team sich daran macht, die Anforderungen zu zerlegen, um sie in ihren Iterationen zu bearbeiten, sollte es immer im Hinterkopf haben, dass es nicht darum geht, alle erdenklichen Fälle abzudecken, sondern möglichst schnell eine Hypothese zu überprüfen und eine erste Version zu liefern. Hier greift auch wieder das Beispiel mit der Smartphone App, die von einer sehr einfachen Version ausgehend anwachsen kann zu einem sehr mächtigen Werkzeug. Es braucht einen Balanceakt zwischen Einfachheit und vorausschauendem Handeln. Damit dies gelingt ist es umso wichtiger, dass das Team an sich arbeitet und technische Exzellenz anstrebt.
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Die Aufzählung ist wieder sehr softwarelastig, lässt sich aber durch alles ersetzen, was ein Team tun muss, um ein herausragendes Produkt zu erstellen. Die Kernaussage ist die, dass ein Team, das aus Experten besteht, die die Freiheit haben, ihre Arbeit so zu organisieren, dass jeder sich voll einbringen kann, in der Regel solchen Teams überlegen sind, die nur Anweisungen befolgen.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten dementsprechend an. Das letzte der zwölf agilen Prinzipien bezieht sich auf den kontinuierlichen Verbesserungsprozess. Das Team setzt sich regelmäßig mit der Zusammenarbeit auseinander und nimmt Anpassungen vor. Diese retrospektive Betrachtungsweise kennt man zwar auch aus klassischen Projekten, aber dort wird sie in der Regel erst zum Abschluss eines Projektes durchgeführt (auch bekannt als „Post Mortem“ oder „Lessons Learned“). Das Problem ist dabei oft, dass die handelnden Personen im nächsten Projekt nicht mehr zusammenarbeiten. Das Projekt selbst profitiert zudem leider nicht mehr von den neuen Erkenntnissen. In agilen Vorgehensweisen legt man daher sehr großen Wert darauf, sich regelmäßig zusammenzusetzen und eine Retrospektive durchzuführen.
Wenn Sie die vier Werte und die zwölf Prinzipien des Agilen Manifests genauer betrachten, so erkennen Sie, dass hier keine bahnbrechenden neuen Erkenntnisse niedergeschrieben wurden. Vieles von dem, was Sie hier gesehen haben, ist gesunder Menschenverstand oder durch Beobachtung erfahrbar. Zudem gab es, wie von Takeuchi und Nonaka schon 1986 berichtet, sehr viele Teams und Unternehmen, die diese Werte lebten und den Prinzipien folgten. Trotzdem bekam dies alles durch den Zusammenschluss und der Unterzeichnung des Agilen Manifests noch einmal eine ganz neue Dynamik. Das Agile Manifest ist der Startschuss für eine große Veränderung der Arbeitsweisen geworden und das Wort „Agilität“ ist in die Managementetagen der Unternehmen eingezogen.
