In vielen Unternehmen und Behörden reift die Erkenntnis, dass plangetriebene Softwareentwicklung mit umfangreichen Dokumentationsvorgaben, strikt abgegrenzten Verantwortungsbereichen, starren Schnittstellen und festen Releasezyklen kaum geeignet ist, aktuellen Anforderungen an mobile Apps, Cloud Services und benutzerzentrierte Webanwendungen zu genügen. Solche Anwendungen sind von geringen funktionalen Deltas zwischen den einzelnen Releases geprägt, wodurch die Kunden schnell Ergebnisse sehen und bereits in frühen Stadien Einfluss auf die Entwicklung nehmen können. Als Ergebnis entstehen Produkte, die den Anforderungen deutlich besser gerecht werden. Die entsprechend kurzen Releasezyklen stellen jedoch viele Entwicklungsmannschaften mit den etablierten Methoden vor erhebliche Probleme.
In einigen Fällen führt diese Situation zu Verunsicherung und dem Versuch, auf agile Entwicklungsprozesse umzustellen. Dabei ist es häufig nicht offensichtlich, dass neue Prozesse in der Regel andere als die bestehenden Strukturen benötigen. Oft ist eine deutlich engere und häufigere Abstimmung zwischen Fachbereich und Entwicklung erforderlich, da das klassische, funktional vollständige Pflichtenheft in agilen Prozessen kaum Nutzen stiftet. Ist ein solcher Versuch gescheitert, wird Agilität mitunter zum roten Tuch, da sie "nicht zum Unternehmen passt".
Agilität bedeutet nicht, dass plötzlich alle Gremien abgeschafft, die Dokumentation geschreddert und jegliche Releaseplanung eingestellt werden sollte. Vielmehr ist es erforderlich, aus den verschiedenen Prozessmodellen die jeweils zum Unternehmen passenden Elemente auszuwählen, ggf. anzupassen und auf geeignete Weise zu einem pragmatischen Prozessmodell zu kombinieren. Das dabei entstehende Prozessgerüst ist häufig sowohl von plangetriebenen als auch von agilen Elementen geprägt. Beispielsweise werden häufig weiterhin inhaltliche Meilensteinpläne erstellt, während sich die Entwicklungszyklen verkürzen und kleinere Funktionsumfänge in die Releases einfließen. Dies wiederum erfordert meist einen hohen Automatisierungsgrad der Qualitätssicherung, insbesondere bei den Integrationstests. Von hier ist es dann oft nur noch ein kleiner Schritt zu DevOps und Continuous Integration. Für diesen pragmatischen Ansatz der Prozessgestaltung hat Volker Gruhn 2014 die sehr treffende Bezeichnung "gezähmte Agilität" geprägt.
Mein Ziel bei der Analyse, Gestaltung und Einführung Ihrer Entwicklungsprozesse ist es, möglichst leichtgewichtige und zielorientierte Strukturen und Abläufe zu schaffen, die Ihr Vorhaben optimal unterstützen, keine künstlichen Barrieren schaffen und trotzdem den Anforderungen an Dokumentationspflichten und Compliance gerecht werden.