Als vor nunmehr über 20 Jahren das Manifest für agile Softwareentwicklung veröffentlicht wurde, konnte wahrscheinlich niemand ahnen, welchen gewaltigen Einfluss diese neuen Ideen auf die Arbeitswelt – primär in der Tech-Branche – haben werden. Scrum hat sich über die Jahre als de facto Standardprozess für agile Softwareentwicklung etabliert und damit die klassische Wasserfallplanung fast vollständig verdrängt. Die Entwicklungsteams sind selbstorganisiert, die Product Owner genießen Flexibilität sowie kurze Feedback-Zyklen und die Scrum Master kümmern sich um alle Belange der Teams. Inspect & Adapt wird gelebt und das Prinzip der kontinuierlichen Verbesserungen ist fest im Arbeitsalltag etabliert. Die Arbeit macht Spaß, die erzielten Resultate sprechen für sich und die schöne neue agile Arbeitswelt ist geboren.
Dass Scrum die klassische Wasserfallplanung fast vollständig verdrängt hat, ist ein Statement, das man leicht in Frage stellen kann, denn Deadlines sind auch weiterhin die treibende Kraft in der Softwareentwicklung. Dass Entwicklungsteams, Product Owner und Scrum Master glücklich und zufrieden ihrer Arbeit nachgehen können, trifft ebenfalls leider nur für die wenigsten Teams zu. Während agile Werte und Prinzipien in kleinen Organisationen oder Start-Ups einfacher umgesetzt und gelebt werden können, treffen sie in größeren oder konservativeren Organisationen recht schnell auf die harte Realität der Arbeitswelt, die Corporate Culture. Doch trotz offensichtlicher Gegensätze von alter und neuer Arbeitswelt möchten die meisten Unternehmen natürlich die Vorteile, die agile Softwareentwicklung mit sich bringt, auskosten. So haben sich in den letzten Jahren agile Prozesse zum heiligen Gral für Unternehmen entwickelt, die endlich ihr volles Potential ausschöpfen und mit leichtgewichtiger Effizienz ihre Time-to-Market verbessern möchten.
Daraus resultieren viele Probleme, die wir alle in der einen oder anderen Form täglich zu spüren bekommen und vielleicht auch Zweifel in Bezug auf agiles Arbeiten aufkommen lassen. In diesem Artikel werden Ursachen, Konfliktfelder und auch Beispiele aus dem Arbeitsalltag näher beleuchtet, um zunächst ein tieferes Verständnis für die Entstehung dieser Probleme zu schaffen und im zweiten Schritt Möglichkeiten aufzuzeigen, wie man sinnvoll mit diesen Situationen umgehen kann.
Let’s Sell Being Agile!
Unternehmen, die agiler werden möchten, werden dieses Vorhaben in der Regel ohne externe Unterstützung nicht erfolgreich umsetzen können. Daher gibt es mittlerweile einen relativ großen Markt für Berater:innen, Trainer:innen oder Coaches, die diese Organisationen mit ihrer Expertise unterstützen möchten. Sie unterstützen z. B. beim Change Management, führen Trainings durch, coachen Mitarbeiter:innen, helfen dabei, agile Prozesse einzuführen und haben einen objektiven Blick von außen – eine Dienstleistung, die zunächst vermarktet und an potenzielle Kunden verkauft werden muss.
Oft ist diesen veränderungswilligen Unternehmen allerdings überhaupt nicht klar, welche Probleme sie mit der Veränderung eigentlich angehen möchten (abgesehen von „alles wird schneller, effizienter und besser“), und sie fokussieren sich primär auf interne Strukturen, Prozesse oder Tools, die verändert werden sollen. Werte wie Offenheit, Transparenz, Vertrauen, offene Feedback- und Fehlerkultur bekommen nicht den nötigen Fokus und die erlernte Kultur wird als gesetzt und unveränderbar angesehen. Sätze wie „Das haben wir schon immer so gemacht.“ oder „Das können wir leider nicht ändern.“ hört man in diesen Organisationen regelmäßig.
Externe Berater befinden sich also schon zu Beginn einer solchen agilen Transformation in einem Spannungsfeld, das extrem herausfordernd ist, denn oft wissen ihre Kunden gar nicht, was auf sie zukommt. Die nötigen Veränderungen erzeugen konstant Widerstände und ein solides Committment in einem solchen hierarchisch-politischen Umfeld zu bekommen, ist sehr schwierig. Das Resultat ist dann oft eine Art Kompromiss.
Frustration über Scrum
Dieser Kompromiss kann operativ in Frustration oder sogar Resignation enden. Der Fokus für die Veränderung wird stark auf Prozesse und Tools gelegt, wichtige Aspekte agiler Prinzipien und Werte werden zwar verstanden, aber nicht umgesetzt oder eingefordert bzw. (vor-)gelebt. Während Scrum Master oder Agile Coaches an allen Fronten Überzeugungsarbeit leisten, leiden am Ende die Mitarbeiter:innen in diesen Organisationen, die aus systemischer Sicht gesehen überfordert sind und ihre Probleme weiterhin mit Umstrukturierungen, neuen Prozessen oder Tools lösen möchten.
Da Scrum, wie zu Beginn erwähnt, das Aushängeschild unter den agilen Prozessen ist, eignet es sich hervorragend als Projektionsfläche für diese angestaute Frustration. Ob in Kommentaren von Blog-Artikeln, YouTube-Videos oder im Bekanntenkreis – die Frustration über Scrum oder agiler Arbeit ist allgegenwärtig und es gibt unzählige Podcasts, Konferenz-Talks und Artikel, die im Detail erklären können, warum Scrum oder „agile“ nicht funktioniert – vielleicht auch gar nicht funktionieren kann?
Einige Beispiele aus der Praxis
In der Praxis entstehen oft Mischorganisationen, die zwar lernen, agile Prozesse zu verwenden, aber nicht ihre Kultur und die Art der Zusammenarbeit anpassen. Dieser „Mismatch“ wird sehr schnell auf der operativen Ebene sichtbar und die Ursache, warum agiles Arbeiten bzw. agile Prozesse in vielen Unternehmen nicht besser (oder sogar schlechter) funktionieren, ist oft ein mangelndes Verständnis von agilen Prozessen sowie den agilen Werten und Prinzipien. Ein paar exemplarische Beispiele aus dem Arbeitsalltag, die in agilen Mischorganisationen auftreten:
„Mein Daily dauert immer mind. 30 Minuten, manchmal sogar noch länger, und wir müssen dort dem Product Owner reporten, woran wir gerade arbeiten.“
Das Daily Meeting wird im Scrum-Kontext oft missverstanden. Dieses Meeting ist nur für das Entwicklungsteam zur internen Absprache für die Erreichung des Sprintziels gedacht. Der Scrum Master ist dafür verantwortlich, dass es maximal 15 Minuten dauert und greift (falls nötig) bei Diskussionen moderierend ein. Wenn ein Product Owner im Daily Reports haben will, weist das auf andere Probleme hin, z. B. fehlende Transparenz oder fehlendes Vertrauen. Außerdem ist es wichtig zu verstehen, warum der Scrum Master nicht proaktiv gehandelt hat, um den Prozess und somit auch das Entwicklungsteam zu schützen.
„Die ganzen Meetings bei Scrum, ich habe das Gefühl, ich sitze jetzt nur noch in Meetings.“
Ein Thema, das man sehr häufig hört oder liest. Meetings können anstrengend sein, vor allem solche, die als nicht wertbringend oder sinnlos angesehen werden. In Scrum hat jedes Meeting einen dedizierten Zweck, daher sollte sich die Wichtigkeit automatisch ergeben. Wenn in Scrum die Meetings an sich oder deren Anzahl als belastend wahrgenommen werden, könnte Moderation oder Struktur in den Meetings fehlen. Finden außerhalb des Scrum-Prozesses noch viele weitere fachliche Meetings statt, sollten diese hinterfragt und auf ihre Wertstiftung geprüft werden, spätestens in der Sprint-Retrospektive. Ein gutes Scrum-Team wird offen und konstruktiv über diese Problematik sprechen, um gemeinsam potenzielle Verbesserungsmöglichkeiten zu finden.
„Story Points? Wir schätzen in Stunden und verplanen die Summe der verfügbaren Stunden pro Sprint. Damit können wir dann auch unsere Reports erstellen.“
Viele Teams haben anfangs Schwierigkeiten, mit Story Points zu arbeiten, da diese im Vergleich zu Stunden oder Tagen abstrakt sind. Das Team muss zuerst ein gemeinsames Verständnis entwickeln, um erfolgreich mit Story Points arbeiten zu können. In der Praxis scheitern manche Teams daran, dieses gemeinsame Verständnis zu etablieren. Doch wer einmal die Grundidee hinter Story Points verstanden hat, wird nie wieder zur reinen Zeitschätzung zurückkehren wollen.
Aber warum funktionieren Story Points so gut in der Softwareentwicklung? Die Schätzung von komplexen Aufgaben in Zeiteinheiten ist generell äußerst schwierig. Story Points verfolgen einen anderen Ansatz, indem sie das konkrete Schätzen von Zeit durch das Schätzen der Komplexität einer Story in Relation zu bereits geschätzten Stories ersetzen. Hierfür wird normalerweise die Fibonacci-Zahlenfolge verwendet (1, 2, 3, 5, 8, 13, …). Das bedeutet, dass kleinere bzw. weniger komplexe Stories genauer geschätzt werden, während bei steigender Komplexität die Schätzung ungenauer wird. Die Story Points entwickeln sich im Laufe der Zeit zu einer Art „eigenen Währung“ für das Team und können, zusammen mit der errechneten Velocity, sehr einfach für die Sprint- und Release-Planung eingesetzt werden. Story Points haben aber nichts in Reports zu suchen und auch das Umrechnen von Story Points in Zeiteinheiten sollte immer vermieden werden.
Jedes Scrum-Team, das aus Gewohnheit oder aus anderen Gründen weiterhin auf Zeitschätzungen beharrt, versäumt eine wertvolle Möglichkeit der Planung mit Scrum. Die durchschnittlich eingeplanten Story Points über alle Sprints (die Velocity) bilden über die Zeit gemessene, also empirische Werte ab, die eine höhere Verlässlichkeit bei der Planung ermöglichen.
„Unsere Retro ist total sinnlos, wir sprechen immer wieder über die gleichen Themen, aber erreichen keine Verbesserungen.“
Es kann sehr frustrierend sein, wenn man die Möglichkeit bekommt über Probleme und mögliche Verbesserungen zu sprechen, sich aber am Ende immer wieder um die gleichen Themen im Kreis dreht. Aber gerade jetzt ist die Retro wichtig, denn sie macht diese Themen immer wieder sichtbar. Werden die Retros vom Team als sinnlos oder ergebnislos wahrgenommen, muss der Scrum Master zunächst verstehen, warum diese Themen nicht lösbar scheinen. In der Praxis sind dies häufig Themen, die nicht innerhalb des Wirkungsbereich des Teams liegen, sondern externen Abhängigkeiten oder Anforderungen geschuldet sind, die in der Tat oft schwerer anzugehen sind und in der Regel Defizite in der Organisation aufzeigen.
Retrospektiven erfüllen aber immer ihren Zweck, besonders wenn sie sich nicht gut oder sogar frustrierend anfühlen. Lässt man die Retrospektiven aus, werden die Probleme nicht von selbst verschwinden.
„Wir machen eigentlich nie eine Retro, brauchen wir nicht oder machen wir nur bei Bedarf.“
Eine Retro ist niemals verschwendete Zeit, auch wenn die Ergebnisse oft als unbefriedigend wahrgenommen werden oder auch wenn wenig Verbesserungspotential sichtbar ist. Sie ist das wichtigste Meeting für das Team, da hier definiert wird, wie es in Zukunft weiter zusammenarbeitet, während Probleme offen angesprochen und Verbesserungsmöglichkeiten gesucht werden. Wenn keine (oder nur selten) Retros gemacht werden, wurde die Wichtigkeit und das Potential des Meetings nicht erkannt. Der Scrum Master muss hier ggf. Überzeugungsarbeit leisten und dafür sorgen, dass dieses Meeting stattfindet und so moderieren, dass das Team Raum zur Weiterentwicklung hat.
Shout Out an die Scrum Master
Nach diesen Beispielen könnte man sich fragen, was ist nur mit den Scrum Mastern los? Doch bevor man diese Frage beantwortet, ist es noch wichtig zu verstehen, dass Scrum Master ein sehr schwieriger Job sein kann. Auf dem Papier mag er zunächst recht einfach aussehen, in der Praxis ist er jedoch sehr herausfordernd. Liest man die Beispiele oben, könnte man denken, dass jeder Scrum Master wissen sollte, wie in der jeweiligen Situation zu handeln wäre. Besonders in Mischorganisationen, die agile Prozesse in klassische Unternehmensstrukturen implementieren, ist allerdings viel Fingerspitzengefühl, Durchsetzungsvermögen und Konfliktmanagement nötig, um die operativ-agile Entwicklungsblase zu schützen. Das kann besser oder schlechter funktionieren und geht natürlich auch nicht spurlos am Scrum Master vorbei, denn es kann sich wie der metaphorische Kampf gegen Windmühlen anfühlen. Deswegen ist es wichtig, besonders in schwierigen Umfeldern, erfahrene und sehr breit aufgestellte Scrum Master oder Agile Coaches einzusetzen, die abgesehen von der Fachlichkeit auch viel Empathie, analytisches Denken und Durchhaltevermögen mitbringen.
Aber auch für die Teams sind solche Umfelder schwierig und die Werte und Prinzipien aus dem Manifest für agile Softwareentwicklung werden oft als nicht mehr als bloße Lippenbekenntnisse wahrgenommen, denn sie sehen regelmäßig, dass zwar das Neue gesagt, aber das Alte getan wird. Neben dem Hinterfragen der Sinnhaftigkeit der „neuen“ Arbeitsweise müssen sie am Ende Probleme ausbaden, die relativ komplexe Ursachen haben, und fühlen sich ohnmächtig.
Aber warum scheitern so viele Firmen, die agil arbeiten möchten?
Die Gründe, warum so viele Firmen Probleme mit agilem Arbeiten haben, sind vielschichtig und komplex. Doch es ist unerlässlich diese zu verstehen, wenn eine nachhaltige und erfolgreiche Veränderung das Ziel ist. Dazu müssen wir bestehende Strukturen, die Kultur und den Führungsstil verstehen.
Organisationsstrukturen
Die klassische Unternehmensstruktur hat sich in den letzten Jahrzehnten kaum verändert. Es gibt starre Hierarchien und klar definierte Rollen bzw. Titel und Verantwortlichkeiten. Diese Corporate Governance fördert ein stark politisiertes Umfeld und basiert auf Regeln, Werten und Prinzipien, die agilen Werten und Prinzipien teilweise unvereinbar gegenüberstehen. Versucht man zum Beispiel agile Interaktionen über Abteilungs- oder Hierarchieebenen hinweg zu etablieren, wird man zwangsläufig scheitern, denn die Organisationsstruktur gibt klare Grenzen und Verantwortlichkeiten vor, die eingehalten werden müssen. Arbeiten in so einem Umfeld Teams aus zwei verschiedenen Bereichen zusammen, wird automatisch ein Silo-Denken einsetzen – kein „Wir“-Gefühl, sondern ein „Wir und die anderen“-Gefühl. Für ein Unternehmen mit diesen Grundvoraussetzungen ist es extrem schwierig, agil zu werden, da nicht nur auf operativer Ebene eine Veränderung stattfinden muss, sondern vor allem auch auf systemischer und arbeitskultureller Ebene. In der Regel haben diese Unternehmen eine so signifikante Veränderung bisher nicht durchlaufen und versuchen, diese mit ihren bekannten Methoden umzusetzen. Das sieht in der Praxis dann häufig so aus:
Hier ist unser Plan, wie wir unsere Organisation in den nächsten 18 Monaten agil machen. Externe Berater reinholen, agile Trainings für die Mitarbeiter:innen machen, agile Prozesse implementieren, und fertig ist die Transformation zum agilen Unternehmen. Mit dem Resultat, dass es häufig schlechter läuft als vorher und Mitarbeiter:innen zunächst frustriert sind und schließlich resignieren.
Unternehmen, die agiler werden möchten, müssen also zunächst verstehen, dass eine agile Transformation eine systemische Veränderung ist. Sie müssen wissen, welche Probleme und Herausforderungen gelöst werden sollen, die Kerngedanken von Agilität wirklich verstehen und explizit offen und bereit für Veränderungen auf allen Ebenen sein. In der Praxis scheitern viele Unternehmen schon an diesem essentiellen Punkt.
Corporate Culture
Die so genannte Corporate Culture findet sich meistens in größeren Unternehmen oder Konzernen, die schon länger existieren und wird stark von den Führungskräften durch Rahmenbedingungen, Strukturen und Werten geprägt, die sie ihren Mitarbeiter:innen vorgeben oder vorleben. Sie beschreibt etablierte Handlungs- und Wertemuster der Organisation, die die Art der Zusammenarbeit definieren, und ist äußerst vielschichtig. Sie fängt schon bei vermeintlichen Kleinigkeiten an, z. B. ob man per du ist oder sich siezt, hat aber auch einen sehr großen Einfluss darauf, wie sich Mitarbeiter:innen in der Organisation verhalten, und zwar primär unbewusst. Neue Mitarbeiter:innen erlernen diese ungeschriebenen Verhaltensregeln in kürzester Zeit und passen, falls nötig, ihr eigenes Verhalten entsprechend an.
Eine vorhandene Kultur in einem Unternehmen zu verändern bzw. transformieren ist eine extrem große Herausforderung und gestaltet sich in der Praxis sehr schwierig, da sich erlernte Muster sehr tief in Menschen verankern und das Überschreiben der alten Muster mit den neuen Ideen, Werten und Prinzipien anstrengend, zeitintensiv und auch unangenehm sein kann.
Wenn wir über agiles Arbeiten sprechen, müssen wir vor allem die vorhandene Kultur zunächst verstehen, denn in den meisten Fällen ist die Corporate Culture der natürliche Feind der Agilität, da sie eine Art Anti-Pattern zu agilen Werten und Prinzipien darstellt. Damit Mitarbeiter:innen diese agilen Werte annehmen und (er-)leben können, brauchen sie ausreichende psychologische Sicherheit. Diese Sicherheit können klassische Manager selten vermitteln, daher werden Servant Leader benötigt.
Manager vs. Servant Leader
In den letzten Jahren setzten sich auch kooperative Führungsstile immer weiter durch, aber in der Praxis begegnet man häufig Managern, die einen autoritären Führungsstil bevorzugen. Sie möchten kontrollieren, steuern, entscheiden und empfinden Feedback oder Rückfragen als störend, Kritik teilweise sogar als Angriff. Führungskräften, die diese Form der Führung bevorzugen, wird es schwerfallen, in der agilen Arbeitswelt ihre neue Rolle zu finden, da ihre eigenen Werte und Prinzipien nicht mit den agilen Werten und Prinzipien übereinstimmen. Sie werden bewusst oder unbewusst Widerstände aufbauen und die Veränderung ablehnen und im schlimmsten Fall sogar sabotieren, um ihre eigene Position zu schützen. Diese Reaktion ist natürlich und auch verständlich, es ist jedoch sehr wichtig, diese Art von Führungskräften in einer Organisation zu identifizieren und zu überprüfen, ob sie das Potential und die Bereitschaft zu einer Veränderung zum Servant Leader haben.
Die Grundidee der agilen Softwareentwicklung ist, dass Teams größtmögliche Autonomie mit gleichzeitiger psychologischer Sicherheit erhalten. Daher gibt es keine (Micro-)Manager mehr, die sagen, was zu tun ist, sondern es gibt Servant Leader, die Mitarbeiter:innen unterstützen und ihnen genau das Umfeld schaffen, welches sie benötigen, um erfolgreich sein zu können. Diese Zusammenarbeit ist geprägt von Offenheit, Vertrauen und gegenseitiger Wertschätzung. In einem (zukünftig) agilen Umfeld wirkt autoritärer Führungsstil toxisch und wird kurz- bis mittelfristig alle Bemühung hin zu mehr Agilität zersetzen.
Das klingt nicht nach den besten Voraussetzungen, was machen wir jetzt?
Zunächst ist es wichtig, dass im ersten Schritt zwischen den Grundideen von agilem Arbeiten und der tatsächlichen Umsetzung in unserem Arbeitsalltag unterschieden wird. Im zweiten Schritt ist es wichtig zu verstehen, warum diese Probleme im Arbeitsalltag so exzessiv auftreten. Wenn diese beiden Ebenen verstanden sind, muss man nicht mehr die Frage stellen, ob agile Softwareentwicklung tot oder zum Scheitern verurteilt ist, sondern kann aktiv in die Lösungssuche einsteigen.
Die Ursachen, warum agile Methoden oder Prozesse nicht funktionieren, können wie beschrieben komplex sein, aber sie sind auch sich selbst korrigierende Systeme und geben Mitarbeiter:innen Möglichkeiten aktiv Impulse zu setzen, um diese Systeme zu verändern. Damit diese Selbstkorrektur funktioniert, muss allerdings ein wichtiger Faktor berücksichtig werden, und zwar das Committment. Hat eine Organisation keine echte Motivation agil zu arbeiten oder zu werden, wird sich agiles Arbeiten immer wie ein schlechter Kompromiss anfühlen, letztendlich vielleicht sogar schlechter funktionieren als vorher und mittel- bis langfristig Mitarbeiter:innen verschleißen.
Scheitert Agilität aber nicht aufgrund fehlenden Commitments, sondern auch durch einige der hier im Artikel genannten Faktoren, gibt es Lösungen und Möglichkeiten, die agile Methoden direkt mitliefern. Im Arbeitsalltag kann es z. B. helfen, regelmäßig das agile Manifest oder den Scrum Guide zu Rate zu ziehen.
Haben alle das gleiche Verständnis von agilem Arbeiten?
Geht im Team gemeinsam das agile Manifest durch, mit besonderem Fokus auf die 12 Prinzipien der agilen Softwareentwicklung. Stimmt ihr diesen Prinzipien zu und folgt ihr ihnen? Bei welchen tut ihr das nicht und warum nicht? Sprecht gemeinsam im Team darüber und versucht zu verstehen, wann und warum ihr abweicht.
Weicht ihr bei eurem Scrum-Prozess vom Scrum Guide ab?
Die wenigsten Teams setzen Scrum eins zu eins aus dem Scrum Guide um, was aber grundsätzlich auch gar kein Problem ist (Individuals & Interactions over Processes & Tools). Es ist aber wichtig zu verstehen, warum ihr abweicht und zu bewerten, ob ihr als Team dadurch Vorteile oder Nachteile habt. Scheut euch nicht davor Neues auszuprobieren oder etwas anders als vorher zu machen und nutzt die gemachten Erfahrungen, um eure Zusammenarbeit kontinuierlich zu verbessern und als Team euren Weg zu finden. Man kann auch sehr gut das japanische Shu-Ha-Ri Prinzip hier anwenden: erst lernen, dann loslösen und letztendlich übertreffen.
Arbeitet ihr in einer agilen Organisation oder in einer agilen Bubble?
In der Praxis findet man oft die Situation vor, dass operative Teams agil arbeiten, im Unternehmen bzw. ab Managementlevel aber noch „klassisch“ gearbeitet wird. Veränderungen in agilen Organisationen sind weitaus einfacher und schneller umzusetzen, während man in einer agilen Bubble in einem klassischen Unternehmen öfter und schneller an Grenzen stößt. In so einem Szenario wird ein erfahrener Scrum Master benötigt, der das Team standfest vor Eingriffen von außen schützt und gleichzeitig die Rolle eines „agilen Botschafters oder Übersetzers“ in die nicht-agile Organisationsebenen einnimmt. Das Setup ist jedoch grundsätzlich sehr schwierig und wird sich nie richtig agil anfühlen. Trotzdem ist es in so einem Fall wichtig zu verstehen, ob die Organisation nicht agil werden will oder es noch nicht schafft.
Versucht nicht in Ist-Zuständen, sondern in Bewegungen oder Richtungen zu denken.
Wenn ihr in einem schwierigen Umfeld arbeitet und euch nur auf die aktuelle Situation fokussiert, werdet ihr immer eine Vielzahl an Problemen sehen. Hier kann es helfen, auch die Vergangenheit im Blick zu haben. Habt ihr vielleicht schon Fortschritte gemacht, die euch gar nicht bewusst sind? Sind die Veränderungen der Weg in die richtige Richtung, brauchen aber mehr Zeit, als ihr erwarten würdet? Lasst euch davon nicht entmutigen. Kontinuierliche Verbesserung ist ein Prozess, der niemals abgeschlossen sein wird. Wichtig ist, dass die Veränderungen in die richtige Richtung gehen und ihr aus Fehlern und gesammelten Erfahrungen die richtigen Schlüsse zieht und dadurch als Team oder Organisation wachst.
Gibt es denn eine Alternative zu agil?
Die IT- bzw. Softwarebranche ist fachlich extrem fordernd und die Komplexitätskurve schnellt mit jedem neuen Framework, jeder neuen Technologie, steil nach oben. Wir befinden uns in einem Umfeld, in dem viele intelligente Menschen gemeinsam hochkomplexe Produkte entwickeln, schwierige Probleme lösen und das oft unter enormen Zeitdruck, der unweigerlich Stress erzeugt. Die Idee hinter Agilität ist es, diesen Menschen ein Umfeld zu schaffen, in dem sie diese Herausforderungen vernünftig und motiviert angehen können. Gelebte agile Werte und Prinzipien zahlen bewusst und unbewusst auf sehr viele Faktoren ein, die unsere Arbeitswelt und unsere Zusammenarbeit in einem solchen Umfeld positiv beeinflussen. Wer das wirklich verstanden hat, wird die Frage, ob es eine Alternative zu agil gibt, nicht mehr stellen. Und letztendlich auch nicht die Frage stellen: So, is Agile Dead Yet?
