Wenn man an sehr komplexen Softwareprojekten arbeitet und das in engem und kontinuierlichem Austausch mit dem Kunden, dann braucht es ein Projektmanagement, das nicht nur flexibel, sondern vor allem transparent ist. Deshalb setzen wir bei QuinScape auf agiles Projektmanagement nach dem SCRUM Framework. Unseren neuen Mitarbeiter*innen, die mit dieser Arbeitsweise noch nicht so vertraut sind, bietet unser Kollege Stefan Doll dazu einen SCRUM-Basisworkshop an.

 

 

SCRUM Master und Consultant Stefan Doll beim SCRUM Basisworkshop (Foto: Marie Langer)

 

 

Who is behind the code? In unserer Reihe „Who’s behind the code“ werfen wir einen Blick hinter die Kulissen von QuinScape! Wer sind die kreativen Köpfe, die an den besten Lösungen für unsere Kunden tüfteln? Welche Teams arbeiten täglich daran, dass niemand jemals wieder schlechte Entscheidungen treffen muss? Und wie sieht der ganz normale Arbeitsalltag unserer Mitarbeiterinnen und Mitarbeiter aus? Hier erzählen wir, wie Code made by QuinScape entsteht.

 

Agil zum Ziel: Lieber kurze Sprints als monolithische Blöcke

Bei QuinScape arbeitet Stefan seit 2019 als Consultant, SCRUM Master und Agile Coach. Den Ablauf großer Softwareprojekte kennt er von allen Seiten. Angefangen als Programmierer im Konzernumfeld mit klassischem Projektmanagement, interessierte er sich zunehmend für agile Arbeitsmethoden. Er ließ sich zum SCRUM Master qualifizieren und arbeitet auch als Agile Coach in einigen Unternehmen.

„Früher haben wir oft monatelang entwickelt, bevor man überhaupt ein Ergebnis hatte, mit dem man arbeiten konnte“, erinnert sich Stefan an seine frühe Zeit als Developer im Konzern. Softwareprojekte, von denen oft viele parallel liefen, glichen monolithischen Blöcken mit hunderten von Dokumenten und riesigen Projektabläufen mit Freigabeverfahren. „Niemand hatte damals auf dem Schirm, dass man solche Projekte auch einfach agiler machen könnte.“

Doch wo genau liegt der Unterschied zwischen klassischem und agilem Projektmanagement?

 

Für mehr Transparenz und eine bessere Zusammenarbeit mit dem Kunden

„Agiles Projektmanagement bedeutet, dass wir in kurzen Zyklen, in sogenannten Sprints, ein wertvolles Ergebnis in Bezug auf die Zielerreichung in einem Kundenprojekt schaffen“, erklärt Stefan. Innerhalb eines Sprints von beispielsweise vier Wochen entwickelt das Developer-Team ein konkretes Ergebnis, mit dem der Kunde dann auch schon arbeiten kann.

„Nimmt man als Beispiel die Entwicklung einer Website, kann ein erstes Ergebnis eine Seite sein, auf der Nutzer sich registrieren und in einem Katalog ‚blättern‘ können. Auch wenn die Website noch keinen Shop zur Online-Bestellung hat, was ein Ergebnis eines späteren Sprints sein könnte, ist die Möglichkeit, sich zu registrieren und in dem Angebot zu ‚stöbern‘, schon ein Wert, der darauf hinarbeitet.“

Sich kontinuierlich mit dem Kunden im laufenden Prozess auszutauschen und funktionierende Software zu liefern, anstatt über starre Zeit- und Featurepläne zu verhandeln, ist auch einer der Grundsätze agilen Arbeitens, festgelegt im Agilen Manifest.

Hier spricht man von „Working Software“. Heißt, ein funktionierendes Teilergebnis ist mehr wert als eine bis ins kleinste Detail ausgearbeitete Dokumentation, wie es beim typischen Lasten- und Pflichtenheft des klassischen Projektmanagements der Fall ist.

 

SCRUM als Framework für agiles Projektmanagement

 

Stefan Doll beim SCRUM Basisworkshop (Foto: Marie Langer)

 

Wenn es um agiles Arbeiten geht, haben sich verschiedene Methoden und Frameworks entwickelt. Neben SCRUM gibt es beispielsweise noch andere Methoden wie Kanban oder Design Thinking.

Für das SCRUM Framework sollte man sich diese Zahlen merken:

3, 5, 3+3.

Diese stehen für

  • 3 Verantwortlichkeiten (oder Rollen),
  • 5 Events,
  • 3 Artefakte,
  • 3 Commitments.

Worum es dabei genau geht, erklärt Stefan seinen Teilnemer*innen ausführlich in seinem Workshop. Hier gibt es eine kurze Übersicht:

 

Die drei Verantwortlichkeiten

Ein SCRUM-Team besteht aus Menschen, die drei unterschiedlichen Verantwortlichkeiten zugeordnet werden.

1) Product Owner

„Der Product Owner ist derjenige, der die Kundenseite vertritt“, sagt Stefan. „Das kann jemand aus dem Kundenunternehmen selbst sein. Bei uns ist es oft einer unserer Consultants.“ Die Verantwortung des Product Owners ist es, alle Kundenanforderungen aufzunehmen, zu beschreiben und dafür zu sorgen, dass sie jedem im Team bekannt sind.

2) SCRUM Master

Die Verantwortung des SCRUM Masters ist es vor allem dafür zu sorgen, dass die SCRUM-Regeln im laufenden Projekt eingehalten werden. „Der SCRUM Master hält dem Team den Rücken frei und kümmert sich darum, dass alle im Team vernünftig arbeiten und ihre beste Leistung abrufen können“, sagt Stefan.

3) Developer

Die Developer schließlich sind diejenigen, die das Projekt umsetzen, also z. B. die Software programmieren, testen und freigeben.

„Agiles Arbeiten bedeutet nicht, dass man keinen Plan macht, sondern dass man für kürzere Perioden plant.“

Die fünf Events

Zum SCRUM Framework gehören fünf Event-Formate, die nach bestimmten Regeln ablaufen und die ‚timeboxed‘ sind, das heißt, für diese Events gibt es einen Zeitrahmen.

1) Die Sprint-Planung

„Agiles Arbeiten bedeutet nicht, dass man keinen Plan macht, sondern dass man für kürzere Perioden plant“, sagt Stefan. Für die Planung eines Sprints, der in der Regel über vier Wochen geht, nimmt sich das Team am besten einen ganzen Tag Zeit.

„Hier geht es darum, ganz genau festzulegen, was wir in der nächsten Periode entwickeln wollen und welche Aufgaben erledigt werden müssen.“ Das ganze Team nimmt an der Planung teil. „Die Sprint-Planung ist so etwas wie ein Vertrag für das gesamte Team, der von allen unterschrieben wird.“ Der Plan, der am Ende des Tages herauskommt, ist für die Zeit des Sprints also Gesetz.

2) Das Daily

Das Daily ist sicherlich das bekannteste Event. „Es hat einen ganz speziellen Zweck“, betont Stefan: „Es soll Transparenz über die Arbeit im Team schaffen – nicht mehr und nicht weniger.“

Damit das gelingen kann, folgt es bestimmten Regeln: Es findet jeden Tag zur selben Zeit am selben Ort und im Stehen statt. Dauer: 15 Minuten. Auf keinen Fall länger!

Jedes Teammitglied schildert kurz den Stand der Dinge, was jeder am Tag geschafft hat und für den nächsten plant. Das kann auch mal bedeuten, dass man gar nichts geschafft hat. „Das Daily ist hier nicht als Statusbericht von einem Untergebenen an seinen Vorgesetzten zu verstehen“, sagt Stefan. „Es geht hier nur um Transparenz.“ Wenn es weiteren Klärungsbedarf gibt, dann kann man dies im Anschluss in 1:1-Besprechungen klären.

3) Review

Im Review zeigt das Team dem Kunden das Ergebnis eines Sprints. Das kann eine Präsentation am Ende des Sprints sein, aber auch innerhalb eines Sprints mehrere kleinere Vorführungen. Wichtig dabei: Zum einen, das Ergebnis sind keine Powerpoint-Slides und zum anderen, es werden nur Features gezeigt, die im Sinne des Kunden fertig sind. „Der Kunde kann diese Features am besten direkt ausprobieren und Feedback dazu geben.“

4) Retrospektive

Mit der Retrospektive als Team-internem Event wird der Sprint abgeschlossen. Hier werden Fragen geklärt, wie: Wie ist es gelaufen? Wie können wir uns im nächsten Sprint verbessern? Wie können wir in Zukunft besser zusammenarbeiten? Welches Feedback gab es vom Kunden? Wie setzen wir das in der nächsten Iteration um? Welche Prozesse haben funktioniert, welche nicht?

5) Der Sprint

Das fünfte Event ist der Sprint selbst, also der Zeitraum, in dem ein Teilergebnis entwickelt wird. Dieser liegt zwischen einer bis maximal vier Wochen. Wichtig dabei ist, dass sich das Team zu Anfang für eine bestimmte Sprintlänge entscheidet, die für alle folgenden Sprints im Gesamtprozess gleich bleibt.

Add-on: Das Refinement

Es gibt auch noch ein weiteres Event, das im SCRUM Framework nicht explizit benannt wird, aber dennoch wichtig ist: das Refinement. „Das Refinement ist dazu da, ein gemeinsames Verständnis davon zu schaffen, was demnächst geplant ist. Es ist sozusagen der kleine Blick in die Zukunft“, erklärt Stefan.

Das können beispielsweise Anforderungen sein, die in naher Zukunft anstehen und die schon Auswirkungen auf den aktuellen Sprint haben. Stefans Empfehlung für das Refinement: einmal pro Woche eine Stunde – am besten mit dem gesamten Team.

„Aufgaben die nicht zum Sprintziel passen, sollten am besten gar nicht erst gestartet werden.“

Die drei Artefakte

Bei den Artefakten handelt es sich um Komponenten im SCRUM Framework, die für Transparenz bei Aufgaben und Ergebnissen sorgen.

1) Sprint Backlog

Das Sprint Backlog ist die priorisierte Sammlung aller Aufgaben, die innerhalb eines Sprint-Zyklus erledigt werden sollen. In der Regel werden die Aufgaben in einem Sprint zusammengefasst, die auf das Erreichen des Sprintziels einzahlen. Das bietet eine gute Orientierung für das Team: Aufgaben die nicht zum Sprintziel passen, sollten am besten gar nicht erst gestartet werden.

2) Product Backlog

Beim Product Backlog handelt es sich um die vom Product Owner sortierten Projekt-Aufgaben, aus denen sich die einzelnen Sprint Backlogs zusammenstellen lassen. Hier werden alle Kundenanforderungen gesammelt und dann weiter spezifiziert, beispielsweise in einem Refinement.

3) Das Inkrement

Beim Inkrement handelt es sich um das oder die Ergebnisse eines Sprints, also beispielsweise ein bestimmtes Feature oder ein Stück Software, das bereits eine festgelegte Funktionalität besitzt.

„Das Product Goal steht wie ein großes Thema oder ein Motto über dem Product Backlog.“

Die drei Commitments

Erst vor Kurzem im SCRUM Framework festgelegt sind die drei Commitments. Auch sie unterstützen in Sachen Transparenz und helfen dabei, das Projekt besser zu steuern und voranzubringen.

1) Definition of Done

Hier geht es darum zu definieren, wann eine Aufgabe als erledigt gilt. Das kann beispielsweise mit einer Checkliste geschehen, die vorgibt, welche Schritte erledigt sein müssen.

2) Product Goal

Das Product Goal wird vom Product Owner festgelegt. Dahinter verbirgt sich das große Ziel, das mit dem Projekt oder Produkt erreicht werden soll. „Das Product Goal hilft dem Team ungemein bei der Planung der Sprints“, sagt Stefan. „Es steht wie ein großes Thema oder ein Motto über dem Product Backlog.“ Vom Product Goal lassen sich dann die Sprint Goals ableiten.

3) Sprint Goal

Das Sprint Goal gibt das Ziel des aktuellen Sprints vor. Auch hier hilft dieses Ziel bei der Orientierung und Auswahl der Aufgaben. In der Regel sollte ein Team im Rahmen der Sprintplanung auch als erstes ein Sprintziel für den zu planenden Sprint erarbeiten, bevor die Aufgaben dem Sprint zugeordnet werden.

 

Und jetzt Action: Lege einen Stundenplan für einen Sprint an

Diese SCRUM-Basics erarbeitet Stefan in seinem Workshop mit den Teilnehmer*innen. In kleinen praktischen Aufgaben lernen sie, sich in dem Framework zurechtzufinden. Stefan verzichtet dabei ganz bewusst auf Powerpoint-Präsentationen und lässt lieber Raum für agile Spiele und Fragen.

Um ein Gefühl für den zeitlichen Ablauf zu bekommen, erstellen die Teilnehmenden in jedem Workshop einen Stundenplan für alle Events eines Sprints. Was dabei schnell deutlich wird: Rund zehn Prozent der Arbeitszeit eines Sprints fallen auf die Events! Die sind für den Projekterfolg aber enorm wichtig und sollten deshalb nicht länger dauern als empfohlen!

Denn machen wir uns nichts vor: Die restlichen 90 Prozent sind nicht nur für die Projektarbeit reserviert. Schließlich gehören E-Mails, Telefon und Videocalls ebenfalls zum ganz normalen Arbeitstag dazu.

Stefans Tipp ist deshalb, gerade am Anfang peinlich genau auf die Regeln der SCRUM Guideline zu achten, bevor das Team seine eigene „Geschmacksrichtung“ entwickelt – und da muss der SCRUM Master sehr sattelfest sein.

 

 

Suchst Du nach einem Arbeitsplatz, der zu Deiner Lebenssituation passt? Dann schau auf unserer Karriereseite vorbei!

 

Das sind wir. QuinScape entstand 2001 aus einer Gruppe begeisterter IT’ler, die eine Chance darin sahen, mit moderner Softwareentwicklung den Weg in die digitale Zukunft zu gestalten. Diese unmittelbare Herkunft aus der Technik und die Begeisterung, etwas bewegen zu können, prägen uns bis heute. QuinScape unterstützt globale Markt- und Markenführer aus den Branchen Automotive und Pharma, aber auch viele Hidden Champions des deutschen Mittelstands darin, nie wieder schlechte Entscheidungen treffen zu müssen – durch herausragende Leistungen in Data Management, Analytics und Software Engineering. Alle Geschäftsführer sind leidenschaftliche Techniker. Entsprechend direkt läuft der Austausch zwischen ihnen und den Teams: Nicht Zahlen spielen die erste Geige, sondern Werte und Ideen. Als stetig wachsendes Unternehmen sind wir bereit, uns mit neuen Ideen auseinanderzusetzen. Um diesen kreativ begegnen zu können, ist eine offene Atmosphäre unumgänglich. Eitelkeiten, das Beharren auf Positionen und starre Hierarchien empfinden wir als vergeudete Arbeits- und Lebenszeit. An ihre Stelle setzen wir lieber etwas ganz Anderes: Wertschätzung sowie eine offene Diskussionskultur quer durch alle Bereiche. Daher sind eine „Open Door Policy“ aller Führungskräfte, innovatives Denken, Fehlerkultur, Experimentierfreudigkeit und Transparenz die Grundpfeiler unserer Haltung.