Wenn Sie eine Rugby-Weltmeisterschaft verfolgen, haben Sie vielleicht schon viele Sprints und Gedränge während des Spiels gesehen. In der Rugby-Sprache ist ein Gedränge "eine Methode zur Wiederaufnahme des Spiels, bei der die Spieler mit gesenktem Kopf eng zusammenrücken und versuchen, in Ballbesitz zu kommen" [ref. Wikipedia]. Für einen Rugby-Laien wie mich dauert es eine Weile, bis ich das verstehe, denn es erscheint mir nicht logisch. Warum nimmt man nicht einfach den Ball auf und rennt los?
Scrum scheint heutzutage mehr mit agiler Softwareentwicklung als mit Rugby zu tun zu haben. Es ist überall und sehr erfolgreich. In meinem Unternehmen (Kepner-Tregoe (KT)) hat unsere Produktentwicklungsgruppe kürzlich eine neue Produktreihe entwickelt Anwendung der agilen Methode. Fortschritt, nicht Perfektion ist der Schlüssel.
Fortschritt - bedeutet das "keine Zeit"?
Der Einsatz von agilem Vorgehen mag für viele Anwendungen ein perfekter Weg sein. Nach meiner Erfahrung mit bestimmten Teams und Branchen ist jedoch die Art und Weise, wie "Fortschritt" definiert wird, besorgniserregend, denn für mich ist "Fortschritt" das wichtigste Kriterium für die Entscheidungsfindung. Einer meiner Kunden sagte zu mir: "Der Markt verlangt von uns, dass wir schnell reagieren, und wir müssen dem Spiel voraus sein". Aber bedenken Sie auch die Kehrseite. Die Entwicklung einer Lösung für eine "gefundene Grundursache" wurde nicht umgesetzt, und die für die Ursachenanalyse Verantwortlichen erklärten mir: "Warum die Ursache finden? Sie wird sowieso nicht behoben". Und warum sollten sie die Ursache finden, wenn sie in den Sprints nicht priorisiert wird? Bedenklich ist, dass auch andere Aufgaben wie die normale Wartung vernachlässigt werden. Der Grund, warum die Teams angewiesen werden, die Aktivitäten in der Entwicklung auf Sprints zu konzentrieren, ist, dass sie einen Wettbewerbsvorteil erlangen und bei der Einführung neuer Funktionen als Erste auf dem Markt sein wollen.
Wenn man die Geschwindigkeit zum wichtigsten Kriterium macht, besteht die Tendenz zu behaupten, dass für andere wichtige Dinge "keine Zeit" bleibt. Wenn die Entwicklung unter Druck erfolgt, wie können Sie dann agilen Entwicklungen Vorrang vor der Ursachenanalyse und der Implementierung einer Lösung einräumen? Ganz zu schweigen von der Durchführung der regelmäßigen Wartung? Ich stimme zu, dass Perfektion bei der Entwicklung neuer Software nicht unbedingt notwendig ist, aber Perfektion ist notwendig, um eine Fehlerbehebung durchzuführen und die Ursache zu beseitigen. Wie oft scheitert eine neue Softwareeinführung, weil versteckte Probleme nicht untersucht und behoben wurden? Wir nennen diese lauernde KrokodileSie warten darauf, jeden Moment anzugreifen, vor allem dann, wenn man es am wenigsten erwartet.
Es geht nicht darum, "keine Zeit" zu haben - wir haben alle die gleiche Zeit. Es ist die Priorität, die wir bestimmten Dingen einräumen, die den Unterschied ausmacht.
Wer nimmt also den Ball auf?
Das sollten beide Parteien. Ich weiß, das scheint widersprüchlich. Bei einem Rugbyspiel kann nur eine Partei den Ball aufnehmen, aber beide sollten daran arbeiten, ihre Taktik zu verbessern, um zu gewinnen.
Die für die Ursachenanalyse Verantwortlichen sollten einen klaren und präzisen Beitrag zur Entwicklung leisten. Eine klare Beschreibung des Problems und eine logisch geprüfte Grundursache, die die Hypothese genau beschreibt, wie diese Ursache zu den Problemen führt. Diese Beschreibung sollte das Verständnis innerhalb des Entwicklungsteams erhöhen und eine klare Rechtfertigung für die zu ergreifenden Maßnahmen liefern. Mit dieser klaren Beschreibung kann das Entwicklungsteam besser einschätzen, was zur Behebung des Problems erforderlich ist. Anstatt z. B. zu sagen, dass es sich um einen Softwarefehler handelt, kann das Entwicklungsteam die Ursache genau bestimmen, z. B. "Bei der Geschwindigkeit xyz schaltet die Maschine ab, da die Grenzwerte zu streng festgelegt wurden".
Klare Beschreibungen, oder wie wir hier bei KT sagen, "getrennte und geklärte" Arbeiten, ermöglichen es den Teams auch, die richtigen Prioritäten zu setzen, indem sie sich mit diesen beschäftigen:
- Was sind die aktuellen Auswirkungen?: Wie wirkt sich das Problem auf den aktuellen Entwicklungszyklus aus? Wenn wir das Problem nicht beheben, wird unsere neue Entwicklung dann noch funktionieren?
- Was sind die Auswirkungen in der Zukunft: Wie lange können wir dieses Thema aufschieben, bis die Dinge furchtbar schief laufen?
- Zeitrahmen: Passt es in den aktuellen Sprintzyklus, wie lange brauchen wir?
Wenn beide Parteien ihre Köpfe zusammenstecken und die Qualität und Taktik des Spiels bei jedem Spiel verbessern, wird es viel besser anzusehen und viel motivierender sein, daran teilzunehmen.
