Prime Directive

In der Retrospektive und anderen Aktivitäten im Scrum-Geschehen kann es schnell zu Situationen kommen, in denen auf Einzelne gezeigt wird. Dann stehen Schuldzuweisungen im Raum, die erst ausgeräumt werden müssen. Das ist der Moment, in dem der Scrum-Master auf die Prime Directive hinweisen (und am besten vor der nächsten Retro in Erinnerung rufen) wird:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“

(aus: Norm Kerth)

Auf deutsch, kurz gefasst:
Jedes Team-Mitglied hat nach seinem besten Wissen und Gewissen gehandelt.

Oder, näher am Original:
Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen,  den Ressourcen und unseren individuellen Fähigkeiten getan hat.

Komfort-Zone

Anschnallen und zurücklehnen? Nur in der Komfort-Zone! So wird der Bereich gemeint, in dem man sich als Mitarbeiter in seiner „täglichen Routine“ befindet und in dem gemächlichen Tempo arbeitet, von dem man weiß, dass man am Ende des Tages den Großteil der Aufgaben geschafft hat – aber nicht alle, denn morgen ist ja auch noch ein Tag.

Scrum setzt auf die stetige Verbesserungen des Teams. Dafür ist es notwendig, die Komfortzone zu verlassen, über den Tellerrand hinauszublicken, von alten Gewohnheiten das Bewährte beizubehalten und aufgeschlossen Neues aufzugreifen („Inspect and Adapt“).
Das Verlassen der Komfortzone ist in gewisser Weise mit dem Überwinden des inneren Schweinehundes vergleichbar: Man schafft nur Neues, kann sich nur verbessern, indem man sich ständig überwindet!

Retrospektive

Ist ein Sprint durchlaufen, schließt sich daran die Retrospektive an – der Rückblick des Teams auf den Sprint.
In der Retrospektive benennt jedes Team-Mitglied Punkte, die es als besonders gut und die es als verbesserungswürdig einstuft.

Eine der grundlegenden und wichtigen Gedanken von Scrum manifestiert sich in der stetigen Verbesserung.
Das Inspect and Adapt-Prinzip besagt, aus Fehlern zu lernen und positive Erkentnisse beizubehalten.
Mit der Retrospektive wird diesem Prinzip Rechnung getragen, denn erst mit der Erkenntnis, welche Probleme („verbesserungswürdigen Punkte“) es gibt, kann der Weg für Verbesserungen geebnet werden.
Gleichzeitig sollen funktionierende Prozesse in Fleisch und Blut des Teams übergehen, damit sie nicht verlernt werden.

Die Retrospektive ist somit ein mächtiges Werkzeug des Change- und Wissensmanagements.

Technische Schulden (technical debts)

Als technische Schulden werden Qualitätsmängel in der Produktentwicklung bezeichnet, die während eines Projekts in Kauf genommen werden. Technische Schulden entstehen z.B., wenn auf Tests verzichtet oder deren Umfang vernachlässigt wird oder Teile der Definition of Done nicht eingehalten werden.
Der Begriff „Schulden“ kennzeichnet dabei denselben Umstand, den man aus dem Finanzwesen kennt:
Wer sich Geld leiht, muss dieses zuzüglich Zinsen zurückzahlen. Es gibt allerdings einen gravierenden Unterschied zur aktuellen Zins-Situation auf dem Finanzmarkt:

Tilgen von technischen Schulden

Bei technische Schulden in der Software-Entwicklung sagt man, dass zum Tilgen von 1€ Schulden 4€ aufgewendet werden müssen.
Man sollte sich also tunlichst überlegen, ob man bereit ist, technische Schulden zu machen, es sei denn es geht um einen Wegwerf-Prototypen.

Warum werden trotzdem technische Schulden gemacht?

Ursachen technischer Schulden

Ursächlich ist zumeist weniger mangelndes Qualitätsbewusstsein im Team als folgende häufige Gründe:

  • Unrealistische zeitliche Zielsetzungen bzw. das Vorziehen von „Deadlines“, ohne dass der Funktionsumfang verringert wird. Das Team versucht dann, denselben Funktionsumfang in weniger Zeit zu realisieren. Dies geht nur auf Kosten der Qualität
  • Im Team herrscht Stress, der wiederum durch unterschiedliche Ursachen hervorgerufen werden kann:
    • Überstunden,
    • Zeitmangel,
    • Umstellung infolge von Umstrukturierungen des Teams,
    • Einflüsse aus dem Management,
    • Kompensation ausgefallener Mitarbeiter,
    • anhaltende technische Probleme,
  • Unverhältnismäßige Vergrößerungen des Product Backlogs oder unverhältnismäßig häufige Anpassungen von User Stories: Das Team muss viel Zeit aufwenden, um die geänderten User Stories neu zu bewerten. Diese Zeit fehlt in der Folge an anderer Stelle
  • Fehlerhafte Architektur-Entscheidungen, die nicht oder zu spät angegangen werden
  • Scrum-Master

    In Scrum gibt es neben der Rolle des Product Owners und des Scrum-Teams natürlich noch den Scrum-Master.

    Kommunikator, Moderator, Organisator

    Er fungiert als Kommunikator, Moderator, Organisator, vermittelt allen Beteiligten wie Scrum funktioniert und gilt als Ansprechpartner, wenn etwas in der Organisation nicht funktioniert. Ein guter Scrum-Master ist ein „Enabler“. Das heißt, er gibt den Beteiligten alle Mittel und alles Wissen, damit diese selbständig (und selbstorganisiert) agieren können.

    Der Scrum-Master achtet darauf, dass alle Beteiligten nach den „Scrum-Spielregeln“ arbeiten, insbesondere die agilen Werte kennen und anwenden.

    Man mag meinen, dass ein Scrum-Master nur in der Anfangsphase benötigt wird. Dies ist jedoch ein allgemeiner Irrtum: Niemand anders als der Scrum-Master kann durch seine neutrale Haltung in Konfliktfällen vermitteln, Impediments („Bedrohungen“) objektiv beurteilen, zu deren  Behebung beitragen und Scrum als Prozess im Sinne der stetigen Verbesserung überschauen.
    Jedes agile Projekt hat eine natürliche Dynamik, ist internen und externen Einflüssen ausgesetzt und lebt entwickelt sich mit den Menschen. Oder bildlich gesprochen: Wenn das Projekt ein Boot ist, dann ist der Scrum-Master der Kapitän und damit derjenige, der dafür sorgt, dass das Boot auf Kurs bleibt.

    User Story

    Als User Story wird durch den Product Owner  genau eine fachliche Anforderung prägnant beschrieben. User Stories mit je einer Karte am Product Backlog sichtbar gemacht. Voraussetzung dafür, dass eine User Story umgesetzt wird, ist die Abnahme dieser durch das Scrum-Team.

    Damit es zu einer Abnahme kommt, muss sich das Scrum-Team einig sein, dass die User Story der gemeinsam festgelegten Definition of Ready genügt. Vor allem aber muss das Team in der Lage sein, den fachlichen Gegenstand der User Story erfasst zu haben, so dass eine anschließende Schätzung (siehe: Estimation) möglich ist.

     

    Product Backlog

    Das Product Backlog enthält eine nach Priorität geordnete Sammlung von User Stories, in denen die Anforderungen an das zu entwickelnde Produkt beschrieben werden . Für die Pflege des Product Backlogs verantwortlich ist der Product Owner.

    Product Owner

    Eine der drei Rollen in Scrum stellt der Product Owner dar. Er ist für den Erfolg des Produkts verantwortlich und der zentrale Ansprechpartner in allen Fragen, die das Produkt betreffen. Auf dem Product Backlog, wo die Anforderungen in Form von User Stories gesammelt werden, entscheidet er durch Priorisierung, welche Anforderungen als nächstes umzusetzen sind.

    Weitere Details in dem ausführlicheren Artikel zur Rolle des Product Owners.