Agile Softwareentwicklung mit Scrum: Mit einem starken Team zum Erfolg

Teamarbeit ist in der Softwareentwicklung von entscheidender Bedeutung - eventuell von noch größerer Bedeutung als in vielen anderen Branchen. Muss hier doch eine Gruppe von Spezialisten, die es gewohnt sind, weitgehend selbstständig und auf sich selbst gestellt zu arbeiten, plötzlich als Team funktionieren. Und anstatt in einer Filterblase ungestört vor sich hin programmieren zu können, müssen nun Aufgaben verteilt, Abläufe koordiniert und Zeitpläne abgestimmt werden. 

Eine Herausforderung, an welcher schon so manches Projekt gescheitert ist. Eine der Methoden, welche dabei hilft diese Schwierigkeiten zu meistern, ist die agile Softwareentwicklung mit der Scrum-Methode.

In diesem Beitrag erfährst Du, welches die größten Herausforderungen in einem Team von Softwareentwicklern sind - und wie Du die Scrum-Methode in der Praxis anwendest, um eine reibungslose Teamarbeit zu gewährleisten. Sowie als Ergebnis von dieser einen raschen und erfolgreichen Projektablauf.

Inhaltsverzeichnis: 

1. Was ist agile Softwareentwicklung (mit Scrum)?
2. Was sind agile Methoden (zur Softwareentwicklung) - sowie deren Ziele?
3. Was bedeutet Scrum? (Zusammenfassung der “Methode”)
4. Wichtige Projektelemente und -begriffe des Scrum-Frameworks.
5. Mitglieder (und deren Rollen) im Scrum-Team.
6. Projektablauf und Vorgehen in einem Scrum.
7. Tipps zur praktischen Umsetzung und Best Practices der agilen Softwareentwicklung mit Scrum.

1. Was ist agile Softwareentwicklung (mit Scrum)?

Agile Methoden wurden erstmals Anfang der 1990er Jahre entworfen und in weiterer Folge beständig weiterentwickelt. Aufgrund des kurzen Entwicklungszyklus durch einen iterativen und inkrementellen Prozess (sich schrittweise in wiederholten Arbeitsschritten der optimalen Lösung annähernd) sind agile Methoden vor allem in Branchen weit verbreitet, in denen die Anforderungen relativ unbeständig sind. 

In den folgenden Kapiteln wollen wir Dir zunächst zum besseren Verständnis die Unterschiede zwischen traditionellen und agilen Entwicklungsmethoden erläutern. Außerdem gehen wir in weiterer Folge auf die Merkmale einer der beliebtesten dieser Methoden (Scrum) genauer ein.

2. Was sind agile Methoden (zur Softwareentwicklung) - sowie deren Ziele?

Dabei handelt es sich Projektmanagementmethoden, die sich dadurch auszeichnen, dass nur Produkte entwickelt werden, welche voll und ganz den Erwartungen des Kunden entsprechen. Dies wird durch kurze, intensive und sich wiederholende Arbeitszyklen sichergestellt, die eine schnelle Entwicklung - und gegebenenfalls eine ebenso rasche Überarbeitung - ermöglichen. 

Dafür wird das Gesamtprojekt zu Beginn in mehrere (kurze) Phasen aufgeteilt, welche in weiterer Folge nacheinander abgearbeitet werden. Sprich, um zur nächsten Projektphase weitergehen zu können, muss immer zuerst die vorhergehende komplett abgeschlossen sein. Und um eine Projektphase abschließen zu können, müssen wiederum alle Beteiligten (inklusive der Stakeholder) Ihre Zustimmung geben. Das bedeutet, diese müssen vollständig von den Ergebnissen der jeweiligen Phase überzeugt sein.

Der Schlüssel zum Erreichen von diesem Ziel liegt im ständigen Austausch der Teammitglieder untereinander, sowie der gleichermaßen konstanten Rücksprache mit den zuvor erwähnten Stakeholdern als externe Projektbeteiligte.

Agiles Programmieren bezieht sich demzufolge auf Methoden, die auf der Idee der iterativen Entwicklung basieren. Bei dieser werden Projekte von selbstorganisierten, fachübergreifenden Teams bearbeitet. Die größten Vorteile der agilen Entwicklung liegen darin, dass sie es einem Team ermöglicht, Ergebnisse schneller, mit höherer Qualität und Vorhersagbarkeit zu liefern, sowie besser auf Veränderungen reagieren zu können. Damit ist sie einer der einfachsten und effektivsten Prozesse, um eine theoretische Idee in eine praktische Softwarelösung umzusetzen. Die vier zentralen Werte der Agilität sind:

1. Die Interaktion zwischen den Teammitgliedern ist wichtiger als das strikte Befolgen von Prozessen und der Verwendung von Tools.
2. Eine funktionierende Software ist wichtiger als eine übermäßig detaillierte Dokumentation.
3. Das rasche Reagieren auf Veränderungen ist wichtiger als das blinde Ausführen eines zuvor festgelegten Planes.
4. Eine harmonische Zusammenarbeit mit dem Kunden ist wichtiger als zähe Vertragsverhandlungen.

Die Grundlage der agilen Softwareentwicklung wurde 2001 in schriftlicher Form im "Manifest für agile Softwareentwicklung" festgehalten. Dieses stellt eine bahnbrechende Denkweise für die Bereitstellung von Leistungen und die Zusammenarbeit mit Kunden dar. So beginnt sie beispielsweise schon damit, dass der Kunde schildert, wie das Endprodukt verwendet werden, und welches Problem es lösen, soll. Dadurch werden die Erwartungen des Auftraggebers an das Endprodukt für das Projektteam schon vor Beginn der eigentlichen Projektarbeit klar. 

Sobald dieses im Anschluss startet, durchläuft das Team einen sich wiederholenden Prozess des Planens, Ausführens und Auswertens. Im Laufe dieser Entwicklungsschleifen kann sich das finale Produkt noch einmal grundlegend ändern. Grundsätzlich soll es das sogar: Jedoch nur, um den Anforderungen des Kunden (und in weiterer Folge der Nutzer) besser zu entsprechen. Kontinuierliche Zusammenarbeit und Kommunikation - sowohl zwischen den Teammitgliedern als auch allen anderen Projektbeteiligten - ist wie bereits erwähnt, eine der Grundlagen von agilen Prozessen.

Agile Methoden bzw. Konzepte wie das Extreme Programming (XP) und Scrum lenken die Softwareentwicklung in kleinen, selbstverwalteten Arbeitsgruppen. Mit diesen können große Verbesserungen der Projektabläufe im Vergleich zu traditionellen Projektmanagementmethoden (wie z. B. dem Wasserfall-Modell oder im weiteren Sinn auch die Lean-Startup-Methode) erzielt werden. Drei Hauptprobleme, die während des Softwareentwicklungsprozess auftreten - und welche mit agilen Methoden deutlich vermindert werden - sind:

1. Unzureichende Kommunikation innerhalb des Teams. 
2. Mangelhafte Planung des Entwicklungsprozesses.
3. Ungenügende Software-Testung.

Ein  Konzept der agilen Methode, welches zur Entwicklung von Software breite Anwendung findet, ist wie bereits angesprochen Scrum. Um was es sich bei diesem genau handelt, wie es funktioniert und wie es vor allem praktisch angewandt wird, das erfährst Du in den folgenden Kapiteln.

3. Was bedeutet Scrum? (Zusammenfassung der “Methode”)

Scrum ist einfach erklärt ein Rahmenkonzept (Vorgehensmodell), das Teams hilft, zusammenzuarbeiten. Ähnlich wie eine Rugby-Mannschaft (daher der Name), die für das nächste wichtige Spiel trainiert, ermutigt das Konzept Teams, 

• durch Erfahrungen zu lernen, 
• sich selbst zu organisieren, während sie an einem Problem arbeiten, 
• sowie über ihre Siege und Verluste zu reflektieren, 

um sich kontinuierlich zu verbessern.

Definition (Deutsch) der Scrum-Methode: Scrum ist ein einfaches Rahmenwerk (Framework), das Einzelpersonen, Teams und Organisationen hilft, durch angepasste Lösungen komplexer Probleme Mehrwert zu schaffen.

Das Scrum-Modell wird zwar am häufigsten in der Softwareentwicklung verwendet, seine Prinzipien und Lektionen können aber auf alle Arten von Teamarbeit angewendet werden. Das ist einer der Gründe, warum es so populär ist. Scrum gehört grundsätzlich zu den agilen Projektmanagementmethoden - ist jedoch wie bereits erwähnt keine eigene Methode, sondern lediglich ein Rahmenwerk, welches eine Reihe von Meetings, Tools und Rollen beschreibt. Diese wirken zusammen, um Teams bei der Strukturierung und Verwaltung ihrer gemeinsamen Arbeit zu unterstützen.

Dabei ist Scrum einfach umzusetzen. Das Framework ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Theorie unbedingt erforderlich sind. Außerdem baut es auf der kollektiven Intelligenz seiner Anwender auf. Anstatt diesen detaillierte (und damit starre) Anweisungen zu geben, leiten die Regeln von Scrum ausschließlich die Beziehungen und Interaktionen zwischen ihnen. Sie geben somit die Freiheit zur selbstständigen Adaption der Vorgehensweise und Lösung von Problemen.

Innerhalb des vorgegebenen Rahmens können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt somit bestehende Praktiken lediglich - oder macht sie überflüssig - stellt aber keine eigene dar. In Summe gesehen macht Scrum nicht mehr als die relative Effektivität des aktuellen Managements, der Arbeitsumgebung und -techniken sichtbar, wodurch strukturelle Verbesserungen an diesen vorgenommen werden können.

Zum besseren Verständnis des Scrum-Konzepts ist es wichtig, die wichtigsten in diesem verwendeten Begriffe zu verstehen. Aus diesem Grund, haben wir Dir diese in der folgenden Liste übersichtlich zusammengestellt.

4. Wichtige Projektelemente und -begriffe des Scrum-Frameworks

• Der Product Backlog ist eine Checkliste, welche alle Anforderungen an die zu erstellende Software enthält.
• Die Weg zur Erstellung des fertigen Endprodukts wird in einzelne Abschnitte (Projektphasen) unterteilt, welche als Scrum Sprints bezeichnet werden. Diese haben in sich wiederum denselben Ablauf und dasselbe Ziel: Einzelne Funktionalitäten des Endprodukts fertigzustellen. Eine typische Dauer für einen solchen Sprint liegt zwischen 1-2 Wochen und einem Monat.
• Um den Abschluss einer Phase (Scrum Sprint) messen zu können, wird für diese eine Definition von Done erstellt. Dabei handelt es sich um die klare Definition, welche Teilfunktionen des Endprodukts in dieser Phase fertiggestellt werden müssen.
• Während jedes Sprints werden die wichtigsten User Stories aus dem Product Backlog ausgewählt und in das jeweilige Sprint Backlog überführt.
• Eine User Story beschreibt ein gewünschtes Feature (funktionale Anforderung) in erzählerischer Form. User Stories werden in der Regel vom Product Owner geschrieben und liegen in dessen Verantwortung.
• Das Sprint-Backlog wiederum ist die Checkliste für die jeweilige Wiederholung / Projektphase, welcher mit einer Definition of Done versehen wird.
• Die in einem Sprint zu leistende Projektarbeit wird als Scope bezeichnet.
• Und deren Ergebnis als Inkrement: Die nach einem Sprint vorliegende, gemäß der Definition of Done überprüfte und freigegebene Software.
• Das Team arbeitet an dem definierten Sprint Backlog und überprüft dabei täglich die geleistete Arbeit (erreichten Fortschritte) in einem kurzen Scrum Meeting, in welchem das gesamte Team zusammenkommt, um sich auszutauschen.
• Ein Scrum-Team arbeitet mit drei Prozessdokumenten - den sogenannten Scrum Artefakten: Dabei handelt es sich um die bereits erwähnten Sprint Backlog, Product Backlog und das Inkrement.
• Und umfasst drei Rollen: Product Owner, Scrum Master und das Entwicklungsteam. Diese arbeiten direkt an der Entwicklung des Produkts und sind den Stakeholdern zur Fertigstellung von diesem verpflichtet.

Doch mehr zu den einzelnen Rollen eines Scrum-Teams - sowie deren wichtigsten Aufgaben - im nächsten Kapitel.

5. Members (and their Respective Roles) of the Scrum Team

Ein Scrum-Team benötigt drei spezifische Rollen: Product Owner, Scrum Master und das Entwicklungsteam. Und da Scrum-Teams funktionsübergreifend sind, gehören zum Entwicklungsteam neben den Entwicklern außerdem Tester, Designer, UX-Spezialisten und OPS-Ingenieure. Die wichtigsten Rollen eines Scrum-Teams wollen wir an dieser Stelle genauer vorstellen.

1. Product Owner:

Ist dafür verantwortlich, den Wert des Produkts, das aus der Arbeit des Scrum-Teams resultiert, zu maximieren. Die Art und Weise, wie dies geschieht, kann je nach Organisation, Zusammensetzung der Arbeitsgruppe und Person des Product Owners selbst sehr unterschiedlich sein. Er ist außerdem verantwortlich für die effektive Verwaltung des Product Backlogs, welcher als übergeordnetes Tutorial alle Anforderungen an das zu erstellende Produkt (in diesem Fall, die zu programmierende Software) enthält. Diese Aufgabe umfasst die folgenden Tätigkeiten:

• Das Entwerfen und die eindeutige Festlegung des Projektziels,
• das Erstellen, klare Kommunizieren und Anordnen der Product-Backlog-Elemente, 
• sowie das Sicherstellen, dass das Product Backlog nachvollziehbar, einsehbar und verständlich ist.

Die oben genannten Aufgaben kann er entweder selbst übernehmen oder an andere delegieren. Unabhängig davon bleibt der Product Owner immer als letzte Instanz rechenschaftspflichtig.

amit er erfolgreich sein kann, müssen seine Entscheidungen von allen anderen im Projekt involvierten Personen akzeptiert werden. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs, sowie durch das einsehbare Inkrement (die nach einem Sprint vorliegende, gemäß der Definition of Done überprüfte und freigegebene Software), beim Sprint Review sichtbar.

Der Product Owner ist eine Einzelperson - kein Gremium - und kann somit die Bedürfnisse verschiedener Stakeholder repräsentieren. Dabei handelt es sich um externe Personen, Personengruppen oder Organisationen, die aktiv am Projekt beteiligt sind bzw. durch den Projektverlauf oder das Projektergebnis beeinflusst werden. Diejenigen, die den Product Backlog ändern wollen, können dies tun, indem sie versuchen, den Product Owner von den von ihnen angestrebten Änderungen zu überzeugen.

2. Scrum Master

Scrum Master: Dieser ist dafür verantwortlich, das Rahmenwerk so zu etablieren, wie es im Scrum-Guide definiert ist. Er tut dies, indem er alle dabei unterstützt, sowohl die Theorie als auch die Praxis des Modells zu verstehen. Und zwar nicht nur innerhalb des Scrum-Teams, sondern innerhalb der gesamten Organisation. Der Scrum Master ist des Weiteren hauptverantwortlich für die Leistungsfähigkeit und die Effektivität des gesamten Teams. Er erreicht dies, indem er es dazu befähigt, seine Vorgehensweisen und Arbeitsmethoden innerhalb der vorgegebenen Rahmenbedingungen zu hinterfragen und zu verbessern. Scrum Master sind echte Führungskräfte, die gleichzeitig dem Team als auch der übergeordneten Organisation dienen.

3. Entwicklungsteam (Development Team)

Sind die Personen im Scrum-Team, die bei jedem Sprint (eine wiederholbare feste Zeitbox, in der ein "fertiges" Produkt mit dem höchstmöglichen Wert erstellt wird) an der Erstellung eines bestimmten Aspekts des angepeilten Endprodukts beteiligt sind.

Die spezifischen Fähigkeiten, die vom Entwicklungsteam jeweils benötigt werden, sind breit gefächert und variieren mit dem Arbeitsbereich. Die Entwickler sind jedoch immer verantwortlich für:

• Das Erstellen des Plans für den jeweiligen Sprint (die Sprint Backlogs),
• die Qualität durch die Einhaltung der Definition von Done (Checkliste von Aktivitäten, die für jede Funktion des Produkts abgearbeitet werden muss)  zu sichern,
• ihren Plan jeden Tag in Richtung des Sprint-Ziels anzupassen und,
• sich gegenseitig professionell zur Rechenschaft zu ziehen, um die gesteckten Ziele zuverlässig zu erreichen.

Zusätzlich zu den drei Rollen des Scrum-Teams kommen noch die Stakeholder hinzu. Bei diesen handelt es sich wie bereits erwähnt um Personen, Personengruppen oder Organisationen, die aktiv am Projekt beteiligt sind oder durch den Projektverlauf bzw. das Projektergebnis beeinflusst werden. Das ist ein sehr weit gefasster Begriff, der eine genauso große Gruppe von Personen umfassen kann. So z. B.:

• Kunden (Auftraggeber),
• Investoren
• Nutzer (des Endprodukts),
• Zulieferer
• sowie Zwischenhändler und Wiederverkäufer,
• bis hin zu anderen Scrum-Teams innerhalb derselben Organisation.

In der Regel handelt es sich bei den Stakeholdern aber um den Kunden bzw. Auftraggeber (sowie eventuelle Investoren). Mit dem Input der Stakeholder stellt das Entwicklungsteam das gewünschte Produkt her. Dies geschieht mit Unterstützung durch den Product Owner. Dieser steht mit den Stakeholdern in Kontakt und sorgt dafür, dass das Entwicklungsteam immer genau über deren Vorstellungen, Anforderungen und Anmerkungen informiert ist.

6. Projektablauf und Vorgehen in einem Scrum

Bei der agilen Softwareentwicklung mit Scrum, werden folgende Phasen durchlaufen. Einzelne davon nur einmal - in der Regel zu Beginn oder am Ende des Scrums - andere wiederum wiederholen sich in jedem Sprint.

1. Organisation des Product Backlog: Manchmal auch als Backlog Grooming bekannt, liegt dieser Vorgang in der alleinigen Verantwortung des Product Owners. Die Hauptaufgaben von diesem sind wie bereits angesprochen, das Produkt in Richtung seiner Vision voranzutreiben, sowie einen ständigen Kontakt zum Markt und den Kunden zu halten. Daher pflegt er diese Checkliste mit Hilfe des Feedbacks von Benutzern und dem Entwicklungsteam, um sie sauber und organisiert zu halten. Schließlich werden auf Basis von ihr nicht nur die Prioritäten im Projekt gesetzt, sondern ebenso Aufgaben erstellt und verteilt.
2. Sprint-Planung: In diesem Meeting wird unter Anwesenheit des kompletten Entwicklungsteam, die im aktuellen Sprint zu leistende Arbeit (Scope), geplant. Es wird vom Scrum Master geleitet und ist der Ort, an dem gemeinsam über das jeweilige Sprint-Ziel entschieden wird. Aus dem Product Backlog werden in weiterer Folge, die zum Ziel passenden User Stories, zum Sprint hinzugefügt. Diese stimmen nicht nur mit dem Ziel überein, sondern werden auch vom gesamten Team als realistisch angesehen. Nach diesem Planungsmeeting muss jedem Teammitglied klar sein, welche Funktionen am Ende des Sprint geliefert werden müssen - und wie er selbst zum Erreichen von diesen beitragen kann.
3. Sprint: Ist der tatsächliche Zeitraum, in dem das Scrum-Team zusammenarbeitet, um eine zusätzliche Funktionalität der zu entwickelnden Software fertigzustellen. Zwei Wochen sind eine typische Länge für einen Sprint. Manche Teams empfinden allerdings eine Woche als passender, um den Arbeitsumfang in einem überschaubaren Rahmen zu halten. Andere wiederum einen Monat, um ernsthafte Fortschritte am Produkt zu ermöglichen. Dave West von Scrum.org rät, dass je komplexer das Projekt und je mehr Unbekannte, desto kürzer sollte ein Sprint jeweils sein. Am Ende ist die Sprint-Dauer jedoch immer eine Teamentscheidung, welche sich vor allem aus der praktischen Projekterfahrung ergibt. Dies ist schlussendlich der Kern der empirischen Natur von agilen Methoden wie Scrum.
4. Täglicher Scrum oder Stand Up: Dies ist ein super kurzes Meeting, das jeden Tag zur gleichen Zeit (normalerweise morgens) und am gleichen Ort stattfindet. Viele Teams versuchen, das Meeting in 15 Minuten zu absolvieren - das ist allerdings nur ein grober Richtwert. Dieses Meeting wird auch als "Daily Stand Up" bezeichnet, um zu betonen, dass es möglichst kurz sein muss. Das Ziel von ihm ist, dass alle im Team auf einer Linie sind, sich am Sprint-Ziel orientieren und einen Plan für die nächsten 24 Stunden haben. Das Stand Up ist außerdem der Zeitpunkt, um etwaige Bedenken bezüglich des Erreichens des Sprint-Ziels zu äußern oder am letzten Arbeitstag aufgetretenen Probleme zu besprechen. Eine übliche Art, ein Stand Up durchzuführen, besteht darin, dass jedes Teammitglied die drei immer gleichen Fragen beantwortet:

1. Was habe ich gestern getan?
2. Was plane ich heute zu tun?
3. Gibt es irgendwelche neu aufgetauchten Hindernisse oder Probleme?

Sprint-Review: Am Ende des Sprints

Sprint-Review: Am Ende des Sprints kommt das Team noch einmal zu einem ausführlichen (dieses Mal allerdings informellen) Treffen zusammen, um sich eine Demonstration der fertiggestellten Funktionen anzusehen oder diese gleich selbst zu überprüfen (agiles Testen). Das Entwicklungsteam präsentiert die Backlog-Elemente, die nun "fertig" sind, den Stakeholdern und Teamkollegen, um Feedback zu erhalten. Der Product Owner hat dabei das letzte Wort, ob diese freigegeben werden können - oder eben auch nicht. Dieses Review-Meeting ist außerdem der Zeitpunkt, an dem der Product Owner das Product Backlog basierend auf den Ergebnissen des gerade abgeschlossenen Sprints überarbeitet. Damit können die Erfahrungen und Rückschlüsse aus diesem bereits in die nächste Sprint-Planungssitzung mit einfließen.

Sprint-Nachbearbeitung:

Das ist der Zeitpunkt, an dem das Team zusammenkommt, um zu besprechen, was in einem Sprint funktioniert hat - und was nicht. Dabei kann es sich um (konstruktive) Kritik an einzelnen Teammitgliedern, der Kommunikation untereinander, Tools oder bestimmten Abläufen handeln. Die Idee ist, einen Ort zu schaffen, an dem sich das Team darauf konzentrieren kann, was gut gelaufen ist - und somit beibehalten werden kann. Sowie, was für das nächste Mal verbessert werden muss.

Soweit die Theorie zum Ablauf einer agilen Softwareentwicklung mit Scrum. Weil aber die Theorie selten im ersten Anlauf reibungslos in die Praxis umgesetzt werden kann, möchten wir Dir zum Abschluss noch einige Tipps und Best Practices zur praktischen Umsetzung mit auf den Weg geben.

7. Tipps zur praktischen Umsetzung und Best Practices der agilen Softwareentwicklung mit Scrum

In diesem Kapitel haben wir basierend auf unserer praktischen Erfahrung einige der häufigsten Probleme zusammengestellt, welche bei der Teamarbeit mit der Scrum-Methode auftreten können. Sowie natürlich auch gleich die Best Practices zur Lösung von diesen.

1. Täglicher Scrum oder Stand Up: Wir haben oft erlebt, dass sich das Meeting recht schnell in ein Ablesen der Kalendereinträge des vergangenen und des nächsten Tages verwandeln kann. Die Theorie hinter dem Stand-up ist jedoch, dass sich der Austausch innerhalb des Teams auf ein tägliches Meeting beschränkt, damit sich dieses den Rest des Tages voll und ganz auf seine Arbeit konzentrieren kann. Falls das Stand-Up-Meeting sich also in eine Vorlesestunde verwandeln sollte, scheue Dich nicht davor, dies offen anzusprechen, um den Fokus wieder auf einen echten Informations- und Erfahrungsaustausch zu richten.
2. Dokumentation: Die Scrum-Methode - wie auch andere agile Softwareentwicklungsmethoden - reduziert den Umfang der Dokumentation erheblich.  In der Tat postulieren agile Methoden, dass der Code selbst die Projektdokumentation sein sollte. Aus diesem Grund hinterlassen Entwickler, die an agile Methoden gewöhnt sind, mehr Kommentare im Code. Unerfahrene Programmierer, die an Bereichen des Systems arbeiten, an denen sie noch nie zuvor gearbeitet haben, empfinden diese Arbeitsweise oft als schwierig.  Eine Lösung für diese Herausforderung kann eine ausführbare Dokumentation sein. Sprich deren kontinuierliche Anfertigung schon während der Arbeit am Projekt (dem Entwickeln der Software). Diese ausführbare Dokumentation besteht ausschließlich aus der Dokumentation, welche den Stakeholdern am Ende des Projekts als Teil des Produkts zur Verfügung gestellt werden muss. Dies ist natürlich von Projekt zu Projekt unterschiedlich, aber sie umfasst normalerweise Dokumente wie Benutzer- Betriebs- und Support-Handbücher, Schulungsunterlagen, und / oder Systemübersichten. Sie umfasst allerdings in der Regel keine Anforderungs- oder Designspezifikationen - was sie auf das Wesentliche reduziert. Dadurch ist zwar einerseits ausreichend Dokumentation vorhanden, um den unerfahrenen Teammitgliedern als Leitfaden zu dienen. Andererseits hält sich der Dokumentationsaufwand in einem überschaubaren Rahmen und kostet so den erfahrenen Entwicklern nicht unnötig wertvolle Arbeitszeit.

Einbindung des Kunden in den Softwareentwicklungsprozess: Die enge Kooperation mit dem Auftraggeber ist zwar von entscheidender Bedeutung für den Erfolg des Projekts. Die agilen Methoden selbst besagen, dass der Kunde von den ersten bis zu den letzten Schritten Teil des Prozesses sein sollte. In der Praxis zeigt sich jedoch, dass die Entwickler oftmals Schwierigkeiten haben, mit den Kunden gemeinsam an einem Projekt zu arbeiten. Denn oft weiß dieser nicht genau, was er in seinem zukünftigen Software-System wirklich benötigt und demzufolge in dessen Programmierung inkludiert haben möchte. Ein Umstand, der ihn daran hindern kann, sich voll und ganz in das Projekt mit einzubringen. Genauso wie es dem Team aufgrund der unklaren Kundenanforderungen schwer fallen kann, festzulegen, was die nächsten Schritte in der Projektentwicklung sein sollen. Um die Kommunikation mit dem Kunden zu verbessern, eignen sich unserer praktischen Erfahrung nach verschiedene Ansätze. Zu diesen gehören:

• Bestimme einen einzigen Ansprechpartner: Da es schwierig für den Kunden sein kann, mit einer kompletten Arbeitsgruppe zu arbeiten. Bestimme als diesen außerdem eine Person, welche die Bedürfnisse des Unternehmens (Kundens) versteht und sie der Gruppe effektiv vermitteln kann.
• Plane strategisch: Anstatt Meetings im gemeinsamen Konferenzraum zu planen, plane sie im Büro des Unternehmensvertreters. Dort fühlt er sich zuhause - und somit sicherer.
• Verwende Personas: Um die geschäftlichen Anforderungen besser zu verstehen und die Zusammenarbeit voranzutreiben. Dieses Hilfsmittel ist zwar imaginär, kann aber trotzdem sehr effektiv eingesetzt werden, um ein genaueres Verständnis für den Kunden, sowie in weiterer Folge eine effizientere Kommunikation, zu erreichen.
• Teste die Software gemeinsam: Veranstalte eine Lunch-and-Learn-Sitzung oder einen Workshop mit echten Daten statt nur einer Demo. Durch diese praktische Vorführung erhält der Kunde ein viel deutlicheres Bild vom Ist-Zustand seiner Softwarelösung. Und was dieser eventuell noch fehlen könnte, um eine echte Problemlösung für seine Nutzer darzustellen.
• Vermittle wie wichtig eine funktionierende Kommunikation ist: Erkläre die Bedeutung von anwendbarem Kundenfeedback.
• Belohne die Zusammenarbeit: Erkenne den Beitrag des Kunden an, indem Du ihn zu Teamevents einlädst oder ihm eine Benachrichtigung schickst, jedes Mal wenn ein größerer Meilenstein erreicht wird. Etwas, wie z. B. der 100. vom System generierte Bericht.

Mit diesen praktischen Tipps und Best Practices zur agilen Softwareentwicklung mit Scrum sind wir auch schon am Ende unseres Beitrags angelangt. Wir hoffen, die hier aufgeführten Informationen und Praxisbeispiele sind Dir bei Deinem eigenen Softwareentwicklungsprojekt hilfreich. Falls Du dabei doch etwas Unterstützung benötigen solltest, laden wir Dich ein mit uns Kontakt aufzunehmen, um für Deine Softwareentwicklung auf unser erfahrenes Team zurückzugreifen - wir freuen uns auf Deine Nachricht. So sparst Du wertvolle Zeit für Deinen Launch, welche Du in den Aufbau Deines eigenen Teams investieren kannst. Damit Du die nächste Produktentwicklung komplett Inhouse stemmst!