Podcast: Definition of Done verständlich erklärt

Während bald die Sommerferien in allen Bundesländern wieder „done“ sind, haben wir über eine kleinere Peinlichkeit zu Beginn meiner Elternrolle gesprochen – und damit die Definition of Done beleuchtet. #VerständlichErklärt #Scrum #Agile

User Stories verständlich erklärt

 User stories in Oxford - (c) Jacopo Romei CC-BYSobald man Software entwickelt, stellt sich die Frage, wie man eigentlich mit Wünschen und Ideen von Entwicklern, Kunden, Führungskräften, Produktmanagern, also den Stakeholdern umgeht.

Schreibt man alles in ein Word-Dokument mit sauberer Gliederung? Nutzt man Skizzen oder Prozessmodellierungswerkzeuge? Machen wir ein Grobkonzept, dann ein Feinkonzept, stimmen es mit dem Kunden ab und fangen dann an zu arbeiten? Oder doch eine Excel-Tabelle oder einen Projektplan mit Tätigkeiten?

Eine beliebte Variante zur Arbeit mit Anforderungen in agilen Projekten nennt sich „User Story“: Eine User Story sind wenige Sätze natürlicher Sprache, um als Gedankenstütze für eine Anforderung zu dienen.

Ein Beispiel für eine User Story:

Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.

Könnte das Team diese Anforderung umsetzen? Vermutlich nicht. Die beschriebene Anforderung ist  recht vage, nur grob umrissen. Eine Idee, die es zu durchleuchten gilt. Das Grundprinzip dahinter: Ein guter und kontinuierlicher Dialog der Beteiligten ist wichtiger als eine detaillierte, niedergeschriebene, im Voraus für das Projekt völlig durchdrungene Spezifikation.

Man kann sich so eine User Story wie ein „Aufhänger für eine Funktionalität“ vorstellen. Die Funktionalität wird sichtbar, anfassbar, begreifbarer. Aber eben nicht vollständig definiert.  Das verhindert allein schon die Unschärfe von Sprache und auch die Komplexität von Softwareentwicklung. Besser wir investieren hier nicht allzuviel Zeit.

Doch mit so großer Unschärfe kann auch das beste Team der Welt nicht wirklich effizient arbeiten. Die User Story enthält zwar wer was warum möchte – aber nicht was genau und schon gar nicht wie genau.

Vom Groben ins Feine.

Wann wird solch eine Idee namens User Story nun also konkreter? Kurz bevor wir die umschriebene Anforderung der User Story umsetzen möchten, sollte sie klein und konkret sein. Um dahin zu gelangen, machen agile Teams häufig so genannte Backlog Refinement Besprechungen. In diesen Besprechungen geht es darum, das Verständnis zu vertiefen und gemeinsam mit dem Product Owner, große User Stories in kleinere zu zerlegen.

 Prioritizing user stories - (c) Jacopo Romei CC-BY - https://www.flickr.com/photos/jakuza/3578548023Spätestens wenn ich eine User Story in eine Iteration reinnehmen möchte, sollte sie also gut verstanden sein, vielleicht auch schon kurz davor. Das bedeutet, dass das Entwicklungsteam weiß, was das Ziel der Umsetzung ist und woran es erkennen kann, dass es dieses Ziel erreicht hat. Häufig sind dann auch weitere Wissensquellen als Anlagen zu einer User Story vorhanden: Vielleicht ein UI-Entwurf, vielleicht eine Spezifikation eines Gesetzgebers, vielleicht Formeln in einer Excel-Tabelle. Hier ist erlaubt, was dem Team hilft – ohne es von Beginn an in seiner Kreativität und Lösungsfindung einzuschränken.

Ich bin fertig und mache dann mal Feierabend für heute.

Woher weiß ein Team nun, ob es das Ziel einer User Story erreicht hat? Wann ist die Funktionalität fertig? Das klärt das agile Team im Dialog mit seinem Product Owner. User Stories werden während dieses Dialogs häufig durch schriftliche Akzeptanzkriterien ergänzt. Das sind stichpunktartige Kriterien, die erfüllt sein sollten, damit der Product Owner eine User Story als fertig akzeptiert. Eine Art Checkliste oder für diese eine User Story geltende Ergänzung der Definition of Done.

Ein Beispiel:

Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.

Akzeptanzkriterien:
– Die Liste zeigt alle noch nicht verkauften Fahrzeuge an
– Die Liste ist nach Kaufpreis sortiert
– Wenn keine Fahrzeuge vorhanden sind, erscheint ein Hinweistext

(c) CC-BY https://www.flickr.com/photos/psd/8591351239Die User Story bleibt dabei auf der Ebene der Benutzerperspektive: Sie sollte also von allen Menschen mit Domänenhintergrund verstanden werden können – und deswegen auch nicht technisch sein. Gedanklicher Kniff: Stellen Sie sich vor, ein Kunde ohne technischen Hintergrund sollte sie verstehen können. Eine Kommunikationsbrücke zwischen Entwickler und Fachperson also.

Ein bisschen mehr Technik bitte.

Wann wird es nun endlich technisch? Wo entsteht die Lösungsidee? Welche Architektur braucht es und welche Anpassungen im Code? Alle konkreten, technischen Tätigkeiten wird ein agiles Team in der Sprintplanung oder in einer Iteration selber identifizieren und als so genannte „Tasks“, also kleine Schritte zur Implementierung solch einer Anforderung, an eine User Story hängen. Das ist elegant, denn so sind fachliches Problem und technische Lösung bis zur Sprintplanung getrennt. Wir verwenden so nämlich keine Zeit auf technische Überlegungen, die vielleicht doch nie umgesetzt werden, weil sich die Marktanforderungen ändern und damit die Prioritäten unseres Backlogs.

Nun: Wie sähe wohl Ihr aktuelles oder nächstes Projekt mit dem Konzept von User Stories aus? Was wäre anders? Was schwieriger, was leichter? Viel Erfolg beim Ausprobieren.

Enterprise Transition Community (ETC) verständlich erklärt

Der Weg hin zu einer agilen Organisation ist mit vielen Hürden und Problemen gespickt. Anforderungen, Ziele und Rahmenbedingungen ändern sich innerhalb von wenigen Tagen und Wochen.

Um so mehr Teams mit agilen Vorgehensweisen arbeiten, umso mehr Hindernisse auf Organisationsebene werden deutlich. Themen, die die Teams davon abhalten, effizient Software zu entwickeln und voranzukommen. Ungelöste Zuständigkeiten, unklare Rollenbilder und Karrierepfade, zu lange dauernde Entscheidungsprozesse, inkonsequentes oder nicht vorhandenes Portfolio- oder Programmmanagement.

Doch wie begegnet man dieser Komplexität, den Risiken und der Vielfalt der Stakeholder einer Agilen Transition?

Auch Software-Entwicklungsteams sind ständig mit veränderlichen Anforderungen und technisch sowie fachlicher Komplexität konfrontiert. Was für diese Teams funktioniert, ist auch bei einer Unternehmenstransition das Mittel der Wahl: Scrum. Durch seine mehrfachen eingebauten Feedback-Schleifen versteht es das Scrum-Rahmenwerk, die Komplexität zu adressieren. Eine Enterprise Transition Community kann so auf die häufig erst bei der Umsetzung auftretenden Hindernisse und Ideen eingehen und in kurzen Zyklen lernen, was funktioniert und was nicht.

Eine Gemeinschaft als Taktgeber für die Veränderung

Die Veränderung hin zu Agilem Vorgehen benötigt Menschen aus den unterschiedlichsten Bereichen eines Unternehmens.

Eine Enterprise Transition Community (kurz: ETC) ist ein Scrum-Team, dass die Transition hin zu agilem Vorgehen in einem Unternehmen durchführt.

Dieses Team arbeitet nach Scrum, produziert aber keine Software. Es liefert Organisationsveränderung in kleinen Schritten je Sprint. Es wurde von einem der beiden Begründer von Scrum, Ken Schwaber, im Jahr 2007 bekannt gemacht (siehe The Enterprise and Scrum) und seitdem in verschiedenen Variationen neu veröffentlicht und in etlichen Unternehmen praktisch eingesetzt (siehe z.B. BMC, EWE oder Amazon).

Enterprise Transition Community

In dem hier dargestellten Prozess kommen auch die bekannten Artefakte und Rollen von Scrum zum Einsatz:

Product Owner – der Fokusgeber

Der Product Owner einer ETC trägt die Verantwortung dafür, dass das Team fokussiert an den Veränderungen mit dem höchsten Wert für das Unternehmen arbeitet. Er verwendet dazu ein Transition Backlog, welches die zu lösenden Organisationsthemen beinhaltet. In regelmäßigen Backlog Refinements werden die teils großen Organisationsveränderungsthemen (Epics) in Sprint-gerechte User Stories zerlegt.

Teammitglieder – Umsetzer und Gestalter

Die Teammitglieder sind Personen des Unternehmens, die ein Interesse an der Veränderung hin zu Agilität haben und sich einbringen möchten mit ihrer Zeit. Die Teammitglieder haben die Umsetzungsverantwortungen der organisatorischen Veränderungen. Sie sollten aus den Bereichen stammen, die maßgeblich von den Veränderungen betroffen sind und diese auch maßgeblich beeinflussen können. Am besten sie gehen die Themen selbst in der Umsetzung an. Falls es aber notwendig sein sollte, sollten sie dazu die Arbeit maximal eine Ebene delegieren, behalten aber die Verantwortung

ScrumMaster – Servant Leader und Facilitator

Der ScrumMaster einer ETC moderiert die Besprechungen, sorgt für das Prozessverständnis von Scrum und arbeitet an Lösungen von Hindernissen, die die ETC davon abhalten, hochproduktiv zu sein. Manchmal unterstützt er in Agilität unerfahrenere Teammitglieder bei der Vertiefung des Verständnisses und der Findung „agiler Lösungen“ für Organisationsthemen. Er dient dem Team und führt Kraft Anerkennung.

Die Organisation teilhaben lassen

Die Stakeholder einer Enterprise Transition Community sind oft breit gestreut im Unternehmen. Jeder betroffene Mitarbeiter und jede betroffene Führungskraft hat ein Interesse an den Ergebnissen dieses Teams. Nach einer anfänglichen Findungsphase der ETC sind sie gerne gesehene Feedbackgeber für „ETC Entwicklungsteam“ und ETC Product Owner im Review-Meeting.

Wer mehr zu dem Thema lesen möchte, empfehle ich die Szenen einer Scrum Transition (englisch), welche auch meine Abbildung inspiriert haben.

Welche Fähigkeiten braucht ein Product Owner in Scrum?

Der Product Owner ist eine der drei Rollen in Scrum. Er verantwortet den Produkterfolg. Doch welche Fähigkeiten helfen dabei, diesen zu erreichen?

Überzeugungskraft

POSpeaking

Immer weniger Menschen möchten heutzutage an fraglichen, vielleicht gar sinnlosen Projekten arbeiten. Software entwickeln als Lohn-und-Brot Job? Egal, ob das Produkt jemand später einsetzt? Das Entwicklungsteam muss an die Vision des Product Owners glauben, um motiviert zu sein.

Dazu braucht es einen überzeugenden Product Owner. Und nicht nur das Team will glauben können, auch die Kunden und Anwender des Scrum-Teams. Beide muss der Product Owner davon überzeugen, dass er die richtigen Entscheidungen trifft zum Wohl des Produkterfolgs.

Was Sie als Product Owner zur Stärkung tun können:

  • ein Produkt suchen, hinter dem Sie wirklich stehen
  • ein Rhetoriktraining besuchen, um Ihre Botschaft zu verstärken
  • Visual Facilitation erlerne, also mit Bildern und Metaphern kommunizieren
  • die Zukunft des Produkts mit guten Geschichten lebhaft ausmalen

Fachwissen über die Domäne und Durchsetzungsfähigkeit

PuzzleDer Product Owner trifft nahezu täglich Produktentscheidungen: In welcher Reihenfolge werden die Anforderungen umgesetzt, welche kommen hinzu, welche werden gestrichen? Und in welcher Ausprägung wird eine Anforderung realisiert? Diese Entscheidungen benötigen ein Fachwissen in der Domäne des Produkts und die Fähigkeit, die Entscheidungen dann auch durchsetzen zu wollen.

Was Sie als Product Owner zur Stärkung tun können:

  • Fachzeitschriften und Bücher zur Domäne lesen
  • Fachkonferenzen besuchen und Kollegen interviewen
  • Sich öfter in einem klarem „Ja“ und „Nein“ üben, auch wenn es unbequem sein sollte

Empathie für den Kunden und Anwender

FeedbackUm die richtigen Entscheidungen zu treffen, braucht es aber nicht nur Fachwissen sondern auch ein gutes Gespür für den Kunden, die Anwender und den Markt.

Gerade technischen Product Ownern fällt es oft schwer, die Nutzerbrille aufzusetzen. Was will der Anwender wirklich? Was sind seine Bedürfnisse? Warum möchte er etwas?

Was Sie als Product Owner zur Stärkung tun können:

  • In User Stories den WARUM-Teil des Satzes vom Anwender erläutern lassen
  • Ein Werkzeug wie das Vision Board verwenden, um den Anwender besser zu verstehen
  • Den (potenziellen) Anwender bei seiner täglichen Arbeit beobachten
  • Beim Formulieren von Anforderungen auf technisches Jargon verzichten

Teamfähigkeit

TeamDer Product Owner ist Teil des Scrum Teams. Und der Erfolg dieses Teams steht und fällt mit dem Zusammenspiel aller Teammitglieder. Wie gut findet man gemeinsame Lösungen für Konflikte und Probleme statt sich hinter seiner Rollenbeschreibung und Verantwortlichkeiten zu verschanzen?

Was Sie als Product Owner zur Stärkung tun können:

  • Lassen Sie sich von Ihrem Entwicklungsteam bei der Erfüllung Ihrer Rolle helfen. Auch Teammitglieder können User Stories schreiben
  • Fragen Sie Ihr Entwicklungsteam, ob Sie an der Retrospektive teilnehmen dürfen
  • Betrachten Sie sich und das Team als „alle im selben Boot“ und suchen Sie aus dieser Haltung Lösungen

Diese Beitrag wurde inspiriert durch Fragen der Teilnehmer meines gemeinsamen CSPO-Trainings mit Peter Beck.

Scrum Sprints verständlich erklärt – Warum Iterationen Sinn ergeben

WarumSprintsBadgeManche Teams fragen mich, warum es in Scrum eigentlich Sprints gibt und ob solch eine künstliche Einteilung in Wochenrhythmen überhaupt mit der Arbeit eines Teams vereinbar ist?

Prinzipiell ist ein Sprint ein gleich langer sich regelmäßig wiederholender Zeitabschnitt eines Scrum Teams, um Feedback zu ritualisieren.

Schauen wir uns an, was dieses ritualisierte Feedback in einem Softwareprojekt bringt:

Von der „Black Box Entwicklungsabteilung“ zum Vertrauensverhältnis durch Kundennähe

Die Sprintplanung gibt dem Product Owner und damit auch dem Kunden eine Vorschau, was das Team in der kommenden Iteration schaffen möchte. Zum Sprintende folgt dann das Review-Meeting, in dem Stakeholder wie Kunde, Anwender, Management und Team zusammenkommen.

Durch die dort entstehende regelmäßige Transparenz über Liefergegenstände und Gespräche von Angesicht zu Angesicht wird Fortschritt erlebbar und Hintergründe von Entscheidungen oder Verzögerungen verständlich. Es entsteht eine Diskussions- und Vertrauensbasis zwischen Kunde und Team.

Weniger unfertige Arbeit

Ein Team, dass früher Feedback vom Kunden erhält, weiß schneller, ob eine Funktion so gelungen ist, dass Sie das Bedürfnis des Kunden tatsächlich deckt. Damit werden Features schneller „als fertig“ abgehakt und weniger unfertige Arbeit ist gebunden, die im Kopf der Teammitglieder den Fokus und das Gefühl von Fortschritt verhindert. Wer mag schon haufenweise unerledigte Dinge in seinem Hinterkopf?

Kostengünstigere Fehlerbehebung

Wer Software entwickelt, produziert auch Fehler. Das ist normal und Teil des Handwerks. Gerade deshalb sollten wir mit diesem Wissen unser Möglichstes tun, um sie dann so günstig wie möglich zu finden und zu korrigieren. Günstig bedeutet in diesem Fall, das ein Fehler um so weniger Geld kostet, um so schneller wir ihn finden. Am besten noch vor der Produktivsetzung. Hierfür haben wir viele Mittel in der Softwareentwicklung wie z.B. Automatische Tests, Code Reviews oder auch Pair Programming. Ein Sprint ist eine Qualitätsschranke, die uns ritualisierte Qualitätskontrollen ermöglicht, in einem Rahmen der so zeitnah ist, dass ich als Entwickler tatsächlich noch wissen kann, in welchem Kontext der Fehler steckt. Besser jetzt gleich nochmal an den Quelltext als in zwei Monaten, oder?

Wissen, wann welches Feature kommt

Softwareentwicklung findet immer für Menschen statt, die Erwartungen an unsere Produkte und Lösungen haben. Ein Teil dieser Erwartungen ist zeitlicher Natur: Wann kann eine Software dies oder jenes? Wann wird mein Kundenfeedback umgesetzt? Wie lange muss ich mit einem Fehler noch leben?

Auf diese Fragen braucht ein Product Owner zuverlässige Antworten, um glaubwürdig zu sein. Sprints ermöglichen es einem Scrum-Team, Daten über die bisherige Produktionsleistung zu ermitteln und diese in die Zukunft fortzuschreiben. So wird eine Roadmap zur Basis des Erwartungsmanagements. Versetzen wir uns mal in die Sicht des Kunden: Wieviel Transparenz würden Sie als Kunde über den Fertigstellungszeitpunk Ihres Features gerne haben?

Niedrigerer Koordinationsaufwand

Und zu guter Letzt spart ein Sprint auch noch Koordinationsaufwand durch regelmäßig festgelegte Termine für alle Beteiligten und somit planbare Räumlichkeiten, Teilnehmer und Ergebniserwartungen.

Vereinbarkeit von Sprints und Arbeitsinhalten

Doch wie teile ich nun meine Arbeit so auf, dass ich sie in Sprints umsetzen kann? In der Essenz geht es darum, Features richtig zu zerteilen und somit kleinere, abgeschloßene Einheiten zu produzieren.

Poster: Warum gibt es in Scrum Sprints?

Ein Bild sagt mehr als tausend Worte

Eine graphische Übersicht dieser Aspekte finden Sie auch auf meinem Teamraum – Poster (PDF; 8 MB).

Sie können es zum Beispiel auf Postergröße ausgedruckt im Teamraum aufhängen, um mit Ihren Kollegen darüber zu sprechen, warum wir in Scrum iterativ arbeiten und was Team und Unternehmen davon haben.

Oder ergänzen Sie es doch noch in einer Retrospektive mit dem Team um neue Aspekte mit Haftnotizzetteln, weshalb Sprints einfach Sinn ergeben?

Scrum skalieren – Communities of Practice (CoP) verständlich erklärt

Communities of Practice in ScrumStellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?

Softwareentwickler arbeiten nun in kleinen Teams von 5 – 9 Personen. ScrumMaster und Agile Coaches investieren viel Energie, diese Teams zu stärken und zu schützen. Im Laufe der Zeit entwickelt dabei jedes Team seinen eigene Definition davon, wie gute Softwareentwicklung aussieht und funktioniert.

Doch was ist mit Querschnittsthemen?

Wie koordiniert man gemeinsame Auslierferungen, an denen mehrere Teams arbeiten? Wie lernen wir teamübergreifend neue Softwareentwicklungspraktiken? Wie entwickeln wir Entwicklungsrichtlinien, die für alle Teams passen? Wo kommen Tester zusammen, um herauszufinden, was gute Qualität für sie bedeutet?

Wenn wir agil mit mehreren Teams arbeiten möchten, brauchen wir teamübergreifend einen Weg, solch einen Austausch zu gestalten. Eine Art von loser Interessensgemeinschaft aus Praktikern. Menschen, die freiwillig und aus Leidenschaft zusammenkommen – vielleicht wie wir Deutschen das so gerne in Vereinen tun (nur weniger bürokratisch)?

Vor über 20 Jahren beschäftigten sich die Sozialforscher Jean Lave und Étienne Wenger mit der Bedeutung von sozialen Konstrukten in Lernprozessen. Und sie formten den Begriff der „Communities of Practice“ – kurz: CoP.

Definition einer CoPEine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.

Eine Teilnahme an solch einer Community ist immer freiwillig – und unabhängig vom bisherigen Wissensstand. Anfänger, Fortgeschrittene und Experten treffen sich regelmäßig, um gemeinsam zu lernen.

Wie beginnt man nun so eine Community of Practice?

Das ist leicht! Derjenige, der für ein Thema eine große Leidenschaft besitzt, sucht nach Gleichgesinnten im Unternehmen. Man legt gemeinsam erste Ziele fest und lädt alle interessierten Kollegen zu einem großen Willkommens-Termin ein. Dort informiert man dann über das Vorhaben und bittet die Teilnehmer, um Feedback, ob sie in Zukunft auch mit an Bord sind. Ein erfahrener ScrumMaster als Experte für Teamprozesse kann von Anfang an schon als Facilitator den Weg der CoP begleiten.

Wie sähe Ihre Firma mit solchen Lerngemeinschaften aus? Was wäre dann anders? Wer würde zu welchen Themen wohl im Austausch sein? Wenn Sie Lust bekommen haben, selbst eine Community of Practice zu Gründen oder Kollegen dabei zu helfen, mit ihrer Initiative erfolgreich zu sein, empfehle ich Ihnen dieses Buch. Und danach viel Spaß bei der Umsetzung! Denn gemeinsames Lernen macht uns doch oft am meisten Spaß, oder?

Manchmal ist Scrum wertlos.

(c) Jared Tarbell, CC-BY-2.0

Viele Unternehmen beschäftigen sich mittlerweile mit Scrum. Neben durchaus erfolgreichen Transformationen von Teams und Abteilungen gibt es auch die Veränderungsinitativen, die auf ihrem Weg zu agilem Arbeiten stecken bleiben:

Mißverstandene Praktiken, fehlende Management-Unterstützung und fragwürdige Rollenverständnisse zeigen sich.

Doch was fehlt diesen Versuchen, Scrum zu etablieren eigentlich? Warum passen die Praktiken nicht oder fühlen sich inkongruent im Unternehmen an?

Bei der Suche nach der Antwort finden wir im ersten Buch von Ken Schwaber und Mike Beedle fünf Kernwerte von Scrum:

Mut, Offenheit, Respekt, Fokus, Commitment

Schauen wir uns die Scrum-Werte einmal etwas genauer an:

Mut ist die Fähigkeit, Herausforderungen trotz Risiken aktiv anzugehen, um Sie erfolgreich zu überwinden. Veränderungen benötigen diesen Mut: Unbekanntes und Neues will gelernt und gemeistert werden. Rollen verändern sich und der Status quo wird in Frage gestellt.

Offenheit ist das bereitwillige Aufnehmen und Teilen von Informationen, um Situationen einschätzen und richtig entscheiden zu können. Nur durch Offenheit entsteht die Transparenz, gute Entscheidungen zu treffen und gegenseitiges Verständnis für die Situation zu entwickeln.

Respekt ist Wertschätzung für Beitrag und Person aller Beteiligten, um konstruktiv zusammenzuarbeiten. Unterschiedliche Lebenswege, Meinungen und Perspektiven verdienen Anerkennung und wollen für Kreativität und Synergien genutzt werden.

Fokus ist die bewußte Einschränkung von Optionen, um gemeinsam effektiv voran zu kommen. Weniger ist mehr. Die Essenz umzusetzen in bester Qualität macht Kunden zufrieden und lässt uns Risiken steuern.

Commitment ist die Selbstverpflichtung zur Erledigung einer Aufgabe oder Mission, um Verlässlichkeit und Motivation zu erhöhen. Im Scrum Team genießen Angestellte eine hohe Freiheit und Selbstbestimmung. Damit wächst ihre Verantwortung für den Erfolg.

Die Einführung von Scrum bringt die Abteilung dazu, diese fünf Werte in ihrer Arbeitskultur zu schätzen: Scrum ist sozusagen ein Kulturwandler, ein Veränderungsagent im System, ein Katalysator für eine neue Form der Zusammenarbeit.

Die wichtigste Frage ist also, wieweit diese Zielkultur erwünscht ist und wie sie zu den weiteren Kulturelementen passen kann.

Einige Beispiele:

  • Wenn Harmonie (und somit Konfliktvermeidung) ein hoher Wert in der bestehenden Kultur ist, wie wird dann Mut wahrgenommen? Als Aggressor?
  • Wenn Erfolg der wichtigste Wert ist, darf Offenheit in der Kommunikation über Fehlschläge existieren?
  • Wenn Arbeit zugeteilt wird und top-down Deadlines ausgerufen werden, wie stark ist die gefühlte Selbstverpflichtung (also das Commitment) des Einzelnen?

Cargo Cult Scrum - (c) tattooblogger, CC-BY-2.0Schafft man es nicht, auf Grund der bestehenden Kultur die Werte von Scrum zu erlernen, sind diese Scrum-Implementierungen wert-los. Dem Vorgehen fehlt die Seele, die Praktiken wirken blutleer. Manche nennen dies einen Cargo-Cult: Ohne in der Tiefe zu verstehen, worum es geht, werden Praktiken falsch eingesetzt – und die erhoffte Veränderung bleibt aus.  Scrum löst sein Versprechen der besseren Arbeitswelt dann nicht ein – was zu verständlicher Frustration und Ablehnung der Methode führt.

Vor einer Scrum-Einführung lohnt es sich also, zu prüfen, ob die Zielkultur lohnenswert und erwünscht ist. Im Zweifelsfall erleben Sie in einem Scrum-Training oder während eines Pilotprojekts, wie sich Agilität anfühlt und welche Reibungspunkte es gibt.

Was ist Ihre Wunscharbeitskultur?

Definition of Done verständlich erklärt

(c) Bernard Goldbach - Creative Commons

Vor Kurzem hielt ich in einem Workshop ein Smartphone in die Luft und fragte einige Menschen, ob das ein gutes Telefon sei. Viele fanden es gut, manche okay und einer mochte es absolut nicht. Bei der Nachfrage nach Gründen stellten wir schnell fest, dass verschiedene Menschen verschiedene Qualitätsmerkmale betrachten und wichtig finden.

Das ist auch in einem Softwareentwicklungsteam nicht anders – bei der Frage, ob ein Stück entwickelte Software fertig ist, gibt es oft Uneinigkeit und Diskussionen. Woher weiß ich, dass ich fertig bin mit der Entwicklung? Was kann ich von meinen Kollegen erwarten, wenn sie ein Feature umsetzen? Was erwartet mein Product Owner?

Um diese Fragen in einem agilen Team zu beantworten und Klarheit zu schaffen, gibt es in der agilen Welt ein Artefakt mit dem Namen „Definition of Done“. Im Prinzip ist es soetwas ähnliches wie eine sehr spezifische Arbeitsvereinbarung oder selbst auferlegte Regeln, wie man Entwicklungsqualität definiert.

Eine Definition of Done (kurz: DOD) ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird.

Man kann sich das als eine Art Kriterienkatalog oder Checkliste vorstellen, die man bei jedem Feature (sprich: User Story) durchgeht und auf Erfüllung überprüft:

  • Habe ich Unit Tests entwickelt?
  • Wurde die Dokumentation erweitert?
  • Sind die Codekonventionen eingehalten?
  • usw.

Definition of Done (DOD)In einem Workshoptermin, den der Agile Coach bzw. ScrumMaster moderiert, wird diese Selbstverpflichtung des Teams als Einigung gemeinsam erarbeitet. In Zukunft ist sie die Basis für Klarheit bei der Frage, ob ein Feature fertig ist und hängt deswegen im Idealfall im Teamraum. Die Verantwortung für die Inhalte und auch die Einhaltung der Vereinbarung liegt ausschließlich beim Team. Ein wachsamer Agile Coach erinnert aber an die festgelegten Elemente zur passenden Gelegenheit.

Übrigens darf man im Laufe des Wachstums eines agilen Teams durchaus erwarten, dass die Definition of Done reift, somit mehr und umfangreichere Qualitätskriterien enthalten sind. Vielleicht ist es damit die erste Checkliste, die organisch wächst.

Qualitätssicherung in agilen Methoden

Scrum sagt, produziere potenziell auslieferbare Software in jedem Sprint, Kanban hat als Prinzip „Fokussiere Dich auf hohe Qualität„.

Leicht erkennbar ist, dass agile Methoden Anforderungen an die zu produzierende Qualität einer Software treffen. Was bedeutet dies nun in der konkreten Anwendung im Unternehmen?

In der perfekten agilen Welt liefern wir einen kontinuierlichen Fluss von Funktionalitäten aus: Auf der Ebene einer jeden Story ist diese getestet auf ihre Qualität und im Kontext des Gesamtsystems validiert, im Extremfall nicht nur auf den Test- sondern auch auf den Produktivserver verteilt.

Um soetwas tun zu können, müssen wir in der Lage sein, mit geringem Aufwand zu prüfen, ob eine User Story funktioniert und die Erstellung der Story eine Auswirkung auf einen anderen Teil des Systems hatte. Schließlich wollen wir ja keine neuen Defekte hinzufügen, weil neue Funktionen hinzukommen. Mittlerweile gibt es ja eine ganze Hand voll Best Practices in diesem Bereich. Specification By Example, TDD, Integrations- und Unittests oder Konfigurationsmanagementtools sind einige von Ihnen.

Schaffen wir es, den Automatisationsgrad von Tests und Deployment so weit zu bringen, dass es im Sprint möglich ist, die Qualität zu sichern, die wir gerne hätten, haben wir Feedback dann zur Hand, wenn es am wichtigsten ist: Kurz nach der Produktion, wenn Entwickler noch wissen, wo der Defekt zu finden ist oder wie das Feature leicht zu modifizieren ist, damit es das tut, was der Kunde wirklich will. Denn wir wollen Fehler beheben, statt sie zu verwalten.

Abhängig von den Fähigkeiten im Team, den bisher verwendeten Tools, der Testbarkeit des Codes und der eigenen Disziplin ist die Erreichbarkeit solch einer Qualitätskontrolle für das eine Unternehmen eine überschaubare Strecke, für das andere ein Ultramarathon, der schnell als unmöglich schaffbar bezeichnet wird.

Ein befreundeter Agile Coach, der aus Leidenschaft extrem lange Strecken läuft, hat mir einmal erzählt, wie man eine 116km-Strecke angeht:

Viel Training, die Vorstellung des nächsten kleinen Abschnitts statt der ganzen Riesenstrecke im Kopf und: man sollte Lust darauf haben.

Wenn ihr Team sich gerne die Finger schmutzig macht, versuchen Sie es mit kleinen kontinuierlichen Schritten: Erweitern Sie die Definition of Done regelmäßig in der Form, dass mehr Aspekte auf Story- und Sprintebene fertiggestellt werden und weniger je Release. Das wird vielleicht zeitweilig anstrengend sein, aber Schritt für Schritt gelingt so auch der lange Lauf – wenn man darauf Lust hat.

Selbstorganisation ist ein (wichtiger) alter Hut

Menschliche Systeme wie z.B. Softwareentwicklungsteams organisieren sich selbst ohne jegliches zutun – schon immer. Dieses Selbstorganisation genannte Phänomen ist das natürliche Verhalten aller komplexer Systeme. Die spannende Frage ist dabei jedoch, ob das zu Tage tretende Verhalten gewünscht oder unerwünscht ist.

Viele Jahre lang haben Führungsrkräfte versucht, das Verhalten durch möglichst detaillierte Vorgaben, Anweisungen und Regeln zu beeinflussen – ein Vorgehen, dass den Anleihen des Taylorismus geschuldet zu sein scheint. Das funktionierte mal mit mehr, mal mit weniger Erfolg.

Ein Trick in der Interaktion mit komplexen Systemen ist: Entscheidungen und Verantwortung werden dorthin gegeben, wo die Informationen präziser und kleiner sind. In der Regel ist das eine Delegation weiter „nach unten“. So werden die Entscheidungen besser und auch eher mitgetragen. Rahmenbedingungen helfen dabei, wichtige Entscheidungsaspekte zu berücksichtigen.

Komplexe Systeme haben emergente Eigenschaften: Das Verhalten des Systems kann nicht alleine durch das Verhalten der einzelnen Teile des Systems bestimmt werden. Ein Team ist mehr als die Summe seiner Mitglieder.

Als Konsequenz daraus verwendet man in agilen Vorgehensweisen die Intelligenz der Gruppe an allen wichtigen Stellen: Planung, Schätzungen, Reviews, Retrospektiven. Keine dieser Tätigkeiten kann von einer Person alleine in hoher Qualität geleistet werden, denn dafür sind zu wenige Informationen in der gedanklichen Abbildung jedes Einzelnen. Wer einmal bei einer Planning Poker Sitzung dabei war, kann dies dort leicht erkennen: Abweichende Schätzwerte sind immer in einem unterschiedlichen Wissenstand begründet. Hier wird aus den Einzelinformationen ein Gruppenmodell, dass die Komplexität einer Anforderung besser wiederspiegelt.

Aus dem selben Grund delegiert man – wie oben geschrieben – also auch möglichst viel Kontrolle an die Teams selbst: Sie haben das vollständigste Model zur Verfügung, um ihr eigenes System zu steuern. So steigt die Stabilität des Gesamtsystems Abteilung und Organisation.

COVID-19 AktionMoment noch, spare 150,- €* bei Newsletter-Anmeldung

Wir unterstützen Dich + Deine Firma mit unseren Scrum-Zertifizierungskursen, um erfolgreich auf Veränderungen zu reagieren.

Melde Dich jetzt für den Agile Growth® Newsletter an + erhalte sofort Deinen Rabattcode über 150,- Euro für Deine nächste Online- oder Präsenz-Seminarbuchung. 

* gültig bei Seminar-Teilnahme im Jahr 2021, kombinierbar mit Frühbucher-Rabatt für Präsenz- und Online-Seminare.