Agile - 10 Wahrheiten

Jede Organisation, die gerade mit Agilität anfängt, muss erstmal lernen, Erfahrung sammeln und Sicherheit in einer Methodologie gewinnen, bevor sie anfängt zu Skalieren oder Elemente der anderen Methodologien zu addaptieren. Sieh auch Shu-Ha-Ri Technik des Lernens. Auch wenn die meisten Agile Methodologien auf einer gemeinsamen Philosophie basieren, sind sie betrachtet in Details deren Implementierung unterschiedlich, da sie unterschiedliche Probleme der Software Entwicklung zu lösen versuchen. Für junge Unternehmen, ohne Erfahrung, ist es besser sich auf diese, eine Methodologie zu konzentrieren, die ihr größtes Problem zu lösen verspricht! Erst mit Erfahrung sollte man dann Lücken in der Problemlösung mit Hilfe von Elementen anderer agilen Methodologien schließen. Die agile Methodologien sind lean und deshalb sind alle deren Komponenten kritisch für den Erfolg. Elemente nicht zu berücksichtigen oder zu verändern könnte dann eher zu Frust führen. Z.B. wenn eine Organisation die kurzen Sprints einführt, aber die Teams-Größe nicht berücksichtigt, oder sich nicht die Beseitigung der technischen Schwierigkeiten (technical debt) auf die Fahnen schreibt, läuft die Gefahr nach kurzfristigen Erfolgen sich vor noch größeren Problemen zu finden. Wenn man es nicht schafft die Business Führungskräfte, Manager und die Benutzer zu überzeugen die neue Arbeitsweise auszuprobieren, wird es keine volle Entfaltung der Vorteile geben. Besonders wertvoll ist die ständige Kommunikation und die gemeinsame Planung und Priorisierung der Aufgaben für die kurzen Releasephasen, die ohne aktive Beteiligung von Business und Benutzer gar nicht möglich ist. Das Lernen ist essentiell, eine fundamentale Komponente der Agilität, und zwar für das gesamte Team, nicht nur für die Entwickler! Die ständige Verbesserung der Qualität und die Steigerung der Kosten-Effizienz ist nicht möglich ohne Analyse der "Lessons Learned" aus jeder Releasephase (Sprint) und die Optimisierung der Policen und Arbeitspraktiken. Das kleine Team, 7 +/- 2 Entwickler und QA, ist essentiell wichtig bei den agilen Methodologien. Dabei ist die physikalische Nähe des Teams (Arbeiten, wenn möglich in dem selben Raum= "Co-Location") wichtige Regel der Agilität im Unterschied zu den anderen, konventionellen Methoden in der Software-Entwicklung! Eine andere Herausforderung von HR Perspektive ist den Erfahrungs-Austausch der Teams sicherzustellen und die Produktivität der Teams durch Wechseln nicht zu drosseln. Jede Entwicklung erzeugt "technical debt"- technische Schulden. Bei den agilen Methodologien werden diese "Schulden" nach jeder Iteration (Sprint) erkannt und müssen in dem nachfolgenden Sprint beseitigt werden! Somit gehört "refactoring" und die Eliminierung von technischen Schulden als beste Praktik in jeder Organisation, die sich agil nennt! Viele IT Organisationen nutzen externe, spezialisierte Service Provider. Das widerspricht einer der Grundkomponenten von Agile- Co-Location. Durch Zeitzonen-und Kultur-Unterschiede wird die Kommunikation erschwert und die Agilität-Vorteile werden reduziert. Es ist sinnvoll Alternativen zu evaluieren, die eventuell die Probleme solcher Organisationen besser lösen als die Agilen Methodologien. "Continuous delivery" ist eine der Grundkomponenten von Agile. Durch die agilen Methodologien, dank der engen Zusammenarbeit von Business, Kunden und Entwicklung, wird kontinuierlich neue oder modifizierte Software zur Benutzung frei gegeben. Diese Tatsache erfordert signifikante Koordinierung und Zusammenarbeit auch mit den Operation-Teams, Business Governance und den Aufbau der entsprechenden Infrastruktur. Die Unternehmen haben unterschiedliche Probleme in der Software-Entwicklung. Manche sind besser zu Lösen mit der Benutzung der agilen Methodologien, andere dagegen, wenn man den traditionellen iterativen oder modifizierten Wasserfall-Modellen treu bleibt! Agilität ist nicht immer und überall "besser"- bei manchen Problemen ist sie aber die schnellere und bessere Lösung.