Produkte zuverlässig und schnell entwickeln
E-Book, Deutsch, 352 Seiten
ISBN: 978-3-446-45091-2
Verlag: Carl Hanser
Format: EPUB
Kopierschutz: Wasserzeichen (»Systemvoraussetzungen)
Boris Gloger beschreibt leicht verständlich die Werte, Regeln, Strukturen und Rollen von Scrum.
Egal ob Sie als Kunde, Führungskraft, ScrumMaster, Product Owner oder Teammitglied an einem Scrum-Projekt beteiligt sind oder aber erst wissen wollen, was Scrum eigentlich ist:
- Sie erfahren, wie Teams durch weitgehende Selbstorganisation und kontinuierliches Planen Produkte schneller und erfolgreicher liefern können.
- Umfassend wird dargestellt, wie Scrum mit mehreren Teams, die über viele Standorte verteilt sind, eingesetzt wird.
- Zudem ist dieses Praxisbuch eine hervorragende Unterstützung für die Zertifizierung zum ScrumMaster.
Hier erhalten Sie einen umfassenden Überblick und wertvolle Tipps, wie Sie Scrum in der Praxis einführen und leben können.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
2
Die Rollen ? klare Verantwortlichkeiten
Die Stärke von Scrum liegt in der klaren Zuordnung und Trennung von Verantwortung für verschiedene Aspekte des Produktentwicklungsprozesses in drei zentrale Rollen: ScrumMaster, Product Owner, (Entwicklungs-)Team. Ich selbst füge für ein besseres Verständnis von Scrum in Organisationen noch den Kunden, den Anwender und den Manager hinzu.
BAR ? ABENDS
LOUNGE MUSIC, die Bar wirkt ein wenig futuristisch. Drei Männer sitzen an einem Tisch. Der Product Owner trägt einen feinen Anzug und Krawatte, er hält einen Block in der Hand, auf dem er etwas notiert. Ein jüngerer Mann sitzt im Freizeitlook am Tisch. Er sieht dynamisch aus und trägt ein T-Shirt mit dem Aufdruck DAS TEAM. Komplettiert wird die Runde durch den ScrumMaster ? er trägt Outdoor-Kleidung, als käme er gerade von einer Expedition.
SCRUMMASTER: Wir sollten noch mal herausstellen, welche Rollen und Verantwortungen wir in diesem Projekt haben. Herr Product Owner, könnten Sie bitte anfangen?
Der Product Owner richtet sich auf, kratzt sich am Kopf, schaut in seine Unterlagen.
PRODUCT OWNER: Ich weiß gar nicht, wo ich anfangen soll. Nun gut, also …
Er schaut noch einmal in die Runde.
PRODUCT OWNER: Ich bin der Product Owner. Meine Aufgabe in diesem Projekt ist es, die Vision zu haben und sie an alle plastisch und präzise zu vermitteln. Das ist nicht immer einfach. Der ScrumMaster hilft mir in der Regel dabei, die Vision zu finden.
Das Team verdreht die Augen. Der ScrumMaster schaut das Team an, runzelt die Stirn. Das Team wendet sich wieder dem Product Owner zu.
PRODUCT OWNER: Wenn klar ist, wohin das Projekt gehen soll, kommuniziere ich die Vision an alle und dann rede ich mit dem Team über die Funktionalitäten, die das Produkt später einmal haben soll. Im Anschluss daran entsteht das Product Backlog, die Liste der Funktionalitäten. Diese Liste wird von mir nach ihrem Business Value priorisiert. Ich muss mir also überlegen, welchen Wert jede einzelne Funktionalität für unser Produkt hat.
Das Team wackelt unruhig auf dem Stuhl hin und her. Der ScrumMaster schaut es an.
SCRUMMASTER: Ja?
TEAM: Jetzt sollte ich etwas hinzufügen. Ich bin nämlich, nachdem der Product Owner das Backlog priorisiert hat, dafür verantwortlich, jedes Backlog Item zu schätzen. Nicht immer einfach, kann ich euch sagen.
PRODUCT OWNER: Stimmt genau. In der Regel macht das Team das aber wirklich sehr gut. Im Sprint Planning gebe ich noch das Ziel vor, damit wir darüber verhandeln können. Am Ende der Iteration komme ich zum Sprint Review und schaue mir an, was das Team produziert hat. Ich kenne das Ergebnis zwar meistens schon vorher, aber diese formale Prüfung ist wirklich gut und, wie ich finde, sehr wichtig.
TEAM: Okay ? lass mich mal. Ich bin das Team. Ich liefere das Produkt. Ich bin dafür verantwortlich, meine Absprachen mit dem Product Owner einzuhalten. Wenn ich sage, ich liefere, dann liefere ich auch. Meine Verantwortung ist, jedes Backlog Item zu schätzen. Ich bin für die Umsetzung vollständig verantwortlich, deshalb habe ich auch die Autorität, die Dinge ? im Rahmen des Möglichen ? so zu tun, wie sie meiner Meinung nach getan werden müssen. Ich organisiere mich selbst, niemand sagt mir, wie etwas getan werden soll. Wenn ich ein Impediment erkenne, gehe ich damit zum ScrumMaster.
Der ScrumMaster schaut auf das Schweizer Messer in seiner Hand, dreht es und legt es auf den Tisch.
SCRUMMASTER: Das war wohl mein Stichwort. Das ist tatsächlich zunächst meine Hauptaufgabe. Ich helfe dabei, dass das Entwicklungsteam so schnell wie möglich vorankommt. Ich bin so etwas wie ein Expeditionsleiter, der seinem Expeditionsteam hilft, die täglichen Probleme zu lösen. Ich helfe, wo ich kann, bin aber nicht derjenige, der das Produkt entwickelt.
Das Team nickt.
TEAM: Darin ist er richtig gut. Er kann manchmal wahre Wunder vollbringen.
SCRUMMASTER, lächelnd: Danke, aber das funktioniert nur so gut, weil ich einen guten Draht zum Management habe. Du machst die Arbeit. Ich sorge nur dafür, dass du dabei so effektiv wie möglich vorgehst. Ich habe aber noch den Product Owner. Mit ihm arbeite ich daran, das Backlog zu optimieren, die Backlog Items geschickt aufzuschreiben und ich helfe auch ihm bei seinen Problemen.
PRODUCT OWNER, nickt: Ja, er ist zu meinen Kollegen gegangen und hat innerhalb der Abteilung Werbung für Scrum gemacht.
Im Hintergrund öffnet sich die Tür der Bar, zwei Frauen und ein Mann kommen herein. Sie gehen zum Tisch und unterhalten sich dabei sehr angeregt.
MANAGEMENT, zur KUNDIN gewandt: Sie sehen, unsere Organisation ist exzellent aufgestellt, um dieses Projekt zu stemmen. Wir haben viel Mühe und Zeit in die Ausbildung der Mitarbeiter investiert.
KUNDIN: Das stimmt, offensichtlich hat die Veränderung in der Softwareentwicklung in Ihrer Abteilung einiges bewirkt. Wir sind sehr zufrieden. Es ist phänomenal, wie gut die Arbeit mit Ihrem Product Owner funktioniert. Noch nie waren unsere Projekte aus finanzieller Sicht so erfolgreich.
KUNDIN zur ANWENDERIN: Du meinst also wirklich, dass diese Funktionalität deine Arbeit erleichtern wird. Würde dich dann unser Produkt mehr interessieren?
ANWENDERIN: Ja klar. Ich habe mit meinen Freunden darüber gesprochen, dass es da etwas gibt, was wir unbedingt benötigen.
Sie kommen zum Tisch der drei Männer.
KUNDIN: Hallo Jungs, wie geht's?
PRODUCT OWNER: Danke, gut, wie geht es unserer Kundin heute?
KUNDIN: Oh ? prima. Wir haben neue Funktionalitäten identifiziert, die wir in einem nächsten Produkt-Release unbedingt benötigen.
TEAM: Hallo Anwenderin, habt ihr euch das Produkt angesehen? Wie ist euer Feedback, was möchtet ihr anders haben?
ANWENDERIN: Wir haben uns das Produkt angesehen und würden an der einen oder anderen Funktionalität noch ein wenig feilen. Aber wir brauchen auf jeden Fall eine andere Menüführung, um das Arbeiten angenehmer zu gestalten.
DAS TEAM, nickt: Haben wir uns gedacht. Das ist kein Problem, bauen wir noch in dieser Iteration um. Dann wird die Story „Menü“ fertig. Klasse.
SCRUMMASTER, winkt das MANAGEMENT kurz heran: Ich wollte mich vergewissern, dass dieser Abend von Ihnen finanziell unterstützt wird. Wird er doch?
MANAGEMENT: Sicher, keine Sorge.
SCRUMMASTER, an alle gewandt: Na, das sieht ja so aus, als würden wir einen angenehmen Abend zusammen verbringen.
Eine Rolle in einem Prozess ist nicht gleichzusetzen mit der Position in einem Unternehmen oder einer Organisation. Viele beschäftigen am Anfang Fragen wie: Wer sollte in einer Organisation der ScrumMaster sein? Wo finden wir die vielen ScrumMaster, wenn jedes Team einen eigenen benötigt? Wer wird der Product Owner? Welche Leute brauchen wir im Entwicklungsteam?
Stellen Sie sich einen kleinen Sandeimer vor. Statt Sand füllen Sie Verantwortlichkeiten in diesen Eimer. Eine mächtige Schaufel „Schutz“, dann eine weitere Kelle „Impediments wegräumen“ und zu guter Letzt eine ordentliche Portion „Scrum-Prozess“. Diesen nun sehr schweren Eimer nehmen Sie in die Hand, wenn Sie die Rolle des ScrumMasters tragen wollen. Genauso machen Sie es mit allen anderen Rollen. Jeder Mitarbeiter, der eine Rolle im Scrum-Prozess übernehmen soll, nimmt einen Eimer und füllt zuvor die Verantwortlichkeiten der jeweiligen Rolle in den Eimer. Nun trägt jeder im Scrum-Team die Verantwortung für das Gelingen der Produktentwicklung. Diese Verantwortung übernimmt man freiwillig.
Hier liegt der Unterschied zur Position: Positionen kann man übergeben und mit ihnen auch die Macht, die durch die Position verliehen wird. Ob dieser Mensch dann auch die mit der Position verbundene Verantwortung übernimmt, ist eine andere Frage. Das Übernehmen von Verantwortung kann man nicht erzwingen. Gary Hamel schreibt dazu über Bill Gore, der zunächst in der Forschungsabteilung von DuPont arbeitete, bevor er mit seinen Grundsätzen von Fairness und Selbstverpflichtung ein eigenes, erfolgreiches Unternehmen aufbaute (die Technologien von Gore stecken zum Beispiel in wasserabweisender Funktionskleidung):
„During his years at DuPont, Bill Gore developed a keen appreciation for the difference between commitment and compliance. As he often put it, „Authoritarians cannot impose commitments, only commands.“ Gore believed deeply that willing commitment is many times more valuable to an organization than resigned compliance. This belief lies at the heart of another Gore tenet: „All commitments are self-commitments.“ In practice, this means that associates negotiate job assignments and responsibilities with their peers. At Gore, tasks can't be assigned, they can only be accepted.“ [Hamel 2007]
Exakt diese Haltung vertreten Ken Schwaber und Jeff Sutherland mit ihrer Idee des Commitments.
Ver | ant | wor | tung*:
[mit einer bestimmten Aufgabe, einer bestimmten Stellung verbundene] Verpflichtung, dafür zu sorgen, dass (innerhalb eines bestimmten Rahmens) alles einen möglichst guten Verlauf nimmt, das jeweils Notwendige und Richtige getan wird und möglichst kein Schaden entsteht
Verpflichtung, für etwas Geschehenes einzustehen [und sich zu verantworten]
Das Englische hält für diese beiden Bedeutungen von „Verantwortung“ zwei Begriffe bereit: a) kann mit „being responsible“, übersetzt werden, was aber den Hauch der bloßen „Zuständigkeit“ hat. Zuständig kann man auch ohne großartige innere Haltung zu einer Aufgabe sein. Bedeutung b) hingegen lässt sich mit „accountable“...
