0511 874 590 50 info@agile-im.de

Vielfältige Eindrücke aktueller Trends

Nachdem wir im November wieder an einigen spannenden Veranstaltungen zu den Themen agile Methoden, Application Lifecycle Management, Wissensmanagement und Social Intranets – zum Beispiel dem Global Scrum Gathering in Prag und dem CCD 2015 in Berlin – teilgenommen haben, wollen wir gern die vielen Eindrücke und unsere Wahrnehmung über wichtige Themen und Trends teilen – und freuen uns natürlich über entsprechendes Feedback und Austausch hierzu. Folgende Herausforderungen kamen nach unserem Eindruck sowohl in Vorträgen und Workshops als auch in Gesprächen mit vielen Teilnehmern am häufigsten vor:

Agilität wächst und gedeiht

Nachdem agile Methoden und insbesondere Scrum in vielen einzelnen Teams und Projekten Erfolge und Verbesserungen erzielen konnten, dehnt sich Agilität bereits seit einiger Zeit einerseits auf zunehmend größere IT Produkte und IT Bereiche (Teams / Produkte) aus. Andererseits finden auch Nicht-IT-Bereiche wie Marketing, HR und für Umsetzung von Strategie und Organisationsentwicklung Gefallen an agilen Methoden und Werkzeugen.

Auch wenn diese nicht neu sind, wächst die Bedeutung der entsprechenden Herausforderungen und Lösungen – zum Beispiel: Wie können mehrere Teams, die an mehreren Subsystemen eines Produktes / Projektes arbeiten, sich miteinander selbstorganisiert abstimmen und eine gemeinsame Architektur oder Plattform ohne zu viele Abhängigkeiten realisieren? Oder im noch größeren Stil: Wie kann ein gesamtes Portfolio / Programm bestehend aus mehreren Streams / Produkten und gegebenenfalls jeweils auch noch aus mehreren Teams (und Subsystemen) möglichst wertschöpfend und produktiv ohne zentralistische Steuerungs- und Kontrollstrukturen bearbeitet werden? Viele Unternehmen stellen sich inzwischen sogar die Frage, ob und wie eine agile Organisation auf allen Ebenen und in (fast) allen Bereichen überlebenskritische Vorteile liefern kann. – Oder praktizieren dies bereits. In diesem Zusammenhang wetteifern verschiedene Philosophien und Modelle miteinander – wie zum Beispiel SAFe, LeSS, Nexus oder Holacracy. Ohne dies zu vertiefen: zu unseren Favoriten für eine ganzheitliche und in allen Dimensionen konsistente Herangehensweise gehört das Viable Systems Model, welches übrigens schon seit 1959 existiert.

Scaling_Agile

Reibung mit nicht agilen Umgebungen

Gleichzeitig – in gewissen Kontrast oder vielleicht auch als logische Konsequenz der oben beschriebenen Entwicklungen – scheinen Reibungen mit klassischen Management Denkweisen und Kulturen sehr präsent zu sein. Im Zuge der Ausweitung von Agilität über einzelne Teams und Experimente stößt diese natürlich stärker mit den noch in vielen Unternehmen vorherrschenden Command & Control Strukturen zusammen. Neben der Frage ob Letztere in hochdynamischen und komplexen Umfeldern noch funktionieren können steht im Zentrum dieser Diskussion auch das zugrunde liegende Menschenbild. – Häufig wird dies dargestellt durch den Gegensatz von Theorie X (unwillige / unselbständige Abarbeiter, die extrinsisch motiviert oder eher möglichst eng gesteuert werden müssen) zu Theorie Y (engagierte, intrinsisch motivierte Wissensarbeiter, die selbständig und selbstorganisiert Verantwortung übernehmen und Umsetzung gestalten).

Neben diesen sehr grundsätzlichen Themen spiegelt sich diese Reibung auch in praktischen Fragestellung wieder – wie zum Beispiel die Einbettung in wenig agile Bedingungen, die sich zumindest nicht von einem auf den anderen Tag ändern lassen: die Organisationen der Kunden von IT Dienstleistern haben nun einmal häufig noch Einkaufs-, Rechts- und Fachabteilungen, die auf Werkverträge und Festpreisen bestehen. Wie lässt sich dies mit agilen Prinzipien und Vorgehensweisen vereinen? Ebenso bietet sich auch in den IT Bereichen Infrastruktur und Betrieb eine agile Vorgehensweise zumindest nicht auf den ersten Blick an – wie passt dies mit einer Anwendungsentwicklung zusammen, die Scrum praktiziert? Und häufig herrschen auch nicht ohne Weiteres die favorisierten Arbeitsbedingungen wie Colocation, T-shaped Skills und langfristig stabile, in Vollzeit für einen Stream / ein Produkt verfügbare Teams. – Was ist dann die Konsequenz? Alles so weiter machen wir bisher (nicht agil) und zunächst für entsprechende Änderungen kämpfen?

Letztlich gibt es aus Sicht der Systemtheorie immer eine nur begrenzt beeinflussbare Umgebung – eine rekursive Sicht der Dinge kann hier also unter Umständen helfen, auf der richtigen Ebene anzusetzen: Menschen > Teams > Bereiche > Unternehmen > Umwelt. Am Ende des Tages gelingt aber agiler Wandel eher schwerlich als reine Revolution der Basis, wenn das (Top) Management nicht zumindest entsprechende „sichere Experimente“ zulässt und langfristig auch den entsprechenden Wandel voran treibt.

Welche Ausrüstung wird für die agile Mission benötigt?

Weitere wesentliche und sehr praktische Fragestellungen drehen sich vor allem darum, mit welchen Methoden, Fertigkeiten und Werkzeugen die Umsetzung der ansprechenden Ideen erfolgen kann. Trotz des agilen Wertes „Working software over comprehensive documentation“ stellt eine nachvollziehbare Dokumentation sowohl für Anwender als auch für (zukünftige) Teammitglieder häufig immer noch einen gewissen Mehrwert dar. Wie kann erreicht werden, dass diese trotz vieler kleiner und iterativer Releases in einer nachvollziehbaren und konsistenten Form entsteht? (In Analogie zur übergeordneten Frage der Architektur: siehe oben.) Weiterhin: wie können Anforderung beziehungsweise Akzeptanzkriterien kontinuierlich, effizient und mit ausreichender Abdeckung in Testfälle, Testszenarien und – in der jeweiligen konkreten technischen Umgebung – in Testautomaten überführt werden? und wie kann die angestrebte hohe Releasefrequenz erreicht werden, ohne Overheads in die Höhe zu treiben.

Hier sind umsetzbare und konkrete Ansätze für Application Lifeycycle Management und Continuous Delivery Lösungen gefragt.

Die (gewollt) intensivere (- wo sinnvoll & notwendig -) Kommunikation zwischen Teammitgliedern, zwischen Teams und mit Product Ownern führt zwangsläufig auch zu dem Bedarf an der Verbesserung der individuellen Kommunikationsfähigkeiten. Dies drückt sich entsprechenden, gut besuchten Workshops zum Kommunikations- und Visualisierungstechniken aus. Ebenso gewinnen offenbar (Social) Intranets und Wikis noch mehr an Bedeutung, um die / den für Selbstorganisation notwendige Kollaboration und Wissensaustausch zu unterstützen. Hierfür müssen diese Systeme den Bedürfnissen der Anwender noch viel mehr entgegen kommen und das leichte Erfassen, Verteilen und vor allem Finden relevanter Informationen in großen, dynamischen, häufig wenig strukturierten Inhalten ermöglichen.

Aber nicht nur Softwarelösungen sind hier sinnvoll, teilweise bieten gerade physische, analoge Arbeitsmittel – Pinwände, Zettel, Stifte usw. – einige Vorteile, die von vielen „PC Arbeitern“ in Zeiten immer digitalerer Kommunikation erst wieder entdeckt werden müssen.

Wie werden Produkte & Teams am besten strukturiert?

Ein zentrales Thema insbesondere bei komplexen Produkten oder Produkt Programmen, die gemeinsame Funktionen nutzen sollen (oder zumindest könnten) ist die richtige Strukturierung der Produkte und damit auch der Teams. Häufig wird für Feature Teams (- unter Vermeidung von Plattform Teams -) plädiert, was dann wiederum Lösungsansätze für überschneidende oder sogar konkurrierende Anforderungen und für Abhängigkeiten erfordert. Als Alternative hierzu hat sich in einigen Organisation ein internes Open Source Modellbewährt, in dem jedes Team Plattform Funktionalität anpassen und erweitern kann, aber das Plattform Team über den späteren Retrofit entscheidet.

Teilweise scheint außerdem die Idee eines „Potentially Shippable Product“ mit jedem Release möglichst bereits vom ersten Sprint an schwer vorstellbar zu sein. Wie kann ein Produkt so in kleinere Teile zerlegt werden, dass diese schon (früh – ab dem ersten Sprint?) auslieferbar sind und bereits einen Mehrwert liefern? Gerade bei komplexen oder weniger leicht anpassbaren Hardware Produkten stellt dies natürlich eine Herausforderung dar. Mit einer gewissen Hartnäckigkeit und geeigneten Konzepten wie dem Minimum Viable Productlässt sich dies aber durchaus häufig lösen – durch Fokussierung auf den wesentlichen Kernnutzen – oder als Variation der eigentlich Idee zum Beispiel durch Mockups, Prototypen, Simulationen.

Was ist der echte Geschäftswert?

Wenn Mehrwert konkret als wesentliches Backlog Ordnungskriterium erfasst und wiedergegeben werden muss, wird häufig erst deutlich wie verschwommen und unklar eigentlich der Geschäftswert vieler geforderter Funktionen ist. Wie kann also „Business Value“ möglichst richtig – im Sinne von tatsächlich erzeugtem Kundennutzen – und auch vergleichbar ermittelt und gemessen werden? Um den Kunden und den Kundennutzen wirklich zu verstehen bieten sich Instrumente wie UX Design, Customer Experience Management, Customer Journeys an. Fast noch herausfordernder ist dies bei der Entwicklung interner Softwarelösungen, weil die Anforderungen der Stakeholder (= Prozessverantwortlichen) häufig nicht unbedingt deckungsgleich mit denen der operativen, eigentlichen Anwender sind.

Wie sehen Ihre Erfahrungen, Herausforderungen und Lösungen für die genannten Themen aus? Wir freuen uns wieder auf einen regen Austausch!

Jetzt zum AIM Newsletter anmelden

Bleiben Sie up-to-date über aktuelle Themen und Trends aus den Bereichen Agile, DevOps und Artificial Intelligence. Sie profitieren von pfiffigen Success Stories, mehrwertigen Fachartikeln, Experteninterviews und Whitepaper, die Ihnen bei Ihrer täglichen Arbeit helfen. Schließen Sie sich über 5.000 Entscheidern an und erhalten Sie monatlich Ihr Update zu Anwendungen, Methoden und Technologien von Künstlicher Intelligenz und Machine Learning sowie Agile und DevOps.

Wir freuen uns über Ihre Newsletter-Anmeldung. Sie erhalten in wenigen Sekunden eine E-Mail mit dem Link zur Aktivierung Ihrer Newsletter-Registrierung.