Kategorien
Was bedeutet Scrum für Entwicklungsteams?
Scrum ist momentan in aller Munde wenn es darum geht, Projekte agil zu entwickeln. So auch bei uns: Wir entwickeln in der Firma die Projekte seit einiger Zeit agil und seit meiner Zertifizierung zum Scrum Master (CSM) weiten wir den Einsatz von Scrum stark aus.
Dabei ist Scrum zunächst „nur“ ein teambasierendes Framework, das auf nur wenigen Rollen, Regeln und Time-Boxen basiert. Ich werde in diesem Beitrag nicht umfänglich auf das gesamte Framework eingehen, das kann man hier gut nachlesen. Ich werde mich vorwiegend auf die Bedeutung für das Entwicklungsteam beschränken. Bei Bedarf bzw. Nachfrage stelle ich aber auch gerne einmal das gesamte Framework in einem gesonderten Beitrag vor.
Ziel bei einer Projektabwicklung mit Scrum ist es, eine deutlich höhere Produktivität und Kundenzufriedenheit zu garantieren, weil durch den ständigen Dialog mit dem Interessenvertreter von Kundenseite (Product Owner) und den kurzen Iterationen (Sprints mit garantierter Auslieferung von lauffähigen Produktinkrementen) eine höchste Übereinstimmung zwischen Entwicklungsauftrag und Ergebnis gewährleistet wird.
Nimmt man das gesamte Scrum Team, so finden sich dort drei Rollen wieder:
- Der Product Owner als Vertreter des Kunden, der vorwiegend die Anforderungen und Produkteigenschaften einbringt und am wirtschaftlichen Erfolg des Projekts gemessen wird.
- Der Scrum Master, der als „Kümmerer“ zwischen Product Owner und Entwicklungsteam vermittelt und dafür sorgt, dass der Scrum Prozess eingehalten wird. Sein Erfolg wird an der Produktivität des Entwicklungsteams gemessen.
- Und schließlich das Entwicklungsteam, dessen Aufgabe es ist, am Ende eines Sprints, der zwei oder vier Wochen dauert, ein lauffähiges Produktinkrement zu liefern und daran auch gemessen wird. Am Ende des Produktionszyklus soll dann natürlich auch das fertige Produkt ausgeliefert sein.
Bei Scrum managt und organisiert sich das Entwicklungsteam selbst. Das liegt daran, dass die Verantwortung für die Fertigstellung des Inkrements oder Produkts in der Hand des Entwicklungsteams selbst liegt. Die Mitglieder des Entwicklungsteams entscheiden idealerweise selbst, welche Tasks sie abarbeiten. Der Scrum Master leitet nur zu dieser Selbstorganisation an, er ist nicht der Projektmanager im herkömmlichen Verständnis – den gibt es bei Scrum nicht. Weiterhin ist das Entwicklungsteam interdisziplinär besetzt und umfasst das gesamte Wissen und die Fähigkeiten, die für das Projekt nötig sind. Es finden sich also nicht nur Entwickler sondern ebenso auch Architekten, Tester etc. im Team. Ein Entwicklungsteam umfasst zwischen fünf und neun Mitgliedern, idealerweise sieben.
Damit verbunden ist auch eine hohe Transparenz und Ehrlichkeit des Entwicklungsteams zum Product Owner, zum Scrum Master und auch untereinander. Das Entwicklungsteam muss ein wirkliches Team werden, Ablehnung von Code Reviews oder der Rückzug ins stille Kämmerlein sind No-Gos mit Scrum. Probleme bei der Entwicklung müssen an Scrum Master sowie Product Owner in aller Offenheit weitergegeben werden. Im Gegenzug dazu erhält das Entwicklungsteam die uneingeschränkte Unterstützung der Organisation und des Kunden. Das bezieht sich auch auf die eingesetzten Techniken: Tests, Continuous Integration, Code Reviews und Versionskontrolle sind Pflicht, selbst wenn sie vom Scrum Framework nicht explizit genannt werden.
Generell gesprochen ist Scrum ein Framework, das vor allem auf Kommunikation basiert. In allen vorgeschrieben Meetings (Planungsmeetings, Sprint-Review-Meeting, etc.) kommunizieren die Mitglieder des Scrum Teams miteinander. Auch beim Daily Scrum, zu dem sich alle Mitglieder des Entwicklungsteams täglich für 15 Minuten mit dem Scrum Master treffen, um über Fortschritte und Probleme im Projekt zu berichten, steht der gegenseitige Austausch im Mittelpunkt.
Wie man schnell sieht, erfordert Scrum von einem Entwicklungsteam eine ganze Menge – Dinge, die man nicht immer voraussetzen kann, sondern die zumeist erst erlernt und eingeübt werden müssen. Das geht nicht über Nacht, sondern die Einführung von Scrum in einem Unternehmen kann sich über Monate hinziehen. Hier ist der Scrum Master gefragt, der das Team immer wieder ermuntert, anleitet, ihm zur Seite steht und Hindernisse für das Team auf jeder Ebene aus dem Weg räumt. Die Einführung von Scrum lohnt sich aber dennoch, denn der Gewinn an Produktivität und Kundenzufriedenheit ist den Aufwand in jedem Fall wert.
Sehr schöner kurzer Überblick – guter Artikel!
Gute Einleitung, danke!
Ich war mal vor längerer Zeit bei ner Softwareschmiede, die alle verschiedenfarbige Armbänder trugen. Sie meinten, dass wäre ihr SCRUM-Status wenn ich mich nicht irre. Gibts sowas wirklich?
lg
Ich arbeite momentan auch in einem Scrum-Team und ich finde die Arbeitsweise super. Für alle ist es noch neu, aber wir haben uns alle recht gut eingelebt. Der Product Owner braucht noch etwas um in seine Rolle zu wachsen, dann wird die Softwareentwicklung zumindest von meinem Gefühl her um einiges besser als bei den herkömmlichen Geschichten. Übrigens funktionieren Daily Scrums auch mit Telefon, falls man Kollegen hat die nicht vor Ort sitzen können.
@David Müller: Ist das nicht dieses „Clean Code“-Ding? Da gibt es doch so etwas?
@Reto: Erstmal Danke für den wirklich guten Artikel. Vielleicht kann ich ja auch noch ein paar Worte aus meiner Zeit bei der letzten Firma erzählen.
Wir haben auch angefangen Scrum einzusetzen. Leider wurde es vom Team nicht so wirklich gelebt. Wir hatten immer wieder Leute dabei, die meinten „na und … habe ich mich halt wieder verschätzt“ oder „stand up meetings finde ich unnötig“. Vielleicht ist der eine Entwickler, der das immer wieder getoppt hat eine Ausnahmeerscheinung. Bestimmt sogar. Trotzdem habe ich immer wieder in Gesprächen gehört, mit Leuten, die einen Mal hinter die Fassade haben schauen lassen, dass nicht alles so toll läuft.
Ich glaube der Idealzustand Scrum ist etwas wunderbares, wenn alle mitziehen. Der Weg dorthin ist steiniger, als man es vielleicht nach außen kommuniziert. Hat noch jemand die Erfahrung gemacht?
Vielleicht packe ich das auch noch mal in nen Artikel 🙂
@Reto … Kompliment, ein guter Artikel, der kurz und knapp den Kern von Scrum umreißt.
@Nils … Deine letzten Sätze
würde ich unterschreiben. Vor allem der Weg zur echten Selbstorganisation ist schwierig. Ich befürchte, dass mancher Scrum-Master mit den gruppendynamischen Prozessen, die er eigentlich begleiten und konstruktiv fördern sollte, überfordert ist. Die Vision des selbstorganisierten Teams, das sich seine Selbstorganisation selbst erarbeit, ist eine Illusion. Eine völlig frei agierendes Team braucht sehr viel länger, eine Begleitung des Prozesses ist m.E. unabdingbar – deshalb gibt es den Scrum Master ;-). Wenn einzelne Teammember sich z.B. dem Daily Scrum entziehen, stecken oft Unsicherheiten oder schwelende Rollenkonflikte im Team dahinter. Dies müsste der Scrum-Master eigentlich aufgreifen. Die Zertifizierungs-Ausbildung vermittelt dies leider nicht ausreichend.
Vielleicht noch eine Ergänzung. Es gibt Hinweise, dass Scrum zählbar erfolgreicher ist als klassiche Vorgehensweisen (tiefergehende Untersuchungen laufen noch):
http://www.pentaeder.de/projekte/2009/07/14/projekte-mit-scrum-sind-erfolgreicher/
Zum Thema Farbbändchen: http://www.clean-code-developer.de/ – da kommen die her, hat aber nicht unbedingt direkt etwas mir Scrum zu tuen.
@ Dennis + Norbert: Danke, die rannten da alle größtenteils mit weißen Bändchen rum, haben von Scrum geschwärmt und waren extremst arrogant. Wie der Karate-Kämpfer, der mit seinem schwarzen Gürtel in der Innenstadt zur Schau trägt…
Ich habe im Konzernumfeld auch die Erfahrung gemacht, dass der Idealzustand Scrum ein steiniger Weg ist, da in großen Unternehmen die vielen politischen Faktoren, die auch das nicht-agile Projektmanagement schwer machen, die Mitglieder des Scrum-Entwicklungsteams ebenfalls beeinflussen und somit die schon angesprochene und unabdingbare Transparenz und Ehrlichkeit in Gefahr bringen. Je kürzer die Projektlaufzeit ist, desto stärker lastet meiner Erfahrung nach der Erfolg auf den Schultern des Scrum-Masters, wenn das Entwicklungsteam nicht durchgängig aus Scrum-erfahrenen und –willigen Mitgliedern besteht.
Was genau ist den ein Scrum Master wenn ich fragen darf?
Ich hab mich noch nicht wirklich mit dem Thema auseinand gesetzt, aber man kommt wohl heutzutage nicht mehr ohne aus.
Überall liest man nur noch Scrum, Agile Softwareentwicklung, usw.
Ist so ein Zertifikat wirklich sein Geld wert?
Nach jeder Recherche lande ich auf http://borisgloger.com/trainings4you/
Irgendwie wirkt das wie ein ZCE Zertifikat für mich.
Einfach nur ein Zettel, der bestätigt das ich mich einmal damit auseinandgesetzt habe und eine Prüfung erfolgreich absolviert habe.
Ist soetwas wirklich seine 2000€ wert?
Eventuell kann ja hier jemand meine Fragen beantworten^^
Daniel
@ragtek … der Scrum Master ist derjenige, der das Team unterstützt, die Meetings (tägliche und andere) leitet, moderiert und ggf. konfliktlösend einspringt. Darüberhinaus ist er für das Beseitigen von Arbeitshindernissen zuständig. Er ebnet gewissermaßen dem Team den Weg.
Ich persönlich halte die üblichen Seminare (auch die Zertifizierungskurse) für nicht ausreichend. In diesen Seminaren wird zwar darauf eingegangen, dass der Scrum-Master konfliktlösend agieren soll. Wie das konkret aussehen kann kommt dann zu kurz. Woher die Konflikte, die es in jedem Scrum-Team gibt, herrühren wird ebenfalls nur am Rande gestreift. In dem Zertifizierungs-Seminar, das ich besucht hatte, war das gerade mal 10 min lang Thema. Ein Scrum Master auch mit Feinheiten der Gesprächsführung vertraut sein, siehe z.B. hier
http://www.phphatesme.com/blog/projektmanagement/advocatus-diaboli/
Langer Rede kurzer Sinn: Ich halte weitere Qualifikation (woher auch immer) für unabdingbar. Der Preis/Wert des Seminars muss speziell in Deutschland auch in Hinsicht auf das Zertifikat bewertet werden – ohne Zettel ist es manchmal schwierig Arbeitgeber oder Kunden zu überzeugen 😉
Hallo, einen sehr schönen Artikel hast Du da verfasst. Ich hatte während meines Studiums eine Seminararbeit über ein Unternehmen, welche SCRUM anwendeten, geschrieben und mich hat das Framework fasziniert. Es ist sogar schon etwas mehr als das. Es unterstützt die Kommunikation, wie Du ja schreibst, in einem hohen Maße. Was mir besonders gefallen hat in diesem Unternehmen: Die Mitarbeiter-Motivation war unheimlich hoch, da ja doch sehr viel Wert, und damit auch Verantwortung, auf das Team gelegt wird.
Mich wundert folgendes:
Es gibt reihenweise Artikel darüber, wie jemand als Scrummaster von oben oder als Coach von außen Scrum in (gerne auch mehreren) Firmen eingeführt hat. Immer mit tollen Erfolgen.
Aber ich sehe kaum Artikel, in denen Entwickler ehrlich über ihre Probleme schreiben.
Ich habe (mal abgesehen von XING) auch noch kein deutschsprachiges Entwicklerforum dazu gefunden.
Ich verstehe das nicht.
Bei uns wurde „von oben“ ein Pseudo-Scrum eingeführt.
Und es gibt nur Probleme.
Es fängt damit an, dass unser Programm sehr sehr groß und schon sehr sehr alt ist. Das heißt, wir haben viel zu wenige automatisierte Tests, jedes Release ist mit viel Testerei von Hand verbunden.
Es geht weiter damit, dass wir sehr schnell auf gesetzliche Änderungen von außen reagieren müssen. Diese Änderungen kommen teilweise von verschiedenen Quellen, haben also schon mal ein bis zwei Wochen Versatz. Das ist halt problematisch bei einem festgezurrten Sprint.
Das weiteren arbeitet eine große Anwendergruppe mit dem Programm, so dass der Support unregelmäßig Unterstützung der Entwicklung anfordern muss. Hier ist unser Chef, der jetzt Scrummaster heißt, der Meinung der Sprint geht vor. Es ist ihm nicht begreiflich zu machen, dass alle Beteiligten darunter leiden, wenn der Support aufgrund mangelnder Unterstützung falsche Aussagen gegenüber dem Kunden trifft. Schlussendlich arbeiten die Entwickler tagsüber am Sprintziel und nach Feierabend unterstützen sie die Supporter. Weil wir ihnen nicht mehr in die Augen sehen könnten, wenn wir sie so hängen lassen würden.
Wir Entwickler sind spezialisiert. Jeder ist für „seinen Bereich“ zuständig. Das ist so, weil auch sehr viel Businesslogik dahinter steckt. Es ist nicht möglich in allen Bereichen so weit Experte zu sein, dass man verantwortlich programmieren könnte. Das ist alles zu komplex.
Das wiederum führt dazu, dass das Sprintziel nicht erreicht wird, sobald ein Spezialist in Verzug gerät.
Ich empfinde das Sprintziel als künstliches Ziel. Im Gegensatz zu den „echten Zielen“: Zum Stichtag x muss in unserem Programm die Gesetzesänderung umgesetzt sein und das Programm muss ausgeliefert sein. Dieser Druck ist hoch, der ist sehr real und spürbar und wir Entwickler stellen uns da unserer Verantwortung und arbeiten in der heißen Phase wirklich hart.
Unsere Geschäftsführung möchte jetzt via künstlichen Sprintzielen dieses Hochdrucktempo das ganze Jahr halten – was uns Entwickler ausbrennt.
Verwerflich finde ich auch, dass bei Scrum massiv über Gruppendruck gearbeitet wird.
Hallo Charly,
Du sprichst wahre und bittere Worte aus. Das was Du schreibst ist leider vielerorts so.
Eine solche Einstellung einer Geschäftsführung geht an der Grundidee der agilen Entwicklung vollständig vorbei. Das hilft zwar nicht in Eurer konkreten Situation dennoch würde ein solcher Managementstil auch andere Wege finden um Druck auszüben.
Einen Chef als Scrum Master umzulabeln ist Unsinn. Es gibt die Metapher „scrum master is a leader without power“ insofern kann ein disziplinarischer Vorgesetzter schwerlich die Scrum Master Rolle übernehmen. Agile Entwicklung und damit auch Scrum erfordert eine bestimmte Einstellung und Werte, die leider nicht überall dort wo Scrum drauf steht zu finden sind.
Das mit dem Gruppendruck würde ich differenziert betrachten. Wenn der Gruppendruck von außen verstärkt wird – was ein Scrum Master mit disziplinarischer Macht tun könnte – ist das verwerflich. Wenn die Gruppe wirklich selbst organisiert ist entsteht ein Netz von Verantwortungsgefühlen (Solidarität), die sich in manchmal auch wie Druck anfühlen können. Eine echte gelebte Solidarität, die den einzelnen gelegentlich (!) dazu bringt über seine Grenzen zu gehen, halte ich hingegen nicht für verwerflich. Ich würde das vielleicht mit dem „Aushelfen“ oder „Zähne zusammenbeißen“ in einer Sportmannschaft vergleichen. Wichtig ist, dass diese Solidarität nicht überstrapaziert und zum Regelfall wird. Diese Gefahr besteht – das darf auch nicht weg diskutiert werden – deshalb ist es so wichtig, dass der Scrum Master eben auch auf die „Sustainability“ achtet.
Nicht vergessen: Scrum ist die Theorie einer Methode, die in der Praxis weder bestätigt noch wiederlegt wurde. Sicherlich kann es helfen ein klares Ziel vor Augen zu haben (vor allem für den Teamleader, da ist das auch bitter nötig), allerdings ist jedes Team anders und wird solche Vorgaben anders antizipieren. Schönes Wort.
Scheitern ist halt immer eine Optio mit der die meisten Projektmanager nicht umgehen können.
In jedem Falle hat sich der Term „Scrum“ bereits seit längerem für das Bullshit Bingo qualifiziert und sollte jeder Entwicklerin von den Lippen gehen.
Im Übrigen, dass der Code allen gehören würde ist in vielen Produktionen schlichtweg nicht der Fall und birgt ein gewisses Risikopotential von Redundanz bis zu Abhänigkeiten von Entwicklern.
Danke aber für den tollen Artikel der einen guten Überblick gibt. Würde mich nach deinen anfänglichen persönlichen Erfahrungen mal interessieren ob / wie / wann man scrum dann ergänzt.
Hey,
unter http://scrum.dhbw-karlsruhe.de gibt es eine interessante Seite zu dem Thema Scrum. Mit Audio, Spielen und Fragebogen und alles was dazu gehört.
Viele Grüße
DeBugger
Was bei all den Scrum-Diskussionen immer wieder totgeschwiegen wird, sind zwei Dinge.
1.) ProductOwner und das gesamte Management und der Vertrieb (einfach alle, die direkten Kundenkontakt haben und/oder die Vision des Unternehmens tragen) müssen die Kunden möglichst darauf einschwören, bei Scrum mitzuziehen.
2.) Wer Scrum mit ganz dogmatischen Ansatz umsetzen will und stark heterogene Fachkräfte in den Teams hat, muss akzeptieren, dass die Produktivität erstmal sinken kann. Ich kenne einige sinnvolle Scrum-Umsetzungen, die die Regeln beugen müssen, weil man sonst einfach kein Geld mehr verdienen würde.
Mein Problem mit Scrum als Entwickler, ist schlicht und einfach dass ich fürs gleiche Geld mehr Verantwortung trage, also mehr Stress, mehr Arbeit bei gleichem Gehalt.
Ich habe sehr wohl erlebt, wie iterative Softwareentwicklung auch ohne Scrum funktioniert. Ein guter Projektmanager schafft es dabei, jedem in seinem eine Aufgabe zu geben, die ihn über wenige Tage beschäftigt und gleichzeitig das Ergebnis näher zur Produktreife bringt.
– mehr Stress
– VIEL mehr Verantwortung
– weniger Geld für den Entwickler
– nicht automatisch das beste Produkt
– zuviel Gequatsche