Management & Controlling
Schreibe einen Kommentar

Distributed Scrum – Chance und Herausforderung

Distributed Scrum
Werbung

Heute besucht uns Dominic Veit, seines Zeichens Geschäftsführer der youngculture (Deutschland) GmbH. Als spezialisierter Dienstleister in den Bereichen Nearshore Software Development, Solution Engineering, E-Commerce und Mobile Applications macht sich das Unternehmen seit geraumer Zeit durch seine innovativen Ideen einen Namen.

Herr Veit, moderne Software-Entwicklung wird immer anspruchsvoller. Als Dienstleister ist youngculture davon sicherlich noch deutlich stärker betroffen als ihre Kunden. Wie meistern Sie diese Herausforderung?

Es war schon länger abzusehen, dass die klassischen Methoden der Software-Entwicklung nicht mehr ausreichen, um den zahlreichen Anforderungen moderner Unternehmen und Projekte zu genügen. Im Gegenteil – das klassische Konzept mit umfangreicher Vorausplanung führt sich mittlerweile geradezu ad absurdum. Die immer kürzeren Lebenszyklen vieler Produkte führen dazu, dass die Planung bereits veraltet ist, bevor die Umsetzung überhaupt starten kann. Abzusehen war dieser Trend übrigens schon in den Neunzigern, allerdings brauchte es seine Zeit, bis neue Konzepte entwickelt und ausgereift waren. Mittlerweile ist es soweit, dass praktisch kein Weg mehr an modernen Techniken wie Scrum und Distributed Scrum vorbeigeht. Unternehmen, die dies weiter ignorieren, laufen Gefahr, schnell ins Abseits zu geraten.

Dann geht youngculture sicherlich mit gutem Beispiel voran und verwendet diese neuen Methoden ebenfalls?

Dominic Veit

© Dominic Veit

Das Konzept von Scrum geht über „nur eine neue Methode“ weit hinaus. Es wirft viele der klassischen Ideen einfach über Bord, und ist damit überaus erfolgreich. Dieser Paradigmenbruch bedeutet aber auch, dass man Scrum nicht einfach von oben herab anordnen kann. Vielmehr müssen die einzelnen Mitarbeiter erst einmal begreifen, welches Potenzial Scrum besitzt, und offen für Veränderung sein. Eines der wichtigsten Elemente in Scrum ist die ständige Kommunikation, die auch für uns eine der wichtigsten Säulen darstellt, auf denen das Konzept steht.

Gewöhnungsbedürftig sind für viele Führungskräfte das Rollenmodell und die Selbstorganisation von Scrum. Wird Scrum richtig umgesetzt, überzeugen die Erfolge allerdings auch harte Skeptiker mühelos. Übrigens entwickelt sich Scrum selbst auch weiter, beispielsweise ist das ursprüngliche Rollenmodell mittlerweile erweitert worden, um den Anforderungen der Praxis besser zu entsprechen.

Scrum erfordert also ein Umdenken bei Entwicklung und Management. Lohnt sich dieser Aufwand in jedem Fall?

Wir haben jetzt schon einige Jahre Erfahrung mit der Heranführung unserer Kunden an Scrum, und aus dieser Erfahrung heraus meinen wir: Es lohnt sich auf jeden Fall. Scrum konzentriert sich auf die kontinuierliche Verbesserung des Produktes, im Gegensatz zu älteren Konzepten, bei denen zunächst das Produkt vollumfänglich durchspezifiziert wurde. Moderne Software ist so komplex, dass dieser klassische Ansatz heute nicht mehr praktikabel ist.

Was dabei herauskommt, kennen viele Computernutzer aus eigener Erfahrung: Halbgare Software, die zwar unzählige Funktionen besitzt, aber auch ebenso viele Fehler aufweist. Der klassische Auslöser für dieses Phänomen ist Zeitmangel. Von vornherein ist für die klassische Planung zu wenig Zeit vorhanden, später verzögert sich die Entwicklung durch zusätzliche Feature Requests, die in der ursprünglichen Planung nicht vorhanden waren. Am Ende wird auf Drängen des Managements eine Version der Software freigegeben, die schlichtweg fehlerhaft ist – mit der Hoffnung, nun Zeit für die notwendigen zusätzlichen Arbeiten zu haben. Allerdings sieht die Praxis anders aus, das wissen sowohl die Nutzer der Software als auch die Entwickler. Mit Scrum lassen sich zum einen diese Reibungsverluste in der Entwicklung drastisch reduzieren, und zum anderen die Qualität der Software deutlich steigern.

Und wie funktioniert das Konzept von Scrum nun eigentlich?

Im Zentrum stehen zwei Erkenntnisse:

a) Entwicklungsprojekte, und dazu gehören mittlerweile nicht nur Softwareprojekte, denn Scrum wird mittlerweile auch in vielen anderen Feldern angewandt, sind in der Regel zu komplex, um sie komplett nach einem zuvor gefassten Plan umzusetzen.

b) Der Projekterfolg lässt sich nur durch ständig verfügbares Feedback sichern.

Daraus ergibt sich eine Strategie zur Strukturierung, die auf vier Prinzipien basiert: Zerlegung des Weges zum Ziel in kleine, gut verifizierbare Schritte, Transparenz durch tägliche und offene Dokumentation der Fortschritte, Überprüfung der bisher erreichten Ziele und entwickelten Funktionalitäten, und als letztes die fortlaufende Bewertung und Anpassung der Anforderungen an das Produkt.

Scrum ist also eher eine Art evolutionärer Prozess?

Scrum ist kein linearer Weg von A nach B sondern eher eine zyklische Weiterentwicklung, bei der das Produkt mit jeder Iteration näher an seine Idealform rückt. Diese Abkehr vom „alles und sofort“ ist einer der Stolpersteine für Einsteiger. Auch die Selbstorganisation kann zunächst irritieren, die Erfahrung zeigt jedoch, dass gerade dieser Freiraum das kreative Potenzial der Mitarbeiter erst vollständig erschließt. Vorgegeben ist jeweils nur das Ziel der Aufgabe, die Umsetzung des Weges dorthin liegt allein in der Verantwortung des Entwicklungsteams.

Natürlich agiert das Team dabei nicht im luftleeren Raum, daher gibt es die Rolle des Scrum Master, der kurz gesagt dafür sorgt, dass Scrum funktioniert. Er gehört selbst nicht zum Entwicklungsteam, sondern sorgt für die Einführung und Einhaltung der Scrum-Regeln. Team-Meetings werden von ihm moderiert, da er sich auch um die Beseitigung aller Störungen im Scrum-Prozess kümmert. Sein wichtigstes Handwerkzeug ist das sogenannte Impediment Backlog, in dem alle Hindernisse protokolliert werden, die das Entwicklungsteam stören. Diese Störungen können beispielsweise im Entwicklungsteam oder im Scrum-Team entstehen, aber auch von außen kommen, beispielsweise wenn während eines Sprints (das sind die eigentlichen Entwicklungsphasen, in denen Aufgaben implementiert werden) Feature Requests gestellt werden.

Gewöhnungsbedürftig aber wichtig ist dabei, dass der Scrum Leader zwar dem Entwicklungsteam gegenüber als Führungskraft auftritt, jedoch kein Vorgesetzter ist. Er wird als Servant Leader charakterisiert, der vom Team gewählt und akzeptiert wird, da er sich um dessen Bedürfnisse kümmert. Gegenüber dem Team ist er weder für die Erteilung konkreter Arbeitsanweisungen, noch für disziplinarische Maßnahmen oder Beurteilungen zuständig.

Neben dem Entwicklungsteam haben Sie gerade noch ein Scrum-Team erwähnt. Was hat es damit auf sich?

Im Scrum-Team werden die Rollen Entwicklungsteam, Scrum Master und Product Owner zusammengefasst. Die ersten beiden haben wir schon angesprochen, der Product Owner sorgt für die strategische Seite der Produktentwicklung. Von ihm wird zu Beginn des Prozesses eine klare Vision des gewünschten Produktes entwickelt und vermittelt. Daraus ergeben sich die Produkteigenschaften, die von ihm entsprechend ihrer Wichtigkeit für den Produkterfolg priorisiert werden. Am Ende jeder Sprintphase entscheidet er, ob die vom Entwicklungsteam gelieferten Resultate akzeptabel sind oder nicht. Damit ist er ein wichtiges Bindeglied, auf der einen Seite kommuniziert er die Vorstellungen und Wünsche des Kunden in Richtung Entwicklung, auf der anderen Seite präsentiert er die gefundenen Lösungen dem Auftraggeber und sorgt für reges Feedback.

Und wie wird aus Scrum nun Distributed Scrum? Mit Telefon und Videokonferenztechnik lässt sich doch das Team jederzeit zusammenbringen?

Die Abgrenzung ist tatsächlich nicht vollständig scharf, da innerhalb des Teams aber die ständige Kommunikation eines der wichtigsten Mittel zum Wissenserhalt und langfristiger Wissensbindung ist, ist räumliche Nähe ein starkes Kriterium. Eine etwas flapsige Definition dazu lautet, dass ein Team nur dann ein Team ist, wenn es die gleiche Kaffeemaschine nutzt. Das soll nun natürlich nicht heißen, dass Teams durch Abschaffen von Kaffeemaschinen gebildet werden können. (lacht)

Das bedeutet aber auch, dass viele Unternehmen bereits Erfahrung mit verteilten Teams gesammelt haben, denn bereits unterschiedliche Stockwerke im gleichen Gebäude sorgen dafür, dass vermehrt auf Telekommunikationsmittel zurückgegriffen wird, statt den persönlichen Kontakt zu suchen. Das lässt sich ebenso auf verschiedene Standorte in einer Stadt oder einem Land übertragen.

Die Probleme für den Scrum-Prozess, die sich daraus ergeben, sind meist nicht auf den ersten Blick ersichtlich, sondern zeigen sich erst langfristig. Dann ist es aber häufig schon zu spät, um effektive Gegenmaßnahmen zu starten. Unsere lange Erfahrung auf diesem Gebiet gibt uns hier einen erheblichen Wissensvorsprung, den wir gerne zum beiderseitigen Nutzen in Kundenprojekten einsetzen.

Und wie sieht das konkret aus? Wie gleichen Sie die räumliche Entfernung aus?

Scrum selbst legt schon großes Gewicht auf ständige Kommunikation, und wir haben unsere Entwicklungszentren strategisch so platziert, dass wir den optimalen Mix aus Entfernung, Kosten und Leistungsfähigkeit erreichen. Unsere Entwicklerteams in Serbien und Rumänien sind mit dem Flugzeug aus dem DACH-Raum jeden Tag mit überschaubarem Zeitaufwand zu erreichen und auch vor Ort sehr gut an die Infrastruktur angebunden.

Wir veranstalten regelmäßige Meetings und Workshops, zu denen nicht nur alle Beteiligten von unserer Seite erscheinen, sondern auch der Kunde eingeladen wird. Unsere Erfahrung zeigt, dass persönlicher Kontakt zu einer wesentlich besseren Integration führt, Vorbehalte und Animositäten praktisch von alleine verschwinden und eine deutlich stärkere Vertrauensbasis entsteht.

Wir unterstreichen dies zusätzlich durch unsere Philosophie langfristiger partnerschaftlicher Kundenbeziehungen, und auch unsere Entwickler sind festangestellte Experten, die dem Kunden jeweils dediziert zugeteilt werden. Damit schaffen wir ein solides Fundament für die Entwicklung ausgereifter Technologien, das den beständig wachsenden Anforderungen nachhaltig gewachsen ist.

Ist Scrum also der Stein der Weisen?

Scrum ist sicherlich noch nicht am Ende seiner Entwicklung angelangt, und selbstverständlich ist es kein Allheilmittel – wir halten es jedoch für die mit Abstand vielversprechendste Methode, auf schnelllebige Märkte sinnvoll zu reagieren. Der Erfolg unserer Kunden bestärkt uns in dieser Einschätzung noch. Die grundlegende Voraussetzung für die erfolgreiche Einführung ist allerdings auch der Mut, sich den Grundlagen und Methoden von Scrum vollumfänglich zu öffnen. Nur wer Scrum richtig umsetzt, kann daraus auch optimalen Nutzen ziehen. Mit uns als Partner sind die besten Voraussetzungen dafür geschaffen, denn mit unserer Erfahrung können auftretende Probleme frühzeitig erkannt und behoben werden.

Herr Veit, wir danken Ihnen für diesen interessanten Exkurs in die Welt moderner Software-Entwicklung.

Foto: Eskemar / shutterstock.com

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Wenn Du wissen möchtest, welche Daten wir beim Hinterlassen eines Kommentars speichern, schau bitte in unsere Datenschutzerklärung.