Scrum in der Softwareentwicklung: agil und strukturiert

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“. Das Scrum Framework ist 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.

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 ist für jedwede logistische Anforderung verantwortlich, 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 innerhalb der Projekte 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.

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 (auch "User Stories") 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 Sprint-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 (auch "Sprint Review"). 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 (auch "Sprint-Rückblick"). 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.

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. Die Liste wird ständig weiterentwickelt und enthält nach Priorität geornet alle Aufgaben, an denen das Scrum-Team arbeiten wird.
2. Das Sprint Backlog ist die Liste aller User Storys, die im Product Backlog mit der höchsten Priorität versehen wurden und daher innerhalb eines Sprints bearbeitet werden sollen.
3. Das Inkrement (englisch: Increment) 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.

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

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!

Scrum bietet eine Reihe von Vorteilen für die Softwareentwicklung. Durch die Verwendung von kurzen Sprints und regelmäßigen Meetings ermöglicht Scrum eine kontinuierliche Anpassung an sich ändernde Anforderungen. Dies ist ein entscheidender Vorteil in einer Branche, die von raschen Veränderungen und technologischem Fortschritt geprägt ist. Das Entwicklungsteam kann schnell auf Feedback reagieren und Änderungen vornehmen, um sicherzustellen, dass das Endprodukt den Bedürfnissen des Kunden entspricht. Dadurch wird vermieden, dass wertvolle Ressourcen in die Entwicklung von Funktionen investiert werden, die am Ende nicht benötigt werden oder nicht den gewünschten Mehrwert bieten.

Ein weiterer bedeutender Vorteil von Scrum ist die Förderung der Zusammenarbeit und Kommunikation im Team. Die verschiedenen Rollen und Meetings in Scrum sorgen dafür, dass alle Teammitglieder auf dem gleichen Stand sind und ein gemeinsames Verständnis der Ziele und Anforderungen entwickeln. Der Product Owner, der Scrum Master und das Entwicklungsteam arbeiten eng zusammen, um sicherzustellen, dass das Projekt erfolgreich umgesetzt wird. Diese enge Zusammenarbeit minimiert Missverständnisse und Fehlkommunikation und trägt zur Effizienz des Teams bei. Durch den ständigen Austausch von Informationen und die offene Kommunikation können Probleme frühzeitig erkannt und gelöst werden.

Ein weiterer Vorteil des Scrum Frameworks ist die Transparenz des Entwicklungsprozesses. Durch regelmäßige Meetings und die Nutzung von visuellen Artefakten wie dem Sprint-Backlog und dem Produkt-Backlog haben alle Beteiligten einen klaren Überblick über den Fortschritt des Projekts. Jeder kann sehen, welche Aufgaben erledigt wurden, welche noch ausstehen und wie der aktuelle Stand des Projekts ist. Dies ermöglicht es, Engpässe oder Verzögerungen frühzeitig zu erkennen und Maßnahmen zu ergreifen, um das Projekt wieder auf Kurs zu bringen. Die Transparenz fördert auch das Vertrauen zwischen dem Entwicklungsteam, dem Product Owner und anderen Stakeholdern, da alle den Fortschritt und die Herausforderungen des Projekts verstehen.

Ein endlicher Zeitrahmen, wie er in Scrum durch die Sprints gegeben ist, kann dazu führen, dass nicht alle Aspekte eines Projekts ausreichend abgedeckt werden. Während ein Sprint bestimmte Elemente und Aufgaben abdeckt, können andere wichtige Aspekte des Projekts möglicherweise vernachlässigt werden. Dadurch besteht das Risiko, dass das Endprodukt nicht alle gewünschten Funktionen oder Anforderungen erfüllt.

Ein weiterer Nachteil von Scrum ist die begrenzte Skalierbarkeit. Scrum wurde ursprünglich für kleinere Teams entwickelt und kann bei größeren Projekten oder in großen Unternehmen an seine Grenzen stoßen. Die Kommunikation und Koordination zwischen den Teammitgliedern kann schwieriger werden, wenn das Team größer wird. Dadurch können Informationen verloren gehen oder Missverständnisse auftreten, was sich negativ auf die Effektivität des Teams auswirkt.

Die Abhängigkeit von einem gut funktionierenden Team ist ein weiterer kritischer Aspekt von Scrum. Die Methodik setzt voraus, dass alle Teammitglieder gut zusammenarbeiten und ihre Aufgaben effektiv erfüllen. Wenn jedoch ein Teammitglied ausfällt oder nicht in der Lage ist, seinen Beitrag zu leisten, kann dies die gesamte Teamleistung beeinträchtigen.

Die starke Fokussierung auf die Sprint-Ziele kann dazu führen, dass andere wichtige Ereignisse oder Aufgaben außer Acht gelassen werden. Das Team konzentriert sich so stark darauf, das Sprint Ziel zu erreichen, dass andere dringende Anforderungen oder Kundenerwartungen nicht voll berücksichtigt werden. Dadurch kann es zu Engpässen oder eben Verzögerungen in anderen Bereichen kommen, die die Gesamtlage des Projekts beeinflussen.

Ein weiterer Nachteil von Scrum ist die mögliche Unvollständigkeit der Produkt-Dokumentation. Da Scrum insbesondere Wert auf die tatsächliche Entwicklung legt, besteht die Gefahr, dass eine wichtige Information, ein Ereignis oder eine Entscheidung nicht ausreichend dokumentiert werden. Dies kann zu Problemen führen, wenn das Team oder andere Stakeholder in Zukunft auf diese Informationen zugreifen müssen.

Die Einträge in den Backlogs können ebenfalls ein Problem darstellen. Wenn die Produkt-Anforderungen nicht klar definiert oder priorisiert sind, kann dies zu Verwirrung führen und die Effektivität des Teams beeinträchtigen. Wenn wichtige Elemente im Backlog fehlen oder nicht eindeutig beschrieben sind, kann dies zu Unsicherheiten und Missverständnissen führen.

Schließlich erfordert Scrum eine gute Kenntnis und Anwendung der Methodik. Wenn Teammitglieder oder Stakeholder nicht ausreichend mit Scrum vertraut sind, können Schwierigkeiten auftreten. Die korrekte Umsetzung der Scrum-Elemente und -Praktiken erfordert Schulungen und eine gewisse Zeit, um sich mit der Methodik vertraut zu machen.

Wir fassten den Entschluss, die agile Arbeit mit Scrum einzuführen, um eine höhere Zufriedenheit in der Entwicklung zu erreichen. Im Laufe des 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 immer 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 sicher gestellt hätte, dass sämtliche neue 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 Requirements 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.

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, eine Zeit, die für Weiterbildung, Support und Fehlerbehebung verwendet werden 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 steht in unserem System ein Produkt-Release. Nach diesem Plan halten wir einen kontinuierlichen Produktionsrhythmus ein, ohne unsere Entwicklung zu überlasten oder den notwendigen Blick über den Tellerrand inklusive Kundenkontakt zu vernachlässigen.

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.

Insgesamt erweist sich Scrum in unserer Softwareentwicklung eine flexible und effektive Methode, um ein hochwertiges Softwareprodukt wie Projektron BCS zu entwickeln. Indem es die Zusammenarbeit, Kommunikation und Transparenz fördert, ermöglicht Scrum unseren Teams, sich kontinuierlich zu verbessern und den Kundenanforderungen gerecht zu werden.

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.