Wenn Sie die Rugby-Weltmeisterschaft verfolgen, haben Sie sicher viele Sprints und Scrums während des Spiels gesehen. Ein Scrum (Gedränge) ist in der Rugby-Sprache „eine Methode zur Spielfortsetzung, bei der sich die Spieler mit gesenkten Köpfen eng zusammenschließen und versuchen, in Ballbesitz zu gelangen“ [Ref. Wikipedia]. Ein Rugby-Laien wie ich braucht Zeit, um das zu verstehen, da es nicht logisch erscheint. Warum nicht einfach den Ball aufheben und loslaufen!
Heutzutage scheint Scrum eher mit der agilen Softwareentwicklung als mit Rugby verbunden zu sein. Es ist allgegenwärtig und sehr erfolgreich. Innerhalb meines Unternehmens (Kepner-Tregoe (KT)) hat unsere Produktentwicklungsgruppe vor Kurzem eine neue Produktpalette unter Anwendung der agilen Methode entwickelt. Fortschritt, nicht Perfektion, ist der Schlüssel.
Fortschritt – bedeutet das „keine Zeit“?
Der Einsatz von Agile mag für viele Anwendungen ein perfekter Weg sein. Meiner Erfahrung nach ist es jedoch bei bestimmten Teams und Branchen besorgniserregend, wie „Fortschritt“ definiert wird, da für mich „Fortschritt“ das wichtigste Kriterium für die Entscheidungsfindung ist. Einer meiner Kunden sagte zu mir: „Der Markt verlangt von uns, schnell zu reagieren, und wir müssen der Konkurrenz voraus sein“. Aber bedenken Sie die Kehrseite. Die Entwicklung einer Lösung für eine „gefundene Ursache“ wurde nicht umgesetzt, und die für die Ursachenanalyse Verantwortlichen erklärten mir: „Warum die Ursache finden? Es wird sowieso nicht behoben“. Und warum sollten sie die Ursache finden, wenn sie in den Sprints nicht priorisiert wird? Beunruhigend ist, dass auch andere Aufgaben wie die normale Wartung vernachlässigt werden. Der Grund, warum Teams angewiesen werden, ihre Entwicklungsaktivitäten auf Sprints zu fokussieren, liegt darin, sich einen Wettbewerbsvorteil zu verschaffen und als Erster neue Funktionen auf den Markt zu bringen.
Indem Geschwindigkeit zum wichtigsten Kriterium gemacht wird, besteht die Tendenz zu behaupten, dass „keine Zeit“ für andere wichtige Dinge bleibe. Wenn die Entwicklung unter Druck stattfindet, wie priorisieren Sie dann agile Entwicklungen gegenüber der Ursachenanalyse und der Implementierung einer Lösung? Ganz zu schweigen von der Erledigung regulärer Wartungsarbeiten? Ich stimme zu, dass Perfektion bei der Entwicklung neuer Softwarekomponenten vielleicht nicht erforderlich ist; Perfektion ist jedoch erforderlich, um eine Lösung zur Beseitigung der Ursache zu implementieren. Wie oft scheitert eine neue Softwareeinführung, weil verborgene Probleme nicht untersucht und korrigiert wurden? Wir nennen diese lauernde Krokodile, die jeden Moment zum Angriff bereit sind, besonders wenn man es am wenigsten erwartet.
Es ist kein Problem von „keine Zeit“ – wir alle haben die gleiche Zeit. Es ist die Priorität, die wir bestimmten Dingen einräumen, die den Unterschied macht.
Wer nimmt also den Ball auf?
Beide Parteien sollten es tun. Ich weiß, das scheint widersprüchlich. In einem Rugbyspiel kann nur eine Partei den Ball aufnehmen, aber beide sollten daran arbeiten, ihre Taktik zu verbessern, um als Sieger hervorzugehen.
Die für die Ursachenanalyse Verantwortlichen sollten der Entwicklung klare und prägnante Informationen liefern. Eine klare Problembeschreibung und eine logisch geprüfte Ursache, die die Hypothese präzise beschreibt und aufzeigt, wie diese Ursache Probleme verursacht. Diese Beschreibung sollte das Verständnis innerhalb des Entwicklungsteams erhöhen, um eine klare Rechtfertigung für die zu ergreifenden Maßnahmen zu liefern. Mit dieser klaren Beschreibung kann das Entwicklungsteam genauer einschätzen, was zur Behebung des Problems erforderlich ist. Anstatt beispielsweise an „es ist ein Softwarefehler“ zu arbeiten, arbeiten sie an einer punktgenauen Ursache, z. B. „beim Betrieb mit der Geschwindigkeit xyz tritt eine Zeitüberschreitung der Maschine auf, da die Grenzwerte zu streng gesetzt wurden“.
Klare Beschreibungen, oder wie wir hier bei KT sagen, „getrennte und geklärte“ Arbeitspakete, ermöglichen es den Teams auch, die richtigen Prioritäten zu setzen, indem sie Folgendes untersuchen:
– Was ist die aktuelle Auswirkung?: Wie beeinflusst es den aktuellen Entwicklungszyklus? Wenn wir es nicht beheben, wird unsere Neuentwicklung dann trotzdem funktionieren?
– Was ist die zukünftige Auswirkung: Wie lange können wir dieses Problem aufschieben, bis die Dinge schrecklich schiefgehen?
– Zeitrahmen: Passt es in den aktuellen Sprintzyklus, wie viel Zeit benötigen wir?
Wenn beide Parteien ihre Köpfe zusammenstecken und die Qualität sowie die Taktik des Spiels bei jedem Spielzug verbessern, wird es weitaus besser anzusehen und weitaus motivierender sein, daran beteiligt zu sein.
