Peter Beck

Du bist Product Owner oder arbeitest als Teammitglied eng mit einem Product Owner zusammen? Vielleicht kennst Du folgende Herausforderung. Jede noch so kleine Entscheidung wird an den PO herangetragen. Und das Team wird nicht schneller als der Mensch in seiner PO-Rolle Entscheidungen treffen kann. Du fragst Dich dann sicherlich oft, könnten viele dieser Themen nicht jeder im Team selbst entscheiden? Richtig zäh wird es, wenn das gleiche Spiel über viele Stakeholder außerhalb des Teams läuft.

Vielleicht hast Du Scrum gerade kennengelernt und fragst Dich, wie soll das bei uns funktionieren? Oder im Team und Unternehmen versucht ihr schon seit längerem Scrum anzuwenden. Aber am Ende eines Sprints ist wenig bis nichts fertig, das Team existiert nur auf dem Papier, Retrospektiven werden erst gar nicht durchgeführt; die Liste könnte jetzt noch viel länger werden. Kurz, es scheint, dass ihr Scrum bei Euch nicht machen könnt. Andererseits ist Dir klar, Scrum richtig anzuwenden würde Euch echte Vorteile bringen. Was also tun? Der folgende Leitfaden wird Dir helfen.

A RACI matrix is a static schema of who is accountable or responsible for defined tasks. It is also documenting who needs to be informed or consulted. All in all, it is a description of the delegation of work in an organization. Unfortunately, a RACI is most probably establishing a blaming culture.

Wenn man Agile und Lean ernst nimmt, dann gibt es nur 3 Arten von agilen Führungskräften. Die wichtigste davon bezeichnen wir in Scrum als Developer.

Unsere Unternehmen, unsere Gesellschaft und jeder Einzelne ist von der Pandemie betroffen. Aber wir alle wissen auch, dass wir noch vor viel größeren Veränderungen steht, auf die wir jetzt und in Zukunft Antworten finden müssen. Genau dafür ist Scrum geschaffen. Gerade jetzt.

Welches Spiel kann ich spontan mit meinen Teamkolleg*innen online spielen? Heute ist eine kleine Liste bei unserem täglichen DSTKaffee zusammen mit unserer Pfad-zum-CSP-Community entstanden:

Seit 10 Jahren helfen wir Unternehmen mit Scrum agil zu werden. Seit 10 Jahren sind wir ein verteiltes Unternehmen. Eine kleine Geschichte vom Tag -1 des Lockdowns, als klar wurde, dass 80% unseres Geschäfts in den nächsten Monaten nicht mehr so stattfinden wird wie es einmal geplant wurde.

Kazunori Yamasaki is a ScrumMaster like in the book. Wearing a bag on this belt filled with markers and Post-its, he is always ready to jump in as facilitator when his teams need navigation to conquer complex challenges. And the teams at Groove X in Tokyo have many of these to overcome these days. Their first product, the robot Lovot, is close to final mass production, and most probably, while you are reading this, you can already buy it.

Als ich den Begriff Agile Leadership zum ersten Mal gehört habe, hatte ich umgehend Bauchschmerzen damit. Schon wieder wird Agile vor altbekannte Konzepte geschrieben, um diese aufzuwerten. Wie Agile Requirements Engineering, Agile Testing oder Agile Wollstricken. Gut, dachte ich, aber Leadership braucht es. Bis ich festgestellt habe, dass der Begriff doch nur verwendet wird, um den Wunsch nach Elitenbildung voranzutreiben, alte Karrierepfade zu festigen oder als Ausrede für Manager, durch ein schwammiges Leadership-BlaBla, erst recht keine Verantwortung mehr zu übernehmen. Hinter all diesem Frust verbirgt sich hinter dem Begriff Agile Leadership aber auch ein grosse Chance zu verstehen, wie Führung in einer Arbeitswelt funktioniert, die sich den agilen Werten verschrieben hat. Die Teile 1 - 3 habe 2 Geschichten von 2 Unternehmen erzählt, um aufzuzeigen, dass Scrum Agile Leadership ist. Dieser Teil fasst die Theorie zusammen und gibt ein paar nützliche Tipps, um in die Praxis zu starten.

In den ersten beiden Teilen wurde anhand der Geschichte von 2 Unternehmen gezeigt, wie ScrumMaster und Product Owner führen. Sie sind eingebunden in einem Führungssystem, welches sich über die Zeit entwickelt. Dieser Teil wird sich ganz dem Team als wichtigste Rolle mit Führungsverantwortung widmen und die Geschichten fortsetzen.

Im ersten Teil wurde an zwei Beispiel-Unternehmen gezeigt, wie Product Owner führen. Der Product Owner ist Teil eines agilen Führungs- bzw. Managementsystems, das für jede Organisation entwickelt werden muss. Scrum liefert einen Rahmen für dieses Führungssystem.

Dieser Teil führt die Geschichten der beiden Unternehmen fort, und zeigt auf wie der ScrumMaster führt.

Die Scrum-Rollen sind die Prototypen für agile Führung und agiles Management. Das Agile Manifest wurde 2001 von den beiden Autoren der ersten Scrum-Publikation mitformuliert. Scrum ist ein Rahmenwerk, um eine Organisation auf Agilität zu optimieren. Es bringt neben dem Grundverständnis, welche Artefakte und Abläufe nötig sind, auch eine Aufteilung der Führungsaufgaben in 3 Rollen mit. Scrum verfolgt auch bei den Rollen einen Lean-Ansatz: Weniger ist mehr. Nur die absolut notwendigen Regeln wurden in das Rahmenwerk aufgenommen.

Das hat den Vorteil, dass jede Organisation das für sie passende Führungssystem innerhalb der Kräftedreieckes der Scrum-Rollen entwickeln kann. Es hat aber auch zum Nachteil, dass das Verständnis um Agile Führung nicht so leicht zugänglich ist und oft auch sehr unterschiedlich interpretiert wird.

Um mehr Klarheit zu schaffen, werde ich in diesem ersten von vier Artikeln die Frage Wie führt der Product Owner? anhand von zwei Beispiel-Unternehmen beantworten.

• Ein junges, stark wachsendes Unternehmen mit anfangs 20 Mitarbeitern.
• Ein über zwei Jahrzehnte gewachsenes, mittelständiges Unternehmen mit 450 Mitarbeitern.

Der Scrum Guide ist heute die unumstrittene Definition von Scrum. Damit dieser aus dem staubigen Umfeld eines tristen Webseitenartikels entfliehen kann und für euere Teams und eure Kollegen leichter zugänglich wird, haben wir das Scrum Guide Poster designt. Als PDF steht es natürlich allen kostenlos zur Verfügung. Wer einen hochwertigen Druck haben möchte, der kann sich hier ein Exemplar bestellen.

Die ersten 100 kostenlose Exemplare wurden schon verschickt. Die hohe Nachfrage hat uns gefreut, deswegen erhöhen wir die Zahl auf 200. Es gibt also noch weitere 100 kostenlose Exemplare für euch zu haben!

Scrum Artefakte oder Prozessdokumente dienen als Orientierung oder Bindeglieder im Prozessrahmen.

4.1 Product Backlog

Das Product Backlog ist das Kernartefakt von Scrum. Bei größeren Produktorganisationen wird das Management desselben unnötig verkompliziert. Was sind Kernaussagen, was sind die Spielregeln für ein Product Backlog, die auch für skalierte Umfelder gelten?

Zunächst einmal: es gibt nur ein Product Backlog. Dazu gibt es im Scrum Guide eine ganz klare Aussage:

Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. […,] Häufig arbeiten mehrere Scrum Teams gemeinsam an einem Produkt. Dann wird ein einziges Product Backlog benutzt, um die anstehende Arbeit am Produkt zu beschreiben. In diesem Fall kann ein Gruppierungsattribut für die Product Backlog-Einträge verwendet werden.

Scrum-Ereignisse umfassen den Sprint, sowie die Scrum-Meetings. Wenn wir die Definitionen im Scrum Guide als Regeln für die skalierte Implementierung auffassen, müssen alle Scrum-Ereignisse sowohl für die einzelnen Scrum Teams als auch für die Gesamtheit - die Produktorganisation - gelten.

In Scrum werden vorgeschriebene Ereignisse verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit anderer, nicht in Scrum definierter, Besprechungen zu minimieren. Alle Ereignisse haben eine zeitliche Beschränkung (Time Box), so dass jedes Ereignis eine maximale Dauer hat. Bei Sprintbeginn steht dessen Dauer fest und darf weder gekürzt noch verlängert werden. Die anderen Ereignisse dürfen beendet werden, sobald sie ihren Zweck erfüllt haben.

Eine der schwierigeren Entscheidungen bei der Bildung einer agilen Produktorganisation ist die Zusammenstellung der Teams. Viele Elemente von Scrum betreffen weitestgehend die Ablauforganisation. Der Aufbau und die stete Leistungssteigerung von Scrum Teams rütteln an der bestehenden Aufbauorganisation

Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam, sowie dem Scrum Master. Scrum Teams sind selbstorganisierend und interdisziplinär.

Schauen wir uns dieses Zitat von hinten nach vorne im Detail an.

Dieser Blogeintrag ist der Anfang einer Reihe von Artikeln, die das Thema "Skalierung von Scrum" auf der Basis von Scrum Guide betrachten und einen Leitfaden in Bezug auf die „regeltreue“ Skalierung von Scrum aufstellen.

Der Scrum Guide definiert Scrum wie folgt:

Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.

Stefan Roock und ich haben auf der 6th Lean, Agile & Scrum Conference 2014 zu ScALeD referiert.

Die Folien zum Vortrag "Beyond SAFe: Wirklich Agile und Lean" sein mit den ScALeD Prinzipien können Sie hier einsehen. Zu Slideshare

Scrum ist ein Rahmenwerk, um komplexe Produkte und Dienste zu entwickeln. Scrum ist nicht dazu da, um Software zu entwickeln. Das Wissen, wie man Software entwickelt, muß das Entwicklungsteam mitbringen und erarbeiten. Das gleiche gilt für die Entwicklung von Hardware- und Mechatronikprodukten.

“Prinzipien skalieren, Praktiken sind kontextabhängig”. Ein Statement von Ken Schwaber, einer der Initiatoren von Scrum. Etwas anders formuliert könnte man auch sagen: Jede Organisation ist einmalig, da ihre Produkte und Services auch einmalig sind. Das bedeutet aber auch, dass jede Organisation ihre ganz eigene Praktiken (=Prozesse) hat, um diese Produkte und Dienstleistungen zu liefern. Was man zwischen Organisationen vergleichen kann, sind gewisse Grundmuster, die wir gerne Prinzipien nennen. Agile definiert sich durch eine Sammlung solcher Prinzipien, die hier verewigt wurden: Agile Manifest. Dieses bemerkenswerte Manifest ist im Kontext der Softwareentwicklung entstanden, wo es in erster Linie darum ging, überschaubare Gruppen in einer für diese Zeit revolutionären Form zu organisieren und damit Leistungsfähiger zu machen. Die Autoren waren so genial, sich nicht auf Praktiken einzulassen, weil sie wussten, dass viele Wege nach Rom führen, und es ja gerade eine Idee von Agile ist, den Weg nicht von vornherein festzulegen.

"Welcher Zertifizierungskurs würde am besten für einen IT PM passen?"

Sie sollten darauf schauen, wo Ihre Hauptverantwortlichkeiten und persönliche Schwerpunkte liegen. Ein Product Owner trägt vor allem die Verantwortung für das Produkt (welche Funktionalitäten werden geliefert)  und für die Planung. Ein ScrumMaster ist verantwortlich für den Prozess. Die Rollen-Definitionen müssten Ihnen eigentlich helfen, die Entscheidung zu treffen.

“Kunden wollen Sicherheit über einen Festpreis. Häufig wird deshalb bereits im Voraus ein Produkt Backlog angefertigt und die Storys geschätzt. Doch bin ich dann wirklich noch agil? Die geschätzten Storys und der daraus festgelegte Preis ergeben, wie viele Personentage ich maximal brauchen darf und daraus auch, wie viele Storys pro Sprint abgearbeitet werden müssen.”...

2012 hatte ich das Vergnügen, Alexander Müller und Martin Hammerle von der  bei mir im Scrum Kurs zu haben und das Team und die Geschäftsleitung beraten zu können. Seitdem verfolge ich immer wieder gespannt die gewonnen Erkenntnisse des Teams, die Alexander Müller uns über seinen  zur Verfügung stellt. Das Besondere daran: Das Team entwickelt Hardware mit Scrum. Etwas, was erfahrene Scrummer wenig verwundert, aber immer noch eine Seltenheit darstellt.

"Mein Entwicklerteam umfasst 6 Personen, von denen nahezu jeder in unterschiedlichen Projekten arbeitet. Hinter diesen Projekten stehen auch unterschiedliche Systeme oder ich nenne es hier mal Produkte. Mein Problem ist, dass die Entwicklerteams für ein Produkt aus ein bis zwei Personen bestehen und somit eigentlich zu klein sind, um sinnvoll Scrum einsetzen zu können..."

Peter Beck hat am 5.6.2013 bei der Scrum Gruppe Karsruhe die Session "Ein Backlog voller Entscheidungen" moderiert. Mehr Informationen zum Treffen hier!

Schon einmal versucht ein Backlog für eine Industrieanlagenentwicklung zu erstellen? Oder schon einmal versucht einen Product Owner, verantwortlich für ein komplexes Mechatronik-Projekt, zu überzeugen Scrum einzusetzen? User Stories sind sicherlich die am meisten propagierte Technik um ein Backlog zu erstellen. Kein Wunder, wurden sie doch in der boomenden Softwareentwicklung als Technik entwickelt. Anderen Gebieten fällt es zunächst schwer User Stories einzusetzen. Die Gründe sind schnell genannt. Komplexität, Ziele und vorhandene Entwicklungspraktiken scheinen nicht dafür zu sprechen. Wie aber soll ein Prodcut Owner nun sein Backlog aufsetzen um sein Entwicklungsprojekt zu starten?

"Wo ist in Scrum Platz für Architekturklärungen? Vielleicht in Backlog-Refinement-Meetings?"

"In den Handouts, die wir von euch bekommen haben, steht: "Planning Poker funktioniert ... hauptsächlich, weil die Menschen, die schätzen, und die, die die Arbeit erledigen, diegleichen sind". Das ist alles, was ich bezüglich der Teilnehmer und Schätzer im Planning Poker in der Dokumentation finden konnte. Die Frage, die mich beschäftigt, ist, ob der Product Owner mitschätzt?..."