Eine Wand mit beschriebenen Notizzetteln

Methoden und Wissen

Software mit Scrum entwickeln: So geht's

11. August 2023 / Annekathrin Gut

Woher kommt Scrum?

Scrum ist eine Form der agilen Zusammenarbeit, die auf Flexibilität und Selbstorganisation des Teams setzt. Entstanden ist sie in der Softwareentwicklung in den 1990er Jahren und wird heute in vielen Bereichen eingesetzt. Ziel ist es, schneller funktionsfähige Softwareprodukte an die Kund:innen ausliefern zu können. Kurze Entwicklungszyklen sollen dafür sorgen, dass der gewünschte Nutzen für die Anwender:innen tatsächlich gewährleistet ist.

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“. Scrum ist ein Vorgehensmodell, das im Produkt- und Projektmanagement angewendet wird. Die Entwicklung läuft in Iterationen ab, den Sprints. Diese sind immer gleich lang - zwei bis vier Wochen - und geben den Entwicklungsrhythmus vor.

Nice to know: Der Begriff Scrum kommt aus dem Rugby und bezeichnet dort eine kreisförmige Aufstellung von zwei Mannschaften, die gemeinschaftlich versuchen, dem Gegner keinen Raum zu überlassen.

Wann ist Scrum sinnvoll?

Scrum hilft, komplexe Aufga­ben zu lösen. Es ist für Projekte geeignet, in denen viel Unklarheit herrscht. Häufig sind das Vorhaben, die nach neuen Lösungen suchen und deren Kombination aus unvorhersehbaren Risiken der Implementierung und noch unklaren Anforderungen bestehen. Auch dass das Ergebnis nicht vorhergesagt werden kann, spricht dafür, Scrum einzusetzen. Scrum ist weniger sinnvoll, wenn es um vorhersehbare Lösungen geht, also Lösungen, die standardisiert sind und bei denen das Ergebnis schon genau feststeht.

Projekte in der Soft­wa­re­ent­wick­lung fallen in die Kategorie "komplex". Sie müssen nicht nur zahl­rei­che indi­vi­du­elle Anfor­de­run­gen berück­sich­ti­gen, sondern auch auf sich häufig ändernde Rahmenbedingungen eingehen. Scrum bietet einen Rahmen, um den Entwick­lungs­pro­zess ausrei­chend koor­di­niert und dennoch flexi­bel und lern­fä­hig genug zu gestal­ten.

Wie funktioniert Scrum?

Scrum bietet einen klaren Rahmen für die Arbeit - ganz im Gegensatz zur unstrukturierten Aufgabenstellung und dem unvorhersehbaren Ergebnis. Das Vorgehensmodell umfasst

  • feste Rollen in einem Team,
  • Ereig­­nisse inner­halb bestim­m­ter Zeit­­span­­nen
  • und Arte­fakte als Wert oder Arbeitsergebnis.

Großer Vorteil ist das itera­tive und inkre­men­telle Vorge­hen: Es werden Schritt für Schritt kleine Lösun­gen erzeugt, die auspro­biert und konti­nu­ier­lich verbes­sert werden. Auf diese Weise nähern sie sich dem gewünsch­ten Ergeb­nis immer mehr an. Alle Lösun­gen sind inkre­men­tell, das heißt sie bauen aufein­an­der auf. Das Projekt wächst orga­nisch.

Rollen im Scrum Team

Die zentrale Rolle über­nimmt das Scrum Team. Es besteht aus Product Owner (PO), Scrum Master und Entwicklungsteam.

Eine Frau erläuternd vor einem Whiteboard

Product Owner

Der oder die PO wird in unse­ren Projek­ten meist vom Unter­­neh­­men gestellt, das den Auftrag vergibt. Er oder sie trägt die Verant­wor­tung für den Erfolg des Produk­tes. Die Product Owner sind also dafür verant­wor­t­­lich, dass die fertig­­ge­­stellte Soft­­ware einen Beitrag zur Wert­­ma­­xi­­mie­rung leis­tet.

Aufga­­be der Product Ownership ist es, zusam­­men mit den Stake­hol­­dern ein Zukunfts­­­bild für das Produkt zu entwi­­ckeln und für ein gemein­sa­­mes Verstän­d­­nis zu sorgen. Hierzu beschäf­tigen sich die PO mit den Anfor­­de­run­­gen an das Produkt und bringen diese in eine Reihen­­­folge (Prio­ri­­sie­rung), so dass Risi­ken früh­­zei­tig ange­­gan­­gen und der Nutzen des Produk­tes maxi­­miert wird.

Eine Frau redet mit Gesten

Scrum Master

Der oder die Scrum Master fördert die Zusam­­me­n­a­r­­beit des Scrum Teams (Wert­strom­­-Ma­­xi­­mie­rung). Diese Rolle ist dafür verantwortlich, Scrum einzuführen sowie das Team und die Kund:innen darin zu unterstützen, die agile Grundhaltung zu verstehen. Die Scrum Master sorgen dafür, dass sich alle an die Scrum-Prinzipien und -Praktiken halten. Damit erhöhen sie das Lernen und die Entwick­­lungs­­­ge­schwin­­dig­keit.

Entwicklungsteam

Das Entwicklungsteam ist cross-funk­ti­o­nal. Es enthält alle Kompe­ten­­zen, die es zur Umset­­zung der Aufgabe benö­tigt. In der HEC gehö­ren dazu übli­cher­­weise Soft­wa­re­ent­wick­­ler:innen, Qualitätsexpert:innen bzw. Tester:innen, Anfor­­de­rungs­­­ma­na­­ger:innen sowie UX-Desi­g­­ner:innen oder Security-Expert:innen.

Ereignisse

Das Herz von Scrum ist der Sprint: Inner­halb eines Zeit­fens­ters (time-box) von maxi­mal einem Monat wird ein ferti­ges, nutz­ba­res und poten­zi­ell auslie­fer­ba­res – oder noch besser: ein ausge­lie­fer­tes – Produktinkre­ment herge­stellt.

In fast allen unse­ren Projek­ten hat sich heraus­ge­stellt, dass zwei Wochen die opti­male Dauer für einen Sprint sind. Der Zeit­raum von 14 Tagen ist lang genug, damit ein Entwick­lungs­team neue Funk­ti­o­na­li­tä­ten mit tatsäch­li­chem Mehr­wert herstel­len kann. Gleich­zei­tig ist die Spanne kurz genug, um Feed­back von Auftrag­ge­ber:innen, Nutzer:innen und Stake­hol­der:innen einzu­ho­len. So können Fehl­ent­wick­lun­gen vermieden werden, die später nur schwer wieder zu korri­gie­ren wären.

Ein Sprint bein­hal­tet das Sprint Planning zu Beginn, die Daily Scrums (die tägliche Abstimmung des Entwicklungsteams), die eigentliche Entwicklungsarbeit und am Ende das Sprint Review sowie die Sprint Retrospektive. Außerdem müssen Zeiten für das Refinement eingeplant werden. Die klar vorgegebenen Ereignisse strukturieren die Entwicklung und verdichten die notwendige Kommunikation.

Scrum Ereignisse: Schritt für Schritt

Das Sprint Planning wird hier grafisch als Scetchnote in den Scrum Zusammenhang gestellt

1. Sprint Planning

Beim Sprint Planning legt das Entwicklungsteam das Sprintziel und die hierfür umzusetzenden Anforderungen gemeinsam fest.

Das Daily wird hier grafisch als Scetchnote in den Scrum Zusammenhang gestellt

2. Daily Scrum

Das tägliche Update des Entwicklungsteams. Es sollte nur eine Viertelstunde dauern!

Die Sprint Review wird hier grafisch als Scetchnote in den Scrum Zusammenhang gestellt

3. Sprint Review

Im Sprint Review werden die während des Sprints umgesetzten Funktionalitäten live am System präsentiert.

Die Sprint Retro wird hier grafisch als Scetchnote in den Scrum Zusammenhang gestellt

4. Sprint Retrospektive

Jeder Sprint wird mit einer Retrospektive abgeschlossen. Zeit für Reflexion und Verbesserung.

Artefakte

Scrum sieht drei Arte­fakte vor: das Product Back­log, das Sprint Back­log und das Inkre­ment.

Der PO berei­tet das Product Backlog vor (Refinement). Oft ist das Entwicklungsteam daran beteiligt. Die erfahrenen Scrum Master der HEC oder weitere Expert:innen können bei dieser Aufgabe unterstützen.

Beim Sprint Plan­ning legen PO und Entwick­lungs­team mit Blick auf das Product Back­log das Sprint­ziel und die hier­für umzu­set­zen­den Anfor­de­run­gen gemein­sam fest. Den Umfang bestimmt dabei allein das Entwick­lungs­team: Nur sie können realis­tisch einschät­zen, wieviel in dem gesetz­ten Zeit­raum zu schaf­fen ist.

Die Anfor­de­run­gen wandern in das Sprint Backlog. Schritt für Schritt und nach festgelegter Priorität werden sie abgearbeitet. Der Fortschritt ist jederzeit einsehbar. Bis zum Ende des Sprints soll eine den Anforderungen entsprechende Leistung - das Inkrement - entstehen.

Welche Rolle spielen die abschließenden Sprint Ereigniss?

Sprint Review

Im Sprint Review werden die während des Sprints umge­­setz­ten Funk­ti­o­na­­li­tä­ten live am System präsen­tiert. Die Präsen­ta­tion über­­­nehmen idea­le­r­­weise die PO. Auftrag­­ge­­ber:innen, idealerweise auch die Stake­hol­­der:innen, geben unmit­tel­­ba­res Feed­­back auf die Funk­ti­o­na­­li­tät des Inkre­­ments.

Alles was noch nicht oder unvoll­­­stän­­dig umge­­setzt wurde, verbleibt im Product Back­log. Ände­run­­gen, Ergän­­zun­­gen oder Fehler, die im Rahmen des Sprint Reviews erkannt werden, werden in das Product Back­log aufge­nom­­men. Die PO prio­ri­­sieren die Anfor­­de­run­­gen neu. Das Entwick­­lungs­­team zieht sich daraus die neuen Aufga­­ben für den nach­­fol­­gen­­den Sprint.

Das Produk­tin­­kre­­ment, das im Sprint erstellt wurde, wird spätes­tens direkt nach Abschluss des Sprints an den Auftrag­­ge­­ber über­­­ge­­ben. Nun kann es produk­tiv gesetzt werden, wenn das zu diesem Zeit­­punkt sinn­voll ist.

Retrospektive

Jeder Sprint wird mit einer Retro­­spek­tive abge­­schlos­­sen. Sie bietet dem Scrum Team die Gele­­gen­heit, sich selbst zu über­­prü­­fen und sich konti­­nu­ier­­lich zu verbes­­sern – und das im Zusam­­men­­spiel mit dem oder der PO des Kunden. Zum Vergleich: Im Sprint Review soll das Produkt selbst über­­­prüft werden. In der Retro­­spek­tive werden der Prozess und die Zusam­­me­n­a­r­­beit im Scrum Team unter­­sucht. Gemein­­sam werden Maßnah­­men zur Verbes­­se­rung erar­­bei­tet, die im nächs­ten Sprint umge­­setzt werden.

Agile Beratende der HEC im Gespräch

Bei der Einführung von Scrum und anderen agilen Methoden der Softwareentwicklung begleiten wir Unternehmen und ihre Teams. Machen Sie sich mit uns auf den Weg!