Die Bedeutung von "erledigt"

Zu viele Software-Entwicklungsprojekte bieten ihren Kunden zum Lieferdatum Software, die zu viele Fehler enthält, nicht fertig ist oder nachgebessert werden muss. In der Regel ist die Applikation unter hohem Druck entstanden, und alle wissen, dass die Maintenance-Teams den Code verbessern müssen.

Immer wieder wird fast fertige Software geliefert. Die Aussage „Es ist fast fertig“ ist in vielen Organisationen schon Standard. Ich habe einmal ein Projekt betreut, bei dem nach 22 Monaten Arbeit mit 25 Entwicklern der Fachabteilung eine Funktionalität präsentiert wurde, die ständig abstürzte, wenn sie von mehr als einem Anwender benutzt wurde. Dennoch war das Software-Entwicklungsteam der Meinung, es hätte „geliefert“. Andere Entwicklungsteams wiederum halten eine Applikation für fertig, die zwar auf den eigenen Entwicklungsumgebungen funktioniert, sich auch kompilieren lässt und auf den ersten Blick fehlerfrei ist, die aber noch kein Tester gesehen hat.Das zeigt, dass wir in der Software-Entwicklung tatsächlich noch viel ändern müssen. In Scrum ist nur „Usable Software“ am Ende eines Sprints zugelassen. „Usable Software“ bedeutet im Grunde genommen nichts anderes als: So, wie die Software geliefert wird, muss nichts mehr getan werden, damit sie genutzt werden kann. Sie ist getestet, die Funktionalität ist integriert, und es dürfte beim Ausrollen an sich nichts passieren. Wenn Teams diese Regel akzeptieren, ändert sich die Haltung sofort.

Wenn nachgearbeitet werden muss, wurde kein Geschäftswert generiert!

Scrum liefert am Ende eines Sprints einen gewissen Geschäftswert. Das funktioniert aber nur, wenn die Software tatsächlich brauchbar ist. Muss man noch nacharbeiten, wurde noch kein Geschäftswert generiert. Wir haben beim Planen des Projekts darüber gesprochen, wie sich der Geschäftswert über die Zeit zusammensetzt. Das geht nur, wenn man am Ende des Sprints tatsächlich nutzbare Software kreiert hat.Die Qualität der Arbeit liegt in der Verantwortung des Teams. Das Team muss zu jedem Zeitpunkt funktionierende Software geschrieben haben. Das Team muss sich darüber im Klaren sein, dass es im Sprint Planning nur das zusagen sollte, was es tatsächlich auslieferbar erstellen kann.Ein andere Variante, sich diesem Thema zu nähern, ist die Festlegung einer Definition of Done. Sie ist bei richtigem Umgang mit diesem Konstrukt hilfreich für alle Beteiligten, denn auf diese Weise entsteht ein gemeinsames Verständnis, in welchem Zustand das gelieferte Produktinkrement am Ende des Sprints ist. Dieser Zustand und damit die „Definition of Done“ variiert von Scrum-Team zu Scrum-Team.

Das Entwicklungs-Team legt die Definition of Done fest

Daher ist es ratsam, die Definition of Done vom Entwicklungs-Team selbst festlegen zu lassen. Wieder geht es darum, zunächst „Transparenz“ zu erzeugen. Wir wollen den wirklichen Stand der Entwicklungsfertigkeiten des Teams (und damit meist der Organisation) festlegen. Die Elemente der Definition of Done, also was es ausmacht „fertig zu sein“, werden von jedem Team festegelegt. Hier ist oft zu beobachten, dass die Linienmanager der Teams, zum Beispiel die Software-Entwicklungsleiter, festlegen wollen, was in die Definition of Done gehört. Das ist verständlich, da sie mit der Definition of Done ein Mittel in der Hand haben, um den Team zu sagen, was sie liefern sollen. Aber das geht in den meisten Fällen nach hinten los. Die Software-Entwicklungsleiter versuchen - wie so oft in der Vergangenheit - über eine Vorschrift, ihre Mitarbeiter zu etwas zu bewegen. Aber hier wird deutlich, dass genau das nicht funktioniert. Nur indem die Mitarbeiter durch Vorleben oder Training verstehen lernen, was von ihnen verlangt wird, werden sie erkennen, was zu einer Definition of Done gehört und sie werden es selbst durchführen.Ein wunderbares Beispiel dazu findet sich in folgendem Blogeintrag von Ryan Tamyko: "I actually don't show people how to make decisions and ship product in any real direct way. There's no How To Ship Product training class or anything like that. Instead, I just do work. I write down ideas and then market them internally. I ask designers about their comps and concept work. I write code with kick ass docs and tests, sometimes while building out the backend for a feature and sometimes just to clean shit up because it needs it. I deploy responsibly because site stability is job number zero. I soft ship new features and try to get other employees to use them. I write and review blog posts and ship features. I fix bugs. I work with support. That's just how you ship software product in 2012.“ [1]Sicher ist die Firma Github eine Ausnahmefirma und hat einen ganz besonderen Managementstil, allerdings zeigt dieses Beispiel, wie man in einer Firma auch auf andere Weise als durch Anweisung Menschen dazu bringen kann, Dinge anzunehmen.Die vom Team festgelegte Definition of Done mag nicht ideal für die Firma sein, sie reflektiert aber das gerade Mögliche. Auf diese Weise entsteht Transparenz und der ScrumMaster kann mit seinem Team daran arbeiten, den Zustand zu verbessern.[quote author = "Giovanni Trapattoni"]"Ich habe fertig"[/quote][1] http://tomayko.com/writings/management-style

Agile Toolbox
Scrum
Scrum-Begriffe
Team
bgloger-redakteur
September 17, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4