Read the book: «Roadmap durch die VUCA-Welt»

Grundlagen von Agilität

Wenn wir uns mit der Digitalisierung und den Veränderungen beschäftigen, die damit für Arbeitsweisen, Unternehmen und auch jeden einzelnen einhergehen, dann spielt das Thema Agilität eine zentrale Rolle. An dieser Stelle möchte ich einen kurzen Überblick über die Grundlagen geben. Schauen wir uns dafür zunächst einmal die historischen Wurzeln an.

Lean Management

Im Zusammenhang mit Agilität wird sehr häufig auch der Begriff „Lean“ verwendet. Teilweise werden diese Begriffe sogar synonym verwendet, was allerdings nicht korrekt ist. Lean stammt aus der Produktion und hat einen sehr starken Fokus darauf, Verschwendung zu reduzieren. Dabei wird oft das Toyota-Produktionssystem, das untrennbar mit dem Namen seines Erfinders Taiichi ŌnoŌno, Taiichi verbunden ist, als Vorbild herangezogen (Ōno 2013). Toyota war es gelungen, ein System einzuführen, dass es dem Unternehmen erlaubte, ganz neue Qualitätsmaßstäbe zu setzen. Viele Unternehmen aus dem Westen unternahmen Reisen zu Toyota, um sich Dinge von diesem Vorzeigemodell abzuschauen.

Heutzutage gibt es in sehr vielen Unternehmen, besonders in der Produktion, Lean Initiativen, die auf den gleichen oder sehr ähnlichen Prinzipien beruhen. Die Gestaltungsprinzipien dieser Produktionssysteme sind dem nachempfunden, was Toyota zum Vorbild gemacht hat. Dabei steht die Vermeidung von Verschwendung an vorderster Stelle. Hier wird versucht, alles, was nicht direkt oder indirekt zur Wertschöpfung beiträgt, zu vermeiden. Ōno nennt diese Arten von Verschwendung MudaMuda. Zusammen mit MuriMuri (Überbeanspruchung) und MuraMura (Unausgeglichenheit) bildet Muda (Verschwendung) das sogenannte 3M des Toyota-Produktionssystems.

Tab. 3:

Das 3M des Toyota-Produktionssystems

Ein weiteres Gestaltungsprinzip ist die Standardisierung. Durch Standardisierung versucht man, möglichst alle unnötigen Arbeitsschritte aus dem Prozess zu entfernen. Dadurch soll zum einen die Effizienz erhöht werden, zum anderen aber natürlich auch die Qualität. Standardisiert wird alles, was wiederholt durchgeführt wird und festen Abläufen und Fertigungsschritten zugeordnet werden kann.

Das Null-Fehler-Prinzip ist ein weiterer wichtiger Aspekt. Dieses hat zur Folge, dass jeder Mitarbeiter die Möglichkeit hat, die komplette Produktion anzuhalten, wenn er einen Fehler entdeckt. Dann ist jeder Beteiligte angehalten, an der Behebung des Fehlers mitzuwirken. Vorher wird nicht weiter produziert. Was auf den ersten Blick wie Verschwendung erscheinen mag, weil andere Produktionsschritte vielleicht gar nicht betroffen sind von dem aufgetretenen Fehler, ist eine Grundlage für die hohe Qualität, die so erreicht wurde.

Natürlich sollten Fehler, die das gesamte System lahmlegen, die absolute Ausnahme darstellen. Denn der möglichst geschmeidige Fluss der Arbeit durch das System ist ein weiteres Gestaltprinzip von Ganzheitlichen Produktionssystemen. Dieser Fluss wird immer wieder auf möglichst geringe Durchlaufzeiten hin optimiert und angepasst.

Ein grundlegender Bestandteil ist auch das Pull-Prinzip. Dieses sieht vor, dass Arbeit jeweils vom nächsten Prozessschritt gezogen wird und nicht vom vorherigen in den nächsten Schritt gedrückt wird. Somit fließt die Arbeit im Optimalfall, durch einen Kundenauftrag gezogen, durch das Fertigungssystem.

Ein sehr anschauliches und greifbares Beispiel für diese Art der Produktion können Sie in dem Roman „Das Ziel“ von Eliyahu Goldratt (Goldratt/Cox 2013) nachlesen. Hier wird die Geschichte eines Fabrikleiters erzählt, dessen Fabrik kurz vor dem Aus steht, weil der Konzern schlechte Zahlen schreibt. Durch einen glücklichen Zufall trifft der Fabrikleiter seinen ehemaligen Physikprofessor wieder, der ihn dadurch beeindruckt, dass er nicht nur ziemlich schnell durchschaut hat, wie schlecht es um die Fabrik eigentlich steht, sondern dem Fabrikleiter auch ein paar Denkanstöße mit auf den Weg gibt. Im Laufe der Geschichte arbeitet der Fabrikleiter immer enger mit dem Professor zusammen und lernt so die Grundzüge der Theory of Constraints kennen, die Sie später noch genauer ansehen werden (siehe Seite 57). So lernt er zum Beispiel, warum Überproduktion ein Problem darstellt und in welchen unterschiedlichen Erscheinungsformen sich Muda zeigt.2

Lean spielt seine Stärken in der Produktion aus. Hier sind sehr viele Dinge geradlinig und vorhersehbar. Zu den Zeiten, als das Toyota Produktionssystem erfunden wurde, befand man sich noch in der Taylorwanne. Und in vielen Produktionsbereichen, die standardisierte Produkte herstellen, besteht diese Taylorwanne auch noch heute. Da, wo wenig Variabilität gefordert ist, hat man es mit komplizierten Systemen zu tun, und dort funktioniert eine Lean Produktion sehr gut. Müsste man hingegen täglich sehr flexibel auf seinen Kunden neu eingehen, weil er etwas komplett anderes fordert, dann müsste man auch täglich seine Produktionsstraße anpassen. Zwar gibt es gewisse Kundenwünsche, die auch in der Produktion viele Produkte zu Unikaten machen, aber diese sind vorhersehbar und durch Techniken wie Just-in-Time (JIT) Produktion behandelbar.

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.

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.

Ein Blick in die agile Praxis: Kanban und ScrumScrum

Das Agile Manifest schreibt nicht vor, wie die Werte und Prinzipien in der Praxis umgesetzt werden sollen. Schon vor der Entstehung des Agilen Manifests gab es eine Reihe von Rahmenwerken (Frameworks), die es erleichtern sollten, entsprechend ähnlicher Prinzipien und Werte den Arbeitsalltag zu gestalten. Diese Rahmenwerke haben den Vorteil, dass sie den Anwendern ziemlich klare Leitplanken und Werkzeuge an die Hand geben, die dafür sorgen, dass sie den Prinzipien entsprechend handeln.

Die bekanntesten beiden Frameworks aus dem agilen Portfolio sind Kanban und Scrum. Von erfahreneren Anwendern werden auch gerne Kombinationen aus unterschiedlichen Rahmenwerken verwendet, wie zum Beispiel Scrum mit Elementen aus Kanban und dem Extreme Programming (xP).7

Um die Grundgedanken und das Zusammenspiel verschiedener Elemente besser zu verstehen, sehen wir uns im Folgenden einmal die beiden populärsten Frameworks genauer an.

Kanban

Am Beispiel von KanbanKanban können Sie sehr schön erkennen, dass die Evolution agiler Frameworks und Methoden nicht erst mit dem Agilen Manifest als Startschuss erfolgt ist. Schon beim Toyota-Produktionssystem fand eine erste Form von Kanban statt. Und blickt man weiter in der Geschichte zurück, kann man sogar noch frühere Wurzeln finden.

Das Wort Kanban stammt aus dem Japanischen und ist eine Zusammensetzung aus den beiden Worten „kan“, was so viel wie Signal bedeutet, und „ban“, was Karte heißt. Somit hieße Kanban wörtlich übersetzt Signalkarte. Laut einer Geschichte, die David Anderson, einer der modernen Vertreter des Kanban, erzählt (Anderson 2011), diente eine Signalkarte schon zu frühen Zeiten zur optimalen Auslastung eines Systems. Ein solches System stellte beispielsweise ein Garten dar, wo man mit Hilfe von Signalkarten sicherstellte, dass nur eine für den Garten passende Menge an Besuchern sich auch in diesem aufhielten. Die Torwächter ließen nur dann einen neuen Gast in den Garten, wenn ein anderer wieder hinausging und seine Signalkarte zurückgab.

Das moderne Kanban hat mit den historischen Ansätzen zwar noch einige Elemente gemein, ist aber stärker angelehnt an das, was wir schon aus dem Lean-Umfeld kennengelernt haben. An dieser Stelle beziehe ich mich daher auf die Regeln und Prinzipien, des modernen Ansatzes, wie ihn Anderson beschreibt und verschiedene andere Praktiker ergänzt und weiterentwickelt haben.

Kanban zeichnet sich dadurch aus, dass man nicht notwendigerweise einen neuen Arbeitsablauf oder neue Rollen einführen muss, um mit Kanban zu starten. Ein Team oder ein Unternehmen, das Kanban anwenden möchte, kann mit dem Arbeitsablauf und den Prozessen starten, die sie gerade praktizieren. Dies senkt die Hürde für den Einstieg.

Zum erfolgreichen Arbeiten mit Kanban gilt es dann, sechs Praktiken in seinen Arbeitsalltag zu integrieren.

1 Visualisierung des Arbeitsflusses: Die erste Praktik besteht darin, den Fluss der Arbeit zu visualisieren. Dies geschieht in aller Regel mit Hilfe eines sogenannten Kanban-Boards. Auf diesem Board kann man in verschiedenen Spalten die einzelnen Schritte der Wertschöpfungskette visualisieren. Einzelne Aufgaben werden auf Papierkarten geschrieben und von einer Spalte in die nächste gezogen, je nachdem in welchem Arbeitsschritt sie sich gerade befinden. Wie Sie sehen, muss hier erst einmal nichts angepasst werden, da lediglich die aktuelle Vorgehensweise abgebildet wird. Hierbei ist es wichtig, die richtige Granularität für die einzelnen Schritte im Wertstrom zu finden, so dass sich eine ausreichende Transparenz ergibt.Abb. 13:Ein exemplarisches Kanban-Board

2 Begrenzung der angefangenen Arbeit im System: Die Arbeit, die sich zu einem bestimmten Zeitpunkt im System befindet, wird als Work-in-Progress (WIP) bezeichnet. Pro Arbeitsschritt, der auf dem Board als Spalte repräsentiert ist, legt man nun eine maximale Menge von Aufgaben fest, die gleichzeitig ausgeführt werden dürfen. Dies macht man mit einer entsprechenden Zahl an der Spalte des Boards sichtbar. Auf diese Weise entsteht ein WIP-Limit, was dazu führt, dass wenn die maximale Anzahl der erlaubten Aufgaben in einer Spalte erreicht ist, keine neue Arbeit in diesem Schritt angefangen werden darf. Hier zeigt sich das daraus entstehende Pull-Prinzip (Ziehen der Aufgaben). Die Aufgaben werden nicht einfach nach Fertigstellung in den nächsten Arbeitsschritt gedrückt (Push), sondern werden nur dann in den nachfolgenden Schritt gezogen, wenn die Kapazität es zulässt. Auf diese Weise sollen Flaschenhälse (englisch: Bottlenecks) aufgespürt werden.

3 Messung und Steuerung des Flusses: Die nächste Praktik besteht darin, den Fluss zu messen und gezielt zu steuern. Dazu werden bestimmte Metriken erhoben, die es erlauben, Aussagen über die Leistungsfähigkeit des Gesamtsystems zu treffen.Eine dieser Größen ist die Cycle-Time. Darunter versteht man die Zeit, die gemessen wird von dem Moment an, wo die erste Arbeit an einer Anforderung durchgeführt wird, bis zum Abschluss dieser Aufgabe. In der Regel wird der Start der Arbeit durch einen Commitment-Punkt auf dem Kanban-Board bestimmt, der die Akzeptanz der Anforderung ausdrückt und eine Verpflichtung zur Umsetzung darstellt. Der Abschluss der Arbeit eines Teams wird durch einen Delivery-Punkt bestimmt, also dem letzten Arbeitsschritt, den ein Team selbst durchführt. Eventuell ist das noch nicht der finale Schritt, da noch andere Teams später im Prozess beteiligt sein könnten.MetrikBeschreibungMessungLead-TimeVorlaufzeit. Die Zeit, die eine Aufgabe von der Erstellung (Eintritt ins System) bis zur Erledigung (beispielsweise Lieferung an den Kunden) benötigt.Zeitpunkt der Fertigstellung – Zeitpunkt der AnforderungCycle-TimeZykluszeit. Die Zeit, die eine Aufgabe innerhalb eines bestimmten Arbeitsschrittes (oder eine Kombination von Arbeitsschritten) benötigt.Zeitpunkt der Fertigstellung des Arbeitsschritts – Zeitpunkt des Starts des ArbeitsschrittsDurchsatzAnzahl der Aufgaben pro Zeiteinheit (zum Beispiel abgeschlossene Aufgaben pro Tag)geschlossene Aufgaben pro Zeiteinheit (kann mit Lead- und Cycle-Time kombiniert werden)Work in Progress (WIP)Aufgaben in Bearbeitung.Anzahl der parallellaufenden Arbeiten in bestimmten Arbeitsschritten.Tab. 4:Wichtige Metriken in einem Kanban SystemEine weitere Metrik ist die sogenannte Lead-Time. Die Lead-Time misst die Zeit von dem Moment an, wenn die Anforderung im System erstellt wird bis zur Auslieferung. Die Lead-Time ist also das, was ein Kunde von außen sehen würde, von dem Moment, in dem er einen Wunsch geäußert hat, bis dass er ein Resultat zurückgeliefert bekommt.Auch der Durchsatz spielt eine wichtige Rolle. Der Durchsatz wird in der Regel errechnet als Quotient aus durchschnittlicher WIP und mittlere Cycle-Time (Little’s Law). Kennt man diese Kennzahlen, dann kann man im Folgenden anfangen Parameter zu variieren und so das Gesamtsystem zu optimieren.Wenn Sie sich die Metriken anschauen und den Zusammenhang mit dem Gesetz von Little vergegenwärtigen, dann lassen sich daraus einige interessante Schlussfolgerungen ziehen. In der Abbildung ist der Wertstrom als ein Kanal dargestellt. Sicher stimmen Sie zu, dass es ein sinnvolles Ziel ist, den Durchsatz zu erhöhen. Die mathematischen Zusammenhänge lassen nun zwei offensichtliche Optionen zu:Option eins besteht darin, einfach mehr Arbeit in den Kanal zu drücken. Damit würde bei gleichbleibender Durchlaufzeit der Durchsatz nach oben gehen. Sie werden aber zurecht sagen, dass das sicher keine gute Idee ist, da dies schnell zu Überlastung und in letzter Konsequenz zum Zusammenbruch führen wird.Die zweite Option besteht darin, die Durchlaufzeit zu reduzieren. In unserer Bild würde das erreicht, indem wir den Kanal verkürzen. Nun ist auch weniger Platz für Work in Progress. Die Reduzierung von Arbeit führt also automatisch zu kürzeren Durchlaufzeiten und somit zu einem höheren Durchsatz. Das ist der Grund, warum die WIP-Limits für Kanban so essenziell wichtig sind.Abb. 14:Littles GesetzLittles Gesetz

4 Explizite Regeln für den Prozess: Kanban macht den Prozess explizit. Normalerweise geschieht dies auf dem Kanban-Board selbst, so dass alle Beteiligten genau wissen, welche Regeln gelten und wo sie zu finden sind. Wichtig ist dabei, eine genaue Definition zu haben, wann eine Aufgabe fertig ist und in die nächste Spalte gezogen werden kann. Auch die Bedeutung der einzelnen Spalten sollte möglichst eindeutig und klar beschrieben sein. Zudem muss geklärt sein, wer etwas ziehen darf, wann etwas gezogen wird und in welcher Reihenfolge die nächsten verfügbaren Tickets gezogen werden. Und natürlich muss auch das WIP-Limit klar ersichtlich sein und von allen eingehalten werden.

5 Förderung von Leadership auf allen Ebenen: Wie Sie sich leicht vorstellen können, führen die bisher vorgestellten Praktiken dazu, dass Sie sehr schnell die Schwachstellen in den bisherigen Abläufen finden können, wie zum Beispiel Flaschenhälse. Um diese zu beheben kommt es auf das Engagement aller Beteiligten an. Nicht nur eine bestimmte Abteilung, sondern alle an der Wertschöpfung beteiligten Personen, egal in welcher Hierarchieebene, sind dazu aufgerufen, sich an der kontinuierlichen Verbesserung zu beteiligen. Zudem müssen auch alle Ebenen die vereinbarten Regeln einhalten (insbesondere das WIP-Limit).

6 Verwendung von Modellen zur Erkennung von Chancen für Verbesserungen: Zur kontinuierlichen Verbesserung soll auch die Praktik führen, Modelle zu verwenden, um Chancen für kollaborative Verbesserungen zu erkennen. Dabei stellen die Modelle vereinfachte Darstellungen des Prozesses dar. Hier gibt es eine ganze Reihe von bekannten Ansätzen, die oft Verwendung finden. So zum Beispiel der Deming-Cycle (PDCA, Plan-Do-Check-Act) oder die Theory-of-Constraints, die Goldratt vorstellte (Goldratt/Cox 2013).

Exkurs | EngpasstheorieEngpasstheorie (Theory of Constraints, TOC)

Die Engpasstheorie besagt, dass der Durchsatz eines Systems einzig durch seinen Engpass bestimmt ist. Sie wurde von Eliyahu GoldrattGoldratt, Eliyahu entwickelt und veröffentlicht.

Gemäß der Engpasstheorie existiert zu jedem Zeitpunkt genau ein Schritt in der Wertschöpfungskette, der einen Engpass darstellt und somit den Durchsatz begrenzt. Dieser Engpass ist oftmals das Glied in der Kette, welches die geringste Kapazität besitzt. Daher sollte das erste Bestreben sein, diesen Engpass zu finden und voll auszulasten. Dazu stellt man sicher, dass der Engpass zum einen möglichst wenig Leerlauf hat und zum anderen nur für die wichtigsten Aufgaben genutzt wird. Alles, was nicht unbedingt vom Engpass bearbeitet werden muss, sollte man auslagern. Fortan wird dann der Engpass den Takt für das Gesamtsystem vorgeben, also nur noch so viel Arbeit im System sein, wie die Kapazität des Engpasses zulässt. Alle Optimierungsversuche sollten sich dann auch auf den Engpass konzentrieren, da jede Optimierung an einer anderen Stelle nicht den Gesamtdurchsatz steigern würde und im Gegenteil nur zu Wartezeiten und Überproduktion führen würde. Folgt man diesen Empfehlungen und erhöht die Kapazität des Engpasses, dann wird man höchstwahrscheinlich in der Folge auf einen neuen Engpass stoßen, bei dem man genauso verfahren sollte.

Goldratt bietet als Beispiel für Prozesssteuerung das sogenannte Drum-Buffer-Rope-Verfahren an. Dabei verwendet er als Bild eine Gruppe von Pfadfindern, die hintereinander im Gänsemarsch laufen, und als Gruppe ein gemeinsames Etappenziel erreichen sollen. Somit stellt der Pfadfinder, der das langsamste Tempo geht, den Engpass im System dar. Unser langsamer Pfadfinder bekommt bildlich gesprochen eine Trommel in die Hand (Drum), und bestimmt auf diese Weise den Takt des Gesamtsystems. Es kann auch jederzeit zu Störungen vor dem Engpass kommen. In unserem Bild beispielsweise ein stolpernder Pfadfinder, der den langsamsten in der Kette dadurch aufhält. Das würde bedeuten, dass der Engpass nicht optimal ausgelastet werden kann, da er abbremsen oder sogar anhalten müsste. Also sollte ein vernünftiger Puffer vor dem Engpass eingerichtet werden, so dass kleinere Ausfälle (Stolpern) den Engpass nicht verlangsamen (Buffer). Zuletzt sollte nun durch das Tempo des Engpasses und die Größe des Puffers gesteuert neue Arbeit in das System gezogen werden. Im Beispiel unserer Pfadfindergruppe würde ein Seil zwischen dem vordersten Pfadfinder in der Gruppe und dem Engpass gezogen, das die Zwischenräume steuert, so dass ein bestimmter Puffer vorhanden ist.

Hält man die vorgeschlagenen Praktiken ein, dann stellt Kanban ein Werkzeug für die evolutionäre Veränderung in Unternehmen dar. Durch das Aufdecken von Engpässen im System und der Konzentration auf eine kontinuierliche Verbesserung wird nach und nach das Gesamtsystem immer leistungsfähiger.

Beim Einsatz von Kanban spielt das Einhalten von WIP-Limits eine sehr große Rolle. Gerade Teams, die noch unerfahren mit dieser Vorgehensweise sind, tendieren dazu, die Begrenzungen zu ignorieren. Dies kann zum einen daran liegen, dass sie noch nicht ganz verstanden haben, welch große Bedeutung die Limitierung der Arbeit für den evolutionären Veränderungsprozess in Kanban besitzt. Zum anderen ist es aber auch häufig so, dass viele traditionelle Unternehmen großen Wert darauflegen, alle zur Verfügung stehenden „Ressourcen“ optimal auszulasten. Daher fühlen sich die Mitglieder eines Arbeitsteams verpflichtet, lieber eine neue Aufgabe zu beginnen, anstatt untätig herumzusitzen. Wie die Engpasstheorie jedoch verdeutlicht, führt das dazu, dass sich die Arbeit vor dem Engpass auftürmt und somit mehr Probleme entstehen, als es Mehrwert bringt. Umso wichtiger ist es, die Arbeit entsprechend zu visualisieren. Denn es geht darum, die Arbeit zu managen und sich die Menschen darum herum selbst organisieren zu lassen. Wenn die Arbeit allerdings nicht sichtbar ist, dann könnte leicht die Tendenz entstehen, das zu managen, was die Manager sehen können: die Menschen.

Der Fokus sollte erst einmal darauf liegen, den Engpass zu entlasten und dafür zu sorgen, dass wieder Kapazitäten frei werden. Wenn hier keine Möglichkeit der Unterstützung besteht, dann kann man die entstandene Zeit für die Verbesserung des Prozesses und des Gesamtsystems zu nutzen, mit dem Ziel, den Engpass langfristig zu beheben. Diese freigewordene Zeit wird oftmals auch als Slack bezeichnet und spielt in so gut wie allen agilen Rahmenwerken eine wichtige Rolle. Slack ist wichtig und notwendig, um die Leistungsfähigkeit des Gesamtsystems kontinuierlich zu steigern.

Bisher haben wir gesehen, wie Kanban funktioniert, wenn ein Team eine Anforderung von der Aufnahme bis zur Umsetzung komplett bearbeitet. In der Praxis wird es aber in einem großen Unternehmen mehrere Teams geben, die in irgendeiner Form zusammenarbeiten müssen, um eine Aufgabe wirklich abzuschließen. Hier ergeben sich schnell Abhängigkeiten und es ist zum einen oft unübersichtlich, zum anderen kaum möglich, ein einziges Kanban-Board zu haben, das alle Arbeitsschritte in der gewünschten Granularität visualisieren kann. Viele einzelne Kanban-Teams machen daher noch nicht automatisch ein agiles Unternehmen aus. Ein anschauliches Beispiel, wie man zu echter „Business-Agilität“ gelangt liefert Klaus Leopold, der zur Orientierung verschiedene Flight-Level (Flughöhen) vorschlägt (Leopold/Kaltenecker 2018).

Auf dem obersten Flight-Level schaut man auf die Wertschöpfungsketten, die in einem Unternehmen vorhanden sind. Die meisten Unternehmen haben mehr als ein Produkt oder teilen ihre Arbeit in unterschiedliche Projekte auf. Diese stellen sehr häufig auch eigene Wertschöpfungsketten mit gewissen Besonderheiten dar. Auf der oberen Ebene interessiert man sich genau für diese unterschiedlichen Initiativen und nutzt die Kanban-Praktiken, um auf dieser Granularität den Gesamtwert für das Unternehmen zu optimieren.

Das Flight-Level darunter konzentriert sich auf eine dieser Wertschöpfungsketten und stellt die Arbeitsschritte und die Aufgaben in einer Granularität dar, die eine Koordination der verschiedenen beteiligten Teams ermöglicht. Es ist die Ebene der Koordination.

Geht man noch ein Level tiefer, so ist man auf der Team-Ebene, wo die Arbeit, die von einem Team erledigt wird, visualisiert und optimiert wird. Wenn hier Arbeiten abgeschlossen werden, wird diese Aktualisierung auf das darüberliegende Level übertragen. Würde man Kanban nur auf das Teamlevel beschränken, dann würde es eventuell zu lokalen Optimierungen kommen, die – wie wir gesehen haben – das Gesamtsystem eventuell sogar verschlechtern. Durch die unterschiedlichen Flughöhen hat man aber auf unterschiedlichen Ebenen die Engpässe und auch mögliche Verbesserungen im Blick, so dass man die gesamte Wertschöpfungskette und auch das gesamte Unternehmen verbessern kann.

Im Zusammenhang mit Kanban fällt oft der Begriff Kaizen, was sich aus den japanischen Begriffen kai (Wandel) und zen (zum Besseren) ableitet. Kaizen beschreibt den kontinuierlichen Verbesserungsprozess, der sich bei Einhaltung der Kanban-Praktiken von allein einstellen sollte. Darüber hinaus gibt es aber eine Reihe von Praktiken, die von den meisten Teams geteilt werden, auch wenn es keine Regeln gibt, die sie vorschreiben. So zum Beispiel regelmäßige Statusmeetings, Reviews oder auch Retrospektiven.

Eine weitere, gern genutzte Praktik bei der Verwendung von Kanban, ist die Einführung von Service Level Agreements (SLA). Die Aufgaben werden dann bestimmten Klassen zugeordnet. So ist es möglich, bestimmte Aufgaben einem Service Level zuzuweisen, der bevorzugt behandelt wird. Sobald dann an einer Station Kapazitäten frei werden, wird eine solche Aufgabe als erstes bearbeitet. Dies führt auch zu unterschiedlichen Cycle- und Lead-Times für die verschiedenen Service Level, die auch zum Kunden kommuniziert werden können.

Scrum

„Mit 85 % ist ScrumScrum die meistgenutzte agile Methode. Danach folgen Kanban, Lean und DevOps.“ Zu diesem Schluss kommt die Studie Status Quo Agile,1 die von der Hochschule Koblenz 2016/17 durchgeführt wurde.2 Scrum erfreut sich damit viele Jahre nach seiner ersten Erwähnung im „New new product development game“ sehr großer Beliebtheit.

Eine tragende Rolle bei der systematischen Umsetzung der von Takeuchi und Nonaka beschriebenen Praktiken nahmen Ken Schwaber und Jeff Sutherland ein. Jeff Sutherland griff die beschriebene Idee auf und nutzte die Erkenntnisse in ersten Projekten. Ken Schwaber veröffentlichte bereits 1995 auf der OOPSLA-Konferenz einen ersten Beitrag über Scrum. Beide Pioniere gehörten auch zu den Unterzeichnern des Agilen Manifests im Jahr 2001. Im gleichen Jahr veröffentliche Ken Schwaber auch das erste Buch zum Thema Scrum, gemeinsam mit Mike Beedle (Schwaber/Beedle 2002).

Schwaber und Sutherland taten sich zusammen und gestalteten gemeinsam den Scrumguide,Scrumguide der die Spielregeln von Scrum definiert, auf die sich alle Anwender des Frameworks berufen.3 Der Scrumguide wurde in viele Sprachen übersetzt und wird regelmäßig aktualisiert. Auch wenn Scrum sehr populär in der IT ist, wird im Scrumguide explizit darauf hingewiesen, dass Scrum in allen erdenklichen Bereichen verwendet werden kann. Von einer großen Liste strahlender Beispiele berichtet Jeff Sutherland in seinem Buch „Die Scrum Revolution“ (Sutherland 2015). Der Scrumguide beschreibt drei wichtige Rollen, die zur Ausführung von Scrum benötigt werden.

Der Product Owner (Eigentümer des Produkts) hat die Verantwortung für das Produkt. Dafür muss er sicherstellen, dass die Aufgaben erledigt werden, die am meisten Wert generieren. Dies gelingt ihm, indem er alle Arbeiten, die zu erledigen sind, um das Produkt herzustellen, in das Product Backlog einträgt und dort in eine eindeutige Reihenfolge bringt.

In der Regel gibt es eine Reihe von Leuten, die ein Interesse an dem Produkt haben. Dies können zum einen (potenzielle) Kunden sein, zum anderen aber die eigene Unternehmensführung oder auch andere Abteilungen im eigenen Unternehmen. Die Aufgabe des Product Owners besteht nun darin, die Interessen dieser Stakeholder einzusammeln und gegeneinander zu gewichten. Dafür muss er in engem Kontakt mit den Stakeholdern stehen.

Im Gegensatz zum Wasserfallmodell, wo das Produktmanagement und die Entwicklung zwei getrennte Abteilungen bilden, ist der Product Owner Teil eines Scrum Teams und daher auch mitverantwortlich für die gelungene Umsetzung der Anforderungen. Der Product Owner ist dafür verantwortlich, was getan wird. In Scrum ist es wichtig, dass es genau einen Product Owner für ein Produkt gibt. Dies soll verhindern, dass sich zum Beispiel ein Komitee nicht einigen kann und somit Entscheidungen sehr träge getroffen werden können. Zwar können verschiedene Personen sich die Aufgaben des PO aufteilen, am Ende muss es aber genau eine Person geben, deren Entscheidung im Zweifelsfall von allen akzeptiert wird.

Das Entwicklungsteam besteht aus den Experten, die das Produkt herstellen. Das Team zeichnet sich durch seine interdisziplinäre Aufstellung aus. Im Scrum-Umfeld wird diese Eigenschaft als „Crossfunktionalität“ (X-funktional abgekürzt) bezeichnet. Es sind Experten aus den unterschiedlichsten Bereichen der Wertschöpfungskette in einem Team vorzufinden, die dann gemeinsam als Team eine Gesamtverantwortung für ein Produkt oder eines Produktbestandteils übernehmen. Dabei bemüht man sich um die Ausprägung eines T-Profils bei den Teammitgliedern (siehe Exkurs).

Exkurs | T-ProfilT-Profil

In klassischen Arbeitsgruppen, die aus Experten der gleichen Fachrichtung bestehen, hat man es in aller Regel mit Spezialisten zu tun. Diese haben eine tiefgehende Expertise in einem bestimmten Fachgebiet. Damit ihre Expertise möglichst effizient genutzt werden kann, ist ihr Arbeitsumfeld so gestaltet, dass sie sich ausschließlich auf diesen Fachbereich konzentrieren können. Auch Mitarbeiterentwicklung findet in diese Spezialrichtung statt. Dies wird oft als I-Profil bezeichnet, weil es eine einzelne, sehr spezialisierte Fähigkeit repräsentiert.

Demgegenüber strebt man in interdisziplinären Teams das sogenannte T-Profil (T-Shape) an. Dies bedeutet, dass das Teammitglied immer noch ein Experte in einem bestimmten Fachgebiet ist, was den Stängel des T repräsentiert. Gleichzeitig bemüht sich das Teammitglied aber auch, Aufgaben aus angrenzenden Fachgebieten zu lernen und bei Bedarf zu übernehmen. Wenn man ein wenig rechts und links seiner eigenen Spezialfähigkeit schaut, dann ergibt sich so der Querbalken des T-Profils.

Erinnern wir uns zurück an die Engpasstheorie, dann sehen wir, dass dieses angestrebte T-Profil kein Selbstzweck ist, sondern sehr wichtig, um die Leistungsfähigkeit eines Teams zu erhöhen. Ein Teammitglied mit I-Profil könnte, wenn ein Engpass gefunden wird, der in einem angrenzenden Arbeitsschritt liegt, nicht unterstützen, da ihm entsprechende Fähigkeiten fehlen. In klassischen Organisationen, die auf Effizienz und Auslastung optimiert sind, würde ein solches Teammitglied sich weiter mit den eigenen Aufgaben beschäftigen. Dies wäre aber eine lokale Optimierung, die dazu führen würde, dass sich vor dem Engpass ein Berg von Arbeit anhäuft. Besitzt das Teammitglied aber ein T-Profil, kann es den Engpass entlasten und somit zur Gesamtleistung des Teams beitragen, selbst wenn einzelne Glieder der Wertschöpfungskette nicht optimal ausgelastet sind.

Oftmals wird das T-Profil so missverstanden, dass jeder im Team in der Lage sein sollte, jede Aufgabe zu übernehmen, die anfallen könnte. Wie Sie oben gesehen haben, ist dies nicht das Ziel (und auch sehr utopisch). Das T-Profil soll vielmehr sicherstellen, dass eventuelle Engpässe entlastet werden können und im Falle des Ausfalls eines oder mehrerer Teammitglieder die Arbeit nicht komplett eingestellt werden muss, nur weil der eine „wissende“ Fachexperte nicht greifbar ist.

Das Entwicklungsteam organisiert sich selbst, so wie es meint, die gesetzten Ziele erreichen zu können. Das Team trägt die Verantwortung, wie etwas getan wird.

In Scrum gibt es keine speziellen Rollen innerhalb des Teams. Es gibt also keine weitere Unterteilung zwischen Entwicklern, Testern, Analysten, Ingenieuren, Layoutern oder welche Spezialgebiete auch immer zur Erstellung eines Produkts benötigt werden. Dadurch soll zum einen die Entwicklung in Richtung T-Profil unterstützt werden, zum anderen aber auch ein Gefühl für die gemeinsam getragene Verantwortung für das Ergebnis gestärkt werden.

Als dritte und letzte Rolle beschreibt der Scrumguide den Scrum MasterScrum Master. Für die meisten Unternehmen, die Scrum einführen, ist diese Rolle ein absolutes Novum, denn in den allerseltensten Fällen gab es zuvor eine Rolle, die eine vergleichbare Aufgabe hatte. Auf der einen Seite soll der Scrum Master das Scrum Rahmenwerk fördern und unterstützen. Er hilft also dem Team zu verstehen, wie genau Scrum funktioniert, und wie ein Rädchen in das andere greift. Zudem besteht sein Hauptfokus aber darauf, die Zusammenarbeit des Teams zu optimieren.

Der Scrum Master hat dafür drei große Fokuspunkte, auf die er sich konzentriert. Zum einen unterstützt er den Product Owner. Er hilft ihm, die Anforderungen zu priorisieren und mit dem Entwicklungsteam in kleine, zu bearbeitende Aufgaben zu zerlegen. Zudem hilft er dem PO, sich in der agilen Produktplanung zurechtzufinden.

Als Zweites richtet der Scrum Master seine Aufmerksamkeit auf das Entwicklungsteam. Hier liegt sein Fokus darauf, das Team zu einer Selbstorganisation zu befähigen und die Zusammenarbeit zu verbessern. Dafür muss der Scrum Master ganz auf seine Überzeugungskraft und seine Coaching-Fähigkeiten zurückgreifen, denn in Scrum ist niemand vorgesehen, auch nicht PO oder Scrum Master, der in irgendeiner Form weisungsbefugt wäre.

Und zuletzt ist die Rolle des Scrum Masters auch dazu gedacht, in die Organisation hineinzuwirken. Wenn man mit Scrum beginnt, wird man schnell feststellen, dass gewisse Hindernisse, die eine selbstorganisierte Arbeit verhindern, nicht nur innerhalb der Teamgrenzen zu finden sind. Viele Probleme und Herausforderungen sind teamübergreifend und zum Beispiel in vorhandenen Strukturen oder Prozessen begründet. Es ist unvermeidlich, dass ein Unternehmen, das sich agil aufstellen möchte und dafür Scrum einführt, sich auch organisatorisch deutlich verändern muss.

Exkurs | Rollen und Positionen

Scrum definiert drei Rollen. In vielen klassischen Organisationen besteht eine sehr starke Fokussierung auf Positionen. Auch wenn beide Begriffe oft synonym verwendet werden, besteht hier ein deutlicher Unterschied. Eine Position ist untrennbar mit einer Person verknüpft. Frau Maier oder Herr Müller haben eine Position inne. An diese Position wiederum sind gewisse Rechte und Pflichten geknüpft. Ein Projektleiter trägt die Verantwortung für ein bestimmtes Projekt und hat vielleicht ein Budget zur Verfügung und dann auch eine Weisungsbefugnis für die Projektbeteiligten. Positionen sind in der Regel ein Kästchen in einem Organigramm, in dem ein bestimmter Name steht.

Rollen hingegen definieren erst einmal nur Verantwortlichkeiten, sind aber nicht personenbezogen. Das heißt, die in einer Rolle definierten Verantwortlichkeiten müssen erfüllt werden, aber es ist nicht unbedingt festgelegt, welche Person dies tut. Somit kann eine Rolle auch durch mehr als eine Person ausgefüllt werden, indem man beispielsweise die Verantwortlichkeiten aufteilt.

In sehr vielen Unternehmen wird eine Rolle an eine Position geknüpft. In manchen Fällen ist der Product Owner, der in Scrum als Rolle definiert ist, eine feste Position mit einer zugeordneten Person. Andernorts sind an die Position (das Kästchen im Organigramm) noch zusätzliche (nicht im Scrumguide definierte) Aufgaben, Rechte oder Pflichten geknüpft. Hier findet schnell eine Vermischung von Rolle und Position statt, die am Ende zu einem falschen Verständnis von den eigentlichen Rollen führen kann.

Neben diesen Rollen gibt Scrum auch ziemlich genau vor, welche Bestandteile es gibt und zu welchen Anlässen und wann die Teams zusammenkommen (Scrum Artefakte und Events).

Das Product BacklogProduct Backlog haben Sie ja schon kennengelernt. Es handelt sich dabei um eine Liste, die alle Arbeit enthält, die vom Team zu erledigen ist, um ein Produkt herzustellen. Diese Liste ist geordnet und die wichtigste Aufgabe befindet sich an der Spitze dieser Liste. Der Product Owner ist dafür verantwortlich, das Product Backlog aktuell zu halten und die Reihenfolge der Arbeit festzulegen. Die einzelnen Bestandteile des Backlogs nennt man Product Backlog Items. Diese werden oftmals in Form einer User Story (also aus der Sicht des Benutzers) geschrieben. Product Backlog Item ist alles, was eine Änderung am bestehenden Produkt darstellt, also zum Beispiel neue Anforderungen, Fehlerbehebungen oder die Beseitigung technischer Schulden.

Die Abarbeitung der Product Backlog Items erfolgt in Iterationen, sogenannten SprintsSprint. Ein Sprint ist per Definition maximal vier Wochen lang. Da die Vorausplanung mit zunehmender Länge der Iteration immer ungenauer wird, legt der Scrumguide hier diese Obergrenze fest. Für die meisten Teams hat sich eine Sprintdauer von zwei Wochen in der Praxis als guter Startwert herausgestellt. Es gibt aber auch Scrum Teams, deren Sprints nur einen Tag dauern, oder die sogar mehrere Sprints an ein und demselben Tag durchführen.

In einem gemeinsam Scrum Event (so nennt man bei Scrum die gemeinsamen Termine in Abgrenzung zu den gemeinhin oftmals als unproduktiv angesehenen „Meetings“), dem sogenannten Sprint PlanningSprint Planning, setzt sich das gesamte Scrum Team (Product Owner, Scrum MasterScrum Master und Entwicklungsteam) zusammen und überlegt, was es im nächsten Sprint voraussichtlich liefern kann. Dafür wird erst einmal ein Sprintziel festgelegt und dann Aufgaben aus dem Product Backlog ausgewählt, die zur Erreichung des Ziels notwendig sind.

Diese Aufgaben werden dann in das Sprint BacklogSprint Backlog übertragen. Dieses stellt somit eine Teilmenge des Product Backlogs dar und wird jeden Sprint neu angelegt. Die Aufgaben im Sprint Backlog werden so verfeinert, dass das Team jederzeit überprüfen kann, wie sein Fortschritt in Hinblick auf die Erreichung des Sprintziels ist. Es werden nur so viele Aufgaben in das Sprint Backlog übernommen, wie das Team meint, im nächsten Sprint fertigstellen zu können.

Im Laufe des Sprints erstellt das Entwicklungsteam ein Inkrement. Ein Inkrement besteht aus dem Ergebnis des aktuellen Sprints sowie den Ergebnissen aller vorheriger Sprints. Ein Produkt Inkrement wird also von Sprint zu Sprint immer größer und umfangreicher.

Damit die Arbeit selbstorganisiert stattfindet und möglichst gut abgestimmt wird, trifft sich das Entwicklungsteam täglich zur selben Zeit am gleichen Ort für ein Planungs- und Abstimmungsmeeting, dem Daily Scrum. Das Daily Scrum findet in aller Regel im Stehen statt (daher auch der alternative Name Daily-Stand-Up). Dies soll dazu dienen, dass die Teilnehmer sich kurzfassen und schnell zum Wesentlichen kommen. Alle Scrum Events haben eine Timebox (Zeitrahmen), also eine maximale Dauer, die nicht überschritten werden darf. Das Daily Scrum soll maximal 15 Minuten dauern und ist somit das kürzeste Scrum Event. Hervorzuheben ist, dass das Daily Scrum nicht dazu gedacht ist, den aktuellen Status zu berichten. Das Team soll sich gezielt abstimmen, wo man im Hinblick auf das Sprint Ziel steht, was noch zu tun ist, was in den nächsten 24 Stunden (bis zum nächsten Daily Scrum) erledigt werden kann und wie man sich am sinnvollsten aufteilt. Zudem sollen Hindernisse (Impediments) sichtbar gemacht werden, die die Arbeit behindern oder sogar verhindern.

Damit eine Aufgabe vom Team als erledigt gekennzeichnet werden kann, muss sie der Definition von Fertig (Definition of Done) entsprechen. Diese Definition stellt eine Checkliste dar, die alles enthält, was erfüllt sein muss, damit eine Aufgabe fertiggestellt ist. Diese wird häufig von dem Unternehmen vorgegeben, damit alle Scrum Teams nach den gleichen Qualitätsstandards arbeiten. Wenn auch nur eine geringe Kleinigkeit fehlt, darf eine Aufgabe nicht als fertig deklariert werden.

Am Ende des Sprints präsentiert das Scrum Team allen Interessierten das fertige Inkrement (also alle Aufgaben, die gemäß der Definition von fertig abgeschlossen wurden). Dies geschieht im sogenannten Sprint Review, das eine öffentliche Veranstaltung ist und zu dem der Product Owner alle interessierten Stakeholder einlädt. Gemäß dem Leitsatz von Scrum – Inspect & Adapt (Feedback einholen und Anpassen) – wird hier das Produkt Inkrement gezeigt und Feedback eingesammelt. Auch das Review ist somit kein einfaches Statusmeeting, um einen Fortschritt zu präsentieren, sondern eine wichtige Gelegenheit, um Feedback einzuholen und strategische Entscheidungen zu treffen. Neue Erkenntnisse hält der Product Owner im Backlog fest, mit dem er dann in das nächste Sprint Planning gehen kann.

Im Anschluss erfolgt dann ein weiterer Schritt, der dazu dient, Feedback einzuholen und eventuelle Anpassungen vorzunehmen: die Sprint Retrospektive. Hier kommt das Scrum Team zusammen und reflektiert gemeinsam den Entwicklungsprozess mit dem Ziel, Verbesserungsmaßnahmen zu definieren, die im Laufe des nächsten Sprints angewendet und in der folgenden Retrospektive auf ihre Wirksamkeit hin untersucht werden können. Diese werden dann auch gleich in das Sprint Backlog des nächsten Sprints eingetragen, damit das Team bei der Planung diese Aufwände mitberücksichtigen kann.

Prinzipiell geht der Zyklus an dieser Stelle wieder von vorne los, allerdings zeigt die Erfahrung, dass das Team auch eine gewisse Zeit in die Pflege und die Verfeinerung des Product Backlogs investieren muss. Diese Aktivität wird als Refinement bezeichnet. Der Scrumguide macht hier, im Gegensatz zu den klar definierten Scrum Events, keine klaren Vorgaben, wie das Refinement abzulaufen hat. Aber er gibt eine Empfehlung, die darin besteht, dass das Team bis zu 10 % seiner Zeit im Sprint für Refinement aufwenden sollte. Das Ergebnis – ein gepflegtes und feingranulares Product Backlog – wird dann als Eingabe für das nächste Sprintplanning genutzt.

Auch in Scrum gibt es Metriken, die helfen sollen, den Prozess kontinuierlich zu verbessern. Allerdings schreibt Scrum hier nichts vor. Viele Praktiker messen zum Beispiel gerne die Menge der Arbeit, die das Entwicklungsteam in einem Sprint erledigt hat. Dies wird dann als Velocity bezeichnet. Dafür muss die Größe der Aufgaben berücksichtigt werden, so dass man entweder alle Aufgaben in die gleiche Größe bringt oder aber die Größe schätzen und in Relation zueinander setzen muss. Hierfür werden meist Story Points verwendet. Dementsprechend wird auch die Velocity eines Teams in der Regel in Story Points pro Sprint angegeben.

Scrum und Kanban erheben beide nicht den Anspruch perfekt zu sein und die Antwort auf alle Fragen zu liefern. Im Gegenteil, sie ermutigen die Anwender dazu, Anpassungen vorzunehmen, um die Vorgehensweisen zu verbessern. Dies ist sicherlich eine gute Idee, denn die Erfinder konnten nicht jeden erdenklichen Kontext in ihre Überlegungen einbeziehen.

Shu-Ha-Ri und Cargo-Kult

Ich erinnere mich noch recht gut an einen Lieblingsfilm meiner Kindheit. Ein schmächtiger, schwarzhaariger Junge steht vor einem Auto. Ihm gegenüber steht ein kleiner Japaner mit einem Schwamm in der Hand. „Auftragen rechte Hand, polieren linke Hand“, leitet der kleine Japaner ihn an. Dabei solle er das Atmen nicht vergessen, ergänzt der wunderliche alte Mann, dann macht er die Bewegung noch einmal vor. Er übergibt dem sparsam dreinschauenden Jungen den Schwamm und überlässt ihn dann seiner Aufgabe. Der Junge ist verdutzt, will er doch eigentlich Karate lernen und sein Lehrer, Mr. Miyagi, lässt ihn nun mit einer Aufgabe stehen, deren Sinn er nicht versteht. Diese Szene aus dem Film „Karate Kid“ ist ein schönes Beispiel für ein Prinzip namens Shu-Ha-RiShu-Ha-Ri. Dieses Konzept aus der Kunst des fernöstlichen Kampfsports ist auch bei der Einführung und Umsetzung von Arbeitsweisen und Methoden hilfreich.

Die erste Stufe ist Shu, was so viel heißt wie „erhalten“ oder „gehorchen“. In dieser Phase sollte das, was der Lehrmeister sagt, minutiös befolgt werden, auch wenn der Sinn sich noch nicht so ganz erschließt. Bei den meisten Dingen, die wir neu lernen, verstehen wir manche Zusammenhänge erst, wenn wir sie mechanisch angewendet haben. So wie Daniel Larusso, der etwas verwundert ist, aber seinem Lehrmeister vertraut und seine Aufgaben erfüllt. Damit trainiert er Bewegungsabläufe ein, und wird immer sicherer bei deren Ausführung.

Abb. 15:

Shu-Ha-Ri in Kanji geschrieben

Wenn die Regeln befolgt wurden und wirklich verinnerlicht sind, dann folgt die zweite Stufe. Ha heißt in etwa „frei werden“ oder „abweichen“. Hier werden die Abläufe angepasst auf die jeweilige Situation. Es wird experimentiert und neues ausprobiert. Nur, wenn vorher die Regeln ganz genau befolgt wurden und verstanden wurden, ist das Verständnis da, warum manche Abweichungen funktionieren und manche eher nicht. Im Film ist Daniel schließlich in der Lage, die gelernten Bewegungsabläufe auch in einem Karate-Umfeld anzuwenden. Hier erscheint er erst noch überrascht, dass die Bewegungen fast von allein fließen. Da er aber aus den grundlegenden Übungen weiß, was ein positives Resultat und was ein negatives Resultat ist, kann er auch einschätzen, ob die kleinen Abwandlungen, die er vornimmt, hilfreich oder eher hinderlich sind.

Die dritte und höchste Stufe ist schließlich Ri. Übersetzt steht dies für „trennen“ oder „abschneiden“. Dies ist die Stufe der Meisterschaft. Die Prinzipien hinter den Regeln sind in Fleisch und Blut übergegangen und das Variieren, Anpassen und Entwickeln neuer Regeln stellt für den Meister keine Hürde mehr dar. Mister Miyagi ist in der Lage, die Elemente des Karate ganz einfach in Übungen zu übersetzen, die er seinem Schüler Daniel aufgibt. Als Meister ist er in der Lage einzuschätzen, dass auch das Polieren des Autos Daniel helfen wird, ein besserer Karatekämpfer zu werden. Er hat seinen eigenen Stil entwickelt, der seiner Persönlichkeit und seiner Individualität entspricht. Den Weg dorthin muss Daniel erst noch gehen, aber vielleicht wird er eines Tages auch selbst ein Meister sein. Dann wird er sich wahrscheinlich losgelöst haben von der Technik des Mister Miyagi und seinen ehemaligen Meister vielleicht sogar überflügeln. Dies ist ihm aber nur möglich, wenn er die vorherigen Stufen erfolgreich gemeistert hat.

Die beiden Autoren des Scrumguides Ken SchwaberSchwaber, Ken und Jeff SutherlandSutherland, Jeff haben schon in den ersten Sätzen darauf hingewiesen, dass Scrum ein einfach zu verstehendes, aber schwierig zu meisterndes Rahmenwerk darstellt. Befolgt man die Regeln, die im Scrumguide festgelegt sind, so stehen die Chancen gut, dass Scrum funktioniert. Erst wenn die Elemente verstanden wurden, macht die Anpassung Sinn. Oftmals tendieren unerfahrene Anwender dazu, die Regeln aufzuweichen, wenn sie „weh tun“. Zum Beispiel, wenn Aufgaben innerhalb eines Sprints nicht fertiggestellt werden können oder wenn jeder im Team ein Spezialgebiet hat, für das er allein verantwortlich ist. Gleiche Gefahr gilt bei Kanban, wo sehr schnell das WIP-Limit bei unerfahrenen Anwendern in Frage gestellt und aufgeweicht wird.

Begibt man sich einmal in die – sehr aktive – agile Community, die in so gut wie jeder größeren deutschen Stadt vertreten ist, und hört man den Teilnehmern an den Diskussionen aufmerksam zu, so wird man viel Frustration bemerken. Vieles rührt von einer nicht sachgemäßen Anwendung der Frameworks her. Dann wird gerne vom sogenannten Cargo-Cult gesprochen.

Ursprünglich war der Cargo-Kult eine Bewegung aus dem Bereich der Fidschi-Inseln und Neuguinea. Hier trafen im zweiten Weltkrieg die Inseleinwohner, die zuvor sehr abgeschieden lebten, auf die US-Armee, die die Inseln als Basis nutzten. Sie errichteten provisorische Flughäfen und Landebahnen und warfen auch Lebensmittel und westliche Kleidung über der Insel ab. Die Einwohner beobachteten die merkwürdigen Fremden und sahen, dass sie auf komische Türme stiegen und so etwas wie Schalen auf den Ohren hatten. Sie winkten mit Stäben und ab und zu fielen von den Göttern gesandte Pakete vom Himmel oder große, stählerne Wesen kamen aus der Luft und aus ihren Mäulern kamen mehr Menschen und Lebensmittel.

Als die Amerikaner irgendwann die Insel verließen, wollten die Einwohner nicht auf den Reichtum aus der Luft verzichten. Um die Götter zur Rückkehr zu bewegen, bauten die Einwohner die Einrichtungen der Amerikaner nach, setzten sich Kopfhörern nachempfundene Konstruktionen auf den Kopf und winkten mit Stäben in den Himmel. Aber kein Paket segelte auf die Insel hinab und kein großes Wesen landete mehr auf den Inseln. Die Einwohner konnten das nicht verstehen, sie taten doch alles genauso, wie die merkwürdigen Fremden es zuvor auch getan hatten.

Der große Unterschied bestand darin, dass sie nicht verstanden, warum es funktionierte, wenn die Amerikaner in den Himmel winkten. Gleiches Risiko besteht auch bei der Anwendung von Methoden, deren Wirkweise man (noch) nicht durchschaut hat.

Häufig liegt die Ursache darin, dass unterschätzt wird, dass die Verwendung agiler Methoden auch Veränderung auf allen Ebenen mit sich bringt. Folglich werden dann zu Beginn nur auf Teamebene Methoden etabliert, die schnell auf organisatorische Grenzen stoßen. Werden diese Grenzen nicht durchbrochen, dann führt dies zu Frust und Resignation. Nicht selten endet das dann darin, dass die agilen Methoden wieder abgeschafft werden. Dies ist aber auf Dauer keine Lösung, weil die VUCA-Welt nach Agilität verlangt. Die Bereitschaft zur Veränderung und die Fähigkeit zu verändern, stellt eine wichtige Kompetenz dar.

➤ Tipps für VUCA-Helden

Agilität stellt eine wichtige Kompetenz des 21. Jahrhunderts dar. Die Anforderungen, die von der Umwelt an uns als Individuum, aber auch an Unternehmen und an die Gesellschaft gestellt werden, erfordern die Fähigkeit, mit Komplexität umzugehen und anpassungsfähig und innovativ zu sein.

1 Verstehen Sie die Ursprünge und Hintergründe von agilen Ansätzen.

Machen Sie sich bewusst, dass Agilität immer schon hilfreich war. Lernen Sie aus der Geschichte und beschäftigen Sie sich mit den ersten Ansätzen und den Kontexten, in denen diese entstanden sind.

Machen Sie sich auch klar, dass hier Entweder-Oder-Denken nicht hilfreich ist. Auch in einem (oftmals als sehr unagil bezeichnetem) Wasserfallmodell können agile Elemente untergebracht werden.

 Wo sehen Sie in Ihrem Umfeld Denkweisen, die Sie als „agil“ bezeichnen würden?

 Was ist Ihre eigene Definition von agil? Was wäre „unagil“?

 In welchem Kontext wurde eine gewisse Methode erstmals angewendet und warum hat sie dort geholfen?

1 Seien Sie kein Dogmatiker.

Der Grundsatz aller agilen Arbeitsweisen lautet „Inspect & Adapt“, also Feedback gewinnen und daraus Anpassungen ableiten. Schauen Sie sich Vorgehensweisen, Prozesse und Produkte kritisch an und nehmen Sie Anpassungen vor. Es mutet merkwürdig an, wenn Frameworks und „agile Gesinnungen“ dogmatisch vertreten werden. Eine Praktik oder Methodik sollte immer zum jeweiligen Kontext passen.

 Warum sind Sie der Meinung, dass eine bestimmte Praktik, Methode oder Verhaltensweise genutzt werden sollte? Haben Sie eine zum Kontext passende Erklärung?

 Haben Sie die Leitplanken und Regeln durchschaut, so dass Sie sich auf die dahinterliegenden Prinzipien und Werte beziehen können?

 Passen die Werte und Prinzipien zu Ihren eigenen Werten (den Werten Ihres Unternehmens, Ihres Auftraggebers, Ihres Kunden, …)?

1 Nutzen Sie die Erfahrung von „Meistern“ bei der Einführung von neuen Methoden und Frameworks.

Gerade bei der Einführung von Frameworks, die das Potenzial haben, ganze Unternehmensstrukturen und Führungsparadigmen zu hinterfragen und die Kultur zu verändern, sollten Sie sicherstellen, dass Sie Menschen mit Erfahrung in diesem Bereich an Bord haben. Erinnern Sie sich an Shu-Ha-Ri. Wenn Sie selbst in Ihrem Umfeld niemanden haben, der mindestens auf dem Ha-Level ist, dann suchen Sie sich Unterstützung.

Nicht wenige agile Transformationen scheitern daran, dass sie halbherzig oder mit guten Absichten (aber schlechter Umsetzung) durchgeführt werden. Die Resultate sind dann häufig zerstörtes Vertrauen beim Management, frustrierte Mitarbeiter, Rückkehr zu alten Prozessen und Arbeitsweisen und Verlust von Mitarbeitern, die einen Einblick in eine neue Arbeitswelt bekommen haben, die sie fortan woanders suchen.

 Suchen Sie sich erfahrene Coaches, Berater oder Unterstützer, die bei der Einführung von agilen Frameworks unterstützen. Wer kann Ihr „Mister Miyagi“ sein?

 Bauen Sie eigene Kenntnisse auf und vernetzen Sie sich, so dass Sie selbst zukünftig in der Lage sind, Anpassungen vorzunehmen (Ha-Level).

 Haben Sie die Wirkweise wirklich verstanden?