Wir hatten zwei Jahrzehnte Zeit, die Werte und Prinzipien des Agile Manifests zu verinnerlichen. Was haben wir gelernt und was lernen wir noch? „Wir sind näher dran und bewusster, aber wir drehen einen Tanker und das geschieht langsam und inkrementell.“
Es gibt noch viel zu tun, um das Versprechen von Agilität einzulösen – dies ist der 20. Jahrestag der Gründung von Agiles Manifest, in dem die Bedeutung einer engen, uneingeschränkten Zusammenarbeit zwischen Softwareentwicklern und Unternehmensführern hervorgehoben wurde. Obwohl „agil“ zum beliebtesten Schlagwort im Business-Technologie-Lexikon geworden ist, ist es oft immer noch nur ein Schlagwort.
Es ist nicht so, dass Unternehmen die Werte und Prinzipien des Agilen Manifests nicht befürworten – die meisten sind es. Allerdings stehen diese Werte und Prinzipien in den meisten Strategien nicht im Vordergrund. „Ich bin mir noch nicht sicher, ob die Denkweise des Agile Manifests die Norm in der Branche ist“, sagt er Kief Morris
, leitender Cloud-Technologe bei ThoughtWorks. „Die Leute wissen, dass sie ihre Denkweise über Technologie ändern müssen, sie reden über digitale Transformation, aber das weiß ich nicht.“ Sie sehen wirklich, wie die Werte und Prinzipien des Agilen Manifests damit zusammenhängen und wie man sie nutzen kann, um es zu einem Erfolg zu machen Wirklichkeit."Die Herausforderung entsteht, „weil viele Agilität als Lösung oder Rezept betrachten, anstatt mit der Philosophie zu beginnen, auf die sich das Agile Manifest konzentriert“, heißt es Bob Ritchie, Vizepräsident für Software bei SAIC. „Viele Best Practices wie automatisierte testgetriebene Entwicklung, automatisierte Builds, Bereitstellungen und schnelle Feedbackschleifen sind in der Branche weit verbreitet. Allerdings sind sie häufig noch von den Geschäfts- und Missionszielen abgekoppelt, weil sie nicht mit dem Grund beginnen.“
Wieder andere sind der Meinung, dass wir die Vision des ursprünglichen Agilen Manifests noch lange nicht erreicht haben. „Absolut nicht in großem Maßstab unternehmensübergreifend“, sagt Brian Dawson, DevOps-Evangelist mit CloudBees. „Wir sind näher dran und bewusster, aber wir drehen einen Tanker und das geschieht langsam und inkrementell.“ Bei Start-ups sehen wir davon viel mehr; Das ist vielversprechend, weil sie die Unternehmen der Zukunft sind.“ Agile Initiativen „werden allzu oft von der Projektplanung oder dem Projektmanagementbüro aus eingeführt und sind auf diese beschränkt. Um die Agile- und DevOps-Transformation zu unterstützen, muss Agile bei allen Beteiligten umgesetzt werden.“
Einige Unternehmen nutzen Agilität „als Allheilmittel, um die Margen durch Kostensenkungen durch einen besseren, glänzenderen Entwicklungsprozess zu steigern“, warnt Ritchie. „Andere gehen sogar noch weiter, indem sie beliebte Kennzahlen im Zusammenhang mit der agilen Kapazitätsplanung wie die Geschwindigkeit zu einer Waffe machen und sie fälschlicherweise als Leistungskennzahl für eine Einzelperson oder ein Team klassifizieren. Unter diesen Umständen werden die Versprechen des Manifests mit ziemlicher Sicherheit verfehlt, da Gelegenheiten zum Engagement und zur Zusammenarbeit Platz für Schuldzuweisungen, Schuldzuweisungen und Burnout werden.“
Was vielen agilen Initiativen fehlt, sind „Möglichkeiten, das, was man tut, auf der Grundlage von Werten und Ergebnissen zu verwalten, anstatt auf der Messung von Aufwand und Aufgaben“, sagt Morris. „Wir haben den Aufstieg formelhafter ‚Enterprise Agile‘-Frameworks erlebt, die Ihnen bei der Verwaltung von Teams helfen sollen von oben nach unten, auf eine Weise, die auf allem basiert, was rechts von den Werten des Agilen steht Manifest. Im Manifest heißt es, wir legen Wert darauf, „auf Veränderungen zu reagieren, statt einem Plan zu folgen“, aber diese Rahmenwerke geben es Ihnen eine Formel für die Verwaltung von Plänen, die Sie nicht wirklich dazu ermutigen, auf Änderungen zu reagieren, sobald Sie sie erhalten gehen."
Die Herausforderung besteht darin, dass „den meisten agilen Initiativen immer noch die Vorarbeit zur Wertstromabbildung und -optimierung fehlt“, sagt er Venky Chennapragada, DevOps-Architekt mit Capgemini Nordamerika.. „Bei agilen Projekten geht es immer noch um die Optimierung der Arbeit, die unnötigen Kontext generiert oder die Qualität verringert.“ Die Veränderungen Die vom Unternehmen geforderten Änderungen müssen die beabsichtigten Ergebnisse liefern und dabei Rückmeldungen von den Kunden einholen, indem sie kleine Änderungen vornehmen, sagt er erklärt. „Schnelles Feedback ist erforderlich, um den Business Case zu rechtfertigen, um weiterzumachen oder woanders zu investieren.“
Das Agile Manifest „spricht von Dingen wie der Wertschätzung von ‚Individuen und Interaktionen gegenüber Prozessen und Tools‘, aber das ist schwierig“, fügt Morris hinzu. „Prozesse und Tools scheinen einfacher zu sein. So viele Softwareunternehmen und Beratungsunternehmen bieten Ihnen Prozesse und Tools an, um Ihnen Agilität und DevOps zu ermöglichen und Sie digital zu machen. Aber es geht ihnen wirklich darum, Ihnen die Gewissheit zu geben, dass es einen einfachen Weg, eine Formel gibt, die Sie genauso erfolgreich macht wie die Unternehmen, die auf dem Markt erfolgreich sind.“
Ritchie stimmt zu, dass die Tendenz zu groß ist, Agilität in starre Prozesse einzuordnen. „Der erste und häufigste Fehler ist die Interpretation von Agilität einfach als einen Prozess oder als etwas, das man einfach kaufen und tun kann, um sich sofort als agil zu bezeichnen“, sagt Ritchie. „Dies führt in den meisten Fällen zu einem Prozess um des Prozesses willen, zu Frustration und – im Widerspruch zur Absicht von Agilität – zu einer noch größeren Trennung zwischen.“ Geschäftsergebnisse und die IT-Experten, die beauftragt wurden, sie zu liefern.“ Damit verbunden, sagt er, kann es oft einen „dogmatischen, agilen Eifer-Ansatz geben, bei dem …“ Alles, was ein bestimmtes Rahmenwerk sagt, muss als Evangelium verstanden werden, und der Emulate-Irrtum-Ansatz – am einfachsten erkennbar an Ausdrücken wie „Wir folgen dem.“ Spotify-Modell.‘“
Umgekehrt besteht die Tendenz, von starren Prozessansätzen wegzukommen und agile Ansätze zu stark zu vereinfachen. Der zweithäufigste Fehler, den Ritchie bei agilen Bemühungen sieht, „ist eine übermäßige Abkehr vom Dogma und zahlreichen Frameworks auf dem Markt und.“ Versuchen Sie, mithilfe der Philosophie „Seien Sie einfach agil“ zur geschäftlichen Agilität überzugehen. Typischerweise zeugen Sie bei diesem Fehler von einem Mangel an Disziplin sehr schnelle und frühe Erfolge, eine Zeit des übermäßigen Engagements und der übermäßigen Versprechungen und letztendlich ein Burnout und Zusammenbruch der Technologie Organisation. Was vielen Organisationen, die mit diesen Fallstricken kämpfen, wirklich fehlt, ist die Analogie zum Sport und die Notwendigkeit der Rolle des Coaches, die Organisation geschickt durch ihre Agilität zu steuern Reise. Auch wenn es für viele IT-Organisationen einen unnötigen Overhead darstellt, habe ich festgestellt, dass dies insbesondere bei der Fall ist In den Anfängen der agilen Transformation gibt es nichts Wichtigeres als einen erfahrenen Agile Sherpa."
Agile Praktiken haben sich bei Organisationen bewährt, „die die Grenzen ihrer Kapazität verstehen und besessen von ihren Kunden sind.“ und Endbenutzer, priorisieren effizient und schnell, testen und beweisen Hypothesen objektiv, lieben das Problem, nicht die Lösung, und haben „Transparente, messbare und ehrgeizige Geschäftsziele zu verfolgen, genießt jedoch die vielen Vorteile echter Geschäftsagilität“, sagt Ritchie sagt.
Die in der angegebenen Werte Agiles Manifest von 2001 sind auch heute noch genauso aktuell wie zum Zeitpunkt ihrer Formulierung und Veröffentlichung:
„Wir entdecken bessere Möglichkeiten, Software zu entwickeln, indem wir es tun und anderen dabei helfen.“
Durch diese Arbeit haben wir Folgendes schätzen gelernt:
- Einzelpersonen und Interaktionen über Prozesse und Tools
- Funktionierende Software über umfassende Dokumentation
- Kundenzusammenarbeit bei Vertragsverhandlungen
- Auf Veränderungen reagieren statt einem Plan folgen“