Was zur Hölle ist denn "partielle Agilisierung"? Es ist der Ansatz, agile Arbeitsweisen isoliert in einer Wasserfall-Struktur zu etablieren. (guess what: doesn't work well)
Start-ups haben einen großen Vorteil. Sie entstehen mit agiler DNA. In jeder Zelle des Unternehmens ist die gemeinsame Vision und der agile Gedanke gespeichert. Was meine ich mit "agilen Gedanken"? Sich schnell am Markt und am Kunden auszurichten und die Erkenntnisse daraus in die Produktausgestaltung direkt und unmittelbar einfließen zu lassen. Ohne lange Approvalschleifen, ohne Board-Entscheidungen, ohne Vorstandsbeschlüsse.
Große Unternehmen haben erkannt, dass sie hier nachholen müssen. Die Start-ups sind nicht nur die vereinzelten kleinen Schnellboote, die man als großer Tanker nicht beachten muss, sondern es bildet sich eine ganze Armada von wendigen und flinken Unternehmungen die a) schneller ans Ziel kommen und b) die Kunden der großen Unternehmen gewinnen. Egal ob das eine bessere User Journey ist, eine bessere User Experience, ein schöneres Design oder ein besseres Verständnis mit den Daten zu agieren.
Nun gibt es aus meiner Erfahrung nach oftmals Versuche in den großen Unternehmen, diese Geschwindigkeit durch "partielle Agilisierung" zu übernehmen. Und genau dabei stoßen wir meiner Meinung nach auf (mind.) 2 große Problemfelder.
Problem Nr 1: Anforderungsanalyse im Wasserfall
Typischerweise werden anfangs die Anforderungen aufgenommen. Gerne sprechen wir dabei von den Business Analysten oder von Requirements Engineers (ggf. im pseudoagilen Kontext die POs). Diese Formulieren in einem (sehr sehr langen) Dokumenten (oder gerne dann auch in einzelnen Epics & Stories, die im Kern Kapitel eines sehr sehr langen Dokuments sind) die Erkenntnisse welche Anforderungen nun umgesetzt werden. Gerne verstreichen hier schon mal ein paar Wochen und Monate. Genau das ist die Zeit die kleine Start-ups nun haben, um schneller und kundenorientierter ihr Produkt zu gestalten.
Danach werden diese Anforderungen in die Entwicklungsabteilungen gekippt. Die Entwickler bauen nun in den Sprints Story für Story die Features. Gerne auch mit all den Scrum-typischen Zeremonien (planning, review, daily, retros...). Nach einer gewissen Zeit sind die Anforderungen nun soweit fertig und getestet und ... dann kommt das große Warten.
Problem Nr. 2: Releases
Die gebauten Features sind nun "Wartezustand" da es für die Plattform ABC nur eine endliche Anzahl von Release-Fenster pro Jahr gibt. Sagen wir mal in Q1 und Q4. Die Kunden da draußen denken aber nicht in Release-Zyklen. Und im Worst Case sind die Entwicklungen zu dem Zeitpunkt des Launches bereits veraltet oder überholt, weil da an der Seite ein Start-up etwas auf den Markt gebracht hat, dass genau den Schmerz des Kunden trifft und der Kunde ist weg und kommt nicht wieder.
Fazit: Agil bedeutet NICHT die Software-Entwicklung mit Scrum-Methoden (oder ähnlichen) umzusetzen. Agil bedeutet (unter anderem) die gesamte Ende-zu-Ende Produktentwicklung in kurzen, repetitiven Zyklen aufzubauen um schnelle Markt und Kundenergebnisse zu erhalten (aka Build-Measure-Learn).
Stay tuned ...there is more to come
Kommentare
Kommentar veröffentlichen