Einige Scrum Erfahrungen
Tags: scrum, softwareentwicklung
Kategorie Software Engineering | 8 Kommentare »
Irgendwann im letzten Jahr hatte ich meine offizielle Zertifizierung als Scrum Master gemacht, doch mit Scrum und anderen agilen Methoden der Software Entwicklung beschäftige ich mich schon seit fast 10 Jahren. So habe ich z.B. in meiner Diplomarbeit Scrum auf emergentes Verhalten im Sinne der Chaostheorie untersucht. In der beruflichen Praxis setze ich Scrum seit ca. 2009 ein, da man ja erst mal ein paar Jahre braucht, um in eine Position zu kommen, in der man die Entwicklungsmethode vorgeben kann ;-)
Verwundert bin ich immer wieder, wie schwer es erfahrenen Projekt- und Entwicklungsleitern (15 Jahre und mehr Berufserfahrung) fällt, Scrum richtig umzusetzen. Mit richtig umsetzen meine ich nicht das bereits seit Jahren praktizierte Vorgehen einfach Scrum zu nennen, weil es gerade hipp ist, sondern sich wirklich auf das geänderte Vorgehen einzulassen. Es werden dann die mehrmonatigen Entwicklungszyklen gerne Sprints genannt, aber an deren Ende steht dann natürlich keine auslieferbare Software, denn die wird ja erst nach 2 Jahren am Projektende erwartet. Das hat natürlich alles wenig mit Scrum zu tun.
Ein Problem könnte der wahrgenommene Machtverlust des Projekt- und Entwicklungsleiters sein. Während es früher an ihm keinen Weg vorbei gab, übernimmt jetzt das Entwicklungsteam selbst die Steuerung. Die Aufgabe des Entwicklungsleiters beschränkt sich dann auf die Schnittstelle zum Produktmanager, um mit diesem die Anforderungen zu erheben und in umsetzbare Teilstücke zu untergliedern und dem Produktmanager den gröbsten Unsinn auszureden. Neben dem professionellen Management dieser Schnittstelle sehe ich persönlich die Hauptaufgabe des Projekt- und Entwicklungsleiters darin, den Teammitgliedern ein ungestörtes Arbeiten zu ermöglichen. So sollten Teammitglieder möglichst von allen Reportingaufgaben befreit und aus internen politischen Diskussionen so weit als möglich rausgehalten werden. Am Ende des Tages schreiben die meisten Softwareentwickler lieber gute Software mit modernen Technologien, als sich an Kämpfen von Alphatierchen zu beteiligen oder sich mit uneinsichtigen Produktmanagern/Kunden rumzustreiten.
Auf der anderen Seite ist die Akzeptanz von agilen Entwicklungsmethoden wie Scrum bei aktuellen Hochschulabsolventen sehr hoch. Für viele ist es selbstverständlich, agil zu entwickeln und sich auf die Unsicherheiten wie ständig wechselnde Anforderungen einzulassen. Es besteht also Hoffnung für die Zukunft, denn irgendwann sind die altgedienten Entwicklungsleiter von heute auf irgendwelche reinen Verwaltungsposten hochbefördert und auf den Ebenen darunter kann dann wieder in Ruhe Software entwickelt werden :-)
Ich habe bis jetzt viel zu wenig gescrumt, kann aber soweit folgendes sagen. Ich sehe die Scrum-Methodik eher als ein Prokrustesbett für die Software-Entwicklung. Beim Trade-off zwischen der Qualität und der Planeinhaltung, gewinnt beim Scrum eindeutig das Zweite. Mir ist aber vollkommen klar, dass die Strategie „lieber ein gutes Produkt heute, als ein perfektes morgen“ je nach Branche/Produkt/Zeit und Marktlage vollkommen legitim sein kann. Nur „meins“ ist es nicht. Daher mein Problem mit dem Scrum.
Hallo Christian,
da müssen wir erst einmal definieren, was Qualität in der Softwareentwicklung bedeutet! Da gibt es ganze Bücher drüber :-) Allgemeine Auffassung ist aber, dass es nicht nur „funktioniert ohne technische Fehler“ und „setzt ursprüngliche Spezifikation vollständig um“, sondern dass gute Software auch „setzt aktuelle Bedürfnisse des Nutzers um“ ist. Gerade dieser letzte Punkt ist mit klassischen Vorgehen kaum schaffbar, da du zu Projektbeginn nicht absehen kannst, was der Nutzer in 12-24 Monaten wirklich braucht. In Scrum hingegen hast du mit jedem Sprint die Möglichkeit, die aktuell drückensten Wünsche des Nutzers umzusetzen.
Persönlich glaube ich, dass der größte Vorteil bei Scrum die extrem kurzen Entwicklungszyklen sind, an deren Ende jeweils ein benutzbares Produkt stehen muss! Das zwingt dich von Anfang an die oft von verschiedenen Teams entwickelten Komponenten (etwa Client und Server) zu integrieren und nicht erst einige Monate vor finaler Auslieferung. Durch die ständig notwendigen Tests (wir wollen ja schließlich nicht ungetestet ausliefern) ist man zudem gezwungen, sich frühzeitig um Testautomatisierung zu kümmern. Sowas wird in klassischen Projekten gerne auf die lange Bank geschoben und führt häufig dazu, dass Testautomatisierung von Integrationstest erst nach dem ersten Release umgesetzt wird.
Hallo Sebastian,
tja was soll ich sagen, vieles was du schreibst empfinde ich genauso.
Viele Entscheider wissen doch noch gar nicht was Scrum ist.
Da erstellt, pflegt und priorisiert dem Scrum Master das Backlog, der eigentliche PO lässt dann vom SM auch noch die User Stories schreiben und dem Team erklären. Das Produkt Management schreibt sowieso nur noch den SM an. Der soll aber bitte auch nohc ganz nebenbei zu 50% entwickeln. Co-Located Teams haben wir ja auch, wenn man mal Europa als Location nimmt…
Wenn man so einem PO dann vorschlägt das Ganze zu ändern und aus dem SM einen PO zu machen, und den alten PO als Kunden-Proxy, hat der eigentliche PO Angst dass er dann wieder Entwickeln müsste… usw…
Wie du also siehst, du bist nicht alleine :)
Grüße aus der Kleinstadt an die Hauptstadt,
Streng geheim :)
Hm, ich glaube da muss man ganz viele Fallunterscheidungen machen, wie die Software-Entwicklung aussehen kann. Ich habe eher von einem Fall gesprochen, wo ein komplett neues Back-end entwickelt wird. Dabei habe ich unter Qualität eher „architekturale“ Eigenschaften verstanden: Eleganz, Wartbarkeit, Erweiterbarkeit, usw.
Wenn einmal etwas nicht nach Plan läuft, will man doch beim Scrum nicht gleich das Sprintziel verfehlen. Also wird versucht das Problem irgendwie mit Krücken im selben Sprint zurecht zu biegen, obwohl es idealerweise eine Planänderung für einen großen Umbau geben müsste. Und genau das passt irgendwie nicht so ganz in das Scrum-Konzept.
Aber, wie gesagt, vielleicht habe ich bis jetzt vom Scrum zu wenig gesehen.
@Streng geheim: I feel your pain :-) Aber ich glaube genau diese weichen Faktoren, Angst vor Verlust von Einfluss, ist das eigentliche Problem.
@Christian: Aha, also wenn ihr erst im Sprint merkt, dass ihr eine nicht umsetzbare Story habt, dann läuft eindeutig was falsch!
Bei mir im Team machen wir auch massive Umbauarbeiten an der Architektur unserer Serverkomponente. Deshalb gibt es erst mal ein „Feature“, genau die Umstellung zu evaluieren und zu untersuchen, was es wirklich bedeutet. Dieses Feature, wir nennen es auch Spike, besteht natürlich auch aus mehreren User Stories, etwa:
– Überblick über die architektonische Änderung verschaffen
– Recherchieren, wie nach heutiger SW Technologie die Ideallösung aussehen würde
– kleine Prototyp umsetzen
– Erstellung und Beschreibung aller User Stories, die bei einer tatsächlichen Umstellung auftreten würden
Am Ende haben wir dann ein neues Feature „Umstellung Komponente XYZ“ mit einer hoffentlich vollständigen Liste von User Stories. Dann kann der Produktmanager immer noch entscheiden, ob er diese Umstellung jetzt will, denn jetzt weiß er ja auch ungefähr, ob es eine Sache von 1-2 Mannmonaten ist oder ob das gesamte Team damit das nächste halbe Jahr beschäftigt ist. Wenn es dann immer noch eine Entscheidung für die Umstellung gibt, wissen wir zumindest schon mal, was ungefähr auf uns an Arbeit wartet und wo die größten Knackpunkte bestehen :-)
Da es die Rollenbezeichnungen „Entwicklungsleiter“ und „Produktmanager“ in der Scrum-Denke nicht mehr gibt haben die Inhaber dieser Titel wahrscheinlich schon aus reinem Selbsterhaltungstrieb heraus Probleme sich in dieser Welt zurechtzufinden?
So wie ich das aus deinem Beitrag rauslese gibt es diese Stellenbezeichnungen aber bei euch durchaus noch?
Was ich mich immer schon gefragt haben, und vielleicht gibts durchaus gute Gründe es nicht zu machen – Warum macht man die erfahrenen „Produktmanager“ aus der alten Welt nicht zu Scrum „Senior Product Ownern“ die dann ein Team von Scrum POs fachlich führen?
Ganz so einfach ist es ja auch wieder nicht. Bei uns, Standard Software, ist eigentlich das Produktmanagement Kunde der Entwicklung. Meiner Meinung nach wäre es sinnvoll das die ehemaligen Entwicklungsleiter als Senior Product Owner zu bezeichnen und entsprechend einzuplanen. Diese können dann ja auch mehrere POs führen.
Naja, mal schauen was das Thema und die Umwandlung ncoh so bringt :)