a Randstad company
Login
© Adobe Stock / Jacob Lund

Bin ich als Entwickler bereit für Scrum?

19.11.2019
David Göhler – Freiberuflicher Autor
Artikel teilen:

Scrum ist ein Frameset mit klaren Vorgaben, um die Entwicklung von Software im Team möglichst effizient zu gestalten. Dabei ändert es einige Vorgehensweisen (im Vergleich zur klassischen Software-Entwicklung), wie ein Team zusammenarbeitet und wo die Verantwortlichkeiten liegen. Als Entwickler ist man also nicht nur technisch gefordert, alle nötigen Fähigkeiten mitzubringen. Man muss auch gewisse Prozess- und Team-Skills besitzen (oder sich zumindest schnell aneignen).

In Scrum gibt es klare Rollenverteilungen, an die sich alle halten müssen. Neben dem Scrum Master als Berater und dem Product Owner als Projektleiter hat das Entwickler-Team klare Aufgaben und Verantwortlichkeiten. Diese klare Abgrenzung sorgt dafür, dass man in Scrum-Projekten komplexe Entwicklungen erfolgreich durchführen kann. Dazu zählen auch sich ändernde Anforderungen und Funktionalitäten, die erst im Laufe der Entwicklung klar werden. 

Scrum erzeugt außerdem eine größtmögliche Transparenz aller Entwicklungsvorgänge. Die Daily-, Review- und Retrospektiv-Meetings sorgen dafür, dass alle Team-Mitglieder möglichst gut über alle Aktivitäten Bescheid wissen. Wer sich ungern in die Karten schauen lässt, ist für Scrum nicht geeignet. Hierbei gilt es auch, mit sachlicher Kritik richtig umgehen zu können.
Gute Scrum-Teams sind möglichst interdisziplinär mit Experten ihres jeweiligen Fachs besetzt. Das bedeutet, dass man auch mit Leuten zu tun hat, die andere Sichtweisen und Fachwissen einbringen. Als Entwickler sitzt man also nicht mehr im Elfenbeinturm nur unter seinesgleichen. 

Notwendige Technische Skills

Gerade, weil ein Scrum-Team mit Experten besetzt ist, sollte man seinen Themenbereich beherrschen und die entsprechenden Fähigkeiten besitzen. Dazu gehören Basics wie die geforderten Programmiersprachen und Entwicklungsumgebungen, aber auch die notwendigen Programmiertechniken, Kenntnisse der notwendigen Frameworks und Pattern. 

Ebenso sollte man mit den gängigen Testing-Methoden vertraut sein. Beim TDD (Test Driven Development) werden zuerst die Tests und dann erst die geforderten Funktionalitäten entwickelt. Gerade das Entwickeln von praxisorientierten Tests erfordert einige Erfahrung.

Vielfach wird auch erwartet, dass man sich schnell in neue Tools, Prozesse und Techniken einarbeiten kann und nicht darauf beharrt, das zu verwenden, was man kennt. Darüber hinaus erfordert die Entwicklung agile Engineering-Techniken, die schon bei der Erstellung berücksichtigen, dass sich die Anforderungen ändern können und man als Entwickler beim nächsten Sprint darauf reagieren muss. 
Nicht zuletzt ist es von Vorteil, wenn man die Methoden des Extreme Programming kennt und selbst schon angewendet hat. Sie gehören zwar nicht fest zu Scrum als Framework, werden aber häufig in Scrum-Teams eingesetzt. Dazu gehört beispielsweise das Pair Programming, bei dem immer zwei Entwickler an einem Code-Stück arbeiten und sich gegenseitig verbessern und abwechseln.

  • GULP ist seit über 20 Jahren ein führendes Projektportal sowie Personalagentur. 
  • Mit einem GULP Profil präsentieren Sie sich zahlreichen potentiellen Auftraggebern.
  • Sie können auch selbst aus einer Vielzahl von Projekten wählen und sich bewerben.

Kostenfreies Profil anlegen!

Wichtige Team-Fähigkeiten für Scrum

Ein Scrum-Team organisiert sich eigenverantwortlich und eigenständig. Es gibt keinen Chef im Team. Jeder ist formal gleichberechtigt (was auch für Tester gilt). Dennoch muss das Team die Verantwortung für die zugesagten Leistungen übernehmen. Es arbeitet dazu zwar eng mit dem Product Owner und Scrum Master zusammen. Während eines Sprints hat sich jedoch der Product Owner rauszuhalten. 

Für eine reibungslose Zusammenarbeit sollte ein Entwickler daher ein echter Teamplayer sein. Das heißt, er kann sich selbst und seine Kollegen motivieren, ist fähig, Kritik anzunehmen und selbst sachlich zu äußern, er muss Vertrauen in die Fähigkeiten der anderen Mitglieder haben und bei Fehlern nicht gleich an die Decke gehen. 

Das bedeutet auch, es einmal auszuhalten, dass andere Aufgaben übernehmen, die man selbst machen wollte und Aufgaben erledigt, die vielleicht keine „Sahnestücke“ sind. Man muss auch die Vorgaben des Product Owners, was die Prioritäten der Entwicklung angeht, akzeptieren können. Ziel ist es immer, die Arbeit optimal zu verteilen, damit das Team seine beste Leistung erbringen kann.
Für das Review ist es wichtig, dass man das Erreichte verständlich erklären und darstellen kann. Außerdem sollte man Verbesserungsvorschläge machen und einbringen können, um das Team für den nächsten Sprint effektiver zu machen. Dies führt naturgemäß zu Veränderungen. Es ist also von zentraler Bedeutung, gegenüber Kritik und Änderungswünschen offen zu sein und sie annehmen zu können, wenn es dem Team dient. Genau das macht das Team agil.

Fähigkeiten für optimale Prozesse & Organisation

Scrum als Entwicklungsrahmen zeichnet sich dadurch aus, die eigene Herangehensweise und Prozesse ständig zu beobachten und Verbesserungen vorzunehmen, wo es möglich und sinnvoll ist. 

Als Team-Mitglied sollte man daher in der Lage sein, bereits bestehende Prozesse ständig zu hinterfragen und Hindernisse zu erkennen, zu benennen und bereit sein, sie abzubauen. Auch hierbei ist es wichtig, in der Retrospektive Kritik sachlich und gut verständlich formulieren zu können. Dazu gehört aber auch, Kritik annehmen und umsetzen zu wollen. Da es im Team keinen Chef gibt, der einem die Entscheidung abnimmt, muss das im Diskurs mit dem Team geschehen. 

Hilfreich dafür, dass das gelingt, ist eine klare und gewaltfreie Kommunikation. Wer in der Vergangenheit damit Schwierigkeiten hatte, sollte entsprechende Weiterbildungsmöglichkeiten wahrnehmen, um „gewaltfrei“ kommunizieren zu können.

Ganz wichtig sind natürlich auch organisatorische Fähigkeiten, seine eigene Arbeit vernünftig strukturieren und priorisieren zu können. Hierbei hat das Schätzen von Aufwänden für die Realisierung der geforderten Funktionalitäten eine besondere Rolle, um das Sprint-Ziel nicht zu gefährden. Ist man hier noch eher unerfahren, sollte man auf seine Kollegen hören. 

Generell ist es für die Zielerreichung hilfreich, selbst schnell entscheiden zu können, ob man eine Schwierigkeit selbst überwinden kann oder dafür besser Hilfe von Kollegen in Anspruch nehmen sollte, damit das Team als Ganzes erfolgreich sein kann. Hierzu sind die Daily Meetings das richtige Forum, um seine Kollegen einzubinden.

Sich in Scrum schulen und zertifizieren lassen

Scrum hat letztlich wenige und recht einfache Regeln, kann in der Anwendung jedoch relativ komplex werden. Wer nach der Lektüre dieses Beitrags der Meinung ist, noch nicht wirklich reif für Scrum zu sein, kann sich natürlich weiterbilden. 

Eine anerkannte Zertifizierung als „Certified Scrum Developer“ bieten diverse Organisationen an, unter anderem auch die Scrum Alliance

Einen gut gelungenen Einstieg in Scrum bietet außerdem der offizielle Scrum-Guide der Scrum-Erfinder Ken Schwaber und Jeff Sutherland. Es erklärt sehr gut die verschiedenen Begriffe und auch die Ziele, die mit Scrum erreicht werden sollen.

Was Auftraggeber sicherstellen müssen

Als Freelancer muss man sich aber nicht nur fragen, was man selbst an Fähigkeiten mitbringen muss. Auch der Auftraggeber ist in der Pflicht, seine Scrum-Teams so aufzustellen, dass eine vernünftige Umsetzung der Scrum-Rahmenbedingungen möglich ist und auch tatsächlich erfolgt. So wird gerne der Product Owner und Scrum Master in Personalunion implementiert, was zu größeren Interessenskonflikten führt. Scrum funktioniert am besten, wenn man sich strikt an die vorgegebenen Regeln hält. Team-Mitglieder dürfen in einem Sprint nicht ständig abgezogen und für andere Zwecke eingesetzt werden, was natürlich auch für Freelancer gilt. 

Außerdem müssen Auftraggeber auch willens und in der Lage sein, berechtigte Kritik aus den Review- und Retrospektive-Meetings anzunehmen und umzusetzen (auch wenn dies mit Kosten verbunden ist), um das Team nicht zu demotivieren und es ihm zu ermöglichen, sich ständig zu verbessern.

Fazit

Für Scrum sind als Entwickler nicht nur technische, sondern vor allem auch soziale, organisatorische und Team-Fähigkeiten gefragt, weil es viel mehr Transparenz und Vernetzung erfordert. Mit den passenden Schulungen und vernünftigen Rahmenbedingungen kann man aber extrem effektiv neue Software entwickeln. Wer die genannten Fähigkeiten größtenteils mitbringt, ist für Scrum gut gerüstet.

Lesermeinungen zum Artikel

2,6 von 5 Sternen | Insgesamt 14 Bewertungen und 5 Kommentare

  • Scrum = Chaos

    Axel Dahmen am 24.11.2019 um 13.13 Uhr

    Ich habe inzwischen in mehreren Scrum-Projekten mitgearbeitet ... Sie alle endeten in extrem überproportionaler Budgetüberschreitung, die per Notbremse gestoppt wurden, in Beschäftigung nur mit sich selbst statt mit der Aufgabe (Retrospektiven, Planning 1, Planning 2) und in nicht Fertigstellung.

    Scrum fördert m. E. massiv den Verantwortungsentzug. Bei Scrum fühlt sich der einzelne Entwickler nicht mehr für eine Entwicklung verantwortlicht. das "Team" trägt ja die Verantwortung. Es folgen endlose Diskussionen über den "besten Weg", "best Practices", statt ein Ergebnis zu erarbeiten.

    Scrum fördert m. E. des Weiteren schlechten Entwicklungsstil. Qualität und effizienter Code machen Platz für Geschwindigkeitgewinn durch sinnentleerte Copy/Paste-Programmierung, da die geforderte "Transparenz" im Team vielen Entwicklern einen Rechtfertigungsdruck durch den Konkurrenzdruck im Team abnötigt. Die Folge ist, dass nur soweit entwickelt wird, wie es die User-Story vorgibt. Gibt es für den nächsten Sprint eine User-Story, die der vorherigen sehr ähnelt, muss der gesamte Code noch einmal angefasst und ggf. vollständig umgebaut werden, da niemand über seinen Tellerrand hinausblickt.

    Durch "Pair-Programming" sind zwei Entwickler an eine einzige Aufgabe gebunden, statt dass beide Entwickler getrennt Lösungen entwicklen (50 % Effizienzverlust). In "Code Reviews" wird über Code-Stil gestritten statt über effiziente Algorithmen. Form ist hier wichtiger als Inhalt.

    Für mich ist Scrum tot.

    Scrum ist eine Budget-Verbrennungsmaschinerie, ein gescheiterter Versuch, soziale Kompetenzen in ein Entwicklungsteam zu bringen, ist ein Versuch, unfähige Entwickler einer sozialen Kontrolle zu unterziehen statt fähige Entwickler ihre Arbeit machen zu lassen.

    Scrum ist der Wunsch nach mehr Effizienz, der aber genau das Gegenteil bewirkt.

    Scrum ist unnötig und ineffizient, speziell für Entwickler, die bereits umfangreiches technisches Know-How besitzen und ständig durch "besondere" Wünsche von anderen Mitgliedern im Team, die sich erst noch beweisen wollen, ob das, was sie im Internet gelesen haben, funktioniert (was es oft nicht tut bzw. nicht so schnell und allumfassend wie es viele Artikel verheißungsvoll versprechen), zurückgehalten werden.

    Scrum ist eine experimentelle Methodik von Gestern, ein gescheiterter, obsoleter Versuch. Ebenso wie das Schreiben lernen nach Gehör.

    Ziel sollte es wieder sein, Experten ihren separaten Bereich zu überlassen, mit einer klaren Schnittstellenbeschreibung und ausreichender Code-Dokumentation. Die Aufgaben sollten regelmäßig aktualisiert werden, das Ziel langfristig bekannt sein. Funktions-Reviews gibt es, wenn der Entwickler fertig ist. Sollte der Mitarbeiter wechseln, dann genügt eine 2 - 4 wöchige Einarbeitungszeit. Die meisten von uns programmieren weder Treiber noch Firmware, sondern die immer gleichen datenbankbasierten Geschäftsvorgänge. Die einzige Herausforderung bei der Übergabe ist hier, die Abhängigkeiten zu erkennen, die sich im Aufgabenbereich des scheidenden Entwicklers entwickelt haben. Der Rest sollte banal und trivial sein.

  • Harte, aber klare Ansage

    A. Fehrmann am 22.11.2019 um 13.12 Uhr

    Als Scrum Master kann ich dem Artikel nur zustimmen. Aus der Praxis habe ich genug Beispiele, wie die Zusammenarbeit ausschaut, wenn man die oben genannten Eigenschaften nicht besitzt. Ich vermute, für die meisten ist die Transparenz wirklich das schwerste. Wenn man die Retrospektiven korrekt durchführt, kommt fast alles ans Licht und wird unbequem, da man sich mit sich selbst und dem Umfeld mehr beschäftigen muss, als man möchte.

  • hat etwas von "Zusammengegoogelt"

    Joerg Schroeder am 22.11.2019 um 12.41 Uhr

    Interessierten empfehle ich "echte" Fachliteratur - hier wurde vieles vermischt, verwechselt und durcheinander gewürfelt. Das Wording ist nicht gerade professionell...

  • Große Überschrift - wenig Inhalt

    Markus Hopfenspirger am 22.11.2019 um 07.37 Uhr

    Zusätzlich haben einige Dinge, die hier beschrieben werden, aus meiner Sicht keinen wirklichen Zusammenhang mit Scrum (Programmiersprachen, Entwicklungsumgebungen usw.) und einige Rollen sind hier mit falschen Nebenwörtern versehen (z.B.: "...dem Product Owner als ***Projektleiter***...") und auch bei anderen Vorgehensweisen muss ein Team Verantwortung übernehmen, im Grunde sollte man doch immer Verantwortung übernehmen für das was man tut, nicht nur im Beruf - was hat das mit Scrum zu tun - .....

    Also echt - bei so einem Thema hätte ich mir von GULP mehr fachliche Kompetenz erwartet.

    Und nebenbei: Wer als Entwickler heute noch nicht "Scrum fähig" ist, der hat die letzten 10 oder vielleicht sogar 15 Jahre echt verschlafen...

  • Kundennutzen Transmission in SCRUM (Agile)

    Fred Schröder am 22.11.2019 um 06.46 Uhr

    System Entwicklung hat nur ein Ziel: Kundennutzen (Auftragserfüllung). Dieser einzig wirklich wichtige Aspekt fehlt vollkommen in diesem Statement. Wie geschieht der Transport und die Umsetzung der betriebswirtschaftlichen, funktionalen, sozialen Ziele im integrierten Kontext, so dass der Kunde am Ende die Rechnung bezahlt.

Weitere Kommentare anzeigen

Ihre Meinung zum Artikel

Bitte verwenden Sie keine Links in Ihrem Kommentar.

Ihr Kommentar wird zunächst geprüft. Möchten Sie informiert werden, wenn er veröffentlicht wurde?
Bitte tragen Sie dazu Ihre E-Mail-Adresse ein:
Wir konnten Ihre Bewertung leider nicht speichern. Bitte geben Sie zuerst Ihr Feedback ab.
Lieber Leser, vielen Dank für Ihr Feedback.
Ihre Bewertung für den Artikel wurde gespeichert. Wir prüfen Ihren Kommentar bezüglich Netiquette und Datenschutzrichtlinien und veröffentlichen ihn danach in Kürze. Sie werden von uns per E-Mail darüber benachrichtigt.
Ihre GULP Redaktion.