Agile Unternehmenskultur berücksichtigt Erkenntnisse aus der Unternehmensentwicklung und der 60 jährigen Geschichte der Informationstechnologie. Dazu werden bewährte und neue Vorgehensweisen in allen Unternehmensbereichen unter Berücksichtigung agiler Werte kreativ adaptiert und genutzt. Selbstverständlich zählt dazu auch die interne IT Organisation und deren organisatorische Abläufe.

Die "agile IT- und Produkt-Transformation" unterstützt als eine von drei Säulen die Realisierung einer zeitgemäßen "agilen Unternehmenskultur" im technischen und organisatorischen Bereich. Sie löst die überkommene Sichtweise ab, die Agenden der Informationstechnologie als eigenständigen Unternehmensbereich zu sehen - "IT zum Selbstzweck".

Moderne Unternehmen verzahnen die Weiterentwicklung von Dienstleistungen sowie von physischen und rein digitalen Produkten mit der Weiterentwicklung der dazu erforderlichen Prozesse und digitalen Hilfsmittel, die selbst als Produkte (bzw. Werkzeuge) zur Sicherung und kontinuierliche Verbesserung der angestrebten Wertschöpfung anzusehen sind (Applikationen, Prozess-Bausteine, APIs usw.).

Ziele auf organisatorischer Ebene:

• Transformation des IT Auftragswesens weg von Großprojekten, komplexen Verträgen hin zu Mietmodellen für agile Produkt-Teams und Produkt-Pipelines
• Transformation der internen IT Kosten weg von Betriebskosten hin zu Ausgaben für die unmittelbare Geschäftsentwicklung
• Transformation des Produktlebenszyklus zu agil entwickelten digitalen Produkten, Dienstleistungen und Channel-APIs
• Auslagerung von IT Aufgaben die nicht unmittelbar zur Geschäftsentwicklung beitragen: SaaS und PaaS Transformation im Kerngeschäft

Ziele auf der operativen Ebene:

• Transformation der IT Organisation und des IT Projekt-Managements in interdisziplinäre agile Teams (vgl. Geschäftsentwicklung)
• Produkt-Transformation: SaaS Ergänzungen (Satelliten-Apps und APIs) statt vollständige Eigenentwicklung
• API-/Channel-getriebene Entwicklung (APIs mit Mehrwert), API Management für eigene und externe Produkte
• Front-End [GUI] und Back-End [API] Produkte sind gleichwertige Liefergegenstände mit integriertem Lebenszyklus für Produkt-Dokumentation und geprüfter User Experience (UX)
• Laufende Prüfung und Verbesserung der Produkt- und API-Qualität (nicht funktionale Anforderungen, 15 Faktor App, Fehlerbehandlung)
• Effizienzsteigerung durch technischen Referenzarchitektur nach Kriterien der "15 Factor App", "cloud readyness" und der Anforderungen intelligenter Geschäftsprozesse
• Effizienzsteigerung durch DevOps und Automatisiserung
• Effizienzsteigerung durch Container basierte Produkt-Pipelines (CI/CD) und Cloud Ready Technologien mit zeitnaher Rückmeldung durch automatisierte Tests und von BenutzerInnen
• Flexible Nutzung von Daten und Prozessbausteinen: LowCode/No Code Ad Hoc Auswertungen und Ad Hoc Prozesse aus vorgefertigten Bausteinen

Hinweis: Erfolgreich realisierte Prozesse mit ausreichendem Grad an Automatisierung sind selbst als Produkte der geschäftlichen und technischen Entwicklung zu betrachten, die intern und über entsprechende Vertriebskanäle auch von Partnern genutzt werden, um Endkunden damit realisierte Endprodukte bereit zu stellen. Folglich können agile Methoden und Prozesse zur Produktentwicklung auch auf die Werkzeuge zur Entwicklung von Endprodukten angewendet werden, insbesonders wenn digitale Produkte entwickelt werden.

Im Beitrag Agile Unternehmenskultur wird eine ganzheitliche Sichtweise ihrer Business Transformation vorgestellt. Die agile Weiterentwicklung von Dienstleistungen bzw. von physischen oder digitalen Produkten ist eng mit der Weiterentwicklung der dazu implementierten Prozesse und digitalen Hilfsmittel verbunden. Diese sind als Werkzeuge zur Sicherung und kontinuierlichen Verbesserung der angestrebten Wertschöpfung anzusehen (Applikationen, Prozess-Bausteine, APIs usw.).

Das Rahmenwerk älterer Scrum Guides (vor 2011) wurde mit "User Stories" als Hilfsmittel zur Erhebung und Pflege von Anforderungen in agilen Projekten ergänzt. Es hat sich seitdem  zur Entwicklung von mehr und weniger komplexen Produkten bewährt, solange die damit verbundenen Geschäftsprozesse und das Netzwerk verbundener Produkte überschaubar ist.

Für komplexe Domänen mit zahlreichen eng verzahnten Geschäftsobjekten, gesetzlichen Vorgaben und daraus resultierenden Geschäftsprozessen  erwies sich diese Kombination später als eingeschränkt im Vergleich zu den früher eingesetzten Techniken für professionelles Anforderungsmanagement. Auf Grund der großen Popularität und Vorteile "schlanker" Vorgehensweisen, wollte aber kaum jemand zu den vormsld bewährten, aber schwergewichtigen Methoden und Werkzeugen zurückkehren, die Kreativität und den direkten Kontakt mit dem Kunden einschränken.

Die klassische Technik der "User Stories"

User Stories berücksichtigen ausgewählte Erkenntnisse der kognitiven Psychologie: Menschen ordnen ihre Welt in Akteuere, Beziehungen zwischen Objekten und deren Verhalten mit Hilfe von Abstraktion. Menschen können vor diesem Hintergrund Wünsche äußern, begründen und bewerten. Die in der ursprünglichen "User Story" Technik vorgeschlagene Struktur vernachlässigt wichtige Aspekte "echter Geschichten", weil  zu Beginn der "agilen Revolution" versucht wurde, Anforderungen auf kurze Überschriften auf Papier-Karten zu reduzieren, und darüber hinaus nur Abnahmekriterien (Rückseite der Karte), den Produkt-Code (Programmiersprache) und die persönliche Abstimmung zuzulassen. Der Beitrag "agile Missverständisse" erläutert, warum dieser Ansatz in der Praxis nur für sehr einfache und kurzlebige Produkte ausreicht.

Der inhaltliche Umfang von User Stories ist für die Verwendung in einem Management Rahmenwerk konzipiert, und soll vor der Umsetztung so weit ausgearbeitet sein, dass die damit verbundenen Aufgaben vom gesamten Team in ein bis zwei Tagen erledigt werden können. Der inhaltliche Umfang ist folglich nicht zur effizienten Beschreibung strukturierter Anforderungen gedacht.

User Stories werden vom "Product Owner" zur Bereitstellung eines (meist digitalen) Produktes in persönlicher Abstimmung mit fachlichen AnsprechpartnerInnen (EndbenutzerInnen, Power UserInnen, ExpertInnen) skizziert und dokumentiert. Dazu eigenen sich unterschiedliche Workshop-Techniken und Brainstormings, da wenig formale Vorgaben zu berücksichtigen sind. Erste User Stories werden zunächst in einem Vorbereitungs-Sprint gesammelt, und später laufend ergänzt, verfeinert und unter Umständen auch wieder verworfen. Der Product Owner kann während laufenden Sprints die Dokumentation von User Stories aus Workshops auch an andere Scrum Rollen delegieren, ohne jedoch die Verantwortung für die Korrektheit und Vollständigkeit abzugeben.

User Stories werden nach vereinbarten Regeln in der fachlichen Sprache des Kunden verfasst, die neben empfohlenen Satzmustern (Templates) diverse "Best Practices" aus dem Anforderungsmanagement berücksichtigen können, z.B. die Sicherstellung des einheitliche Gebrauches von Begriffen durch laufend erweiterte Glossare. Davon wird in der Praxis leider selten Gebrauch gemacht.

Typisches Satzmuster (Templates) für User Stories:
Als <Rolle> will ich <Ziel> [,so dass <Grund>]

Zur Begrenzung der Satzlänge wird dabei häufig auf das Konzept des verwendeten Geschäftsobjektes (Daten- und Schlüssel-Analyse) und des beteiligten IT-Systems (Produkt, Schnittstelle) verzichtet oder vergessen. Diese wichtigen Informationen werden z.B. in der Domänen-Analye, Anwendungsfall-Analyse, Schnittstellen-Analyse und Prozess-Analyse berücksichtigt. Es fehlt zudem die Möglichkeit, Abläufe oder fachliche Beziehungen zu fordern.

Das Akronym INVEST hilft beim verinnerlichen folgender Merkmale einer guten Story:

•  [Independent] Jede Story muss eindeutig identifizierbar sein, dazu wird überlicherweise eine Nummer vergeben. Darüber hinaus sollen möglichst wenig Abhängigkeiten zu anderen Stories bestehen, oder es sind entsprechende Hinweise vorzusehen.
• [Negotiable] die beschriebene Funktionalität soll keine unnötigen Vorgaben und Annahmen für die Umsetzung beinhalten, und so formuliert sein, das ausreichend Spielraum für eine effiziente Realisierung bleibt. Deshalb sollten Stories nicht auf konkretes GUI Design, konkretes Schnittstellendesign oder konkrete technische Datenstrukturen verweisen, außer diese sind durch nicht funktionale Anforderungen vorgeben.
• [Valuable] Der geschäftliche Wert der beschriebenen Funktionalität wird ggfs. erläutert, wenn er nicht unmittelbar ersichtlich ist. Hinweise auf den Wert der Möglichkeit, Geschäftsobjekte anlegen, ändern oder entfernen zu können (CRUD) sind in der Praxis z.B. überflüssig.
• [Estimateable] Die mit der geforderten Funktionalität verbundene Arbeit muss vor dem Hintergrund des gemeinsam erarbeiteten Wissens schätzbar sein.
• [Small] klein - vom Team in ein bis zwei Tagen umsetzbar.
• [Testable] Testbar - vor dem Hintergrund des gemeinsam erarbeiteten Wissens muss das Team für die mit einer Userstory verbundenen Akzeptanzkriterien ausreichend genaue Tests erstellen können (wenn möglich automatisiert!).

Es ist zudem gestattet, schriftlich "Akzeptanzkriterien" zu dokumentieren, jedoch ohne konkrete Testdaten und Testszenarien. Derartige Information soll wenn möglich nur mündlich und über wohl strukturierten Code ausgetauscht werden.

Was agiles Anforderungsmanagement auszeichnet:

• Agile Grundwerte der Organisation: vgl. agiles Manifest
• Die konsequente Vermeidung von Wegwerf-Artefakten und die Reduktion von Planungs-Overhead durch emprische Prozessverbesserung
• Die langfristige Zuordnung von Anforderungen und Domänen/Subdomänen zu Produkten ohne Overhead für kurzfristige Management Bedürfnisse

Transparentes Geschäftsprozess-Management und intelligente Prozesse

Die erfolgreiche Transformation des Kerngeschäfts in bewährte und neue Geschäftsbereiche im digitalen Zeitalter erfordert ausreichend genaue Kenntnis der bestehenden Geschäftsprozesse und der in der täglichen Praxis verwendeten Applikationen, Services und Endgeräte sowohl Ihrer eigenen Kunden, aber auch Ihrer Geschäftspartner und Ihrer Endkunden. Der Beitrag Agile Unternehmenskultur stellt einen ganzheitlichen Ansatz zur kontinuierlichen Weiterentwicklung ihres Kerngeschäfts und der damit verbundenen Prozesse und Produkte dar.

Aus Sicht einer prozessorientierten Unternehmenssteuerung ist die laufend aktualisierte Dokumentation bestehender und neu geplanter Geschäftsprozesse und daraus abgeleiteter Anforderungen für interne Abläufe und IT-Services unverzichtbar für die kontinuierliche Evaluation und Verbesserung von Prozesse auf allen Ebenen einer Organisation. Da die Lebensdauer eines "Projektes" sinnvollerweise begrenzt ist, muss diese Dokumentation Projekt- und Produkt- übergreifend angelegt werden, mindestens aber für die Lebensdauer eines geplanten Produktes. AI Techniken können darauf aufbauend z.B. natürlich sprachliche Schnittstellen erzeugen.

Die "agile Geschäftsentwicklung" und darauf abgestimmtes agiles Anforderungsmanagement unterstützt als eine von drei Säulen die Realisierung einer "Agilen Unternehmenskultur" im geschäftlichen und organisatorischen Bereich. Sie löst die überkommene Sichtweise ab, die Agenden der Geschäftsentwicklung als eigenständigen Unternehmensbereich zu sehen, losgelöst von der Bereitstellung und Verarbeitung der dazu erforderlichen Informationen.

Zu beachten: Erfolgreich realisierte intelligente Geschäftprozesse mit ausreichendem Grad an Automatisierung sind selbst als Produkte der geschäftlichen Entwicklung zu betrachten, die intern, sowie über entsprechende Vertriebskanäle auch von externen Partnern genutzt werden, um Endkunden damit realisierte Endprodukte bereit zu stellen.