Category Archives for "Projekterfahrungen"

Scrum backlog Item

Scrum in der Hardware: So starten Sie!

​Scrum in der Hardware scheint sich als eine Art Trend und Mythos zu halten, wie es vor noch gar nicht langer Zeit auch mit Scrum in Automobilbereich der Fall war und noch früher mit Scrum selbst. Da ich auch mit Scrum in der Hardware mittlerweile durchaus positive Erfahrungen gemacht habe, finden Sie hier ein kleines Starterset​, das Sie zur Reflexion nutzen können.

Scrum in der Hardware

​Scrum in der Hardware

Grundlagen verstehen

​Die Grundlage über "gute Entwicklungsprozesse", die Takeuchi und Nonaka 1986 in ihrem New New Product Development Game beschrieben hatten, sind bis heute gültig. Wer sich das Paper einmal genauer ansieht, wird feststellen, dass es hier nicht um Softwareprozesse ging, sondern um ​physische Produkte: Auto, Kamera, Kopierer. Das Paper wird auch als Quelle genannt, wenn es um den Begriff "Scrum" geht. Die folgenden Kernelemente haben die beiden Japaner in sechs Kernthesen festgehalten:

  • ​Built-in instability
  • ​Self-organizing project teams
  • ​Overlapping development phases
  • ​“Multilearning”
  • ​Subtle control
  • ​Organizational transfer of learning

​Genau genommen sind diese Elemente heute inhärent in Scrum vorhanden und damit auch außerhalb der Software gültig. Was Sie nur jetzt tun müssen, sind die Erkenntnisse auf Ihre Praxis von Scrum in der Hardware zu transferieren.

Eine häufige Erkenntnis - gerade im Hardwarebereich - ist zum Beispiel, dass es keine selbstorganisierenden Projektteams gibt. Wenn Sie ​heute Entwicklungsteams ​betrachten, dann stellen Sie schnell fest, dass solche Teams einen sehr großen Anteil an erfolgreicher Entwicklung haben. Und dazu müssen Sie überhaupt keine Software entwickeln. Weitere Aspekte schauen wir uns später noch genauer an.

Als grundlegende Wissensquelle für Scrum in der Hardware kann dieses Paper für alle Interessenten nur wärmstens empfohlen werden.

​Typische Fragen im Vorfeld beantworten

Fragen zu Scrum in der Hardware

​Es sind immer ähnliche Fragestellungen, die bei den Mitarbeitern und im Management auftauchen. Sie können diese Fragestellungen im Vorfeld schon einmal angehen. Vor allem, reden Sie früh mit Kritikern und arbeiten Sie mit offenen Formate ehrlich über die Ansichten und Bedenken. Dann klappt es auch mit Scrum in der Hardware!

  • check
    ​Ja, das erstellen von Inkrementen dauert grundsätzlich länger, als in der Software. Da muss der eine oder andere Manager gedanklich noch seine Hürden überwinden und ein Anwender auf die Grundlagen für Prinzipien und Werte fokussiert werden. Stellt grundsätzlich aber kein Problem dar.
  • check
    ​Nein, auch existierende Hardware Entwicklungen sind in der Regel nicht optimal. Oft fehlt es an elementaren Grundlagen, wie cross-funktionale Teams, miteinander häufig und zielführend kommunizieren oder auch an gemeisamer Planung. Auch hier können Sie einfach ansetzen.
  • check
    ​Doch, Sie können auch frühes Feedback erzeugen, das wenig kostet. Experimentieren Sie mit Pappschachteln, 3D Druck, Knetmasse, gehen Sie zum Konstrukteur in die Werkstatt, visualisieren Sie und sprechen Sie früh und regelmäßig über die Entwicklung und Erkenntnisse.

​Erfolgreiche Muster für Scrum in der Hardware

Grundlagen verstehen

​Auch in der Hardware fängt der erste Schritt mit den Grundlagen an. Sie müssen die Kernelemente von Scrum verstanden haben und dieses verinnerlichen. Dazu stehen natürlich verschiedene Möglichkeiten zur Verfügung, am effektivsten sind direkte öffentliche oder inhouse Scrum Trainings oder aber Online Scrum Kurse:

  • ​Lernen Sie die Events in Scrum kennen und verstehen Sie den Inhalt dieser. Auch für Ihre Implementierung brauchen Sie dann genau diese Events.
  • ​Begreifen Sie, was die Rollen für Rechte und Pflichten haben und übertragen Sie dieses Konzept auf Ihren Kontext.
  • ​Was für Artefakte gibt es in Scrum und wie passen diese auf Ihre Situation? Wie können Sie diese interpretieren und in Ihre Praxis überführen

​Dazu bietet es sich an, dass Sie sich bei der Auswahl der Trainer oder der Trainings auch daran orientieren, wie genau die Erfahrungen der Trainer sind.

Keine Softwaremuster kopieren

Wenn Sie die Software Projekte mit Scrum kennen, dann machen Sie nicht den Fehler die Praktiken aus der Hardware 1:1 kopieren zu wollen:

  • ​Ein Inkrement in der Software ​muss nicht identisch ​mit einem Inkrement in der Hardware sein. In ​den meisten Fällen ist es das auch nicht.
  • ​Scrum in der Hardware erstellt nicht so oft "lauffähige" Systeme, wie das die Software tut. Das liegt alleine daran, dass physikalische Aufbauten deutlich teurer sind, als Software zu kompilieren und auf ein Gerät zu spielen.
  • ​Trotzdem kann Hardware auch regelmäßgen Mehrwert liefern, der zum Lernen und für Feedback hilfreich und wichtig ist!

​Teamgröße ​in der Hardwareentwicklung

Schauen wir in den Scrum Guide, in Studien von Jeff Sutherland und eigene Erfahrungen, dann sind die Teams häufig mit Scrum Master und Product Owner weniger als zehn. In den Studien von Jeff Sutherland sind die effektivsten Teams vier bis fünf Entwickler.

​In der Hardware haben wir häufig typische Funktionen auf Personen verteilt, die wir alle brauchen. Beginnen wir mit dem Konstrukteur. Dann haben wir in der Regel je nach Produkt auch Elektronikentwickler, die sich Steuerung und Co kümmern. Hier findet sich oft der Fall, dass diese noch weiter spezialisiert sind und Sie mehrere davon in einem Team haben.

Wenn Sie elektronische Teile verbauen, dann haben Sie praktisch immer Leiterplatten (PCB), also Teile auf denen Sie elektronische Bauteile anbringen. Für diese Aufgaben findet sich auch ein Designer, Ingenieur oder Konstrukteur.

Werden Teile eingekauft, dann findet sich auch ein Einkäufer im Team, ein Test- und Qualitätsingenieur sind ebenso mit im Boot, wie vielleicht jemand von der Simulation.
 ​

​Build-Measure-Learn

​Ob Sie Lean Start-Up nun kennen oder nicht, wichtig für Scrum in der Hardware ist es, dass Sie früh damit beginnen zu evaluieren, ob das, was Sie tun, das Richtige ist. Das klingt trivial, aber es kann häufig schon mit einfachen Prototypenaufbauten, mit Pappschachteln ​für Navigationsgeräte oder 3D Drucke für mechanische Wohnwagenparkhilfen darstellen, sinnvoll sein Erkenntnisse zu erlangen, die viele Kosten sparen und zur Entwicklung beitragen.

Auf die Architektur achten

Modulare Architektur bei Scrum in der Hardware

Nicht nur im Softwarebereich ist die Frage nach einer geeigneten Architektur eine häufig gestellte, sie gilt auch ganz besonders im Hardwarebereich.

Wer Wikispeed als Beispiel für agile Hardwareentwicklung nicht gelten lassen will, weil es eben doch nichts mit der deutschen Automobilindustrie zu tun habe, der kommt aber früher oder später bei ​dessen Architektur raus: Wikispeed ist von Anfang an so ausgelegt, dass sich die Hardware inkrementell weiterentwicklet werden kann. Die deutsche Automobilindustrie eher auf günstige Entwicklung.

Das macht die Software schon lange. Will ich konsequent die Ziele von Scrum, Flexibilität und Kundenzufriedenheit, erreichen, dann benötige ich genau so eine modulare Architektur.

Auf die Scrum Werte fokussieren

Die Scrum Werte sind ein inhärenter Bestandteil von Scrum. Also auch dann, wenn Sie in der Hardware Ihre Projekte durchführen. So oft ich auch in enttäuschte oder gelangweilte Gesichter schaue, wenn ich die Scrum Werte erwähne - sie sind zusammen mit agilen Prinzipien einfach essentiell wichtig.

  • ​Mut
  • ​Respekt
  • ​Offenheit
  • ​Commitment
  • ​Fokus

Achten Sie auch bei Scrum in der Hardware darauf, dass Sie sich Gedanken über die Werte machen und diese auch interpretieren. Das tun Sie immer im Team und auch welche Bedeutung diese Scrum Werte für die Organisation haben, ist wichtig für ein gemeinsames Verständnis.

Auf was es ankommt

Iterative und inkrementelle Entwicklung ist wichtig, auch für die Hardware. Eine implizite Annahme, die viele Menschen sofort treffen ist, dass nach jedem Sprint ein vollständiges System "lauffähig" sein muss. Nehmen wir einmal das erste Inkrement von Tesla. War das ein Auto? Nein, es war eine Webseite mit der Möglichkeit seinen Namen und Kreditkartennummer einzutragen. Dieses Inkrement (genau genommen ist es ein MVP - minimal viable product) finden Sie heute auch nicht in einem Tesla. Der Wert steht im Vordergrund.

Also verabschiedenen Sie sich von der Annahme, dass nach zwei Wochen eine neue Einparkhilfe, eine Nockenwelle, ein Auto oder ein neues Tablet aus dem Sprint purzelt. Es gibt dort häufig (noch) physikalische Grenzen, die wir nicht übergehen können. Aber das ist auch nicht nötig. Sie können viele Dinge innerhalb eines Sprints tun, bei denen Sie Scrum unterstützt.

Sie können aber wertvolles Feedback und vor allem Mehrwert als Inkrement immer liefern.

  • ​Bauen Sie ein Team von Mitarbeitern auf, die zusammen das Produkt entwickeln. Überlegen Sie welche Disziplinen Sie alles benötigen und bilden Sie dann ein entsprechendes Team, befähigen Sie dieses Team selbst Entscheidungen zu treffen. Selbstermächtigung und -organisation ist das Stichwort. Die wenigsten Teams im Hardwarebereich sind so aufgestellt!
  • Überlegen Sie, wie schnelles Feedback für das Produkt genenriert werden kann. Auch wenn die Hardware nicht Software ist, können mit 3D Druck, Simulationen oder simplen Prototypenaufbauten früh Meinungen und Ansichten von Stakeholdern erreicht werden.
  • ​Schaffen Sie Transparenz in dem Sie alles über den Projektverlauf zeigen, was Sie können. Wo steht das Projekt, wo klemmt es und wie kann schnell Abhilfe erfolgen.
  • angle-double-right
    Nutzen Sie Retrospektiven um sich schnell neuen Herausforderungen stellen zu können. Wo muss was getan werden, damit Sie Probleme im Prozess beseitigen, effizienter und schneller arbeiten können, wie halten und motivieren Sie Mitarbeiter?

So erstellen Sie Ihr Sprint Backlog richtig

​Ein Sprint Backlog erstellen ist eine Aufgabe, die jedes Scrum Team vor sich hat. Besonders das Entwicklungsteam hat seinen Fokus auf dem Sprint Backlog, denn es ist der Plan für den Sprint. Es lohnt sich ein paar Gedanken und Ansichten zum Sprint Backlog zu reflektieren, um mit einer guten und praktikablen ​Lösung für das eigene Team in die Sprints gehen zu können.

In diesem Artikel beleuchte ich das Artefakt Sprint Backlog genauer und zeige meine Erkenntnisse, Praktiken und Erfahrungen damit auf.

​Reflexion: Sprint Backlog in Scrum

​In Scrum ist das Sprint Backlog der Plan des Entwicklungsteam für den Sprint das Sprint Ziel zu erreichen und ein Done Inkrement zu ​entwickeln. ​Dieses wird im Scrum Event Sprint Planung erstellt.

Der Scrum Guide über das Sprint Backlog

​Schauen wir uns auch hier einmal kurz an, was über das Sprint Backlog im Scrum Guide zu lesen ist und machen uns dann daran, wie wir das Sprint Backlog am besten umsetzen können.

Backlog im Scrum Guide 2016

Scrum Guide

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment.

​[...]

​Ein Artefakt

​Das Sprint Backlog ist damit eines, der drei im Scrum Guide genannten Artefakte. Es findet damit seinen Platz neben dem Product Backlog und dem Produktinkrement. Dieses Trippel habe ich im Blog an anderer Stelle schon genauer betrachtet.

​Erstellung des Sprint Backlogs

​Das Event Sprint Planning

Backlog in der Sprint Planung

​Das Sprint Backlog wird während des Sprint Plannings erstellt. Diesen Sachverhalt schaue ich mir nun nicht weiter an, auf der Startseite und im Artikel über das Sprint Planning finden Sie weitere Informationen dazu, wenn Sie das Thema näher interessiert.

Im Folgenden gehe ich nun auf die eigentliche Erstellung des Sprint Backlogs ein und auf das, was Sie beachten sollten und wie Sie folglich ein guten Sprint Backlog erstellen können.

Das Sprint Backlog

Das Sprint Backlog erstellen Sie am einfachsten, ​durch ​die nun folgenden Schritte. Wenn Sie Ihr Sprint Backlog erstellen,​ achten Sie bitte trotzdem auf Ihre Rahmenbedingungen​. Mein Weg funktioniert oft gut, ist aber kein allgemeine Lösung. Gerade für die Scrum Anfänger oder die Verbesserer finden sich hier einige Dinge, die zu​r ​Reflexion einladen.

Aus was besteht das Sprint Backlog?

​Wenn Sie Ihr Sprint Backlog erstellen, denken Sie bitte daran, dass das Sprint Backlog mehr als das eigentliche Board ist. Das Sprint Backlog ist der Plan des Entwicklungsteam für den Sprint, wie es gedenkt das Sprint Ziel zu erreichen und ein Done Inkrement zu bekommen. Deswegen sollten Sie auf die folgenden Dinge Wert legen.

  • check
    Die Definition of Done. Achten Sie darauf, dass beim Sprint Backlog auch die Definition of Done vorhanden ist. Sie hilft nicht nur dem Entwicklungsteam abzuschätzen, wieviele Einträge es in einem Sprint schaffen kann, sondern schafft auch das Verständnis, wann Arbeit fertig ist.
  • check
    ​Das Sprint Ziel. Das Sprint Ziel hilft die Richtung des Sprints zu verstehen. Und damit sollte das Sprint Ziel natürlich mit dem Plan des Entwicklungsteam harmonieren.
  • check
    Das Sprint Board. Hier visualisieren Sie des Arbeit des Teams. Häufig verstehen Teams unter dem Sprint Backlog nur dieses Board.

​Wie wird das Sprint Backlog aufgebaut?

Sprint Backlog erstellen Schritt 1

​Wenn Sie das Sprint Backlog aufbauen, hilft aus aus meiner Sicht so einfach wie möglich zu bleiben. Dabei bieten sich vier Spalten an:

  • 1
    ​Product Backlog Item. Die erste Spalte hält das Product Backlog Item. Es ist damit entweder genau das Element aus dem Product Backlog oder aber eine Kopie davon. Es dient mehr oder weniger zu Gruppierungs- und Übersichtszwecken. Sie können dann auch pro Product Backlog Item eine "Swimlane" einziehen, die eine bessere Übersicht schafft, in dem es die Backlog Items von einander optisch trennt.
  • 2
    Die geplante Arbeit. In der zweiten Spalte hängen Sie dann alle Arbeit auf, die das Team sich für die entsprechenden Product Backlog Items überlegt hat. Sie finden dann in der Regel zu jedem Product Backlog Item mehr als eine geplante Aufgabe.
  • 3
    Die aktuelle Bearbeitung. Alle Arbeit, die sich aktuell in der Bearbeitung beim Team befindet, ist in dieser Spalte zu finden. Sie können diese Spalte auch über ein WIP (work in progress) Limit steuern. Dann dürfen sich zu keinem Zeitpunkt mehr als X Aufgaben in diesem Schritt befinden.
  • 4
    ​Fertige Aufgaben. ​Hat das Team Aufgaben abgeschlossen, dann werden diese Aufgaben hier hin gehängt.

​Die parallele Arbeit begrenzen

​Um den Scrum Wert Fokus zu ​erreichen, kann es ​unter anderem sehr sinnvoll sein, dass Sie die parallele Arbeit begrenzen. Dazu können Sie mit sogenannten WIP Limits arbeiten.

Sprint Backlog erstellen Schritt 2 WIP Limit

​Ein WIP Limit finden Sie in der Regel über der Spalte, beim entsprechenden Schritt. Es wird als Zahl, oft in rot und eingerahmt dargestellt. Jetzt gilt es aufzupassen: zu keinem Zeitpunkt dürfen mehr Aufgaben, als die Zahl ausdrückt, sich im Schritt befinen.

​Avatare nutzen

Sprint Backlog erstellen Schritt 3 Avatar

​Eine weitere Möglichkeit besteht darin, Avatare zu nutzen. Wenn Sie Ihr Sprint Backlog analog erstellen, dann haben Sie sehr wahrscheinlich kleine "Kunstwerke" als Avatare. Neben der Transparenz, die Sie sofort etablieren, haben Sie auch die Möglichkeit ein WIP Limit über die Avatare aufzubauen. Wenn ein Mitarbeiter keine Avatare mehr hat (z.B. durch die Regel, dass jeder Mitarbeiter nur drei dieser Avatare haben darf), dann kann er auch keine weiteren Aufgaben mehr anfangen.

​Sprint Ziel direkt am Sprint Board platzieren

​Wenn Sie das Sprint Ziel direkt am Sprint Board platzieren, dann können Sie einfach im Daily Scrum gegen dieses reflektieren. Egal ob Sie einen eher diskussionsbedingten Ansatz nutzen, oder sich an den drei Fragen orientieren - ​Sie haben einen visuellen Anker, der wirkt.

Sprint Backlog erstellen Schritt 4 Sprint Ziel

​Definition of Done in die Nähe der "fertig" Spalte

Sprint Backlog erstellen Schritt 5 DoD

​Hängen Sie die Definition of Done immer in der Nähe von der Spalte fertig auf. Es gehört zum einen thematisch direkt dort hin, zum anderen bietet dieser Platz immer eine Möglichkeit zur Reflexion.

Wo befindet sich das Sprint Backlog?

Wenn Sie ein Sprint Backlog erstellen, dann versuchen es möglichst analog zu benutzen. Das Product Backlog wäre eher ein Kandidat für ein digitales Tools. Die wenigstens Tools schaffen es nämlich die Definition of Done, das Sprint Ziel und das Sprint Board sinnvoll darzustellen. In dem Sprint haben Sie oft nicht so viele Aufgaben, dass ein analoges Abbilden aus dem digitales Product Backlog ​größere Schwierigkeiten darstellt würde.

Das Sprint Backlog befindet sich optimalerweise direkt beim Entwicklungsteam. Es ist der Plan des Entwicklungsteam, also macht es natürlich Sinn, wenn es dort zu finden ist. Wenn Sie einen Teamraum haben, dann gehört das Sprint Backlog genau dort hin.

​Wie ordnet man das Sprint Backlog an?

​Wenn Sie das Sprint Backlog positionieren möchten gibt es einige Dinge, die Sie im Auge bahalten können, um die Akzeptanz des Sprint Backlogs zu erhöhen.

​Stop's & Shop's

​Analog vs. digital

​Ein analoges oder digitales Sprint Backlog erstellen - was ist besser? Analog schlägt digital - gerade wenn das Teams noch nicht erfahren ist und eine hohe Reife in der Anwendung von Scrum hat, kann ich ein analoges Sprint Backlog nur empfehlen. Schauen wir uns kurz einmal an, warum ich das Sprint Backlog in der analogen Variante bevorzuge

  • check
    Änderungen am analogen Sprint Backlog sind schnell gemacht. Es benötigt keinen Administrator vom Tool, es geht kein Gesuche los, "wer kann mir dieses Recht geben" oder "welches Recht brauche ich dazu?". Wir erinnern uns kurz: Menschen und Interaktionen mehr als Prozesse und Tool.
  • check
    ​Ein digitales Sprint Backlog wird als vorgegeben wahrgenommen. Haben Sie schon mal in einem Tool wie Jira gearbeitet? Wie oft sind Sie auf die Idee gekommen, den Prozess anzupassen? In der Regel macht man das wenig - es riecht nach Vorgaben und "hinzunehmenden Voraussetzungen".
  • check
    ​Ein analoges Sprint Backlog ist schnell aufgebaut und geändert. Sie brauchen recht wenig Invest, um ein Sprint Backlog zu installieren. Wenn Sie sich erst ein Tool auswählen müssen, dann vielleicht Lizenzen anfordern und eine Einrichtung durch die IT benötigen, dann kostet das alles Zeit. Die Zeit haben Sie locker schon wieder drin, wenn Sie analog starten (was nicht bedeutet, dass Sie es immer analog machen müssen).
  • check
    ​​Wer analog startet, kennt die digitalen Anforderungen. ​Sie können sehr einfach die Anforderungen für Ihr digitales Board durch einen analogen Prototypen erarbeiten. Sie werden nach einiger Zeit merken, dass Sie den Prozess nur noch wenig anpassen. Halten Sie dann Ihre Anforderungen fest und Sie wissen sehr gut, nach welchem Tool Sie mit welchen Anforderungen Sie Ausschau halten müssen.

Sprint Board, Sprint Ziel und Definition of Done

Hängen Sie - wie oben bereits beschrieben - das Board gemeinsam mit dem Ziel und der Definition of Done auf. Halten Sie unbedingt dann Ihr Daily Scrum auch immer vor dem Board, dem Ziel und der DoD ab. Hier sind meine Favoriten für dieses Vorgehen.

  • check
    ​Die Fragen im Daily Scrum lassen sich auch visuell auf das Sprint Ziel beziehen. Wenn Sie das Daily Scrum nach den drei Fragen ausrichten, dann hilft der Blick und die Visualisierung auf das Sprint Ziel, die Fragen fokussiert vorzunehmen.
  • check
    Definition of Done hängt beim "fertig". Wenn Sie die Definition of Done (in der Regel eine Liste von Kriterien) neben der Spalte "fertig" hängen haben, dann schärft das noch einmal zu reflektieren, ob beim "Umhängen" von "Bearbeitung" auf "fertig" auch wirklich an alles gedacht wurde.

​Sprint Backlog in der Retrospektive

​Auch das Sprint Backlog gehört zur "Infrastruktur" Ihres Teams und diese können Sie ohne Probleme in einer Retrospektive genauer beleuchten. Und genau das sollten Sie von Zeit zu Zeit auch tun, um den Prozess nicht aus den Augen zu verlieren.

Unterbrechungen in Scrum: richtig handeln!

​Wie gehen wir optimal mit Unterbrechungen in Scrum um?

​Unterbrechungen in Scrum während des Sprints, also die notwendige Abweichung von dem im Sprint Planning aufgestellten Sprint Backlog, ist gar nicht so selten. Wir leben in einer unbeständigen Welt und wenn die Rahmenbedingungen komplex sind, dann treten Änderungen am Plan auf, mit denen wir umgehen müssen. Das Unterbrechungen in Scrum auftreten, da sind sich viele einig - doch wie gehen wir mit diesen konkret um?

Diese Fragestellung beleuchte ich in meinem Artikel, angereichtert mit ​den Erkenntnissen, die ich vom Scrum@Scale Training mit Jeff Sutherland in München erlangt habe. ​Es ging nur am Rande um​ Unterbrechungen in Scrum. Ich habe aber eine wichtige neue Erkenntnis zu meinen bisherigen Betrachtungen gewonnen.

​Was sind Unterbrechungen?

​Unter Unterbrechungen verstehe ich die Situation, dass ein Team etwas im Sprint Planning geplant hat und dann plötzlich aus irgendwelchen Gründen noch eine andere Aufgabe in diesem Sprint erledigen muss. Das sollte nicht vorkommen, aber in der Realität sieht das immer anders aus. Gerade wenn das Team eine bestimmte Sprintlänge wie zum Beispiel einen Monat nutzt, ist die Wahrscheinlichkeit hoch, dass auch Unterbrechungen in Scrum ​auftreten. Deshalb beziehe ich mich bei Unterbrechungen nun immer darauf, wenn etwas unvorhergesehenes im Sprint passiert, was ich nicht in meinem Sprint Backlog zu Beginn ​geplant hattee. Ein typisches Beispiel dafür sind Fehler, die umgehend behandelt werden müssen.

​Wie kann ich Unterbrechungen in Scrum behandeln?

​Zunächst gehe ich auf die beiden von mir praktizierten Möglichkeiten ein, eine Unterbrechung in Scrum zu behandeln. Zum Schluss möchte ich die Idee von Jeff Sutherland noch einmal aufgreifen und hier mit in diese Überlegungen mit einbringen.

Um Unterbrechungen in Scrum abzufangen drängt sich eine Möglichkeit sofort in den Vordergrund: das Arbeiten mit Puffern. Auch meine beiden Ansätze basieren immer auf einem Konzept eines Puffer. Wenn ich von so einem Puffer spreche meine ich damit eine bestimmte Zeit/Kapazität, die Im Sprint Planning bewusst nicht verplant und frei gehalten oder aber als bewusster Puffer-Platzhalter mitgeplant wird. Tritt nun eine Unterbrechung in Scrum auf, dann konsumiert diese Unterbrechung - und die damit verbundene zu erledigende Aufgaben - Zeit von genau diesem Puffer.

Puffer sind teuer!

Klingt alles plausibel finden Sie? Ja, ist es auch, nur Puffer haben auch Nachteile! Durch so einen Puffer erkaufe ich mir Sicherheit. Schauen wir uns die beiden Beispiele an:

  • check
    ​Durch einen Puffer erhöhen Sie die Wahrscheinlichkeit, dass Sie eine Lieferung zu einem bestimmten Datum auch wirklich halten können. Durch einen Puffer können Sie auf mögliche Probleme während der Entwicklung reagieren.
  • check
    ​Sie wissen, dass Sie weitere Aufgaben mit einer bestimmten Wahrscheinlichkeit zu erledigen haben, die Sie noch nicht kennen und daher auch nicht planen. Durch den Vorhalt von Zeit (also Puffer) stellen Sie sicher, dass zusätzliche Aufgaben trotzdem bearbeitet werden können und Ihre Planung nicht obsolet wird.

Betriebswirtschaftlich gesehen, sind Puffer immer teuer und wenn ich sie nicht brauche sind sie Verschwendung. Ob Sie nun diese Entscheidung für oder gegen einen Puffer treffen ist eine wirtschaftliche Abwägung. Scrum selbst arbeitet ohne Puffer.

​Puffer in der Kapazität des Teams

​Wenn wir bereits wissen, dass wir mit Unterbrechungen konfrontiert werden, dann hilft es, ​wenn wir uns der eigenen Kapazität im Team klar werden. Was also schafft das Team, wenn es nicht unterbrochen wird? Dabei ist es zweitrangig, ​was für eine Kapazität wir im ​zu Beginn annehmen. Wichtig ist erst einmal nur, dass das Team diese kennt. In der Realität ist das oft bei gerade startenden Teams nicht so.

Wenn ich diese Kapazität kenne und vielleicht sogar noch historische Werte habe, wie ich die Unterbrechungen in Scrum bestimmen kann, dann ist es umso besser. Wenn ich diese nicht kenne, dann muss ich schätzen.

Was kann ich also tun? Die Lösung kann darin liegen, in einem Team mit einem Puffer in die Sprint Planung zu gehen. Ich plane nur das, was ich kenne. Zudem reserviere ich dann von der maximal möglichen Kapazität einen bestimmten Prozentsatz. Diesen beplane und betrachte ich nicht weiter. Alle unvorhergesehenen ​Aufgaben ​werden darin bearbeitet. 

Die folgende Abbildung zeigt, wie Sie mit Unterbrechungen in Scrum umgehen können.

Unterbrechungen in Scrum

Puffer im Backlog

​Letztendlich betrifft auch der Puffer im Backlog die Kapazität des Teams. Allerdings ist die Ebene dieser Puffersteuerung eine andere. Wenn ein Team beispielsweise mit Story Points arbeitet und eine durchschnittliche Velocity von 20 Story Points hat, dann könnte das Team einen "Platzhalter" von 5 Story Points im Sprint Backlog haben.

Damit sind ist die ganze Kapazität im Fokus der Sprint Planung.

​Das Learning vom Training

​Was mir ​gut zu den Unterbrechungen in Scrum ​von den Aussagen vom Jeff hängen geblieben ist, war die Aussage, dass diese Puffer von Sprint zu Sprint kleiner werden muss! Läuft der Puffer über, muss neu geplant werden und eine Anpassung vorgenommen werden.

Ich denke alleine das einmal im Kopf zu haben und dann so die eigene Implementierung zu überprüfen ist schon eine gute Möglichkeit zur Reflexion.

Velocity beinhaltet auch Interrupts

Im Scrum@Scale Guide 0.8 findet sich der Hinweis, dass die Velocity mit den Interrupts zu behandeln ist ( "Velocity for each team including buckets of where velocity is spent (e.g., interrupts, technical debt, etc.)"). Demzufolge ist die Version mit der User Story (oder dem Product Backlog Item) im Backlog die "richtige" Version.

Je länger ich über die beiden Versionen mir Gedanken mache, desto mehr finde ich den Platzhalter im Product Backlog besser, als das pauschale Berechnen einer Kapazität, die dann auch nicht mehr im Fokus ist. Dieses hat die folgenden Gründe, die ich gerne noch zur Diskussion stelle:

  • 1
    Der Scrum Wert "Fokus". Durch den Fokus in einer Sprint Planung auf dem Event und dem Inhalt für den kommenden Sprint ist es essentiell, dass alles was im Fokus steht auch im Product Backlog und dann im Sprint Backlog abgebildet ist. Das ist bei der Platzhalter-Methode der Fall, denn es ist klar und sichtbar, dass eine bestimmte Kapazität im Sprint reserviert ist.
  • 2
    Der Schmerz bleibt sichtbar. Wenn mit einem Platzhalter Product Backlog Item gearbeitet wird, dann ist jedem bewusst, dass diese Unterbrechungen stattfinden und diese sind sichtbar.
  • 3
    Leichter Austausch durch Product Backlog Items möglich. Sollte eine Unterbrechung nicht erfolgt sein, so ist direkt klar, in welcher Größenordnung noch ggf. Product Backlog Items nachgezogen werden können. Bei einer Reservierung einer Kapazität besteht wahrscheinlich eher die Gefahr, dass Parkinsonsche Gesetz zuschlägt.
  • 4
    Kapazität ist das, was ein Team auch leisten kann. Das Separieren von "planbaren" und "nicht planbaren" in einer getrennten Kapazität lässt den Blick von der gesamten Kapazität abrücken.


Phasenorientierte Pseudo-Agilität

In der letzten Zeit fällt mir häufiger eine phasenorientierte Pseudo-Agilität bei Scrum Implementierungen auf. Ich bezeichnet damit die Situation, das alte Denken von klassischen Phasen auf die Iterationen oder Sprints zu portieren. Dabei stellt sich oft heraus, dass diese Vorgehensweise im Grunde keine Verbesserungen bringt. Schauen wir uns den Sachverhalt einmal anhand eines Szenarios genauer an.

Phasenorientierte Pseudo-Agilität

Um uns der phasenorientierten Pseudo-Agilität zu nähern, betrachten wir das folgenden Bild, dass ein typisches "Scrum Wasserfall" und ein "richtiges iteratives und inkrementelles Vorgehen" zeigt.

Phasenorientierte Pseudo-Agilität

Sie haben keinerlei Vorteil, wenn Sie zum Beispiel ihr aktuelles, sequentielles Vorgehen nun in einen kürzeren Sprint durchführen. Stopp, werden die ersten nun sagen. Wir haben sehr wohl einen Vorteil, denn jetzt überprüfen wir häufiger unsere Arbeitsergebnisse und werden besser! Schauen wir uns diesen Sachverhalt weiter unten noch mal genau an.

Das Problem Scrum Wasserfall

In den meisten Fällen sieht ein verkürzter Scrum Wasserfall aber wie folgt aus. Es werden häufig folgende Situationen angetroffen:

  • Innerhalb des Sprint wird kein lauffähiges Inkrement erzeugt. Und das unabhängig davon, ob der Sprint "erfolgreich" verlief oder nicht. Es wird ein gewisser Vorrat an Product Backlog Items abgearbeitet, die aber nicht die Eigenschaften von Product Backlog Items haben. Es sind praktisch bekannte Aufgaben, einfach in ein Product Backlog übernommen.
  • Tritt während des Sprints ein Problem auf, zieht das alles in Mitleidenschaft. Wenn auf diesem Product Backlog Item weitere aufsetzen, dann wird eine ganze Kette verschoben oder kommt ins Straucheln.
  • Sie sind nicht in der Lage innerhalb des Sprints eine Priorisierung vorzunehmen.

Scrum Backlog Sprint

Fazit zur Pseudo-Agilität

Auch wenn es für viele Teams auf der Tagesordnung steht, diese Art der Sprints helfen nicht. Sie werden so nie helfen und agil werden Ihre Teams und die Organisationen nicht. Pseudo-Agilität ist ziemlich gefährlich. Natürlich müssen Sie Ihr Product Backlog Refinement verbessern. Auch das ist leichter gesagt, als getan. Die Gründe liegen darin, dass sehr wahrscheinlich mit dem Gedanken von Spezifikationen an Scrum heran gegangen wird. Spezifikationen sind nicht optimal für Scrum geschnitten - sie sind immer auf Vollständigkeit bedacht. Das verträgt sich nur bedingt und sollte dringend an der Grundursache angegangen werden.

2 Mehrere Produkte im Team

Agile, iterative und inkrementelle Entwicklung

Agile, iterative und inkrementelle Entwicklung

Ich darf täglich Kunden beobachten, die entweder mit Scrum Produkte entwickeln oder es demnächst vorhaben. Leider geht das Verständnis von Scrum, wenn sie sich dafür als “agile Entwicklung” entscheiden, in der Praxis und Theorie weit auseinander.

Häufig kommen das Aussagen, dass “Scrum so einfach nicht funktioniert” und wir “einen pragmatischen Ansatz benötigen, um Scrum an unsere Umgebungen anzupassen”. Innerlich baut sich dann ein Gefühl bei mir auf, dass sich zwischen Schmunzeln, Lachen, Wut und Ohnmacht ausdrückt.

Das ist gar nicht negativ auf den Kunden bezogen, sondern fängt bei mir selbst an. Ich trage - nicht erst seit gestern - die Gedanken von Scrum und Co durch die Welt, weil ich davon überzeugt. Vielleicht oft nicht aus der gesamten Perspektive, die für den ein oder anderen Betrachter notwendig sind. Deshalb versuche ich einen neuen Anlauf hier im Blog, der in meine must-have Readinglist für alle Kunden, Partner und Interessenten eingeht 🙂

agile, iterative und inkrementelle Entwicklung

Die Rahmenbedingungen müssen stimmen

Damit eine agile, iterative und inkrementelle Entwicklung wirklich Sinn macht, müssen die Rahmenbedingungen für Ihr Umfeld stimmen. Wenn Sie nicht die Rahmenbedingungen besitzen, die für Scrum optimal sind, dann werden Sie auch nur bedingt Vorteile in diesem Framework finden.

Diesen Rahmenbedingungen können Sie sich mit dem Stacey Landscape Diagram recht gut nähern oder Sie verwenden das Cynefin Framework. Wenn Ihre Analyse ergibt, dass Ihr Produkt, welches Sie entwickeln möchten, in einer komplexen Umgebung befindet, dann liegen Sie an der Stelle schon mal recht gut für einen Einsatz von Scrum. Wenn Sie die Rahmenbedingungen begriffen haben, spielen zudem noch eine Menge an weiteren organisatorischen Rahmenbedingungen mit in eine Entscheidung für eine Umsetzung mit Scrum. Ein Klassiker dabei ist immer wieder zu denken, mit einem großen “Roll-Out” kann eine solche Einführung gelingen. Das funktioniert nicht, denn Scrum basiert zum einen auf Empirie und zum anderen auf einem Inspect & Adapt Ansatz. Ohne jetzt zu sehr in die Details einzusteigen, wenn Sie nicht in der Lage sind, auf Basis Ihrer gemachten Erfahrungen den Prozess kontinuierlich zu verbessern, diesen transparent zu haben und darauf hin Anpassungen vorzunehmen, dann wird Ihnen auch der Erfolg von einem Scrum Team verwehrt bleiben.

Sie müssen überhaupt erstmal inkrementell entwickeln können!

Wenn Sie die benötigten Rahmenbedingungen (sowohl für Ihr Umfeld, als auch Ihre Organisation) vorfinden, dann ist das ein erster wichtiger Schritt. Allerdings müssen Sie auch die Fähigkeit besitzen, inkrementell Produkte zu entwickeln, denn dieses Denken in Inkrementen ist essentiell und sehr wichtig. Inkrementell bedeutet, dass Sie innerhalb Ihrer gewählten Länge des Sprints (wenn Sie sich nach dem agilen Manifest richten, dann müssen Sie innerhalb weniger Wochen oder Monate (regelmäßig) liefern, nach dem Scrum Guide, darf dieses nicht mehr als ein Monat sein) ein erlebbares Inkrement liefern können, das einer sauberen Definition of Done entspricht und durch den Kunden auch inspiziert werden kann. Das bedeutet, dass der Kunde Erfahrungen mit dem Inkrement machen und etwas “erleben” kann.

Natürlich ist oft die Euphorie recht groß zu Beginn einer neuen Transformation auf Scrum, aber auch voller Gefahren, wenn man die wirkliche Tragweite eines Inkrements nicht richtig verstanden hat. Deshalb gehe ich auf die aus meiner Sicht größten Stolpersteine noch einmal ein:

  • Sie liefern ein Inkrement aus und dieses Inkrement ist nicht erlebbar. Das kann die unterschiedlichsten Gründe haben wie zum Beispiel: Die Software ist nicht in einem Zustand, so dass sie ein Kunde auch wirklich erleben kann. Sie haben ein Produkt erstellt, aber keinen wirklichen “Durchstich” durch das Produkt generiert, so dass dem Kunden nur ein Blick auf einen Teil des Produktes möglich ist und der ganze Wert nicht erkenntlich ist. Ein Blick auf das Produkt ist also im Sinne eines Projektfortschritts wenig transparent.

  • Wenn Sie Ihre bisherige Entwicklung lediglich in “Sprints” zwängen, innerhalb in des Sprints aber nach wie vor ein sequentielles Vorgehen umsetzen, dann werden Sie keine agile Entwicklung und keinen Vorteil aus Scrum ziehen können. Das mag zu Beginn vielleicht noch ein logischer Weg sein, verstößt später aber gegen das Inspect und Adapt und auch eine regelmäßige Lieferung von funktionierender Software wird dann problematisch werden.

Sie müssen sich grundsätzlich einmal über den Wertstrom für Ihr Produkt, Ihre Software oder Ihren Service bewusst werden. Nur wenn Sie diesen kennen, können Sie überhaupt entscheiden, wie Ihre Teams organisiert sein sollten. Nur wenn Sie die Teams richtig aufstellen, dann können Sie auch inkrementell entwickeln.

Kennen Sie die Scrum Werte und agilen Prinzipien?

Leider immer sehr vernachlässigt und als “einfach” abgestempelt: die agilen Prinzipien und Scrum Werte. In der Regel haben natürlich die wenigsten Unternehmen, die keinen besonderen Wert darauf legen, diese verstanden. Ich werde die an dieser Stelle nicht erneut herleiten, sondern verweise auf meine bisherigen Blogbeiträge dazu.

Nicht erreichte Product Backlog Einträge gehören nicht in den nächsten Sprint - oder doch?

Immer wieder sehe ich gerne den folgenden Effekt bei Srcum Teams. Der Sprint ist zu Ende und es gibt noch einige Arbeit die im Sprint geplant wurde, aber nicht erledigt werden konnte. Sie liegt also als halbfertige Arbeit vor und gilt nicht als “fertig”, da sie natürlich nicht der Definition of Done entspricht.

Was macht der Product Owner und das Entwicklungsteam? Ganz oft nach dem Motto: was muss, das muss eben und schon stehen diese Einträge wieder im nächsten Sprint. Es wird sich häufiger nicht einmal die Mühe gemacht, dass man sich dem Thema erneut widmet.

Dafür gibt es folgende Ursachen aus meiner Sicht:

  1. Sie entwickeln nicht wirklich inkrementell, denn diese Einträge müssen immer gemacht werden, egal was passiert. Sie sind also zu erledigen, da sonst andere Dinge überhaupt nicht erledigt werden können (Vorarbeiten Integration, etc.).
  2. Sie haben doch nicht die Rahmenbedingungen von komplexen Produkten. Sie müssen nämlich bestimmte Aufgaben immer machen und es ist egal, wie sich der Markt entwickelt. Da würde ich zum einen immer gerne mal hineinschauen, ob dem auch wirklich so ist. Zum anderen scheint wenig Notwendigkeit zu bestehen, mit Scrum zu entwickeln.

Wie Sie richtig gute Product Backlog Items erstellen

Im Folgenden Abschnitt möchte ich das Augenmerk noch einmal genau darauf legen, wie Sie konkret auf gute Produkte hin entwickeln können. ich starte dabei ich mit den elementaren Variablen auf die Scrum fokussiert: Flexibilität und Kundennutzen.

Die Flexibilität fokussieren

Vielleicht ist die Annahme für viele zu trivial und wird gerne als überzogen und zu theoretisch abgetan. Nur wenn Sie dieses Inkrement liefern können, auch dann haben Sie überhaupt die Möglichkeit eine wirkliche agile und inkrementelle Entwicklung durchzuführen. Wenn Sie einmal das Konzept von einem Inkrement verstanden haben, dann begreifen Sie auch sehr schnell den Sinn von Scrum und dann wird schnell alles schlüssig.

Hinweis!

Wenn Sie zu den Personen gehören, die einfach “agile Elemente” einmal ausprobieren und nicht alle Vorteile von Scrum ausschöpfen wollen oder müssen, dann können Sie das natürlich tun. Ihr Ergebnis ist dann kein Scrum, Sie können aber trotzdem Ihre ersten Versuche machen und ausprobieren, wie sich zum Beispiel bestimmte Praktiken wie Planning Poker, User Stories oder Taskboards anfühlen und bei Ihnen einsetzen lassen.

Sie brauchen eine Flexibilität, um an einem dynamischen und volatilen Markt bestehen zu können. Wir erinnern uns an das Cynefin Framework, nur wenn Sie die Schritte “probe - sense - respond” benötigen, dann sind Sie auch im komplexen Bereich. Und dann brauchen Sie auch genau diese Inkremente. Wenn Sie die Inkremente nicht schaffen, dann entwickeln Sie an Ihrem Markt vorbei. Wenn Sie nicht am Markt vorbei entwickeln, dann haben Sie diese komplexen Rahmenbedingungen nicht. Und dann brauchen Sie dieses Inkrement auch nicht, dann sollten Sie aber genau überlegen, was für Vorteile Sie sich von Scrum erhoffen und warum Sie es einsetzen.

Die Kunden im Blick

Als nächstes müssen Sie Ihre Kunden im Blick behalten. Das sagt sich zwar einfach, ist aber in der Realität schwer. Denn Kunden im Blick halten bedeutet nicht, dass Sie mit diesem “halt mal sprechen” und dann der Meinung sind, zu wissen was dieser genau braucht. In komplexen Rahmenbedingen “driftet” die Erwartungshaltung des Kunden beachtlich. Und das auch oft so, dass Sie die Erwartungshaltung nicht einfach in einem Gespräch erarbeiten können, sondern der Kunde muss diese erleben. Nur durch die oben genannte Flexibilität hat ein Product Owner überhaupt die Möglichkeit irgendeine Verbesserung zur Optimierung des Mehrwerts für den Kunden herbeizuführen. Er ist derjenige, der das Beste aus dem Produkt mit dem Entwicklungsteam zusammen herausholen muss. Dafür ist es unabdingbar, den Kunden und die Wünsche zu erleben, zu reflektieren und dann zu kennen.

Gute Product Backlog Items erstellen

Im Grunde ist das einfach aber nicht leicht umzusetzen. Sie haben genau dann gute Product Backlog Items, wenn diese für sich einzeln genommen

  • einen Mehrwert liefern und
  • sich einzeln in ein Inkrement überführen lassen

Das finden wir zum Beispiel in den INVEST Kriterien von User Stories. Sie müssen einen Wert (value) liefern und sie dürfen nicht voneinander abhängig sein. Wenn Sie dieses Muster etablieren, dann werden Sie mit Ihrem Inkrement Erfolg haben.

Scrum Entwicklungsteam

Teamzusammensetzung

Teamzusammensetzung in Scrum: So geht’s!

Wer mit Scrum startet, muss sich Gedanken machen, wie die Teamzusammensetzung der Teams aussieht, die ein Produkt umsetzen. Mit der Teamzusammensetzung ist gemeint, wie das Team, dass in Scrum cross-functional entwickeln soll, sich zusammenstellt. Welche Personen mit welchen Skills werden benötigt und arbeiten in dem Team zusammen und entwickeln das besagte Produkt. Während früher die Teams einfach durch das Management bestimmt wurden, geht es mehr und mehr dazu über, dass sich Teams frei organisieren dürfen. Doch wie funktioniert diese Selbstorganisation?

Teamzusammensetzungen früher: es wird bestimmt!

Wenn Sie nicht in einem super innovativen Unternehmen arbeiten, das eine Teamfindung für Projekte erlaubt, kennen Sie die Zuweisungen von Mitarbeitern zu Projekten wahrscheinlich nur zu gut. Der Chef bestimmt, wer an welchen Projekten arbeitet. Das kann der richtige Weg sein, sein Personal zuzuteilen. Aus Sicht des Management ist es vielleicht sogar einzig richtige.

Es gibt - gerade im Bereich der Wissensarbeit - Projekte, in denen das nicht mehr so einfach der Fall ist. Hier spielen deutlich mehr Faktoren für eine Teamzusammensetzung ein, als es früher der Fall war. Motivation, Selbstbestimmung und das exzellente Können sind nun Treiber geworden, die für die Teamzusammensetzung eine Rolle spielen.

Die Teamzusammensetzung neu gedacht

Voraussetzungen

Für die folgende Beschreibungen gehe ich davon aus, dass wir uns über ein größeres Unternehmen unterhalten, in dem auch verschiedene Projekte durch verschiedene Teams bearbeitet werden können.

Wenn Sie nur ein Produkt und nur ein Team haben, dass alle benötigten Fähigkeiten besitzt, dieses Produkt zu entwickeln, haben Sie natürlich nur sehr geringe Möglichkeiten, die Teamzusammensetzung innerhalb des Unternehmens zu beeinflussen.

Es muss also eine gewisse Auswahlmöglichkeit zwischen Personen und Teams bestehen.

Freiheit und Anarchie funktionieren nicht

Mehr als einmal habe ich es nun erlebt: Das Management möchte Freiheit geben und startet für neue Teams mit der Ansage: “Sucht euch euer Team selbst!”. Diese Veränderung der Teamzusammensetzung ist zum einen sehr groß. Zum anderen ist die Bedeutung der Teamzusammensetzung so nicht richtig.

Was passiert dann häufig? Es gibt Teams, da wollen alle arbeiten, in anderen aber nur wenige oder gar keiner. Jetzt hat die Organisation ein Problem! Die Mitglieder der zukünftigen Teams versammeln sich verstärkt um die Teams und erwarten nun natürlich, dass sie auch dort arbeiten können. Aus Sicht der Psychologie ist so eine Ansage für eine optimale Teamzusammensetzung nicht hilfreich.

Hier kommen die ganzen Anzeichen zum Vorschein, die es früher auch schon gab - aber durch die Bestimmung einer Führungskraft festgelegt wurde. Die Wünsche waren und sind ähnlich, hier kommen Sie aber ans Tageslicht und erzeugen eine Transparenz. Das ist gut, denn nur so können Sie auch reagieren.

Wir brauchen andere Werkzeuge, um Teams zusammenzustellen. Doch wie machen wir das am besten?

Manche Teamzusammensetzungen ändern sich nicht

Seien wir realistisch. Auch bei aller Euphorie von Teams, dass sie nun etwas selbst zusammenstellen und sich in Teams frei organisieren dürfen, gibt es Rahmenbedingungen, die vorhanden sind und berücksichtigt werden müssen. Und gute Mitglieder oder ganze Gruppen eines Unternehmens wissen, was sie gut können und wollen vielleicht auch gar nichts anderes machen. Das betrifft vor allem die Teamrollen. Wenn es zum Beispiel den Architekten in einem Scrum Team nicht gibt, gibt es doch Präferenzen und die Skills werden auch benötigt. Es ist also sehr unwahrscheinlich, dass sich gute Mitglieder so zusammenstellen, dass eben dieser Skill in einem Team fehlt. Das machen Teams oft auch über die vorgegebenen Grenzen hinweg heute schon.

Wie es trotzdem klappen kann: Teamzusammensetzung neu gedacht!

Es geht auch anders. Wer sich etwas über Teamzusammensetzungen Gedanken macht, kann auch mit nicht so einfachen Rahmenbedingungen sich von alten Strukturen lösen. Dabei sollen zwei wichtige Dinge im Fokus stehen:

  • Die Motivation der Gruppen zur Aufteilung auf Teams soll bewahrt und gefördert werden
  • Unternehmerische Strukturen müssen sich in den Teams abbilden

Gerade zu Beginn haben Sie wahrscheinlich viele Rahmenbedingungen. Wenn Sie drei Architekten haben und drei Teams zusammenstellen wollen, die alle einen Architekten brauchen, dann können Sie nicht ohne Regeln diese Teams aufstellen. Denn wenn ein Team an einem Produkt arbeiten soll, das alle Architekten gut finden, dann wollen vielleicht alle darin arbeiten. So etwas ist dann in den unternehmerischen Strukturen zu berücksichtigen.

Werkzeuge für die Teamzusammenstellung

Das Schöne ist, dass Sie nur ein paar wenige Werkzeuge für eine Teamzusammenstellung benötigen. Der Rest funktioniert praktisch alleine. Sie benötigen lediglich zwei einfache Werkzeuge, um Ihre Teamzusammenstellung zum Erfolg werden zu lassen:

  • Stellen Sie Regeln auf, die Ihre benötigten Unternehmerische Strukturen abzubilden.
  • Nutzen Sie ein Format für die Zusammenstellung und etablieren Sie dazu ein kleines Event.
Regeln Teamzusammensetzung

Ich benutze gerne ein Flipchart mit Regeln, die von allen Teams einzuhalten sind. Das können grundlegende Themen sein, die oft allen klar sind, aber ich schreibe sie zum gemeinsamen Verständnis noch einmal auf. Das sind zum Beispiel:

  • Jedes Team hat einen Analysten
  • In jedem Team muss mindestens eine Person aus Bereich A sein
  • Jedes Team hat nicht mehr als X Personen aus Bereich Y
  • Es gibt mindestens 4 Personen in jedem Team
  • ...

Auch Sie werden diese Bedingungen bei einer Teamzusammensetzung haben. Überlegen Sie auch mal an implizite Dinge, die Ihnen sowieso klar erscheinen. Sowas sind oft die ersten Schritte sich an diese Regeln zu machen.

Das Format ist immer wieder Komponente, an der ich variieren kann. Ich nutze zwar auch hier praktisch immer wieder sehr ähnliche Komponenten, aber die Freiheit zur Änderung bestünde - ebenso bei Ihnen. Was aus meiner Sicht gut funktioniert aber etwas Zeit für die Vorbereitung entspricht ist das folgende Vorgehen. Schreiben Sie Stellenbeschreibungen für die Rollen im Team. Jedes Team hat dann eine bestimmte Anzahl von Stellenbeschreibungen. Hier sind dem Format keine Grenzen gesetzt, Sie können also entweder damit beginnen, nur so viele Stellenbeschreibungen zu nutzen, wie sie auch Plätze im Team haben. Oder Sie variieren und machen einen Überhang an möglichen Stellen. Das liegt an Ihnen.

Im folgenden Bild ist ein Teamboard abgebildet. Dort sehen Sie ebenso die Stellenbeschreibungen. Sie können jetzt pro Team so ein Setting bereitstellen.

Stellenbeschreibung Teamrollen

Stellen Sie sich hier eine Art Marktplatz vor: verschiedene Teams haben verschiedene Stellenbeschreibungen und die Mitglieder dürfen sich nun diese Stellenbeschreibungen ansehen.

Auch hier können Sie wieder unterschiedliche Szenarien durchspielen.

First Come, first serve

Ein einfaches Prinzip ist nach FCFS vorzugehen. Nachdem Sie also die Regeln vorgelesen haben, lassen Sie die Mitglieder einfach machen. Wer eine passende Stellenbeschreibung findet, nimmt sich diese und platziert sich beim Team.

Wenn alle Beschreibungen einen Mitarbeiter gefunden haben, haben Sie Glück. In der Regel ist es aber nicht so. Ein oder zwei Mitglieder sind nicht zufrieden oder wollen doch in einem anderen Team arbeiten. Das passiert und ist normal.

Teamzusammensetzung Scrum nur Stellenbeschreibung Team

Hier bietet es sich dann an, die Rollen umzudrehen. Lassen Sie dann die existierenden Teams die Gruppe an über gebliebenen Personen anschauen und überlegen, was dem eigenen Team noch an Kompetenzen fehlt und ob das jemand leisten kann. Aus Sicht der Psychologie ist das spannend: die, die nichts gefunden haben, lernen jetzt kennen, warum sie von anderen doch gebraucht werden. Für die Motivation in der Teamzusammensetzung ist das ein nicht zu unterschätzender Vorteil.

Einstellungsgespräch

Wenn Sie Mitglieder haben, die in diesen Teams einen entschiedenen Anteil haben, können Sie diese auch als Sparringspartner nutzen und alle die, die in das Team wollen müssen die Stellenbeschreibung noch einmal challangen. 

Teamzusammensetzung Scrum

Jeder der eine passende Stellenbeschreibung findet, nimmt sich diese und “bewirbt” sich beim Teamvertreter. Wenn mehrere im Team sind, kann dieser Prozess dann auch gerne vor allen Teammitglieder stattfinden.

Hier ist das warum sehr entscheidend, also das Team sagt ob der auf die Stellenbeschreibung passt und der Interessent muss klar darlegen, warum er denkt, er passt in das Team.

Fazit für Ihre Teamzusammensetzung

Es ist kein großer Schritt für die Führungskräfte, aber ein großer für die Befähigung und Motivation Ihrer Teammitglieder. Machen Sie aus Gruppen im Unternehmen echt Teams, die Ihre Teamrollen mit Begeisterung ausfüllen und leben. Nutzen Sie die oben beschriebenen Werkzeuge für Ihre Veränderung der Teamzusammensetzung. Sie werden sehen, dass mehr Verantwortung, Ermächtigung und Selbstorganisation der Mitarbeiter sich mehr als auszahlt - für Sie als Führungskraft und das ganze Unternehmen.

YouTube ScrumKurs24

Commitment und Schätzung

Das Problem von Commitment und Schätzung

Commitment und Schätzung werden in meiner beruflichen Tätigkeit oft als Synonym verwendet. Ein fataler Fehler, denn kein Team, kein Mitarbeiter traut sich mehr etwas zu schätzen, denn seine Schätzung wird als Commitment aufgefasst und weiter verwendet.

Der Manager nimmt die Schätzung und teilt es dem Vertrieb, dem Geschäftsführer und weitere Stakeholdern mit. Dabei wollte das Team einfach eine Schätzung abgeben, wie lange sie wohl mit der vorhandenen Mannschaft brauchen, um eine Funktionalität zu liefern. Es ist egal und unbedeutend, ob diese Schätzung richtig oder falsch ist. Es war und bleibt eine Schätzung.

Diese Schätzung "wir denken, wir brauchen Zeit X, um diese Funktionalität zu liefern", wird als Commitment (Verpflichtung) interpretiert, "wir liefern in der Zeit X diese Funktionalität".

Commitment heißt Forecast im Scrum Guide

Commitment und Schätzung

Während früher sich das Wort "Commitment" im Scrum Guide gefunden hat, gibt es das nun nur noch in den Scrum Werten, aber nicht mehr bei der Schätzung. 

Es wurde ersetzt. Das neue Wort heißt Forecast. Forecast soll ausdrücken, dass sich in Zeiten von Komplexität und Ungewissheit, keine Verpflichtung auf genau diese X Einträge aus dem Backlog erreichen lässt. Stattdessen gibt das Entwicklungsteam nun eine Vorschau ab - muss es nun keine Verpflichtung mehr geben?


In meinen Augen muss das Entwicklungsteam nach wie vor eine Verpflichtung abgeben. Das Wort wurde zwar in der Beschreibung geändert, aber die Bedeutung hat sich für mich inhaltlich nicht stark geändert. Es hilft aber typischen Außenstehenden Personen einen besseren Einblick zu bekommen. Während früher vielleicht kein Manager zwischen Commitment und Schätzung unterschieden hat, fehlt diesen Personen nun das harte Kriterium. Foreacest klingt weitaus schwächer oder einfacher. Es entschärft die Sprache in meinen Augen.

Commitment

Keine Schätzung ohne Wahrscheinlichkeit!

Commitment und Schätzung lassen sich leicht unterscheiden, wenn die, die Schätzungen vornehmen eine Wahrscheinlich mit angeben.

quote-right

Entwickler: "Mit einer Wahrscheinlichkeit von 60% brauchen wir 7 Tage"

Manager: "Und wie komme ich auf 95%?"

Entwickler: "dazu brauchen wir 47 Tage"

Manager: "was?"

Und plötzlich sind alle Personen in einem Dialog und kommunizieren. Es ist keine absolute Schätzung, sondern hilft, die inhaltliche Diskussion anzustoßen.

Falsche Schätzung und Commitment führt zudem zum Parkinsonschen Gesetz: Wenn ich sage, ich brauche 7 Tage und bin nach 2 Tagen fertig, was tue ich dann? In der Regel füllt sich die vorhandene Zeit mit der Aufgabe. Obwohl wir mehr leisten könnten (wir sind nach 2 Tagen fertig) werden wir die 7 Tage ausnutzen. Denn sonst hätte wir uns ja "verschätzt". Das kann dann bei Vorgesetzten oder Auftraggebern in den falschen Hals kommen.

Puffer Commitment und Schätzung

Zudem generieren Sie hiermit Puffer bei den Mitarbeitern. Ihr Mitarbeiter werden beginnen mehr zu schätzen, als sie brauchen, wenn Sie die Schätzung als Commitment ansehen.

Mehrere Produkte im Team

Mehrere Produkte im Team entwickeln

Das Setting: Mehrere Produkte im Team entwickeln

Mehrere Produkte ein Scrum TeamMehrere Produkte im Team – eine Herausforderung vor der ich einmal mit einem Team stand. In dem besagten Projekt standen die Rahmenbedingungen fest. Ich bin ein Fan von Scrum nach Lehrbuch, da bei allen Derivaten zwar immer Verbesserungen erzielt werden können – nie aber so gigantische, wenn das Framework komplett und vollständig angewendet wird.

Nicht immer sind die Rahmenbedingungen so, wie diese sein sollten. Nicht immer haben wir wirklich alle Ansatzpunkte in der Hand, um Scrum in seiner Gänze zu machen. Auch wenn dann solche Implementierungen streng genommen kein Scrum (vgl. Scrum Guide) sind, kann es eine beachtliche Prozessverbesserung mit sich bringen.

Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum Guide

Mehrere Produkte im Team war in diesem Setting die einzige Möglichkeit, denn es gab nicht mehr Teams, es konnten nicht weniger Produkte entwickelt werden und Scrum sollte ausprobiert werden. Es stand damit auch der experimentelle Charakter im Vordergrund.

Um was für Produkte geht es?

ProduktDie Produkte, die durch das Team umgesetzt wurden, waren reine Softwareapplikationen. Es waren teilweise kritische Applikationen im Unternehmen, teilweise auch nicht. Die Wichtigkeit der kritischen Applikationen war enorm, denn darüber verdiente das Unternehmen sein Geld. Dabei wurden die Produkte nicht im klassischen Sinne verkauft, sondern durch die Nutzung und Anwendung dieser Produkte entstand für das Unternehmen Geld.

Nicht jede Applikation wurde neu entwickelt. Es gab diese Applikationen bereits und an einigen wurde mehr neues umgesetzt, an anderen weniger. Mehrere Produkte im Team waren nötig, da diese Produkte durch ein Team betreut wurden und alle Produkte noch Anpassungen bekamen.

Zusammenstellung des Teams

TeamzusammensetzungDas Entwicklungsteam mit Scrum Master befanden sich an einem anderen Standtort als die drei Produkt Owner, aber alle in Deutschland.  Das Team hatte die benötigten Skills aus diesem Produkt ein Produktinkrement herzustellen. Alle Teams waren bei einem Softwareunternehmen tätig. Die Product Owner waren nicht im direkten Konkurrenzkrieg sondern partnerschaftlich unterwegs. Sie stammten auch alle aus dem gleichen Unternehmen, mussten aber für bestimmte Applikationen den Mehrwert im Sinne des Kunden treiben.

Wie wurden mehrere Produkte im Team entwickelt?

Mehrere Produkte im Team zu entwickeln benötigte einige Anpassungen, die sich aber grundsätzlich einfach und unkompliziert durchführen ließen. In diesem Abschnitt gehe ich einmal auf diese Änderungen im Detail ein.

Sprint Planning 1

Scrum Sprint PlanningDas Sprint Planning 1 wurde mit allen Product Ownern der einzelnen Produkte durchgeführt. Dazu gab es im Vorfeld schon eine Abstimmung (PO-Arbeit) zwischen den einzelnen Personen. Die Product Owner haben im Vorfeld Ihre Product Backlog Items (aus drei Backlogs) gegeneinander konsolidiert und sich auch eine Reihenfolge einigen müssen. Für das Team stand genau ein Product Backlog zur Verfügung, in dem alle relevanten Items vorhanden waren. Diese waren beschrieben, geschätzt und in einer Reihenfolge sortiert. Ebenso war der Business Value in jedem Product Backlog Eintrag für das Unternehmen erkennbar.

Die Product Owner haben Ihre Einträge vorgestellt und das Team hat solange Einträge aufgenommen, solange klar war, dass die Product Backlog Einträge noch in den Sprint gepasst haben und zusätzlich auch bei Abhängigkeiten möglich waren.

Backlog Refinement

Backlog Refinement ToolboxIm Backlog Refinement wurden die einzelnen Product Backlog Einträge (PBI) durchgesprochen. Für die Vorstellung und die Durchspräche eines PBI wurde in etwa 20 Minuten benötigt. Vor dem eigentlich Projekt wurden ebenso zwei Refinements unternommen, damit genug Product Backlog Einträge zur Verfügung standen. Bei einigen Einträgen war das Wissen über die Product Backlog Einträge bei allen Product Ownern verteilt und nicht alle Product Owner mussten immer anwesend sein. Um mehrere Produkte im Team zu entwickeln, war es absolut notwendig, dass immer ein Product Owner dabei war, der die Einträge erklären konnte. Das ist natürlich nicht verwunderlich, aber wichtig zu verstehen, ist es trotzdem!

Sprint Ziele

Mehrere Produkte im TeamWie sich jeder vorstellen kann, war es mit den Zielen nicht ganz so einfach, da unterschiedliche Produkte in der Regel auch unterschiedliche Ziele haben. Ebenso war es auch bei diesem Projekt. Es gab zu Beginn Ziele, die alle Teams nutzen konnten. Als die Teams starten gab es mehr “lernende” Ziele und ebenso waren einige “qualitative” Ziele durchaus für alle zu benutzen.

Soweit es wirklich möglich war, haben wir versucht in Abhängigkeit der Vision immer Sprint Ziele zu finden, die für alle Applikationen / Produkte galten. Das war uns wichtig, denn je nach Anzahl der User Stories war es nicht immer leicht für wenige Stories (für ein Produkt) ein extra Ziel zu finden. Es gab aber tatsächlich solche Moment, in denen wir dann pragmatisch diesen Weg gegangen sind.

Vision

Scrum VisionDie Vision hat recht gut funktioniert. Wir haben hier den Weg gewählt, diese in vier Sätzen auf einem Flipchart zu erstellen. Es war hilfreich, dass wir die Applikationen in Summe mehr oder weniger das gleiche Ziel für das Unternehmen hatten, die Vision war also für alle gemein gültig.

Produktinkremente

Mehrere Produkte im Team - mehrere InkrementeMehrere Produkte im Team bedeutete auch mehrere Inkremente, die das Team zeigt und vorstellt. Nun war es so, dass nicht alle Inkremente übermäßig viel Arbeit und Aufwand bedeuteten. Es gab nicht immer für jede Applikation ein Inkrement, sobald aber Product Backlog Items für eine Applikation vorhanden waren, gab es auch ein Inkrement.

Mehrere Produkte im Team – was war nicht so gut?

  • Wenig überraschend, hat ein Team, das mehrere Produkte entwickelt, nicht viel Zeit für jedes Produkt, wie wenn das Team ein Produkt am Stück entwickeln würde. Der Arbeitsfortschritt für die einzelnen Applikationen wäre wohl schneller gewesen, wenn alle Applikationen nacheinander entwickelt worden wären. Das ist der Blick von außen auf alles. Da hier aber teils auch Wartungsarbeiten und kleine Verbesserungen vorgenommen wurden, wäre es nicht trivial, das anders aufzustellen. Die Velocity war damit nicht überragend hoch, reichte aber den Product Owner der jeweiligen Applikationen für Ihre Umsetzungen. Bei Problemen haben die Product Owner Prioritäten und Abhängigkeiten vor dem Sprint Planning mit weiteren Hierarchieebenen besprochen und eine Lösung im Vorfeld gesucht.
  • Mehrere Produkte im Team bot eine neue Herausforderung für die Product Owner in der Releaseplanung. Es war nicht immer klar, wann welche User Story auf Basis der Velocity umgesetzt werden kann. Die finale Abstimmung wurde in der Product Owner Runde besprochen und dann final priorisiert. Das erforderte häufiger eine Neuplanung auf Basis aktueller Product Backlog Items, die nicht wie geplant umgesetzt werden konnten.
  • Man stößt bei dem Thema “Mehrere Produkte im Team” immer wieder an Grenzen. Diese lassen sich in Retrospektiven gut untersuchen. Das haben wir gemacht, aber keine entscheidende Verbesserung aufgrund der Rahmenbedingungen erzielen können. Es wurden mögliche Änderungen identifiziert das Setting “Mehrere Produkte im Team” anzupassen – diese Änderungen wurden dann im Ganzen unter Berücksichtigung aller Pro und Contras mit dem Management nicht mehr adressiert. 
3 Backlog Refinement

So verbessern Sie Ihr Backlog Refinement

Das Backlog Refinement

Backlog Refinement ToolboxDas Backlog Refinement in Scrum ist eine sehr wichtige entwicklungsbegleitende Tätigkeit, die im Scrum Guide mit etwa 10% der Entwicklungskapazität des Team berechnet wird. Ziel dieser Aktivität ist es, dass Anforderungen aus dem Product Backlog eine gewisse Reife erlangen, um in der Sprint Planung sinnvoll prozesiert werden zu können. Das Entwicklungsteam und der Product Owner haben hier die Möglichkeit das Verständnis zu schärfen: sie detallieren Anforderung, schätzen und schneiden diese.

Das sagt der Scrum Guide zum Refinement

User StoryBei der Frage nach einer ersten Idee zur Umsetzung des Backlog Refinement lohnt sich der Blick in den Scrum Guide. Hier finden wir die folgenden Angaben:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner�s discretion.

Meine Erfahrung zum Backlog Refinement

Scrum MasterMeine eigenen Erfahrungen und Eindrücke zum Backlog Refinement möchte ich Ihnen hier natürlich auch noch auf den Weg mitgeben:

  • Bevor der erste Sprint startet, finde ich es als hilfreich mit dem Team und dem Product Owner ein bis drei Refinements zu machen, um das initiale Backlog auf einen guten Stand zu bringen. Das müssen Sie natürlich nicht tun, es hilft in meinen Augen aber sehr, dass die nachfolgenden Events in Scrum schnell und gut durchgeführt werden können, da die Basis der Anforderungen auf einem guten Stand ist.
  • Es kann Projekte geben, in dem das Backlog Refinement nur minimal Zeit in Anspruch nimmt. Das hängt immer ganz von den Rahmenbedingungen ab.
  • Ich nutze klare Vereinbarungen zwischen Team und Product Owner: das Backlog Refinement ist – wie die anderen Events auch – ein fester Termin mit Agenda, um das Thema der Komplexität zu verringern und einen Rahmen zu schaffen.
  • Natürlich nicht immer zu halten, aber gerne als Startwert für mich zur Kontrolle: Können die Product Backlog Items im Refinement innerhalb von 20 Minuten besprochen werden? Wenn nein, dann sind sie in der Regel zu groÃ� oder benötigen noch weitere Verfeinerungen. Auch das ist sehr abhängig vom Kontext, stellt für mich aber einen Wert bei der Analyse von neuen Teams dar.

Der Ablauf eines Backlog Refinements

Ablauf im Backlog RefinementIn meinen Augen hilft es oft sehr, sich über so einen Ablauf einmal in Detail Gedanken zu machen. Ich sehe auch das Backlog Refinement immer unter dem Gesichtspunkt einer kontinuierlichen Verbesserung.

Legen Sie das Backlog Refinement als Termin an

Ich empfehle sich im Vorfeld bei der Festlegung der Scrum Umsetzung zwischen Product Owner und Entwicklungsteam das Refinement als festen Platz im Sinne eines Termins festzulegen. Dazu sollten sich Product Owner und Team überlegen, was sie gedenken an Zeit für dieses Meeting zu benötigen. Auch hier gilt, an diesen Wert ist das Team mit dem PO natürlich nicht gebunden, wenn es geändert werden muss, wird es geändert und angepasst. Dazu bietet sich dann auch die Retrospektive an.

Den Termin für das Backlog Refinement kann wahlweise der Product Owner oder auch der Scrum Master einstellen. Für beides gibt es Präferenzen:

  • Wenn bei Ihnen der Scrum Master alle Termine verwaltet, dann kann er es natürlich auch für das Backlog Refinement tun. Der Vorteil ist, dass er sich damit um alle Termine kümmert und wenn zum Beispiel jemand absagt, krank ist oder sonst etwas passiert, er immer direkt am Puls der Zeit ist. Das sollte er zwar so oder so sein, aber aus meiner Erfahrung hilft das trotzdem noch einmal.
  • Wenn der Product Owner bei Ihnen zum Beispiel auch für das Sprint Review einläd, dann wäre auch das Refinement für ihn eine gute Möglichkeit seine Wichtigkeit und den Fokus für das Team auszudrücken. Gefühlt – und je nach Reife des Teams und dessen Zusammensetzung – hat es ein anderes Gewicht, wenn es der Product OwnerÂdie Einladung ausspricht.

Der Vorteil als Meeting

Natürlich stelltÂimmer die Frage nach der Sinnhaftigkeit eines zusätzlichen Meetings. Meine Präferenz liegt darin, dass zu Beginn gleich klar ist, dass es dort noch Aufwand für ein Meeting gibt. Es hilft gleich zu Beginn zu überschauen, was an “Management” für den Sprint und den Inahlt wirklich nötig ist.

Agenda und Teilnehmer festlegen

Zu jedem guten Termin gehört eine Einladung und die richtigen Teilnehmer. Auch das gilt es für jedes Mal zu überprüfen. Ein möglicher Einladungstext bzw. Agenda für die elektronischen Kalender könnte wie folgt aussehen:

Backlog Refinement Agenda & Einladungstext

Liebes Scrumteam,

ich möchte euch hiermit zu unserem Backlog Refinement einladen. In diesem Regeltermin kümmern wir uns um die Reife der Einträge im Backlog.

Datum & Zeit:

  • xx.xx.xxxx (ggf. auch Serientermin), um xx.xxUhr

Ziel:

  • Verfeinerung der Product Backlog Items und Schaffen eines gemeinsames Verständnis über Anforderungen

Agenda:

  1. Vorstellung neuer oder wichtiger Product Backlog Items (PBIs) durch den Product Owner
  2. Fragen zu dem PBI durch das Entwicklungsteam
  3. Verfeinerung des PBI durch �berprüfung und ggf. Erweiterung der Akzeptanzkriterien
  4. �berprüfung auf die richtige Grö�e: kann das PBI im Sprint umgesetzt werden? Wenn nicht, wie schneider wir diese Anforderung?
  5. Schätzen der Anforderungen

Vielen Dank im Voraus für eure Teilnahe und Engagement,

[Scrum Master oder Product Owner]

Nehmen Sie das bitte auch als Vorlage und nicht als reine einzige Umsetzungsmöglichkeit. �berprüfen Sie in wie weit das Ihre Anforderungen an die Einladung vom Backlog Refinement erfüllt und passen Sie es dann entsprechend an.

Das Backlog Refinement als Meeting

Scrum Product OwnerZu dem ausgewählten Termin steht dann das Backlog Refinement als Termin dann an. Der Scrum Master kümmert sich um die Einhaltung der typischen Regeln und hat natürlich auch die Timebox mit seinem Timekeeper im Blick. Es kann hilfreich sein, die entsprechenden Regeln noch einmal auf dem Flipchart zusammenzufassen und im Raum aufhängen, damit jedem gleich noch einmal klar ist, worum es geht. Ja, das wissen die Teilnehmer bereits durch den Kalender, aber gerade in gröÃ�eren Organisationen habe ich die Erfahrung gemacht, dass es durchaus hilfreich ist dieses noch einmal “analog” im Meeting zu unterstützen.

Der Product Owner stellt vor

Der Product Owner kann beliebige Product Backlog Items vorstellen, die ihm wichtig sind. Das beinhaltet zum Beispiel:

  • Ganz neue Product Backlog Items, die das Team noch gar nicht kennt und die erst kürzlich in das Product Backlog eingezogen sind
  • Bereits geschätzte Product Backlog Einträge, die der Product Owner erneut geschätzt haben möchte, Fragen zur Aufteilung (Schneiden) hat oder Details neue Details einbringen möchte
  • Zukünftige Backlog Items, die noch so weit in der Zukunft liegen, dass diese nicht detailliert genug sind, dem Product Owner aber die Einschätzung des Teams helfen kann für wirtschaftliche Entscheidungen

Der Product Owner sollte auch die Person sein, die neue Erkenntnisse und die Details sowie �nderungen direkt im Backlog vermerkt. Das sollte definitiv nicht der Scrum Master tun, das Backlog gehört dem Product Owner und er ist dafür verantwortlich.

Die Vorstellung und Informationen können variieren und je nach Kontext unterschiedlich sein, der Product Owner…

  • …Âliest die User Story vor
  • …Âbeschreibt durch Personas eine Zielgruppe oder geht genauer darauf ein
  • …Âbringt neue Sichten von Kunden mit und diskutiert diese mit dem Team
  • …Âzeigt die angereichterten Informationen aus einem letzten Workshop mit der Zielgruppe

Das Team schätzt und stellt Frage

Das Entwicklungsteam hört sich die Vorstellung des Product Owners an. Darauf hin sollte es natürlich Fragen stellen, wenn welche vorhanden sind. Hier lohnt es sich als Scrum Master oder agiler Coach auch immer darauf zu achten, wie lange diese Diskussionen dauern. Ich persönlich habe die Erfahrung gemacht, dass 20 Minuten ein erster guter Richtwert darstellt. Das variiert je nach Team, Branche und Aufgabe, aber wenn man noch keine empirischen Daten hat, hangel ich mich immer an diesem Wert entlang.

Dauer von Product Backlog Items

Wenn Sie noch keine empirische Erfahrung haben, dann sollten Sie mit dem Wert 20 Minuten pro Product Backlog Item starten. Ihre Erfahrung wird zeigen, ob dieser Wert für Sie nützlich ist. Damit könnten Sie dann drei Product Backlog Items in einer Stunde schaffen. Hier merken Sie schnell, ob das für Sie reicht oder nicht.

Zeitpunkt für dasÂBacklog Refinement

Das Backlog Refinement ist eine entwicklungsbegleitende Tätigkeit und hat keinen festen Platz, wie ein Event in Scrum. Schauen wir uns einmal die Möglichkeiten an, wo und wie das Backlog Refinement am besten untergebracht werden kann.

Backlog Refinement als Entwicklungsbegleitende Aktion

Scrum EntwicklungsteamIch persönlich finde es prima das Backlog Refinement entwicklungsbegleitend durchzuführen. Achten Sie aber auch hier auf Ihre Rahmenbedingungen, wenn sich Anforderungen nicht zu schnell ändern, dann wählen Sie die Frequenz mit Bedacht.

Backlog Refinement zwischenÂSprint Review und Sprint Planning

Sprint ReviewJe nach Sprintlänge kann das Refinement auch direkt nach dem Sprint Review durchgeführt werden. Dann haben Sie zum nächsten Sprint Planning bereits alle aktualisierten Anforderungen vorliegen. Nach dem Sprint Review ist ein guter Zeitpunkt das zu tun, denn wenn die Teams vorgestellt haben, was sie gemacht haben, können Product Owner und Stakeholder das Inkrement erleben und Eindrücke reflektieren.

Nicht zu unterschätzend ist der Fakt, dass sich hier bereits alle wichtigen Personen treffen und so das Backlog Refinement gemeinsam erarbeiten. Das können Sie natürlich auch im Meeting machen, oft sind dann aber nicht alle Stakeholder erreichbar.

2 Gute User Stories schreiben Titelbild

10 Tipps für User Stories

​Gute User Stories schreiben ist eine herausfordernde Aufgabe! Wer sich mit diesem Kommunikationsversprechen bereits einmal auseinander gesetzt hat weiß, was anfangs leicht klingt, kann ganz schön kompliziert werden. In diesem Artikel zeige ich 10 Tipps, um gute User Stories zu schreiben.

Gute User Stories schreiben ist Übung

Sie müssen bei den User Stories üben, üben, üben. Es ist zwar nicht immer leicht und nicht alle Eigenschaften ergeben sich gleich zu Beginn, die wahre Kraft um gute User Stories schreiben zu können ergibt sich aber nach mehrmaliger Anwendung. Sollten Sie vor den Tipps zurückschrecken oder diese noch nie im Zusammenhang gehört haben, dann machen Sie sich nichts draus. Ein guter Meister ist noch nie vom Himmel gefallen.

10 Tipps, die Sie zur Reflexion nutzen können!

1
Formate Retrospektive

An das bekannte Format halten!

Als <ROLLE> möchte ich <BEDÜRFNIS>, um <GRUND> - dieses einfache Format hilft Ihnen unglaublich beim Schreiben dieser User Stories. Denn so haben Sie immer den Anwender im Blick, wissen wie sein wirkliches Bedürfnis ist und kennen auch noch den Grund. Gute User Stories schreiben beginnt mit dieser einfachen Vorlage, die Sie wirklich beherrschen und anwenden können sollten.

Fragen Sie im beruflichen Umfeld bitte häufiger nach den Gründen! Das was in der User Story fast nebenläufig mit zu finden ist, hilft nicht nur hier, sondern praktisch überall. Wir tun oft zu viel, ohne die genauen Umstände zu kennen!

Auch wenn das Format an sich bekannt ist, finde ich im Scrumumfeld gerne auch die ein oder andere User Story die zum Beispiel nicht den Grund enthält. Was zunächst irrelevant aussehen kann, entpuppt sich aber nicht selten als ernstzunehmendes Problem!

2
Gute User Stories schreiben

Card, Conversation & Confirmation

Verstehen Sie die User Story mehr als nur die typische Karte, angepinnt an einer Wand. Denn das ist lediglich einer der drei ursprünglichen Bereiche, die die User Story abbilden kann.

  • Card: die typische Karte, die wahrscheinlich jeder kennt. Der Inhalt dieser Karte ist unter Punkt 1 aufgeführt. Das repräsentiert das typische User Story Format.
  • Conversation: das Kommunikationsversprechen, das zusichert, zu geeigneter Zeit über diese Karte zu sprechen. Die User Story ist also immer verhandelbar und keine Spezifikation, die bereits bis ins Detail ausspezifiziert ist.
  • Confirmation: Das ist der Akzetanztest für die Karte. Hier muss der Product Owner die Erwartungshaltung ausdrücken, die er mit dieser User Story verbindet. Diese eigenen sich auch als gute Testgrundlage oder als Basis für das Schneiden der User Stories.

Fragen Sie im beruflichen Umfeld bitte häufiger nach den Gründen! Das was in der User Story fast nebenläufig mit zu finden ist, hilft nicht nur hier, sondern praktisch überall. Wir tun oft zu viel, ohne die genauen Umstände zu kennen!

Jon Reffies hat dazu einen guten Artikel geschrieben, der lesenswert ist!​

3
Teamdynamik

Den Benutzer nie aus dem Blick verlieren!

Es passiert schnell, den eigentlich Anforderer zu vergessen! Gute User Stories schreiben sich aber leider nicht ohne den Benutzer. Dieser wird gerne einmal in der Diskussion vergessen. Überlegen Sie immer für wen Sie gerade etwas umsetzen wollen. Es gibt dabei immer einen Anwender, der genau diese Anforderung auch haben möchte.

Arbeiten Sie hier mit Personas. Gute User Stories schreiben bedeutet auch immer seinen Anwender zu kennen! Wenn Sie einmal der Meinung sind, es gibt keinen Anwender, dann arbeiten Sie sich an die Wurzel der Anforderung zurück. Woher kommt diese? Wer hat diese gestellt?

Personas helfen Ihnen ein klares Bild über Ihre Zielgruppe zu bekommen.​

4
Archivierung der Retrospektive

INVEST-Kriterien bei User Stories beachten!

Die sechs INVEST Kriterien helfen Ihnen eine gute User Story zu schreiben. Denn das INVEST Akronym gibt an, wie eine User Story sein sollte.

  • Independent (User Stories sollen nicht von einander abhängig sein)
  • Negotiable (User Stories sollen verhandelbar sein)
  • Valuable (User Stories haben immer einen (Mehr)wert und sind nicht Mittel zum Zweck!)
  • Estimated (User Stories sollen eine Abschätzung haben)
  • Sizable (Eine User Story hat immer die richtige Größe, damit sie auch in einem Sprint bearbeitet werden kann)
  • und Testable (Durch Tests kann eine User Story überprüft werden)

Auch das bietet einen perfekten Anhaltspunkt, gute User Stories zu schreiben.

5
Daily Scrum Kommunikation

Über die User Story diskutieren!

Eine User Story ist immer nur ein Kommunikationsversprechen, welches auch eingelöst werden muss. Das ist eines der drei C's (Communication) einer User Story. Mit dem Kunden und / oder dem Product Owner sollte diese Diskussion geführt werden.

In meinen Augen sprechen wir zu wenig und diskutieren auch zu wenig über Anforderungen. Durch das Kommunikationsversprechen und die nicht komplett fertige Story werden Sie dazu praktisch gezwungen - und das ist auch gut so!​ Fühlen Sie sich frei und diskutieren Sie! Natürlich erst zu dem Zeitpunkt, wenn Sie diese Story auch umsetzen wollen.

6
Akzeptanzkriterien

Akzeptanzkriterien beachten!

Anhand der Akzeptanzkriterien wird das dritte der drei C's einer User Story adressiert: Confirmation! Sie können diese Kriterien immer nutzen, um zum einen die Erwartungshaltungen zu treffen und zum anderen auch die Story zu testen (was oft mit dem ersten Punkt einher geht).

Gute User Stories schreiben bedeutet sich genau hier ausreichend und präzise genug Gedanken zu machen​. Konzentrieren Sie sich als Product Owner hier auf das WAS. Versuchen Sie nicht die Lösung in die Akzeptanzkriterien zu legen.

Beispiel: um von Ort A nach Ort B zu gelangen können Sie heute schnell mit dem Auto sein. Allerdings wäre das Akzeptanzkriterium "Reisemittel ist ein Auto" schon die Lösung. Gehen Sie davon weg und beschreiben Sie wichtige Zeiten oder Umstände (z.B. sehr komfortabel), um die Erwartung zu treffen.​

7
Daily Scrum Kommunikation

Vertikal statt horizontal!

Gute User Stories schreiben bedeutet, sich auch mit der ursprünglichen Intention und dem Durchstich zu befassen. Versuchen Sie die User Story immer so zu schreiben, dass der funktionale Durchstich durch das System gewährleistet ist. Wenn Sie die User Stories horizontal der Wertschöpfungskette schneiden, gewinnen Sie wenig zu anderen Vorgehen!

Beispiel: Versuchen Sie nicht zuerst einen Login Screen zu vergolden und dann die Datenbankanbindung als nächsten Schritt zu implementieren. Dadurch steuern Sie auf das Problem zu, dass das eine nur mit dem anderen genutzt werden kann. Schaffen Sie den Login Screen nicht, können Ihre Stakeholder nichts sehen. Setzen Sie das Konzept des vertikalen Durchstichs ein und machen Sie immer ein wenig von allem, aber immer erlebbar.​

8
Daily Scrum Kommunikation

User Stories aufteilen!

Wenn die User Story einmal zu groß wird und im Sprint nicht bearbeitet werden kann, dann hilft die Aufteilung! Die Aufteilung wird immer dann interessant, wenn das Team zu hohe Story Points schätzen lässt. Die Aufteilung können Sie im ersten Schritt immer anhand der Akzeotanzkriterien vornehmen. Sollte das mal nicht klappen, fragen Sie Team und Product Owner nach einer gute Lösung.

Ist noch zu wenig bekannt und das Team kann keine Lösung finden, dann schlagen Sie eine Analyse / Spike etc. vor​. Das wird benutzt um mehr Gewissheit über bestimmte Sachverhalte zu bekommen.

9
Daily Scrum Kommunikation

User Story mal gemeinsam im Expertenteam lösen!

Bei Ihnen arbeiten auch nur Experten und nicht jeder kann alles? Dieses gern genommene Argument mit Scrum nicht erfolgreich arbeiten zu können, nutzen Sie am besten im nächsten Experiment, in dem Sie gerade die verschiedenen Personen - die Experten sind - einmal gemeinsam versuchen lassen eine User Story lösen zu lassen.

Oft meinen die Experten, sie können weder die anderen Stories schätzen noch an ihnen mitarbeiten. Schlagen Sie das Experiment vor, dass im nächsten Sprint mal etwas neues ausprobiert wird. Bringen Sie zwei Personen zusammen, die gemeinsam an einer Story arbeiten, die es sonst nie getan hätten. Reflektieren Sie dann in Retrospektiven!

10
Daily Scrum Kommunikation

Einfach mal die User Story weglassen!

Auch wenn der zehnte Tipp vielleicht komisch klingt, probieren Sie doch einmal die User Story wegzulassen! Wenn Sie dieses Format nicht mehr nutzen, geht es Ihnen dann besser? Vermissen Sie dann einen entscheidenen Teil?

Probieren Sie es aus und machen Sie ein Experiment, analysieren und bewerten Sie es doch in einer der nächsten Retrospektiven!

Gute User Stories schreiben endet natürlich nicht mit diesen zehn Tipps. Durch die Erfahrung wird es Ihnen erst möglich, Ihren eigenen Stil zu verbessern und effektiver zu sein. Probieren Sie und reflektieren Sie, zum Beispiel in Retrospektiven!

Wie sieht es mir Ihren Tipps aus? Was hilft Ihnen, was hat Ihnen geholfen? Freue mich auf Ihr Feedback!

>