GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Hier erhalten Sie einen schnellen, aber detaillierten Überblick über das Scrum Framework. Dieses Whitepaper "Scrum in a Nutshell" beschreibt die wichtigsten Scrum-Rollen, Scrum-Artefakte und Scrum-Zeremonien.
Scrum - Das Agile Framework
Scrum ist ein Framework, das eine iterative und inkrementelle Produktentwicklung ermöglicht, die es erlaubt, Dinge zur richtigen Zeit zu erledigen und den Wert des Gelieferten zu maximieren. Aufgaben werden von selbstorganisierenden Teams schneller und mit höherer Qualität ausgeführt. Es wird ein hohes Maß an Selbstmotivation erreicht und ist der Grund dafür, dass Teams mit Scrum schneller eine höhere Produktivität erreichen können. Kundenanforderungen werden ständig nach dem Geschäftswert priorisiert und in regelmäßigen Abständen in das Produkt integriert, so dass der Kunde dem Team umgehend Feedback geben kann und somit die Qualität des Produkts rechtzeitig verbessert wird.
Ein Scrum-Projekt beginnt meist mit einer Vision des zu entwickelnden Produkts oder Systems. Die Vision mag anfangs vage sein und sicherlich eher auf Marktfragen als auf technische Begriffe bezogen sein. Im weiteren Verlauf des Projekts wird sie klarer. Aus dieser Vision heraus schreibt der Product Owner das Product Backlog.
Zu Beginn einer Iteration (Sprint) legt der Produkteigentümer dem Team das priorisierte Product Backlog vor, das auswählt, was seiner Meinung nach bis zum Ende des Sprints in einen Zuwachs an potenziell lieferbaren Funktionen umgewandelt werden kann. Auf diese Weise wird das Sprint Backlog erstellt. Danach wird das Team mit der Entwicklung der von ihm gewählten Funktionen allein gelassen. Das Team befasst sich nun eingehender mit den Anforderungen, betrachtet die verfügbare Technologie und bewertet seine eigenen Fähigkeiten und Fertigkeiten. Dann legt es gemeinsam fest, wie die Funktionalität aufgebaut werden soll, wobei es seinen Ansatz täglich modifiziert, um neue Komplexitäten oder Schwierigkeiten herauszufinden. Das Team findet heraus, was zu tun ist, und wählt den besten Weg dazu aus. Dieser kreative Prozess ist der Kern der Scrum-Produktivität. Am Ende des Sprints präsentiert das Team dem Product Owner das Inkrement der Funktionalität, damit er einerseits die Funktionalität überprüfen und andererseits rechtzeitig Anpassungen am Projekt vornehmen kann.
Scrum-Rollen - Scrum kennt 3 Rollen:
Alle Verantwortlichkeiten für die Leitung des Projekts sind auf diese drei Rollen verteilt.
Product Ownwer
Der Product Owner vertritt die Interessen aller am Projekt Beteiligten (Stakeholder) und ist für das Endprodukt verantwortlich. Er eruiert die Produktanforderungen vom Stakeholder, erstellt das Product Backlog (Anforderungen aufgeschlüsselt in User Stories), ist verantwortlich für den Return on Investment (ROI) und erstellt den Release-Plan. Der Product Owner priorisiert das Product Backlog anhand von Business Value Points, um sicherzustellen, dass die wertvollste Funktionalität zuerst entwickelt wird.
Die Spannung zwischen dem, was das Unternehmen will, und dem, was das Team tun kann, macht Scrum zu einem so effektiven Mittel für eine qualitativ hochwertige Produktion.
Das Scrum Team
Das Team findet heraus, wie man das Product Backlog in eine Erweiterung der Funktionalität innerhalb eines Sprints verwandeln kann. Jedes Teammitglied ist für den Erfolg jeder Iteration und des Projekts als Ganzes mitverantwortlich. Das Team ist verantwortlich für/an:
Der Scrum-Master
Der Scrum Master ist für den Scrum-Prozess verantwortlich. Er stellt sicher, dass sich alle an die Regeln halten. Er beseitigt auch Hindernisse für das Team. Der Scrum Master ist nicht Teil des Teams.
Die drei beschriebenen Rollen haben sich dem Projekt verpflichtet. Andere sind vielleicht nur an dem Projekt interessiert (beteiligt), aber sie sind nicht am Haken. Scrum macht eine klare Trennung zwischen diesen beiden Gruppen. Engagiert: Die Rollen, die für das Projekt verantwortlich sind, haben die Autorität, das zu tun, was für den Erfolg des Projekts notwendig ist. Beteiligt: Die anderen Stakeholder, die nicht für den direkten Erfolg verantwortlich sind, können sich nicht unnötig einmischen. Es sollte immer klar sein, wer zum Beispiel für den ROI verantwortlich ist und wer einen Anteil am ROI hat, aber nicht rechenschaftspflichtig ist.
Scrum-Artefakte - Scrum kennt 3 Hauptartefakte:
Produkt-Backlog
Die Anforderungen an das Produkt sind im Product Backlog aufgeführt. Es handelt sich dabei um eine sich ständig ändernde, dynamisch priorisierte Liste von Anforderungen, geordnet nach Geschäftswert. Die Anforderungen werden nach dem Bestellwert in User Stories aufgeschlüsselt.
Burndown-Chart
Das Burndown-Chart zeigt den verbleibenden Arbeitsaufwand pro Sprint. Es ist ein sehr nützliches Mittel, um die Korrelation zwischen der zu einem beliebigen Zeitpunkt verbleibenden Arbeit und dem Fortschritt der Mannschaft(en) zu visualisieren. Mit Hilfe des Burndown-Charts wird der Fortschritt der Mannschaft(en) in Bezug auf die Planung überprüft und bei Bedarf Anpassungen vorgenommen.
Sprint-Backlog
Das Sprint Backlog enthält alle engagierten User Stories für den aktuellen Sprint, aufgeschlüsselt nach Aufgaben des Teams. Alle Punkte des Sprint Backlogs sollten entwickelt, getestet, dokumentiert und integriert werden, um die Verpflichtung zu erfüllen.
Potentially Shippable Product Functionality
Scrum erfordert von den Teams, bei jedem Sprint eine Erweiterung der Produktfunktionalität zu erstellen. Dieses Inkrement muss potenziell lieferbar sein, da der Product Owner sich möglicherweise dafür entscheidet, die Funktionalität sofort zu implementieren. Dies setzt voraus, dass das Inkrement lieferbar ist:
Scrum und Projektsteuerung bewusst aufeinander beziehen. Klären Sie, welche Entscheidungen das Team im Sprint trifft und welche übergreifend beim Projektmanagement liegen. Eine gemeinsame Beispielsituation macht widersprüchliche Erwartungen früh sichtbar.
Eine fachliche Auseinandersetzung mit der Verbindung von verbindlicher Projektsteuerung und agilen Arbeitsweisen. Die Themen reichen von klaren Verantwortlichkeiten über Entscheidungsprozesse bis zur verlässlichen Lieferung.
Von Dr. Markus Groß
Aus „Scrum in a Nutshell“ lässt sich mehr gewinnen als eine Momentaufnahme. Die nachfolgende Vertiefung ordnet für Auswahl der Praktiken ein, welche Annahmen geprüft und welche Konsequenzen organisatorisch sauber umgesetzt werden sollten.
Der Ausgangspunkt dieses Beitrags führt beim Aspekt „Scrum in a Nutshell“ zu einer klaren Prüffrage: Es ist zu klären, welche Entscheidung nicht an Technik oder Dokumentation delegiert werden darf. Beim Schwerpunkt „Scrum in a Nutshell“ geht es um ein Management- oder Governance-Framework und seine praktische Nutzung sowie um den Bezug zu „Methodenumfang“; zu entscheiden ist, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Reifeentwicklung“), ohne das Framework zum Selbstzweck zu machen. Die Grenze der Betrachtung bleibt eindeutig: Ein Framework liefert Orientierung (hier bezogen auf „Integration“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Für den nächsten Review wird vereinbart: Zielkonflikt, Optionen, Konsequenzen und Empfehlung entscheidungsreif verdichten; im vorliegenden Abschnitt wird dies an „Auswahl der Praktiken“ konkretisiert. Der vorgesehene Nachweis lautet: eine nachvollziehbare Managemententscheidung mit Auftrag; „Reifeentwicklung“ liefert dafür den praktischen Anwendungsfall. Als Messperspektive dient: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung; der konkrete Prüfmaßstab wird aus „Reifeentwicklung“ abgeleitet. Die bisherige Diskussion liefert mit „klare Zuständigkeiten und Entscheidungsrechte“ einen zusätzlichen Prüfstein; er sollte mit „Methodenumfang“ verbunden und nicht isoliert bewertet werden.
Der Beitrag gewinnt beim Aspekt „Methodenumfang“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, wie Störungen, Rückfragen und Ausnahmen zur Verbesserung genutzt werden. Beteiligt sind hier vor allem Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision; ihre Perspektiven treffen beim Aspekt „Auswahl der Praktiken“ unmittelbar aufeinander. Besondere Aufmerksamkeit verdient das Szenario, in dem Terminologie und Prozessbilder wachsen (hier bezogen auf „Prozessnutzen“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben. Die praktische Konsequenz heißt: Muster regelmäßig auswerten und Regeln gezielt anpassen; „Verbesserungsschritt“ liefert dafür den praktischen Anwendungsfall. Für Audit und Führung reicht Aktivität nicht aus; die Bewertung erfolgt hier aus der Perspektive „Prozessnutzen“. Benötigt wird folgender Nachweis: eine Änderung, deren Anlass und erwartete Wirkung dokumentiert sind; bewertet wird außerdem: der Zusammenhang zwischen „Methodenumfang“ und „Auswahl der Praktiken“. Beim Aspekt „Auswahl der Praktiken“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Der nächste sinnvolle Schritt für „Managementbedarf“ trennt Aussage, Voraussetzung und Konsequenz voneinander: Es ist zu klären, welches stärkste sachliche Argument gegen die bevorzugte Lösung spricht. Als belastbare Grundlage dienen Zielproblem, ausgewählte Praktiken, Rollenentscheidung, Arbeitsergebnisse, Abweichungen und Verbesserungsnachweise; für den Aspekt „Managementbedarf“ muss ihre Herkunft nachvollziehbar bleiben; als Bezugspunkt dient „Prozessnutzen“. Die Entscheidung über „Verbesserungsschritt“ sollte deshalb ausdrücklich festhalten, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Verbesserungsschritt“), ohne das Framework zum Selbstzweck zu machen. Ein schlanker, aber wirksamer Ansatz lautet: Gegenargumente nicht abwehren, sondern als Belastungstest verwenden; der Belastungstest erfolgt mit Blick auf „Entscheidungsweg“. Für Audit und Führung reicht Aktivität nicht aus; der Prüfkontext ist hier „Anpassungstiefe“. Benötigt wird folgender Nachweis: eine dokumentierte Abwägung mit verbleibender Unsicherheit; bewertet wird außerdem: die beobachtbare Veränderung beim Aspekt „belastbare Nachweise statt bloßer Dokumentenfülle“. Aus den vorhandenen Kommentaren lässt sich besonders der Punkt „belastbare Nachweise statt bloßer Dokumentenfülle“ aufnehmen; die Bewertung erfolgt hier aus der Perspektive „Rollenklarheit“. Aus der Perspektive „Verbesserungsschritt“ entsteht daraus eine konkrete Rückfrage an die Umsetzung.
Für die belastbare Anwendung von „Arbeitsergebnis“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, ob die Maßnahme das beabsichtigte Risiko oder Ergebnis tatsächlich verändert. Die alltagstaugliche Übersetzung für „Arbeitsergebnis“ lautet: Nur die für das Ziel erforderlichen Elemente werden übernommen und anhand beobachtbarer Ergebnisse weiterentwickelt – betrachtet im Kontext „Scrum in a Nutshell“. Damit wird zugleich die Grenze beim Aspekt „Entscheidungsweg“ sichtbar: Ein Framework liefert Orientierung (hier bezogen auf „Wirkungsprüfung“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Der nächste Arbeitsschritt lautet: Design, Ausführung und Wirkung getrennt beurteilen; im vorliegenden Abschnitt wird dies an „Scrum in a Nutshell“ konkretisiert. Die Dokumentation hält zwei Dinge fest – eine Wirkungsprüfung mit Gegenbeispiel und Folgemaßnahme; zusätzlich sichtbar wird: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Beim Aspekt „Entscheidungsweg“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Der Praxistest für Managementbedarf bleibt bewusst einfach: Die Regel zu Arbeitsergebnis muss im Normalbetrieb verständlich, beim Aspekt Auswahl der Praktiken im Ausnahmefall entscheidbar und nach einer Änderung erneut prüfbar sein. Fehlt eine dieser Eigenschaften, besteht bei Reifeentwicklung weiterer Handlungsbedarf.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.
Comments 39
Spannend finde ich die praktische Seite: woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Reicht dafür zunächst ein kleiner Pilot oder braucht es sofort einen breiteren Ansatz?
Für mich wäre ein begrenzter Anwendungsfall der beste Einstieg. Dann sieht man relativ schnell, ob die Information tatsächlich zu einer anderen Priorität oder Entscheidung führt.
Ein konkreter Fall hilft, aber die Zuständigkeit muss von Anfang an klar sein. Sonst ist zwar das Problem sichtbar, die notwendige Entscheidung bleibt aber liegen.
Der Pilot ist aus meiner Sicht sinnvoll, wenn er nicht nur die formale Durchführung prüft. Entscheidend ist, ob anschließend eine bessere oder schnellere Entscheidung möglich ist.
Das überzeugt mich. Ein konkreter Fall mit klarer Zuständigkeit und Nachprüfung dürfte mehr zeigen als ein umfangreiches Modell ohne praktische Rückkopplung.
Danke für die Einordnung. Wie lassen sich kurze Arbeitszyklen und klare Verantwortlichkeiten gut miteinander verbinden?
Die Entscheidungsrechte sollten klar bleiben, auch wenn sich die Arbeit flexibel organisiert. Regelmäßige Rückmeldungen machen offene Punkte früh sichtbar.
Mich interessiert noch, wie man in kurzen Arbeitszyklen mit vertretbarem Aufwand erkennt, ob nur die Dokumentation oder auch die Praxis funktioniert. Damit wäre der nächste Entscheidungspunkt klarer. Der Maßstab sollte schon vor dem ersten Fall verständlich sein.
Wo würdet ihr bei Verbindlichkeit von Qualitätskriterien anfangen, wenn die Zuständigkeit beim Übergang in den Betrieb unklar bleibt?
Mein Vorschlag wäre, die Übergabe erst mit benanntem Verantwortlichen und nachvollziehbaren Abnahmekriterien abschließen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Verbindlichkeit von Qualitätskriterien sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Für mich liegt der Schwerpunkt hier: Als Nachweis von Grundlagenwissen kann sie hilfreich sein. Die Anwendung und der Umgang mit Konflikten müssten zusätzlich betrachtet werden.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Die Ausgangsfrage „Wie aussagekräftig ist eine Zertifizierung für die praktische Arbeit im Team?“ ist damit für mich noch nicht vollständig beantwortet.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Wie würdet ihr bei Verbindlichkeit von Qualitätskriterien erkennen, dass eine Maßnahme im Alltag wirklich trägt und nicht nur formal erledigt ist?
Ich würde dafür einen konkreten Prüffall festlegen: erwartetes Ergebnis, beobachtetes Ergebnis und benannter Prüfer. Wenn die Abweichung sichtbar bleibt, lässt sich auch sinnvoll über die nächste Maßnahme entscheiden. Mit Blick auf Verbindlichkeit von Qualitätskriterien würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Mein Vorschlag wäre: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Guter Punkt. Ich würde zusätzlich fragen, was passieren soll, wenn sich die Voraussetzungen während des Betriebs ändern. Meine Ausgangsfrage bleibt: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Auf die Ausgangsfrage bezogen: Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Wie könnte bei Nachvollziehbarkeit von Priorisierungsentscheidungen eine Rückmeldung aus der operativen Umsetzung in die Steuerung einfließen?
Ein kurzer Austausch über konkrete Schwierigkeiten wäre aus meiner Sicht hilfreicher als eine reine Fortschrittsabfrage. Aus der Rückmeldung sollte eine benannte Entscheidung oder Maßnahme entstehen. Für Nachvollziehbarkeit von Priorisierungsentscheidungen würde ich den ersten Prüfschritt bewusst klein halten.
Der praktische Wert von schlanke Governance für agile Arbeit hängt für mich an einer Frage: Führt die Information rechtzeitig zu einer besseren Entscheidung?
Dazu eine Rückfrage: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Für mich müsste sich zeigen, dass Rückmeldungen wirklich Entscheidungen verändern. Neue Termine allein schaffen noch keine bessere Zusammenarbeit.
Damit bin ich noch nicht ganz zufrieden. Wie würde man prüfen, ob die vorgeschlagene Lösung im Alltag tatsächlich eingehalten wird? Meine Ausgangsfrage bleibt: Wie wird aus der Methode mehr als eine neue Bezeichnung für die bisherigen Besprechungen?
Welche Entscheidung müsste zu Nachvollziehbarkeit von Priorisierungsentscheidungen zuerst fallen, wenn ein Dienstleister einen Teil der Umsetzung übernimmt?
Ich würde die erwarteten Ergebnisse und Übergaben konkret vereinbaren; ein Vertrag allein belegt noch keine Umsetzung. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Nachvollziehbarkeit von Priorisierungsentscheidungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Bei schlanke Governance für agile Arbeit würde ich neben dem Sollzustand auch typische Ausnahmen betrachten. Gerade dort zeigt sich die Alltagstauglichkeit.
Wie geht man mit Vorgaben um, die den Handlungsspielraum des Teams tatsächlich begrenzen?
Das ist ein wichtiger Punkt. Die Grenzen würde ich transparent machen. Innerhalb dieser Grenzen sollte das Team aber echte Entscheidungsmöglichkeiten behalten.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern?
Ich sehe den größten Nutzen in schlanke Governance für agile Arbeit. Das sollte sich mit wenigen verständlichen Signalen und konkreten Beispielen prüfen lassen.
Dazu eine Rückfrage: Wer entscheidet bei einem Zielkonflikt zwischen kurzfristiger Lieferung und nachhaltiger Qualität?
Für mich liegt der Schwerpunkt hier: Die Entscheidung sollte ausdrücklich besprochen werden. Wenn der Konflikt nur still in das Team verlagert wird, verschwindet er nicht.
Für schlanke Governance für agile Arbeit sollte auch feststehen, welche Annahmen der Bewertung zugrunde liegen. Sonst wird ein Status leicht länger fortgeschrieben als sinnvoll.