12.01.2022

Scrum in der Softwareentwicklung: agil und strukturiert

Geht es um agile Methoden der Softwareentwicklung, kommen Sie um einen Begriff nicht herum: Scrum. Was aber ist Scrum eigentlich und wie entfaltet es seine Stärken in der Softwareentwicklung? Welche Rollen und welche Aktivitäten gibt es in Scrum? Was sind Vorteile und Nachteile dieses agilen Rahmenwerks? All das erfahren Sie in diesem Artikel. Darüber hinaus gewähren wir einen Einblick in unsere agile Scrum-Variante, die wir erfolgreich zur Entwicklung von Projektron BCS nutzen.

Was ist Scrum eigentlich?

Scrum ist eine agile Form der Zusammenarbeit, die auf Flexibilität und Selbstorganisation des Teams setzt. Für die Anwendung gibt es einen offiziellen Scrum Guide, der genaue Regeln und Handlungen vorschlägt.

Obwohl viele Personen Scrum als agile Entwicklungsmethode bezeichnen, handelt es sich eigentlich nicht um eine Methode, sondern um ein „Framework“. Konkret ist Scrum ein Vorgehensmodell, das im Produktmanagement und Projektmanagement angewendet wird. Die Entwicklung wird nach Scrum in Iterationen organisiert, den Sprints. Die Sprints geben dem Team durch ihre gleichmäßige Länge einen Rhythmus.

Welche Rollen gibt es in Scrum?

Wir besetzen bei Projektron vier Scrum-Rollen: Development Team, Scrum Master, Product Owner und Chief Product Owner. Nach dem Framework sind drei Rollen in Scrum vorgesehen:
 

  1. Das Development Team (Dev-Team) besteht meist aus Entwicklern.
  2. Daneben hat jedes Team seinen eigenen Scrum Master. Der Scrum Master fungiert als eine Art Moderator im Team und achtet darauf, dass die Zusammenarbeit reibungslos funktioniert. Er beschafft zum Beispiel Ressourcen, hilft dem Team bei Problemen und ist Ansprechpartner für Außenstehende.
  3. Die Product Owner vertreten die Interessen des Kunden und sind Ansprechpartner für andere Stakeholder. Sie sammeln Kundenwünsche, priorisieren sie und geben sie an das Dev-Team weiter.


Ein Scrum Team sollte fünf bis neun Mitglieder umfassen. Bei mehr Personen werden Organisation und Kommunikation sehr aufwendig. Bei weniger Personen wird man kaum alle benötigten Kompetenzen im Team vorfinden, um jede Aufgabe qualifiziert abzudecken.

Jede Person, die nach dem Framework nicht Mitglied des Scrum-Teams ist, aber ein Interesse an der Entwicklung des Produkts hat, wird als Stakeholder bezeichnet. Stakeholder nehmen am Scrum-Prozess in unterschiedlicher Weise Teil, sind aber nicht Teil des Scrum-Teams. Beispiele für Stakeholder sind Kunden, Benutzer oder das Management.

Welche Aktivitäten gibt es in Scrum?

Es gibt wiederkehrende Aktivitäten, die als regelmäßige Termine angesetzt werden.

  1. Zum einen gibt es den Sprint - ein fest definiertes Zeitintervall von ein bis vier Wochen, in dem das Team an den User Storys arbeitet. User Storys geben die neuen Anforderungswünschen der Kunden wieder.
  2. Im Anschluss legen die Teams eine Pause ein, den Zwischensprint. Erst danach starten sie in den nächsten Sprint. In dieser Phase bearbeiten die Teams Fehlertickets, planen den kommenden Sprint und führen sprintunabhängige Dinge durch (z.B. Mitarbeitergespräche).
  3. Jeder Sprint startet mit einem Planning. Dieser Termin dient dazu, dass die Product Owner, die für den Sprint eingeplanten User Storys den Entwicklern vorstellt, Verständnisfragen klärt und das Sprintziel deutlich wird. Nach dem Planning arbeiten die Entwickler dann zwei Wochen an der Umsetzung der im Sprint eingeplanten User Storys. Je nach Kapazität der Entwickler (Urlaub, Termine etc.) variiert das Umsetzungsvolumen von Sprint zu Sprint.
  4. Innerhalb des Sprints gibt es jeden Tag einen kurzes Meeting von ca. 15 Minuten, den Daily Scrum. Hier ist jeder Entwickler dazu eingeladen, im Kreis seiner Kollegen ein kurzes Update seiner Arbeit zu präsentieren: Wo stehe ich gerade? Welche Schwierigkeiten habe ich überwunden? Welche Herausforderungen stehen mir bevor? Wo brauche ich Hilfe?
  5. Zum Ende des Sprints präsentiert das umsetzende Team seine erzielten Arbeitsergebnisse in der Demo. Zu diesem Meeting erscheinen alle an den User Storys beteiligten Product Owner. Gegebenenfalls stoßen Entwickler hinzu, die von den Auswirkungen betroffen sind. Dieser Termin bietet den Entwicklern eine Bühne, um ihre Leistung im zurückliegenden Sprint zu präsentieren und lädt zum Austausch und Feedback aller Beteiligten ein. In der Demo zeigt sich auch, ob das Sprintziel erreicht wurde oder ob vielleicht noch Nacharbeiten nötig sind.

Schließlich endet der Sprint mit einer Retrospektive. Dazu trifft sich das Sprint-Team um die Zusammenarbeit zu reflektieren und Vereinbarungen für künftige Sprints zu treffen. Was ist gut gelaufen, was muss im nächsten Sprint besser laufen? In der Retrospektive geht es nach dem agilen Rahmenwerk also nicht um inhaltliche Arbeitsergebnisse, sondern vornehmlich um den Arbeitsprozess.

Woher kommt der Name „Scrum“?

Der Name Scrum leitet sich von einem Spielzug im Rugby ab und kann mit „Gedränge“ übersetzt werden. Jeff Sutherland und Ken Schwaber übernahmen den Rugby-Approach aus der IT. Sie benannten ihr Anfang der 1990-er Jahre neu entwickeltes Rahmenwerk in Bezug auf die ursprüngliche Bezeichnung in Scrum um. Den Rugby-Approach hatten ursprünglich die beiden japanischen Wirtschaftswissenschaftler Hirotaka Takeuchi und Ikujiro Nonaka 1986 als Vorgehensweise im Lean Management definiert.

Welche Artefakte gibt es in Scrum?

Neben den Rollen und den Aktivitäten gibt es in Scrum noch drei Prozessdokumente - die Scrum-Artefakte:

  1. Das Product Backlog ist die Gesamtliste aller User Storys (Anforderungen) die für das Produkt realisiert werden sollen.
  2. Das Sprint Backlog ist die Liste aller User Storys die innerhalb eines Sprints bearbeitet werden sollen.
  3. Das Inkrement ist ein potenziell auslieferbares Teilergebnis oder Produkt, das am Ende eines Sprints nach der Definition of Done entstanden ist. Die Entscheidung darüber, ob das Inkrement ausgeliefert wird oder nicht, liegt im Ermessen des Product Owner.

Wie funktioniert die Qualitätssicherung in Scrum?

Basis für die Abnahme der User Storys am Ende des Sprints in der Demo ist die Definition of Done (DoD). Es müssen alle Punkte der Definition of Done erfüllt sein, damit eine User Story fertig ist, also vollständig und releasefähig implementiert. Zur Sprint Demo ist es nur erlaubt, fertige User Storys zu präsentieren. Folgende Kriterien zur Sicherung der Qualität sind meist in der Definition of Done enthalten:

  • Build, Deploy, Download bereit
  • Lauffähige Installationsroutine
  • Lauffähiger Projektron-BCS-Server
  • Nebenwirkungen geprüft
  • Code-Review nach dem 4-Augenprinzip
  • Abnahme durch Entwickler selbst
  • Unit-Tests implementiert und laufen durch
  • Funktion geprüft nach dem 4-Augenprinzip
  • Code entspricht Konventionen (keine Warnungen)
  • Architektur
  • Code ist dokumentiert
  • Branches pflegen
  • Konfiguration standard/kundenspezifisch
  • Custom-kompatibel
  • Backward-kompatibel

Vorteile und Nachteile von Scrum

Dem Hype um Scrum in der Softwareentwicklung folgte ein bis heute anhaltender Popularitätstrend von Scrum im agilen Projektmanagement . Dieser Hype lässt schnell vergessen, dass Scrum zwar unbestreitbare Vorteile, jedoch auch einige Nachteile mit sich bringen kann. Nur wer die potenziellen Fallstricke und Tücken kennt, kann bereits frühzeitig entsprechende Anpassungen vornehmen. Wagen wir eine Bestandsaufnahme!

Vorteile von Scrum

Scrum in der Softwareentwicklung…

  • ist schnell einführbar dank schmalem Regelwerk.
  • können Sie leicht adaptieren und auf Ihre individuellen Anforderungen pro Projekt anpassen.
  • liefert schnell erste Ergebnisse bei unklaren Gesamtanforderungen.
  • begünstigt zügiges Reagieren auf kurzfristig geänderte Anforderungen.
  • erlaubt kurzfristigen Abbruch laufender Entwicklung.
  • befähigt Entwickler, schnell in andere Teams und zwischen verschiedenen Fragestellungen und Aufgaben zu wechseln.
  • fördert eine intensive Kommunikationskultur mit kurzen Wegen.
  • ermöglicht das Ausprobieren neuer Techniken bei relativ geringem Risiko (Abbruch nach einem Sprint ist möglich).
  • verursacht einen geringen Administrations- und Dokumentationsaufwand.

Nachteile von Scrum

Gefahr erkannt, Gefahr gebannt. Rufen Sie sich daher folgende Schwächen vor Augen: Scrum in der Softwareentwicklung…

  • vernachlässigt mitunter nicht produkt- oder sprintspezifische Fragen allgemeiner Art zu Architektur, Benutzeroberfläche (GUI), Performance und Systemumgebung.
  • kann Entwicklungsteams schnell von den allgemeinen Firmenzielen und -problemen entkoppeln. Obwohl das Ziel nach agilen Prinzipiel variabel ist, ist es wichtig, dass das Ergebnis dennoch auf die Unternehmensziele einzahlt.
  • birgt die Gefahr, dass Risiken in der Planung erst während der schon begonnenen Realisierung festgestellt werden.
  • erfordert ein hohes Maß kommunikativer und weiterer Soft-Skills wegen des hohen Kommunikations- und Abstimmungsaufwands.
  • verlangt Entwicklern hohes Engagement und Eigeninitiative ab, da es nur wenige konkrete Handlungsempfehlungen erteilt und Hierarchien fehlen.

Struktur sticht Agilität: Darum nutzen wir bei Projektron Scrum

Wir fassten den Entschluss, die agile Arbeit mit Scrum einzuführen, um eine höhere Zufriedenheit in der Entwicklung zu erreichen. Im Dezember 2009 etablierten wir Scrum in der Softwareentwicklung als Vorgehensweise. Im Gegensatz zu andren Unternehmen, die Scrum in der Regel einführen, um agiler zu arbeiten, etablierten wir bei Projektron Scrum in der Softwareentwicklung, um strukturierter zu arbeiten.

Die Notwendigkeit dazu ergab sich aus der zuvor herrschenden unstrukturierten Vorgehensweise: Die Kundenbetreuer ersuchten Entwickler ihrer Wahl wann es ihnen beliebte und baten sie, Anforderungen ihrer Kunden und Supporttickets schnell umzusetzen. Vertriebsmitarbeiter versprachen im Kundengespräch vor Ort Anpassungen an der Software, die Entwickler nun schnell ins nächste Release bringen mussten. Kundenbeschwerden wurden überhastet in Anpassungswünsche übersetzt.

Auf diese Weise war oft nicht klar,

  • was das nächste Release enthalten sollte,
  • ob kurzfristig noch weitere Umsetzungswünsche eintrudelten,
  • wie lange es noch dauern würde, bis das Release erfolgen konnte,
  • welche weiteren Anforderungen (außer der des konkreten Kunden) die Erweiterung auch zu erfüllen hat und
  • wie die Anpassung oder Erweiterung getestet werden soll

Es existierte zum Zeitpunkt der Einführung von Scrum noch kein Prozess, der sicherstellte, dass sämtliche neuen Softwareerweiterungen in die Dokumentation aufgenommen werden und der Kunde davon erfährt.

Die wichtigsten Ziele bei uns lauteten also:

  • feste Termine für Releases und kürzere Dauer bis zum nächsten Releasetermin
  • Transparenz bezüglich der Inhalte des nächsten Release
  • gebündelte Anforderungen möglichst vieler Kunden an Erweiterungen durch eine Produktmanager-Rolle (die es vorher nicht direkt gab)
  • deutlich mehr Aufwand und Planung für Test/Tests
  • eine vollständige Dokumentation
  • Schutz der Entwickler vor Störungen durch Vertriebler und Berater.

Agile Softwareentwicklung nach Scum: Beispiel Projektron

Derzeit arbeiten drei Scrum Teams an der Entwicklung von Projektron BCS inhouse in unserem Hauptsitz in Berlin. Jedes Entwicklungsteam arbeitet in zweiwöchigen Sprints, die jeweils um eine Woche versetzt starten. Nach dem Sprint folgt für jedes Entwicklungsteam versetzt der Zwischensprint, der Zeit für Weiterbildung, Support und Fehlerbehebung bieten soll.

Betrachten wir das gesamte Sprint-Schema wird klar, dass sich pro Woche immer zwei Teams im Sprint und ein Team im Zwischensprint befinden. Nach jeweils insgesamt zwölf Sprints erfolgt ein Produkt-Release. Nach diesem Plan stellen wir einen kontinuierlichen Produktionsrhythmus sicher, ohne unsere Entwicklung zu überlasten oder den notwendigen Blick über den Tellerrand inklusive Kundenkontakt zu vernachlässigen.

Jedes Team untersteht je einer Scrum-Masterin aus den Bereichen Dokumentation, Marketing und Personal. Marketing und Dokumentation bleiben so stets über den aktuellen Fortschritt der Produktentwicklung informiert und kommunizieren Neuentwicklungen und Anpassungen sofort und direkt an Kunden und Interessenten.

Hinzu kommen:

  • mehr als 20 Domain Product Owner
  • ein Produktmanagement-Kernteam
  • ein Chief Product Owner

Alle Beteiligten sind zertifizierte Scrum Masterinnen oder Scrum Product Owner und sind außerdem nach PRINCE2 oder IPMA zertifiziert.

Customized: Das unterscheidet Scrum bei Projektron vom Standard-Scrum

Wir führten im Dezember 2009 Scrum in der Softwareentwicklung bei Projektron als Vorgehensmodell mit nachhaltigem Erfolg ein. Dafür haben wir das Standard-Scrum-Vorgehen nicht einfach nach einer standardisierten Schablone übernommen, sondern wir haben es sukzessive besser an unsere spezifischen Erfordernisse angepasst.

Sechs große Anpassungen waren folgende:

  1. Wir haben die Rolle des Product Owner aufgeteilt: Es gibt inzwischen über 20 Domain Product Owner (DPO), die für bestimmte fachliche Features zuständig sind.
  2. Daneben gibt es ein dreiköpfiges Produkt-Kernteam und einen Chief Product Owner (CPO), der die strategische Richtung vorgibt und die Aufgabe der Priorisierung übernimmt. Den CPO gab es bei Projektron also schon, bevor er in die Scrum-Lehre einging.
  3. Als Scrum Master setzen wir drei Frauen aus den Abteilungen Marketing und Dokumentation ein. Da sie keine Entwickler sind, steuern sie keine eigenen fachlichen Gedanken zu technischen Fragen bei und bleiben im internen Diskurs neutral. Und da sie keine Berater sind, kommen sie auch nicht in Versuchung, Lösungen für ihre eigenen Kunden zu forcieren. Gleichzeitig bringen Sie täglich frische Motivation von Außen in die Entwicklerteams ein. Da die Scrum-Teams noch immer stark männlich dominiert sind, brechen wir somit bewusst Strukturen und Klischees auf und schaffen einen Anreiz für Entwicklerinnen, unsere Teams zu verstärken.
  4. Das Planning wurde in zwei Meetings aufgeteilt. Im zweiten Meeting bespricht das Entwickler-Team die User Storys im Detail ohne Anwesenheit des Product Owner.
  5. An jedem Montagnachmittag sind zwei Stunden für alle Entwickler reserviert, um Aufwände für interne und externe Anforderungen zu schätzen.
  6. Der Zwischensprint dauert bei Projektron eine Woche. Während dieser Zeit stellen die Entwickler jeweils eines Teams den kompetenten 3rd-Level-Support. Die beiden anderen Teams werden nie gestört und können konzentriert weiterarbeiten.

Die größte Anpassung hatte sehr positive Auswirkungen auf die Funktionalitäten unserer Software. Wir begannen zunächst damit, den aktuellen Stand des Sprints analog auf Zetteln zu notieren. Nach nur zwei Monaten war klar: Wir müssen die Darstellung in unsere Software Projektron BCS verlagern. Längst unterstützt Projektron BCS den Daily Scrum mit einem Aufgabenüberblick, der sich flexibel an unsere und auch Ihre Bedürfnisse anpassen lässt. Sprint-Status und Sprint-Fortschritt stellt BCS als Burndown Chart mit Cumulative-Flow-Diagramm grafisch dar.

Daneben nahmen wir weitere Anpassungen an Scrum vor, die wir inzwischen aber wieder abgeschafft haben. Sie erwiesen sich schlichtweg nicht gut genug oder praxistauglich für unsere individuellen Bedürfnisse. Zu Beginn nahmen beispielsweise zwei Entwickler nicht am Sprint teil, um den Support zu unterstützen und der Scrum Master war gleichzeitig Entwickler des damals einzigen Teams.

Heute nehmen alle Entwickler, gruppiert in drei Teams, am Sprint teil. Die Rollen der Scrum Master sind nicht mit Entwicklern besetzt, sondern mit Personen, die gleichzeitig die Schnittstelle zwischen Entwicklung, Marketing, Dokumentation und Support bedienen. Mit dieser Methode bleiben alle Mitarbeiter eng mit der Entwicklung verbunden.

Mit Scrum agil gen Zukunft: Ausblick

Geben wir uns mit diesem Status Quo zufrieden? Natürlich nicht. Wir optimieren unsere Prozesse und Vorgehensweisen kontinuierlich. Darüber hinaus stehen weitere tiefgreifende Veränderungen und Erweiterungen an. Aktuell stehen folgende Aufgaben auf dem Plan:

  • Die drei bisherigen Scrum-Teams sollen um ein viertes Entwicklungsteam erweitert werden.
  • Jedes Team soll sich Schritt für Schritt auf bestimmte Bereiche und Aspekte der Entwicklung spezialisieren.
  • Unsere eigene Projektmanagementsoftware soll die langfristige Releaseplanung noch besser unterstützen.

Über den Autor

Die Entwicklung bei Projektron setzt seit vielen Jahren auf die Softwareentwicklung nach Scrum. Eingeteilt in drei Scrum-Teams widmet sie sich der kontinuierlichen Weiterentwicklung von Projektron BCS und dem Umsetzen von kundenspezifischen Anpassungen. Dabei hat sie den Scrum-Prozess adaptiert und an die eigenen spezifischen Bedürfnisse und Anforderungen angepasst. Die agile Vorgehensweise ermöglicht vier BCS-Releases pro Jahr.

Nach oben

  

Vorteile & Nachteile von Scrum in der Softwareentwicklung

Vorteile & Nachteile von Scrum in der Softwareentwicklung

Alle Referenzen Seitenanfang