Wie wo was Nearshore - Teil 4
Neulich hatte ich die Frage gestellt, welche konkrete Erfahrungen Sie in Ihren Projekten mit Entwicklungsmodellen gemacht haben. Ich spreche dieses Thema auch in den zahlreichen Gesprächen mit Kunden und Kollegen an und finde die Antworten, die in der Praxis gefunden werden, sehr spannend.
Hier und heute möchte ich ein solches Praxisbeispiel anführen und daran verdeutlichen, daß es auf die konkrete Situation ankommt und nicht auf die Erfüllung irgendwelcher dogmatischer Theorien.
Zunächst also die Ausgangslage: Ein mittelständischer Hersteller von Standard-Software sucht einen Nearshore-Partner, um neue Module und Produkte entwickeln zu lassen. Im aktuellen Geschäftsmodell des Kunden sind Flexibiliät und Geschwindigkeit von größter Bedeutung, um auf häufig veränderte Einsatz-Szenarien und Anforderungen reagieren zu können. Der klassische Wasserfall-Ansatz, egal wie dynamisch ausgelegt und mit welch schlauen Change Management Prozeduren gekrönt, würde zu viel Zeit und Aufwand für Dokumentation und Spezifikation erfordern, obwohl Anforderungen mehrheitlich beschreibbar und folglich spezifizierbar wären.
Gemeinsam mit dem Nearshore-Partner Infobest wurde daher ein agiles Modell entwickelt, das einige wesentliche Elemente von Scrum enthält wie z.B. eine zentrale Backlog-Liste; Priorisierung der Features in der Backlog-Liste durch den Kunden; 2-wöchige Sprints; Einschätzung durch den Lieferanten, welche Punkte aus der Backlog-Liste in den nächsten Sprint passen (und damit Entscheidung darüber, welcher Inhalt mit einem gegebenen Budget umgesetzt wird, ein ganz zentrales Scrum-Theorem). Soweit so gut die Theorie. Allerdings wurde z.B. darauf verzichtet, tägliche Scrum-Meetings zu sklavisch festgelegten Uhrzeiten anzusetzen, geschweige denn den Kunden darin einzubeziehen. Die Entwickler und Tester arbeiten zu teilweise sehr unterschiedlichen Tages- (und Nacht)zeiten, so daß solche Meetings keinen Sinn ergeben. Stattdessen treffen sich alle oder einige der Projektmitglieder mehrmals täglich zu Abstimmungsgesprächen und der Projektleiter stellt sicher, daß er den Überblick über die Aktivitäten behält. Unnötig zu erwähnen, daß seine Arbeitszeiten die “umspannendsten” sind. Ebenfalls von der Scrum-Theorie abweichend beinhaltet nicht jede Lieferung am Ende eines Sprints zwangsweise eine vollständig lauffähige neue Version des gesamten Produktes. Vielmehr wurde genau festgelegt, welche Art der Qualitätssicherung innerhalb eines Sprints von Infobest zu leisten ist und in welcher Form der Kunde am Ende eines Sprints seine eigene Abnahme für den jeweiligen Sprint durchführt. So kann es durchaus passieren, daß ein bestimmter Teil vollständig und QA-gesichert geliefert wird, das Produkt insgesamt jedoch auch Elemente enthält, die aufgrund von Seiteneffekten oder Sprint-übergreifenden Themen (ein typisches Beispiel wäre die Überarbeitung des UI-Layouts oder Reports) nicht vollständig erledigt sind. Der Kunde stimmt daher viel mehr mit dem Lieferanten ab, welche der Sprints eine komplette neue Version darstellen sollen und welche Sprints lediglich die neu entwickelten Funktionen des individuellen Sprints vollständig enthalten müssen.
Nicht orthodox? Mag sein und sicher werden die Verfechter der Scrum-Philosophie an dieser Stelle die Bleistifte spitzen, um ihre Argumente darzulegen, warum das alles so ganz furchtbar ist. Aber das Schöne an diesem “eingedampften” Scrum-Modell ist, daß es genau für dieses Projekt-Szenario wunderbar funktioniert.
November 19th, 2009 at 21:20
Danke für den Einblick in eine “Success Story” für den Einsatz von agilen Praktiken beim Nearshoring!
Wichtig ist, dass es funktioniert. Das wird von vielen Vordenkern der agilen Methoden auch immer wieder bestätigt: Ziel ist es, Werte zu schaffen.
Wenn hierbei nicht immer alles nach Lehrbuch gemacht wird und es klappt trotzdem, dann ist dies ok.
Andererseits sollte man selbst auch immer sehr kritisch sein, ob es nicht noch Möglichkeiten gibt sich bzw. das Team und damit das Projekt weiter zu verbessern.
November 20th, 2009 at 08:32
<p><p>Danke für Ihren Beitrag. Genau darum geht es: daß es funktioniert. Modelle wie Scrum wurden ja letztlich von Menschen aufgrund der Erfahrung entwickelt, daß eine gängige Theorie nicht (mehr) richtig funktioniert und deshalb verbessert werden muß. In dem oben beschriebenen Szenario hat das Vorgehensmodell auch nicht von Anfang an auf dem Tisch gelegen. Lustigerweise war es tatsächlich so, daß wir uns zunächst bewußt gegen Scrum entschieden haben, weil wir die täglichen Meetings für wenig realistisch und hilfreich erachtet haben und die Lieferung eines kompletten und uneingeschränkt lauffähigen Gesamtproduktes alle 2 Wochen den Aufwand immens erhöht und die Geschwindigkeit unseres Erachtens nach stark eingeschränkt hätte. Erst im Verlaufe des Projektes sind wir langsam auf den Gedanken “gestoßen”, daß man so etwas wie Scrum auch interpretieren und verändern kann, wenn es denn Sinn macht. Mal sehen, wo wir in 6 oder 12 Monaten stehen…