GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
4 Minuten Lesezeit
(825 Worte)
Scrum in a Nutshell
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:
- Produkt-Owner
- Scrum Team
- Scrum-Master
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:
- Software-Qualität
- technische Implementierung von Benutzergeschichten
- Lieferung eines funktionalen Software-Inkrements
- sich selbst organisieren
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
- Diagramm zum Abbrand
- Sprint-Backlog
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:
- gründlich getestet
- gut strukturiert
- gut geschriebener Code
- die Bedienung der Funktionalität durch den Benutzer ist dokumentiert
| 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. |
Blog-Beitrag abonnieren
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.
Über den Autor
Kommentare 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.