Pragmatisches Projektmanagement

Herzlich Willkommen zu einer neuen Ausgabe vom Pragmatischen Projektmanagement, deiner Quelle für Informationen und Inspiration zu alltäglichen Herausforderungen im Management von Softwareentwicklungsprojekten. Dich erwarten Einblicke, Erfahrungen und unsere individuellen Ansichten zu Methoden, Werkzeugen, Vorgehensweisen und Fragen aus dem Leben eines Projektmanagers.

Gern diskutieren wir mit Euch auf LinkedIn zu Euren Erfahrungen und Ansichten.

Scrum ist eines der bekanntesten agilen Frameworks – und wird trotzdem oft missverstanden. Viele Teams sagen, sie „machen Scrum“, weil sie ein tägliches Stand-up durchführen. Doch Scrum ist weit mehr als das. Wenn du es wirklich verstehst und richtig anwendest, bekommst du ein leichtgewichtiges, aber kraftvolles System, das dir hilft, komplexe Projekte effektiv umzusetzen – mit Transparenz, klaren Rollen und einem ständigen Blick auf echten Mehrwert.

Die Basis: Rollen, Events und Artefakte

Scrum basiert auf drei Rollen, fünf Events und drei Artefakten.

Die drei Rollen:

1. Product Owner: Verantwortlich für den wirtschaftlichen Erfolg des Produkts. Die Person priorisiert die Anforderungen im Product Backlog und trifft Entscheidungen über den Mehrwert.
2. Scrum Master: Unterstützt das Team und schützt es vor Störungen. Die Person moderiert, coacht und sorgt dafür, dass Scrum verstanden und richtig gelebt wird.
3. Entwicklungsteam: Cross-funktional, selbstorganisiert, verantwortlich für die Umsetzung. Das Team plant, schätzt und liefert gemeinsam.

Die fünf Events:

1. Sprint: Der Herzschlag des Prozesses. Ein fester, zeitlicher Rhythmus, meist 1 bis 4 Wochen lang.
2. Sprint Planning: Was wollen wir im kommenden Sprint erreichen? Wie schaffen wir das?
3. Daily Scrum: Kurzes, tägliches Abstimmungsmeeting: Was habe ich erreicht, was will ich heute erreichen, was blockiert mich?
4. Sprint Review: Am Ende des Sprints wird das Inkrement vorgestellt, Feedback gesammelt.
5. Sprint Retrospektive: Hier reflektiert das Team: Was lief gut, was nicht, was verbessern wir im nächsten Sprint?

Die drei Artefakte:

1. Product Backlog – Eine priorisierte Liste aller bekannten Anforderungen.
2. Sprint Backlog – Die Aufgaben, die im aktuellen Sprint umgesetzt werden.
3. Inkrement – Das fertige, potenziell auslieferbare Produktstück am Ende des Sprints.

Diese Grundlagen sind sicher jedem Scrum-Anwender geläufig. Aber was macht den Unterschied zwischen erfolgreichem Scrum und Methoden-Theater aus?

Arbeit sichtbar machen

Scrum lebt von Transparenz. Das bedeutet: Arbeit muss sichtbar sein – für dich, für dein Team und für eure Stakeholder. Nur was sichtbar ist, kann gemeinsam verstanden, priorisiert und bearbeitet werden.

Ein Sprint Backlog, Taskboards, Burndown-Charts oder digitale Tools wie Jira, Trello oder Azure DevOps helfen, den Überblick zu behalten – besonders in verteilten Teams. Aber Vorsicht: Nur weil etwas irgendwo eingetragen ist, heißt das noch lange nicht, dass es wirklich sichtbar ist.

Viele Backlogs verkommen über die Zeit zu digitalen Müllhalden. Glaubst du nicht? Dann schau mal rein: Gibt es bei euch Epics, die längst „done“ sind, unter denen aber noch alte, unklare Tasks hängen? Oder vergessene Product Backlog Items, die keiner mehr auf dem Schirm hat? Für jeden Fund darfst du gern an den Sonnenstrahl e. V. spenden. 😉

Warum das ein Problem ist? Weil fehlende Sichtbarkeit direkt auf die Kapazitätsplanung wirkt. Wenn Aufgaben im Verborgenen erledigt werden – nebenbei, heimlich oder einfach schlecht dokumentiert – kann dein Team seine Arbeit nicht realistisch einschätzen. Ihr plant für fünf Tasks, arbeitet aber an acht. Oder ihr glaubt, alles sei im Flow, dabei hängt eine wichtige Aufgabe fest, ohne dass es jemand merkt.

Unsichtbare Arbeit führt zu Überlastung, Frust und Fehlplanungen. Niemand weiß, woran wer gerade wirklich arbeitet. Prioritäten verschwimmen, Verantwortlichkeiten sind unklar. Und es entstehen stille Heldengeschichten: Einzelne retten heimlich Projekte, statt dass das Team als Ganzes agiert.

Darum gilt: Alles kommt auf den Tisch. Keine geheimen Nebenaufgaben. Keine Sondertickets „für später“. Keine Tasks, die du „mal eben schnell“ nebenher erledigst. Wenn du etwas tust – schreib es sichtbar auf. Wenn etwas erledigt ist – zeig es. Wenn etwas blockiert ist – sprich es an.

Regelmäßige Stand-ups helfen enorm, den Status aktuell zu halten. Und ein gepflegtes Board ist nicht nur ein Kontrollinstrument – es ist ein Spiegel eurer Zusammenarbeit. Gute Teams nutzen diesen Spiegel zur Reflexion und Steuerung, nicht zur Kontrolle.

Frag dich also regelmäßig:

• Ist unser aktueller Arbeitsstand klar erkennbar?
• Gibt es Aufgaben, die im Verborgenen laufen?
• Versteht jeder im Team, woran gerade gearbeitet wird – und warum?

Arbeit sichtbar zu machen ist kein Selbstzweck. Es ist die Basis für echte Zusammenarbeit, kluge Planung und nachhaltige Ergebnisse.

Team-Performance messen – aber sinnvoll

Scrum ist nicht zahlengetrieben – aber das bedeutet nicht, dass du gar nichts messen solltest. Im Gegenteil: Einige einfache Metriken helfen dir und deinem Team, Muster zu erkennen, Blockaden aufzuspüren und die eigene Arbeitsweise kontinuierlich zu verbessern. Wichtig ist nur, wie du mit diesen Zahlen umgehst.

Typische Scrum-Metriken sind zum Beispiel:

• Velocity – Wie viele Story Points liefert das Team im Schnitt pro Sprint?
• Durchlaufzeit (Lead Time) – Wie lange dauert es vom Start eines Tasks bis zur Fertigstellung?
• Fehlerrate / Bug Count – Wie viele Nacharbeiten oder Fehler tauchen nach Abschluss auf?
• Teamzufriedenheit – Wie erlebt das Team die Zusammenarbeit, z. B. per monatlichem Mini-Stimmungsbarometer?

Diese Metriken sind keine Leistungsbeweise. Sie sind Werkzeuge zur Selbstbeobachtung, keine Mittel zur Kontrolle oder zum Vergleich zwischen Teams. Du solltest nie sagen: „Team A ist besser als Team B, weil es eine höhere Velocity hat.“ Stattdessen frag dich: Was sagt die Entwicklung der Zahlen über unser Team aus?

Ein Beispiel: Steigt eure Velocity langsam und stabil an, kann das ein Zeichen für mehr Routine, besseres Refinement und weniger Blocker sein. Fällt sie plötzlich, lohnt sich ein Blick hinter die Kulissen: Gab es viele Unterbrechungen? Neue Teammitglieder? Unklare Anforderungen?

Bei der Durchlaufzeit ist es ähnlich: Wird sie länger, kann das auf zu große Aufgaben, Wartezeiten oder schlechte Priorisierung hindeuten. Wird sie kürzer, habt ihr vielleicht bessere Schnittstellen geschaffen oder kleinere Stories definiert.

Was zählt, ist die Tendenz – und dein Verständnis der Ursachen. Eine Metrik wird erst wertvoll, wenn du sie im Kontext liest.

Nutze die Zahlen vor allem als Gesprächsanlass in Retrospektiven oder Reviews. Frage das Team:
„Was nehmen wir aus dieser Entwicklung mit?“
„Was hat gut funktioniert?“
„Was hat uns gebremst?“

Und: Gib den Metriken nicht zu viel Gewicht. Nicht alles lässt sich messen – Vertrauen, Teamgefühl und kreative Problemlösung schon gar nicht. Aber wenn du Metriken klug einsetzt, können sie helfen, Klarheit zu schaffen und echte Verbesserungen anzustoßen. Nutze Metriken nicht zur Kontrolle, sondern zur Reflexion. Und wenn sich ein Wert ändert – frag nicht „Was läuft falsch?“, sondern „Was hat sich verändert?“ und „Was lernen wir daraus?“ Das macht den Unterschied zwischen Zahlen und Erkenntnis.

Retrospektiven, die nichts bringen? Schau auf Muster – und auf Rollen

Du merkst es recht schnell, wenn eine Retrospektive zur Pflichtübung wird: Es kommen immer die gleichen Aussagen. Das Format ist monoton. Niemand spricht offen. Die Vorschläge klingen halbherzig – und landen danach im digitalen Nirwana.

Dabei ist die Retrospektive eines der mächtigsten Werkzeuge im Scrum-Framework. Sie ist der Ort, an dem ihr als Team innehaltet, Muster erkennt und Veränderungen bewusst gestaltet. Aber damit das gelingt, braucht es mehr als ein paar Post-its und die Frage „Was lief gut, was nicht?“

Ein Aspekt, der oft unterschätzt wird: Die Teamdynamik – und hier lohnt ein Blick auf das Modell von David Kantor, auch bekannt als „Four Player Model“. Dieses Modell beschreibt vier typische Gesprächsrollen, die in einem gut funktionierenden Team vorhanden sein sollten:

• Der Mover bringt neue Ideen ein und initiiert Veränderungen („Lasst uns das mal ausprobieren…“).
• Der Follower unterstützt Vorschläge und bringt sie in Bewegung („Das klingt gut – ich mach mit.“).
• Der Opposer hinterfragt kritisch, warnt vor Risiken oder Überforderung („Was, wenn das nicht klappt?“).
• Der Bystander beobachtet und reflektiert von außen („Ich sehe, dass wir oft an der gleichen Stelle hängenbleiben…“).

Wenn du das Gefühl hast, dass eure Retrospektive festgefahren ist, dann frage dich: Welche dieser Rollen sind in eurem Team sichtbar? Und noch wichtiger: Welche fehlen vielleicht?

Manche Teams bestehen fast nur aus „Followern“. Da wird alles abgenickt, aber wenig gestaltet. Andere haben dominante „Mover“, die alles dominieren – während Bystander und Opposer verstummen. Eine gute Retrospektive lebt davon, dass alle Rollen vorkommen dürfen. Du brauchst Ideen, Zustimmung, Kritik und Reflexion.

Wenn du als Scrum Master moderierst, achte darauf: Wer spricht viel? Wer gar nicht? Wer bringt neue Impulse – und wer stellt sich quer? All das ist wertvolles Feedback zur Teamkultur. Vielleicht braucht ihr bewusst Raum für die leisen Stimmen, vielleicht mal eine andere Methode – oder sogar ein 1:1, um unausgesprochene Konflikte aufzulösen.

Ein weiteres Warnsignal: Wenn sich durch Retrospektiven nichts ändert. Dann fehlt oft der Transfer. Gute Retro-Ergebnisse münden in konkrete, überprüfbare Maßnahmen. Ohne das wird es schnell frustrierend.

Du kannst dir nach jeder Retro ein kurzes Check-in gönnen:

• Haben wir heute ehrlich gesprochen?
• Haben wir echte Ursachen hinterfragt?
• Gibt es konkrete Maßnahmen – und wer treibt sie?

Retrospektiven sind kein Selbstzweck. Sie sind ein Hebel zur Weiterentwicklung – wenn du bereit bist, auch unbequeme Dinge anzuschauen und die Gruppenmuster zu hinterfragen. Und manchmal heißt das: Nicht das Format ändern, sondern das Gesprächsklima.

Definition of Done und Ready – was bedeutet „fertig“ eigentlich?

Ein weiteres Schlüsselelement in Scrum ist die Definition of Done (DoD). Sie beschreibt, wann etwas wirklich fertig ist. Nicht: „Es läuft bei mir lokal“, sondern: „Es ist getestet, dokumentiert, durch Code Review gegangen und im Hauptbranch.“ Die DoD ist dein Qualitätsversprechen – und sie hilft dir, Missverständnisse zu vermeiden.

Die Definition of Ready (DoR) dagegen sagt: Wann ist ein Backlog Item überhaupt „bereit“, um in einen Sprint zu gehen? Klare Akzeptanzkriterien, keine offenen Abhängigkeiten, gut geschätzt – so stellst du sicher, dass dein Sprint Planning nicht zum Rätselraten wird. Beide Definitionen sorgen für Klarheit. Du solltest sie gemeinsam im Team entwickeln und regelmäßig überprüfen. Und vor allem: Sie müssen gelebt werden, nicht nur in einem Wiki stehen.

Fazit

Scrum ist kein Zauberwerk, sondern ein klar strukturierter Rahmen, der dir hilft, Komplexität zu managen und echten Fortschritt zu machen. Aber: Es funktioniert nur dann wirklich gut, wenn du es ernst nimmst, verstehst und gemeinsam mit dem Team immer wieder reflektierst.
Also – wie läuft’s bei euch? Macht ihr „Scrum“, oder lebt ihr es wirklich? Wenn du magst, können wir gemeinsam deine Scrum-Prozesse analysieren – oder du holst dir direkt mein Retrospektiven-Checksheet. Sag einfach Bescheid!

Im nächsten Teil unserer Serie lassen wir Scrum und Kanban die Manage betreten. Bis dahin freue ich mich auf Eure Reaktionen auf LinkedIn.