Katzenbilder

Fotos Büro

Hier eine Übersicht der Fotos, die zur Zeit in meinem Büro hängen.

Bilder Garten

Bilder 2016

Bilder 2017

Methoden

Unter dieser Katergorie finden sich Sammlungen von Methoden, Techniken, Tools zu verschiedenen Themen.

Coaching Methoden werden sowohl im Business Coaching, als auch im Personal Coaching genutzt.
Agile Methoden finden ihre Anwendung im agilen Management, z.B. im Scrum oder extrem Programming.
Projektmanagement Methoden kommen aus dem klassischen Projektmanagement.

Umfeldanalyse

Coaching Methode: Umfeldanalyse

Analyse der äußeren Einflüsse bei komplexen Situationen

Frage / Vorgehen

1. Schritt:

Klären, was unter Extern und Intern verstanden wird.
Die Einflussfaktoren Ökologisch …, etc. erläutern

2. Schritt:

Den Klienten aufschreiben lassen, was im Einzelnen beeinflusst (z.B. Familie, Chef) und wie diese Beeinflussung wirkt. (z.B. „macht zusätzlichen Stress“)
Den Klienten bewerten lassen, wie er diesen Einfluss empfindet
- o -5 sehr negativ
- +5 sehr positiv

Aufbau

{fastsocialshare}

SituationBewerten

Coaching Methode: Aktuelle Situation anhand von Kriterien bewerten

Kriterien zur Bewertung einer aktuellen Situationsbewertung finden und die Situation bewerten. Kann auch verwendet werden, um ein oder mehrere Ziele eines Klienten nach Kriterien bewerten zu lassen. Wenn der Coache noch keine Entscheidung treffen kann.

Hilfsmittel / Material

Vorlage: Aktuelle Situation und Ziele (Situationsbewertung)
Stifte: FineOne: Schwarz, Blau, Grün

Fragen / Vorgehen

1. Schritt: Thema benennen und aufschreiben

Aufgabenstellung: Bitte schreiben Sie das Thema der aktuellen Situation auf.

2. Schritt: Kriterien

Nach welchen Aspekten bewerten Sie die aktuelle Situation? Schreiben Sie einmal die für Sie wichtigen Kriterien auf. (Schwarzer Stift)

3. Schritt: Bewertung der aktuellen Situation

Wenn Sie einmal überlegen, wie gut die Aktuelle Situation Ihren Kriterien entspricht. Tragen Sie bitte bei den einzelnen Kriterien auf der Skala ein A ein. Und zwar auf dem Niveau, auf dem sich das Kriterium gegenwärtig befindet.

4. Schritt: Erträgliches Kriterienniveau

Können wir gerade die Stifte tauschen. Sie geben mir den schwarzen Stift und Sie erhalten einen blauen Stift.
Über legen Sie bitte, welche Ausprägung die Kriterien haben müssen, damit es noch Ihrem empfingen gerade gut genug erfüllt ist. Tragen Sie auf der Skala für dieses Kriterium ein E ein.
Wie würde sich die Situation in Vergleich zur Gegenwart unterscheiden.

5. Schritt: Zielniveau

Wenn Sie sich jetzt überlegen wie gut das Kriterium erfüllt sein muss, damit Sie zufrieden sind. Welchen Wert auf der Skala würde dann erreicht werden.
An was würden Sie merken, dass dieses Niveau erreicht ist?

6. Schritt: Wichtigkeit der Kriterien

Wenn Sie jetzt überlegen, wie wichtig die einzelnen Kriterien für Sie sind. Tragen Sie bitte in der letzten Spalte ein, wie sich die Kriterien in Ihrer Beziehung zu einander verhalten. Vergeben Sie eine 7 wenn das Kriterium sehr wichtig ist, eine 6 wenn es weniger wichtig ist, usw. Eine 1 bedeutet, dass Ihnen das Kriterium eher unwichtig ist.

Aufbau

{fastsocialshare}

PhasenmodellMeilensteine

Coaching Methode: Phasenmodell und Meilensteine

Vielen Menschen stehen, wenn sie etwas neues Anfangen, vor einem unüberwindbaren Berg an Aufgaben. Sie gehen diesen Berg an Aufgaben nicht an, weil sie von der Größe der Anforderungen, die hier an sie gestellt werden, überwältigt sind.

Wenn diese Aufgaben in kleine Einzelaufgaben unterteilt werden, die jeweils mit einem Zwischenergebnis enden, das für sie erreichbar erscheint, reduzieren sich die Ängste vor der überwältigenden Gesamtaufgabe. Der Coache kann mit den ersten Schritten beginnen, an den Meilensteinen einen Erfolg feiern und zur nächsten Aufgabe weiter gehen.

Diese Methode findet im Projektmanagement Anwendung. Das gesamte Leistungserstellungsmodell des agilen Management beruht auf diesem Vorgehen.

Ziel / Wozu?

Den Weg zum Ziel in kleinere Einheiten unterteilen
Phase:
- Ein Abschnitt im dem gearbeitet wird: To Do
Meilenstein:
- Ein Ergebnis, das mit einem Endtermin versehen wird.

Hilfsmittel / Material

Flip-Chart, Pin-Board

Geht auch mit Open-Project

Fragen / Vorgehen

1. Schritt:

Meilenstein benennen
Phasen benennen

2. Schritt:

Meilensteintermine festlegen

3. Schritt

Meilenstein Ergebnisse benennen

4. Schritt

To Do´s in den Phasen benennen

Aufbau

{fastsocialshare}

Fischteich

Coaching Methode: Fischteich

Menschen verhalten sich ähnlich wie Fische oder Pflanzen. Jede Pflanze benötigt einen ihr angepassten Standort und einen bestimmten Boden zum Wachsen. Je nach Boden, Sonneneinstrahlung, Nachbarpflanzen, etc. gedeiht eine Pflanze besser oder schlechter.

Ähnlich ist es bei Menschen. Befinden sie sich in einer für sie, individuell optimalen Umgebung, dann entwickeln sie sich zu Leistungsträgern und Führungspersönlichkeiten (oder was auch immer für ihn besonders positiv ist) oder verkümmern zu introvertierten Einzelgängern. Würde sich jeder Mensch in einer für sich optimalen Umgebung befinden, dann könnte er sich optimal entwickeln.

Die Methode Fischteich basiert auf dieser Annahme. Es wird zunächst einmal die bestehende Umweltsituation analysiert und mit dem Coache erarbeitet, welche alternative Situation für ihn ein "optimaler Fischteich" ist. Anschließen kann entweder nach einem "optimalen Fischteich" gesucht werden, oder die Maßnahmen ergriffen werden, um den gegenwärtigen "Fischteich" optimal zu verändern.

Das Ziel dieses Coaching Ansatzes liegen also nicht in direkter Zielerreichung des Coache. Die Ziele in diesem Coaching liegen darin, den "Fischteich" des Coaches zu verändern und damit eine optimale Entwicklung des Coache zu fördern.

Dabei werden eine Reihe an Einflussfaktoren untersucht, wie:

- Zusammenarbeit mit anderen Menschen

- Wertschätzung der Menschen auf die Arbeit des Coache

- Motive und Motivationen des Coache

- Werte des Coache

- Angewohnheiten des Coache, in Bezug zur Umwelt

- etc.

{fastsocialshare}

Einsichten

Coaching Methode: Einsichten

Die Methode gehört zu den einfachsten Coaching Methoden. Es ist lediglich eine Sammlung von Einsichten, die ein Klient- oder eine Klientengruppe im Verlauf einer Diskussion gewonnen hat.

Warum sie hier erwähnt wird?

Die Ergebnisse sehr vieler hoch konstruktiver Diskussionen, Besprechungen, etc. gehen verloren, weil sie nicht notiert werden. Dieser Flip-Chart, am Anfang der Diskussion auf gehangen, erspart in vielen Fällen ein umfangreiches Protokoll.

Auch wenn ich nur mit einem Klienten arbeite, ist zumindest dieser Flip-Chart die minimale Ausstattung jedes Coachings. Es hilft dem Coache die Erfolge eines Coachings zu fixieren und sichert so eine Nachhaltigkeit des Coachings.

Einsichten

{fastsocialshare}

Blitzentspannung 1: Droschkenkutschersitz

Entspannung wärend des Coaching.

Auch für die kurze Entspannung am Arbeitsplatz zwischendurch geeignet.

Vorgehen

Stuhl vom Tisch wegrücken.
Ellenbogen auf den Knien abstützen.
Kopf nach vorne hängen lassen.
Wirbelsäule nach vorne – unten „durchhängen“ lassen.

{fastsocialshare}

Blitzentspannung 2: Beckenschaukeln

Kurze Entspannung zwischendurch beim Coaching. Auch am Arbeitsplatz anwendbar.

Entspannung des Rückens.

Vorgehen

Auf dem vorderen Stuhldrittel aufrecht hinsetzen.
Füße schulterbreit mit der ganzen Fußfläche auf den Boden stellen.
Becken nach vorne kippen und nach oben schieben.
Dabei entsteht ein leichtes Holkreuz.
Becken nach hinten schieben (Rundkreuz, Rundrücken)

{fastsocialshare}

Zielstruktur

Coaching Methode: Zielstruktur

Wenn der Klient viele Ziele nennt und / oder viele Oberziele hat, die sich in Unterziele unterteilen lassen.
Oder wenn er ein Oberziel nennt, dass aber zu unspezifisch ist, um es zu erreichen.

Fragen / Vorgehen

1. Schritt:
- Zielkategorien aufschreiben
- Ziele sammeln
2. Schritt:
- Ziele auf Moderationskarten aufschreiben
3. Schritt:
- Ziele strukturieren
4. Schritt
- Ziel durch Ergänzungen konkretisieren, bis zur SMART Formulierung. Eventuell dafür anderes Medium.

Material / Hilfsmittel

Coaching Methode: Zielstruktur Wenn der Klient viele Ziele nennt und / oder viele Oberziele hat, die sich in Unterziele unterteilen lassen.

{fastsocialshare}

Blitzentspannung 3: Muskelpumpen

Kurze Entspannung zwischendurch. Anregen des Kreislaufes

Vorgehen

Aufrecht, mit nach vorne gekippten Becken auf dem vorderen Drittel des Stuhls sitzen.
Beide Füße schulterbreit, mit der ganzen Fußfläche auf dem Boden stehen.
Teil 1:Heben und senken Sie abwechselnd die Fersen.
Teil 2: Strecken Sie die Beine und ziehen Sie dabei die Fußspitzen an und neigen Sie den Oberkörper nach vorne (Dehnung der Waden und der Oberschenkel).

{fastsocialshare}

FaktenKonsensEntschiedung

Coaching Methode: Fakten <-> Subjektive Wahrnehmung -> Diskussion -> Handeln

Vielen Gruppen fällt es schon schwer sich gemeinsam auf einzelne Tatsachen oder Ereignisse zu einigen. Diese Instrument hift einer Gruppe von Menschen basieren auf Fakten und ihren persönlichen Gefühlen zu diesen Fakten ein Konsenz zu erreichen und darüber zu einem gemeinsamen Handeln geführt zu werden.

Es hilft zunächst einmal zwischen den Fakten und der subjektiven Wahrnehmen zu unterscheiden. "Was wissen wir wirklich?" und "Was vermuten wir?" Erst nach dieser Unterscheidung erfolgt eine Diskussion, was sich daraus an Handlungsalternativen ergibt.

Fragestellungen werden nacheinander von dem Moderator genannt. Der Flip Chart wird also erst im Zeitverlauf entwickelt:

Welche Tatsachen (oder Ereignisse) haben liegen zur Zeit vor?
Bitte beschreiben Sie, wie jeder einzelnen von Ihnen mit diese Tatsachen wahrnimmt?
Wie können wir die eingenommenen Wahrnehmungen zusammen bringen?
Wie wollen wir aufgrund der Wahnehmungen in Zukunft handeln?

Hilfsmittel

Flip-Chart oder Pin-Board

Coaching Methode Fakten, Diskussion, Handlung

{fastsocialshare}

Blitzentspannung 4: Palmieren

Kurzentspannung der Augen beim Coaching und am Arbeitsplatz

Vorgehen

Schließen Sie die Augen.
Legen Sie die Hände so über die Augen, dass diese unter der Hälfte der Handinnenfläche liegen.
Die Finger werden über der Stirn gekreuzt.
Die Innenflächen bilden so eine Höhle für die Augen ohne diese zu berühren.
Lassen Sie Ihre Augen in der Dunkelheit ruhen.

{fastsocialshare}

EinsichAnderung

Coaching Methode: Einsicht - Änderung - Erwartungen

Genau wie das Tool Einsichten, wird diese Methode gerne verwendet, um die Diskussionen von Gruppen zu einem gemeinsamen Ergebnis zu zentrieren und gemeinsame Erwartungen der Gruppe transparent zu machen und später zu überprüfen. Ebenso kann diese Coaching Methode in einem Einzelcoaching verwendet werden, um einem Coache, basierend auf Einsicht, die Änderungen die er durchführen möchte zu erkennen und sich der Vorteile aus dieser Verhaltensänderung bewusst zu werden und sie zu fixieren.

Frage: Was habe wir aus den bisherigen Diskussionen an Erkenntnissen gewonnen?
Frage: Welche Änderungen sollen wir, aufgrund der gewonnenen Erkenntnisse umsetzen?
Frage: Was erwarten wir aus den gemeinsamen Erkenntnissen an positiven Effekten?

Einsichten Veränderungen Folgen

{fastsocialshare}

Blitzentspannung 5: Kreisen

Zwischendurch im Coaching oder am Arbeitsplatz.

Entspannung der Hals und Schultermuskulatur

Vorgehen

Alle Übungen sehr langsam machen!

Setzen Sie sich auf das vordere Drittel des Stuhles und stellen Sie die Füße schulterbreit fest auf den Boden oder stehen Sie auf und stellen sich gerade hin.
Kopf nach vorne fallen lassen und nach rechts kreisen. (mind 3X)
nach links kreisen. (mind 3X)
Rücken gerade machen und Arme hängen lassen.
Schultern nach vorne kreisen. (mind 3X)
Schultern nach hinten kreisen. (mind 3X)
Hände nach vorne ausstrecken, Arme gerade.
Die Unterarme nach innen kreisen lassen. (mind 3X)
Die Unterarme nach außen kreisen lassen. (mind 3X)
Die Hände am Handgelenk nach innen kreisen lassen. (mind 3X)
Die Hände am Handgelenk nach außen kreisen lassen. (mind 3X)
Finger lockern.
Langsam und entspannt wieder auf dem Stuhl zurück setzen.

{fastsocialshare}

Coaching Methode: Alternativen bewerten

Zum Treffen einer "objektiven Auswahl" aus vier Alternativen, nach den vom Klienten festgelegten und bewerteten Kriterien.

Vorgehen

1. Schritt: Alternativen aufschreiben

Bitte schreiben Sie die Alternativen, die Sie erarbeitet haben, auf.

2. Schritt: Kriterien

Nach welchen Aspekten bewerten Sie die Alternativen? Schreiben Sie einmal die für Sie wichtigsten Kriterien auf. (Schwarzer Stift).

3. Schritt: Mindestausprägung

Wenn Sie einmal überlegen, wie gut die Handlungsalternativen die von Ihnen genannten Kriterien erfüllen müssen. Tragen Sie in die Skala bitte mit dem blauen Stift ein, wie stark die von Ihnen genannten Kriterien erfüllt sein müssen, damit Sie zufrieden sind.

4. Schritt: Bewerten der Alternativen

Tragen Sie jetzt bitte ein, wie gut die einzelnen Alternativen Ihre Kriterien erfüllen. Beginnen Sie bitte mit Alternative 1. Verwenden Sie den schwarzen Stift und tragen Sie bitte für Alternative 1 eine 1 ein. Für Alternative 2 eine 2 usw.

Anmerkungen

Die Spalte "Wichtigkeit" zunächst wegklappen.

Unbedingt vorher erklären, dass nicht nur Kreuze gemacht werden sollen, sondern Buchstaben eingetragen werden müssen.

Es gibt eine zweite Seite. Diese erst dann hervor holen, wenn der Klient die letzte Zeile schreibt.

Formular

Die Nutzenwertanalyse ist eine Alternative zu dieser Methode. Sie ist allerdings wesentlich schwieriger durchzuführen und braucht länger.

Coaching Methoden: Links

{fastsocialshare}

5MalWarum

Coaching Methode: 5 X Warum?

Die Ursache hinter der Ursache, oder der Schleier hinter dem Schleier

Das klingt nach einem alten Kinderspiel. Es wird solange immer wieder nach "dem Warum" gefragt, bis die Eltern entnervt aufgeben oder in blanker Verzweiflung versinken. Und natürlich finden wir irgendwann keine Antworten mehr und begründen entweder mit "weil Gott das so will" oder wir geben zu, dass wir selber auch keine Antwort mehr haben. - Was mehr oder weniger auf das Gleiche heraus läuft - es sei denn wir glauben, dass wir erkannt haben, was Gott oder die Götter wollen. Was ich ja nach wie vor für ziemlich anmaßend halte.

Im Coaching kann diese Fragetechnik sehr positive Effekte erzielen. Die meisten Menschen haben für ihre Handlungsweisen, Ansichten und festgefahrenen Handlungsschemas ein Schema an plakativen Antworten, die sie seit einer langen Zeit benutzen, ohne diese jemals zu hinterfragen. Die Argumentationskette ist auf den ersten Blick schlüssig - auch wenn die ganze Argumentationskette auf einer Annahme beruht, die eher auf tönernen Füßen steht.

Bricht der eigene Argumentationsstrang zusammen, erhält der Coache den inneren Raum, der es ihm ermöglicht ihn mit neuen "wohlbegründeten" Handlungsweisen zu füllen.

Vorgehen

1. Schritt: Die Frage ausschreiben: "Warum ist ... so?"

2. Schritt: Die Antwort vom Klienten aufschreiben lassen. ("Das ist so, weil....")

3. Schritt: Weiterfragen: "Warum ist...(das was "hinter dem Weil steht") so?"

4. Schritt: Die Antwort vom Klienten aufschreiben lassen. ("Das ist so, weil....")

etc.

Natürlich muss nicht genau 5 Mal gefragt werden. Bei vielen Aussagen zeigt sich an der Antwort des Klienten schon viel früher, dass die als Wahrheit angenommene Begründung so nicht ganz richtig ist.

Kommt der Klient aber nicht mehr weiter, dann geht die Fragetechnik wieder rückwärts.

1. Rückschritt: "Wenn wir also zur Kenntnis nehmen, dass die Begründung so nicht schlüssig ist, was ergibt sich dann für die Antwort (z.B. in Schritt 4). - Natürlich wird auch hier der sich ergebende Schluss des Klienten wieder aufgeschrieben.

2. Rückschritt: "Wenn wir also ..."

Dieser Prozess wird fortgesetzt, bis der Klient bei Antwort 1 angekommen ist.

{fastsocialshare}

FaktenWahrnehmung

Coaching Methode: Fakten und Wahrnehmung

Viele Menschen haben Schwierigkeiten, zwischen den Fakten, die ihrer Wahrnehmung zugrunde liegen und der Wahrnehmung zu unterscheiden. Häufig fällt es ihnen schwer, die Fakten auf der einen Seite und eine Wahrnehmung auf der anderen Seite zuzuordnen. Diese Übung hilft beides zu unterscheiden.

Das Instrumentarium ist für die Moderation von Gruppen hilfreich.

Die "Karten" müssen von der einen auf die andere Kategorie umsortiert werden können. Wenn der Teilnehmer sich selber mit seiner Zuteilung wichtig ist, kann er Karten und Wahrnehmung mit Linien verbinden.

Hilfsmittel:

Pin Board oder Flip-Chart

Fakten und Wahrnehmung

{fastsocialshare}

SWOT Analyse

SWOT-Analyse - Stärke/Schwächen, Risiko/Chancen

Die SWOT-Analyse ist eine Methode, die der Betriebswirtschaftslehre häufig verwendet wird um eine Situation, eine Alternative oder ähnliches zu bewerten. Auch im Coaching kann sie von dem Coache für den gleichen Zweck verwendet werden.

Bewertung einer Situation. Bei mehreren Alternativen für jede Alternative eine eigene SWOT-Analyse
Analysiert werden:
- Von außen kommen (Extern): Risiken und Chancen
- In dem Klienten (seinem Unternehmen, seiner Familie) kommen (Intern): Stärke und Schwächen

Fragen / Vorgehen

1. Schritt:
- Instrument aufzeichnen
2. Schritt:
- Klären, wie extern und intern abgegrenzt werden (Was wollen wir darunter verstehen?)
3. Schritt
- Die einzelnen Felder ausfüllen

Aufbau / Hilfsmittel

SWOT-Analyse im Coaching einsetzen

{fastsocialshare}

Coaching Methoden

Coaching Methoden / Coaching Werkzeuge / Coaching Tools / Coaching Methodenkoffer

Coaching ist keine "einheitliche Methode".

In einer Coaching Sitzung werden von dem Coach, in Abhängigkeit der Fragestellung des Klienten und je nach Situation, die entsprechenden Methoden ausgewählt.

Die hier dargestellten Methoden sind ein Auszug aus den möglichen Coaching-Methoden, die ich verwende. Es sind Werkzeuge. Einen großen Werkzeugkasten zu haben, bedeutet noch nicht ein guter Handwerker zu sein.

Und: Mit Werkzeugen kann auch viel falsch gemacht werden.

Ein Hammer ist ideal, um einen Nagel in die Wand zu schlagen. Für eine Schraube ist er mehr oder weniger ungeeignet.

Wenn ein Mensch nur einen Hammer hat, dann sieht alles aus wie ein Nagel. Die genaue "Nutzung der Werkzeuge" kann je nach Klienten und Fragestellung variieren und ob diese Werkzeuge verwendet werden ist einfach Situations- und Klientenabhängig.

Natürlich handelt es sich hier nur um einen Auszug aus einem wesentlich größeren Methodenkoffer. Ich möchte Ihnen einen Eindruck von Methoden geben, die ich in einem Coaching einsetze. Natürlich bin ich nicht der einzige Coach, der diese Werkzeuge verwendet und natürlich habe ich die auch nicht alle selber entwickelt. Die meisten sind unter Coaches in dieser oder einer ähnlichen Form genauso gebräuchlich, wie ein Schraubenzieher oder ein Zollstock unter Handwerkern.

Wozu	Methode ansehen
Kriterien zur Bewertung einer aktuellen Situationsbewertung finden und die Situation bewerten. Kann auch verwendet werden, um ein oder mehrere Ziele eines Klienten nach Kriterien bewerten zu lassen.	ansehen
Die Nutzenwertanalyse wird auch im Projektmanagement angewendet, um "objektiv" eine Bewertung von Zielen, dem Nutzen von Produktkomponenten oder ähnlichem zu finden.	ansehen
Die SWOT-Analyse (auch Stärken, Schwächen, Risiken Chancen-Analyse) hat eine ähnliche Nutzung. Auch hier geht es um die Bewertung einer Situation für das Treffen einer Entscheidung. Es werden die externen Risiken und Chancen und die internen Stärken und Schwächen gesammelt und miteinander verglichen	ansehen
Alternativen bewerten, die vorher in einem Brainstorming oder mit ähnlichen Methoden ermittelt wurden. Es kann sich um alternative Ziele oder alternative Handlungsmöglichkeiten handeln.	ansehen
Ankommübung: Es gibt hunderte davon. Ziel ist es, die Teilnehmer aus einer aktuellen Stress Situation heraus zu holen und ihnen zu helfen, ihren Kopf für das Coaching frei zu machen.	ansehen
Blitzentspannung 1: Droschkenkutschersitz - Rückenentlastung. Entspannungsübung für zwischendurch wärend des Coaching.	ansehen
Blitzentspannung 2: Beckenschaukeln - Rückenentlastung. Entspannungsübung für zwischendurch wärend des Coaching.	ansehen
Blitzentspannung 3: Muskelpumpen - Kreislauf anregen. Entspannungsübung für zwischendurch wärend des Coaching.	ansehen
Blitzentspannung 4: Palmiren - Entspannung der Augen. Entspannungsübung für zwischendurch wärend des Coaching.	ansehen
Blitzentspannung 5: Schulterkreisen - und ähnliches Kreisen. Entspannungsübung für zwischendurch wärend des Coaching.	ansehen
Der Future Pass dient dazu, den Klienten dabei zu unterstützen, sowohl das Ziel, das er erreichen möchte, als auch den Weg zu diesem Ziel zu visualisieren und damit sein eigenes Handeln darauf zu fixieren.	ansehen
Ebenen des Menschen: Gesprächsgrundlage für Analyse der Lebenseinstellung, Widerstände, Gründe für das eigene Handeln und Möglichkeiten der Veränderung	ansehen
Rad des Lebens: Aktuelle Bewertung verschiedener Lebensbereiche und festlegen der Zielwerte	ansehen
Reisegepäck / Trennungsritual: Was bleibt zurück, wenn die Ziele festgelegt sind?	ansehen
	ansehen
Vorhandene Ressourcen sammeln und bewerten.
Ressourcen aus verschiedenen Lebensbereichen erkennen.	ansehen
Selbstbild, Fremdbild, Wunschbild: Unterschiede und Übereinstimmungen erkennen	ansehen
Alternativen / Ziele bewerten und auswählen	ansehen
Personen Kurzbeschreibung werden dazu verwendet, den Klienten die Akteure in einem häufig komplexen Zusammenhang klarer erkennen zu können und seine persönliche Sichtweise auf die jeweilige Person deutlicher zu machen.	ansehen
Ein Beziehungs-Netzwerk wird genutzt, um komplexe soziale Systeme zu beschreiben und die Nähe und Entfernung von Menschen darzustellen. Ich verwende hier gerne einen Flip-Chart und Figuren. Es kann aber auch einfach auf einem Blatt Papier gemacht werden.	ansehen
Die Stakeholder-Analyse ist ein im Projektmanagement etabliertes Verfahren, um Betroffene, Beteiligte und Interessierte zu ermitteln und sie nach den Kriterien Einstellung und Macht zu analysieren.	ansehen
Die Umfeldanalyse dient der Beschreibung der aktuellen Situation, also einer Ausgangssituation. Sie wird ebenfalls im Projektmanagement angewendet.	ansehen
Ein Phasenmodell mit Meilensteinen stammt ebenfalls aus den Methoden des Projektmanagements. Zielsetzungen, die bis zu ihrer Erreichung einen längeren Zeitraum benötigen, werden dadurch strukturiert.	ansehen
Rollenklarheit ist immer notwendig, wenn eine Rolle gelebt werden soll. Innere Konflikte entstehen häufig, wenn verschiedene Rollen miteinander in Widerspruch stehen. Konflikte zwischen Menschen entstehen, wenn die Erwartungen über die Art, in der eine Rolle gelebt werden soll, unterschiedlich sind. Dieses Instrument dient der Rollenklärung.	ansehen
Rollen und persönliche Einstellung und Verhaltenserwartung: Die Aufgaben und Verhaltenserwartungen von Rollen werden von Menschen sehr individuell wahrgenommen. Diese Methode hilft dem Klienten für ihn positive und negative Rollenerwartungen in Relation zueinander zu stellen und eine Entscheidung darüber zu treffen, wie er mit diesen Erwartungen umgehen möchte.	ansehen
Beziehungsspiel: Die Erwartungen - gemeinsame und jeweils individuelle - werden gegenüber gestellt, um das zu erkennen, was als gemeinsame Basis besteht und was zu Unterschieden führt. Der Klient erkennt so Gemeinsamkeiten und Unterschiede. Diese Methode kann bei jeder Beziehung angewendet werden, gleichgültig ob es sich um Beziehungen zwischen Kollegen, Partnern oder Vorgesetzten und Mitarbeitern handelt.	ansehen
Die Risiko-Chancen Matrix entstammt dem Instrumentarium des Projektmanagements. Sie ist für das Coaching ebenso gut geeignet, um die Risiken und die Chancen abzuschätzen, die sich aus einer Situation ergeben.	ansehen
Eine Zielstruktur ist immer dann notwendig, wenn der Klient mehrere Ziele nennt, die sich in mehrere Unterziele unterteilen lassen oder wenn die genannten Ziele so unkonkret sind, dass sie besser aufgesplittet und damit konkretisiert werden.	ansehen
Ressourcen der Vergangenheit: "Früher war alles besser?", "Das war mal anders!" - Situationen, die in der Vergangenheit schon einmal besser waren und Handlungsweisen, die in der Vergangenheit erfolgreich angewendet wurden, können mit der Übung wieder aktiviert werden.	ansehen
5X Warum? ist eine Fragetechnik, die den Hintergrund eines Problems, einer Handlungsweise oder einer Einstellung hinterfragt.	ansehen
"Tue es einfach!", klingt nach einer Handlungsanweisung und das steckt auch genau dahinter - wobei diese Handlungsanweisung vom Coach nur initiiert wird. Als Handlungsanweisung des Coaches an sich selbst, erfolgt sie von Coache an sich selber.	ansehen
Fakten und Wahrnehmung, unterscheiden sich häufig stark voneinander. Diese Übung hilft beide zu unterscheiden.	ansehen
Fakten, Diskussion, Handeln ist ein Instrument, das es ermöglicht Fakten, unterschiedliche persönliche Meinungen, die Bildung eines gemeinsamen Konsens und die Handlungsoptionen, die sich daraus ergeben, für alle transparent zu machen. Dieses Tool ist für Gruppendiskussionen und Teamentscheidungen sehr gut geeignet.	ansehen
Zeitstrahl, Ereignis, Gefühl wird dafür genutzt, einen Konsens zwischen einzelnen Menschen, oder auch bei einer Person über die Ereignisse zu finden, die in der Vergangenheit passiert sind. Im nächsten Schritt, werden dann die Gefühlssituationen, die sich aus den Ereignissen ergeben haben, hinzugefügt.	ansehen
Einsichten gehört zu den einfachsten Coaching Methoden. Es ist eine Sammlung der Einsichten, die ein Klient - oder ein Gruppe von Klienten im Verlauf einer Diskussion gewonnen hat.	ansehen
Einsichten, Änderungen, Erwartungen basiert häufig auf den Ergebnissen der Methode Einsichten. Diese Methode kann - als "Schnellcoaching" - auch in einem Einzelcoaching verwendet werden, wenn nur wenig Zeit ist. Die häufigste Anwendung findet sie aber als Moderationstechnik in Gruppen. Hier begleitet und fixiert der Flip-Chart die Änderungsentscheidungen und die zukünftigen Erwartungen	ansehen
Fischteich ist ein Vorgehen, das auf der Annahme beruht, dass es für jeden Menschen eine optimale Umgebung gibt, in der er sich entwickeln kann. Ziel dieser Methode ist es, festzustellen wie dieser "optimale Fischteich" aussieht.	ansehen

Methoden 36

{fastsocialshare}

Coaching Methode: Ankommübung / Rückblick auf den Weg

Den oder die Teilnehmer aus der aktuellen Tages - und Stress Situation heraus holen und ihnen zu helfen ihren Kopf für das Coaching frei zu machen.

Vorgehen

Diesen Text langsam vorlesen dabei viele Pausen machen.

Text

Schließen Sie die Augen.

Setzen Sie sich bequem.

Rücken Sie sich zurecht, bis Sie eine angenehme Position gefunden haben.

Lassen Sie die Muskeln fallen. Entspannen Sie sich.

Gehen Sie mit den Gedanken zurück zu dem heutigen Morgen.

Wann sind Sie aufgewacht?

Wie fühlten Sie sich, als Sie aufgewacht sind?

Waren Sie ruhig oder gestresst?

Was haben Sie wahrgenommen?

Spürten Sie Ihren Traum noch?

Fühlten Sie noch die Nacht?

Sie stehen auf.

Was tun Sie als nächstes?

Vergegenwärtigen Sie sich alle Schritte.

Ihre Empfindungen.

Ihre Gedanken.

Jetzt verlassen Sie Ihre Wohnung, Ihr Haus.

Erleben Sie, wie die Tür ins Schloss fällt.

Wie fühlen Sie sich?

Sind Sie ruhig? Sind Sie gestresst?

Was nehmen Sie wahr? Was hören Sie? Was riechen Sie? Was fühlen Sie?

Sie sind auf dem Weg hierher.

Im Auto? Zu Fuß? Mit dem Bus oder der Bahn?

Was fühlen Sie?

Was nehmen Sie wahr? Was hören Sie? Was riechen Sie? Was fühlen Sie? Was sehen Sie?

Sind da andere Menschen um Sie herum?

Was haben Sie erlebt?

Jetzt kommen Sie hier ins Haus.

Was fühlen Sie?

Was nehmen Sie wahr? Was hören Sie? Was riechen Sie? Was fühlen Sie? Was sehen Sie?

Sind da andere Menschen um Sie herum?

Was haben Sie erlebt?

Jetzt betreten Sie diesen Raum.

Was fühlen Sie?

Was nehmen Sie wahr? Was hören Sie? Was riechen Sie? Was fühlen Sie? Was sehen Sie?

Sind da andere Menschen um Sie herum?

Was haben Sie erlebt?

Jetzt sind Sie angekommen.

Jetzt sind Sie im Hier und im Jetzt.

Was fühlen Sie?

Was nehmen Sie wahr? Was hören Sie? Was riechen Sie? Was fühlen Sie? Was sehen Sie?

Was haben Sie, erleben Sie?

Entspannen Sie sich noch ein wenig.

Öffnen Sie langsam die Ihre Augen.

Setzen Sie sich aufrecht hin und betrachten Sie, was Sie wahrnehmen.

Coaching Methoden: Links

{fastsocialshare}

Coaching Methode: Future Pass

Den Weg zum Ziel visualisieren. Einzelne Schritte des Weges zum Ziel, Schwierigkeiten und Erfolge bis zum Ziel geistig erleben und so für den Klienten fixieren.

Voraussetzungen:

Unfangreiche Analyse und Festlegung der Zielbilder, sowie der einzelnen Schritte des Weges zusammen mit dem Klienten.

Vorher muss geklärt werden:

Mit was ist der Coachee unzufrieden.
Wie genau ist die aktuelle Situation?
Welche Ressorucen braucht er, um sein Ziel zu erreichen?
Welche Handlungen sind notwendig?
Hygiene: Spricht etwas dagegen, diese Zukunft zu erreichen?

Danach:

Ressourcen klären.
Handlungen in der Zukunft klären.

Fragestellung / Vorgehen

1. Teil (Blick zur Gegenwart)

Sehen Sie sich das Bild der Gegenwart noch einmal an. Wie fühlen Sie sich? Was sehen Sie? Was sagen Sie sich selber in der Gegenwart? Was sagen Andere zu Ihnen?

2. Teil (Future Pass)

Drehen Sie sich herum. Sehen Sie diese Rot-Linie. Das ist der Weg in Ihre Zukunft. Wir gehen jetzt langsam diesen Weg nach vorne. Schließen Sie bitte die Augen und konzentrieren Sie sich auf das, was mit Ihnen in diesen Jahren passiert ist.

Nach ein paar Schritten stehen bleiben. Wir sind jetzt ein paar Monate in Ihre Zukunft gegangen. Was hat sich ereignet. Was ist Ihnen passiert? Waren Sie zufrieden mit …? Was hat Sie zufrieden gemacht?. Wir gehen jetzt weiter hin zu Ihrer Zukunft. Lassen Sie die Augen geschlossen. Konzentrieren Sie sich ganz auf das, was in Ihnen in Bezug auf … passiert ist. Erzählen Sie mir welche Ereignisse Sie sehen.

Nach ein paar weiteren Schritten: Wir sind jetzt ein Jahr (mehrere Jahre, im Jahr) angekommen. Was ist passiert? Was hat sich verändert? Was haben Sie getan? Was haben Andere getan? Waren Sie zufrieden? Was hat Sie zufrieden gemacht? Was hat dazu geführt, dass Sie …? Was hat Ihnen geholfen so zu sein …? Was hat Sie motiviert?

3. Teil (Blick zurück)

Wir sind jetzt im Jahr … angekommen. In der Zeit, wo sie … konnten. Wo sie ... waren. Öffnen Sie bitte die Augen und sehen Sie sich dieses Bild an, das Sie sind. Wie fühlen Sie sich? Was hat sich verändert?

Jetzt drehen Sie sich bitte um. Sehen Sie das Bild dahinten (der Gegenwart), das Jahre zurück liegt.

Wie fühlt sich das an, wenn Sie dieses Problem so lange gelöst sehen? Was habe Sie getan um dieses Problem zu lösen? Hat sich die Arbeit gelohnt?

Werden Sie diesen Weg gehen?

Material/Hilfsmittel

2 Flip-Charts, Klebeband oder Kordel und einen großen Raum.
Weg sollte über mehrere Meter gehen.
Alternativ zur Kordel geht auch Klebeband

Coaching Methode: Future Pass Den Weg zum Ziel visualisieren. Einzelne Schritte des Weges zum Ziel, Schwierigkeiten und Erfolge bis zum Ziel

{fastsocialshare}

Trennungsritual

Coaching Methode: Reisegepäck / Trennungsritual

Wenn festgelegt ist, welche Veränderungen erreicht werden sollen, dann gibt es immer einige Sachen, lieb gewonnene Ideen, Ansichten, etc., die nicht zu den neuen Zielen passen.

Wird von Ihnen kein Abschied genommen, dann belasten Sie auf dem Weg zu Ziel.

Fragen / Vorgehen

Bevor man sich auf eine Reise begibt, muss man seine Sachen packen. Wenn wir packen, dann müssen wir uns entscheiden, was wir auf der Reise brauchen und was uns nur belastet.

Bevor Sie sich auf den Weg machen, bevor Sie in Ihre Zukunft gehen, bevor Sie zu Ihren Zielen gehen, lassen Sie uns überlegen, was Sie auf diese Reise in Ihre Zukunft mitnehmen möchten. Was brauchen Sie, damit Ihre Träume Wahrheit werden, real werden?

Was nehmen Sie mit auf Ihre Reise in die Zukunft?
Was packen Sie in eine Kiste, damit es gut verschlossen und geschützt in Ihrer Vergangenheit verbleiben kann?

Hilfsmittel / Materialien

Flip-Chart, Whiteboard, Stifte
Eventuell mit den Sachen in der Kiste ein Trennungsritual machen.
Oder ein Ritual machen, um die Kisten zu verschließen, damit das alles gut aufgehoben bleibt.

Coaching Methode: Reisegepäck / Trennungsritual

{fastsocialshare}

Nutzenwertanalyse

Coaching Methode: Nutzenwertanalyse

Zur Wahl zwischen mehreren Alternativen, mit Hilfe von bewerteten Kriterien.

Die Nutzenwert Analyse ist ein kognitives Entscheidungsverfahren zwischen verschiedenen Alternativen. Es hilft dem Klienten dabei rationale Kriterien für die Wahl seiner Handlungsalternativen zu bestimmen und dann entsprechend dieser von ihm definierten Kriterien zu entscheiden.

Fragen / Vorgehen

1. Schritt:
- festlegen der Kriterien
2. Schritt
- Kriterien in ihrer Bedeutung für den Erfolg bewerten.
3. Schritt
- Auswahl der Alternativen
4. Schritt
- Jede einzelne Alternative nach den Kriterien bewerten und diese Werte eintragen.
- Der Nutzenwert der jeweiligen Alternative errechnet sich dann aus der Gewichtung des Kriteriums und der Bewertung der Alternativen
5. Auswahl
- Die Alternative wählen, die den höchsten Nutzenwert hat.

Materialien / Hilfsmittel

Excel oder ähnliche Tabellenkalkulation

{fastsocialshare}

RisikoChancenMatrix

Coaching Methode: Risiko / Chancen bewerten und Maßnahmen entwickeln

Für einen Coache bleiben viele Risiken diffus. Diese Risikomatrix hilft dem Coache dabei dieses difuse Gefühl der Angst, das er in einer neuen Situation empfindet zu rationalsieren und die Risiken kognitiv zu benenne und zu bewerten.

Diese Methode ist nützlich,

wenn,eine Situation oder eine Handlungsalternative mehrere Risiken und Chancen enthält.
zur Bewertung der Risiken für verschiedene Handlungsalternativen. Dann pro Handlungsalternative eine Risikoliste.
Die Risiken werden nach Eintrittswahrscheinlichkeit und Folgen bewertet.
Anschließend werden Maßnahmen zur Risikoreduktion entwickelt.

Fragen / Vorgehen

1. Schritt:
- Risiken und Chancen ermitteln. Jeweils als Risiko und als Chance kennzeichnen.
2. Schritt
- Klient ordnet den Risiken eine Eintrittwahrscheinlichkeit auf einer Skala von 1-5 zu.
- Klient ordnet dem Risiko eine Bewertung der Folgen für die Handlungsalternative zu (auf einer Skala von 1 bis 10. 1 = geringe Folgen, 10 = extrem negative Folgen).
3. Schritt
- Klient entwickelt Maßnahmen zum Umgang mit Risiken und Chancen.
- Zwischendurch immer mal nach der Risiko-Chancen Spalte sortieren.

Material / Hilfmittel

Excel Vorlage

Risiko und Chancen Matrix, Coaching Methode

{fastsocialshare}

Coaching Methode: Ressourcen bewerten

Hier ein Instrumentarium um die Ressourcen, die einem Klienten zur Verfügung stehen "rational" zu bewerten und Defizite in der Ressourcenauswahl zu ermitteln.

Fragestellung / Vorgehen

In einem ersten Schritt werden die Ressourcen ermittelt, die benötigt werden.

Diese Ressourcen werden in der ersten Spalte dieser Liste eingetragen.

Mit dem Klienten wird dann erarbeitet:

welche Ressourcen vorhanden sind
was der beste denkbare Wert für die Ressourcen ist.
welchen Zielwert er für die jeweilige Ressource anstrebt.

Materialien / Hilfmittel

Tabelle zur Bewertung der einen Ressourcen zur Problemlösung.

Coaching Methoden: Links

{fastsocialshare}

Weiterlesen: Coaching Methoden: Links

Tue

Coaching Methode: "Tue es einfach"

Alles ist vorbereitet. Der Klient hat alle Ressourcen vorbereitet. Er kann anfangen seinen Weg zu gehen, der zum Erreichen seiner Ziele führt.

Aber er schafft es nicht den ersten Schritt zur Umsetzung zu gehen. - Irgendetwas kommt immer dazwischen.

Ist es "Aufschieberitis"? Ist es "die Angst vor dem ersten Schritt"? Ist es ein "festhängen in alten Gewohnheiten"?

Es gibt eine Vielzahl an Gründen und Begründungen. Der Klient sucht und findet immer wieder kurzfristige "Notwendigkeiten" um genau mit den Tätigkeiten nicht zu beginnen, die ihn seinen Zielen näher bringen.

Es siehst so aus, als ob er auf der untersten Stufe der Treppe, die er mit Leichtigkeit gehen kann, festhängt. Er braucht eigentlich nur einen kleinen Schubs, um über diese "Klippe zu springen". Aber genau dieser Schubs fehlt ihm.

Was helfen kann, ist ein "Befehl durch den Coach", eine Anweisung genau das was er möchte zu tun. Dieser Anstoß kann Verbal über einen Befehl, eine konkrete Handlungsanweisung erfolgen. Er kann auch in Form eines Rituals oder durch das Setzen eines Ankerpunktes erfolgen.

Der Methode liegt eine gewisse Suggestion zugrunde. "Lass alle Bedenken los." "Setze es um".

Ich habe die Erfahrung gemacht, dass hier die Unterstützung durch einen guten Hypnotiseur ebenfalls sehr hilfreich sein kann. Auch der "Anker" durch einen Coach kann den Coache bei der Umsetzung unterstützen.

{fastsocialshare}

EbenenMensch

Coaching Methode: Ebenen des Menschen

Gesprächsgrundlage zur Analyse der Fragestellungen. Hintergründe einer Fragestellung oder eines Verhaltens erkennen und neue Verhaltensalternativen entwickeln.

Dieses Modell geht davon aus, daß die Handlungen von Menschen durch Einflussfaktoren aus verschiedenen Ebenen beeinflusst werden. Es dient als Gesprächsbasis über die verschiedenen Ebenen, vom Glauben bis zur Rolle, die bei jedem Menschen vorhanden sind.

Vorgehen / Fragestellung

Es gibt einen Wirkungszusammenhang. Die Ebenen beeinflussen einen Menschen von innen nach außen.

Was ist Ihnen wichtig? Diese Frage zielt auf die Identität des Menschen. Hier geht es um seine Werte und Wertvorstellungen.

Einleitung: Ich möchte Ihnen gerne ein Modell von verschiedenen Bewußtseinsebenen jedes Menschen zeigen. Ich möchte Ihnen gerne zeigen, wie Ihre Glaubenssätze Ihre Fähigkeiten und Ihr Verhalten beeinflussen.

Material / Hilfsmittel

Ebenen des Menschen die das Verhalten beeinflussen.

{fastsocialshare}

RaddesLeben

Coaching Methode: Rad des Lebens

Ein Messinstrument um die Zufriedenheit in verschiedenen Lebensbereichen zu bestimmen und Verbesserungspotentiale zu erkennen.

Der Klient erkennt, in welchen Lebensbereichen welche Zufriedenheitsgrad besteht
Der Klient erkennt, in welchen Bereichen er mehr erreichen möchte
Darstellen, wie wichtig diese Lebensbereiche für den Klienten sind

Vorgehen / Fragen

Wichtigkeit
- Sie sehen hier verschiedene Lebensbereiche. Markieren Sie doch bitte auf den Skalen, wie wichtig diese Bereiche für Sie persönlich sind.
Qualität der Lebensbereiche
- Auf diesem Blatt sehen Sie verschieden Bereich im Leben eines Menschen.
- Markieren Sie bitte, wie zufrieden Sie im Moment mit diesen Lebensbereichen sind
- Verraten Sie mir bitte, wie zufrieden Sie in diesen Bereichen gerne wären.

Hilfsmittel / Aufbau

{fastsocialshare}

Ressourcenabfrage

Coaching Methode: Ressourcen erkennen / Ressourcen abfragen

Die Ressorcen, die aus verschiedenen Lebensbereichen zur Zielerreichung zur Verfügung stehen, erkennen und benennen.
Defizite erkennen und sehen, wo diese Ressourcen gefunden / geschaffen werden können.

Fragestellung / Vorgehen

Wenn Sie jetzt Ihr Ziel vor Augen sehen: Was brauche Sie um dieses Ziel zu erreichen?
Was unterstützt Sie? Was können Sie?
Wer unterstützt Sie? Welche Hilfe benötigen Sie? Welches Wissen würde Ihnen helfen?
Welche Organisationen / Institutionen können Sie mit was unterstützen?

Materialien und Hilfsmittel

Ressourcenabfrage

{fastsocialshare}

SelbstbildWunschbild

Coaching Methode: Selbstbild / Fremdbild / Wunschbild

Differenzen zwischen Selbstbild und Fremdbild erkennen. Oder Differenzen zwischen Selbstbild und Wunschbild
Das erwünschte Fremdbild als Ziel formulieren
Handlungsmöglichkeiten zum gewünschten Fremdbild oder zum Wunschbild finden.

Diese Methode stammt aus dem Einzelcoaching. Sie kann allerdings auch genutzt werden, wenn sich unterschiede zwischen dem Selbstbild, Fremdbild und Wunschbild einese Teams zeigen.

Fragestellung / Vorgehen

Zum Spiegel
- Dieses leere Blatt ist Ihr Spiegel. Wenn Sie in diesen Spiegel blicken – was sehen Sie dann? Was sind Sie? Wie sind Sie? Wie sehen Sie sich? Wie nehmen Sie sich wahr? Wie empfinden Sie sich?
- Zu "der Andere sieht"
- Wenn Sie ein anderer Mensch anschaut? Wenn ein anderer Mensch Sie bei dem sieht was Sie tun? Wenn … Sie bei Ihrer täglichen Arbeit sieht? Mit Ihnen redet … Ihnen zuhört … Was sieht er? Was empfindet er? Was nimmt er wahr? Was hält er von Ihnen? Wie schätzt er Sie ein?
Zu Wunschbild
- Wenn Sie wählen könnten… Wenn Sie selber entscheiden könnten … Wie würde der Andere Sie wahrnehmen? Was würde er empfinden? Was würde er von Ihnen halten? Wie wollen Sie sein? Wie wollen Sie für Andere sein?
Handeln zum Wunschbild / Wege zum Wunschbild
- Wenn Ihnen alle Möglichkeiten offen stehen würden… Welche Handlungen würde dazu führen, dass der Andere Sie so wahrnimmt, wie Sie das in Ihrem Wunschbild beschrieben haben?
- Wenn Sie Ihr Wunschbild sehen. Was könnten Sie tun, damit Sie dieses Wunschbild erreichen?

Materialien / Hilfsmittel

Hilfsmittel zur Coaching Methode Selbstbild, Fremdbild, Wunschbild

{fastsocialshare}

AlternativenAuswahl

Coaching Methode: Mind-Map: Alternativen auswählen

Wenn mehrere alternative Handlungen oder alternative Ziele zur Auswahl stehen, dann kann hiermit von dem Klienten eine systematische Vorauswahl getroffen werden. Dieses Auswahlverfahren ersetzt zumeist eine genaue Überprüfung der Auswahlentscheidung. Der Klient findet schnell eine Lösung.

Fragestellung / Vorgehen

Zu alternativen Handlungsmöglichkeiten / alternativen Zielen

Das Ziel muss vorher geklärt sein. (Wenn es um alternative Handlungsweisen geht)
Die Ausgangslage muss geklärt sein.
Ressourcen, die zur Zielerreichung zur Verfügung stehen, können später untersucht werden.
Vorher hat ein Brainstorming oder ähnliches stattgefunden, das zu einer Sammlung von Alternativen geführt hat.
Es dürfen nicht zu viele Alternativen vorliegen – sonst klappt das Instrumentarium nicht.

1. Schritt: Alternativen in ein Mind-Map schreiben

2. Schritt: Zu jeder Alternative zwei Stränge:

Dafür: Was spricht dafür?
Dagegen Was spricht dagegen?

3. Schritt: Alternativen verwerfen

Welcher der Alternativen sieht umsetzbar und zielführend aus?
Welche der Alternativen ist nur schwer umsetzbar – oder nicht zielführend?
Nicht umsetzbare Alternativen werden gestrichen

4. Schritt: Ausgewählte Alternativen weiter verarbeiten

Hilfsmittel / Materialien

Methode zur Auswahl und Bewertung von Alternativen im Coaching

{fastsocialshare}

Rollenklarheit

Coaching Methode: Rollen klären

Verstehen, welche Aufgaben und welche Handlungserwartungen an Rollen gestellt werden.
- Von sich selbst
- Von Anderen
eventuell mit zwei Personen erstellen und dann nach Übereinstimmungen und Unterschieden suchen.

Fragen / Vorgehen

1. Schritt:
- Was ist eine Rolle?
2. Schritt:
- Was verstehen wir unter Aufgaben?
- Was verstehen wir unter Verhalten?
3. Schritt:
- Klient schreibt auf, welche Aufgaben nach seinen Erwartungen / Ansichten zu einer Rolle gehören.
- Klient schreibt auf, welches Verhalten nach seinen Erwartungen / Ansichten zu einer Rolle gehören.
4. Schritt
- Klient schreibt auf, welche Aufgaben nach der Meinung von Anderen zu einer Rolle gehören.
- Klient schreibt auf, welches Verhalten nach seiner Meinung zu einer Rolle gehört.

Je nach Situation kann die Methode nach Punkt Schritt 3. beendet werden. Dann ist auch der zweite Teil der Zeichnung nicht notwendig.
Schritt 4 ist immer sinnvoll, wenn der Klient eine Differenz zwischen seinen Rollenerwartungen und den Rollenerwartungen von anderen Menschen (Kollegen, Chefs, Partnern, etc.) empfindet.
Die Übung kann auch im Konfliktmanagement sinnvoll sein, wenn zwei Menschen diese Übung unabhängig voneinander machen und dabei Erwartungsunterschiede sichtbar werden, die zu Konflikten führen können.

Material / Hilfsmittel

Hilfmittel im Coaching zum Klären der Rollenerwartungen an einen Menschen

{fastsocialshare}

RolleVerhaltenserwartung

Rolle: Aufgabe- und Verhaltenserwartungen bewerten

Ziel dieser Methode ist es, dem Klienten bewusst zu machen, welche Aufgaben und Verhaltensweisen, die an Rollenanforderungen gestellt werden, von ihm positiv und welche anders empfunden werden.

Die negativen Aufgaben / Verhaltensanforderungen werden anschließend zusätzlich sortiert nach:

„Weiter aushalten“ (Take it)
„Einstellung ändern“ (damit können wir weiter arbeiten)
ablehnen (Aufgabe, Verhaltenserwartung an den Anforderungssteller zurück geben)

Fragen / Vorgehen

1. Schritt:
- Aufgaben, die mit einer Rolle verbunden, sind aufschreiben (andere Übung)
2. Schritt
- Klient bekommt die Vorlage und sortiert hier die Aufgaben und Verhaltensweisen nach Lieben, Ertragen, Hassen
3. Schritt
- Der Klient klärt, wie er mit den Aufgaben die er hasst, umgehen möchte. Entsprechend dieser Vorgaben wird damit weiter gearbeitet.

Materialien / Hilfsmittel

Rolle und erwartetes Rollenverhalten im Zusammenhang erkennen im Coaching

{fastsocialshare}

Beziehungsspiel

Coaching Methode: Beziehungsspiel

In Beziehungen die Gemeinsamkeiten und die Unterschiede in den Erwartungshaltungen erkennbar machen.
Relevant für jede Beziehung zum Erkennen von Konfliktpotential.
Diese Aufgabe kann mit dem Klienten alleine gelöst werden. Ideal ist es natürlich, wenn der Beziehungspartner dabei ist und sich selber äußern kann.

Fragen / Vorgehen

1. Schritt:
- komplett aufzeichnen
2. Schritt:
- Was erwarten Sie in der (Arbeits-)beziehung von ….?
- Was erwartet … in der (Arbeits-)beziehung von Ihnen?
- Was erwarten Sie gemeinsam (beide) in dieser Beziehung?
3.Schritt: Skalierung
- Markieren Sie bitte die drei Punkte, die Ihnen besonders wichtig sind.
- Markieren Sie bitte die drei Punkte, die … besonders wichtig sind.
- Markieren Sie bitte die drei Punkte, über die Sie die häufigsten Auseinandersetzungen haben.

Material / Hilfsmittel

In Beziehungen die Gemeinsamkeiten und die Unterschiede in den Erwartungshaltungen erkennbar machen.

{fastsocialshare}

PersKurzbeschreibung

Coaching Methode: Personen-Kurz-Beschreibung

Eine einzelne Person wird von dem Klienten anhand wesentlicher Kriterien beschrieben.
Diese Personenbeschreibungen können anschließend zur Analyse von Beziehungen, Beziehungsnetzwerken, etc. verwendet werden.

Fragen / Vorgehen

1. Schritt:
- Alle Personen benennen, die in der aktuellen Situation, oder für die aktuelle Zielerreichung wichtig sind. (Stakeholder)
2. Schritt
- Für jede der Personen eine solche Personenkurzbeschreibung ausfüllen.
3. Schritt
- Mit einer Netzwerktechnik weiter arbeiten.

Hilfmittel / Materialien

Eine einzelne Person wird von dem Klienten anhand wesentlicher Kriterien beschrieben.

{fastsocialshare}

Beziehungsnetz

Coaching Methode: Beziehungsnetz

Beziehungen zwischen einzelnen Menschen in einem Zusammenhang darstellen.
Berücksichtigt werden die Kriterien
- Zusammengehörigkeit in einem Team / Familie / Freundeskreis …
- Nähe zueinander
- Persönliche Beziehungen, insbesondere:
  - Konflikte
  - Freundschaften, Liebesbeziehungen

Fragen / Vorgehen

1. Schritt:
- Ausfüllen der Personenkurzbeschreibungen, benennen der Personen und benennen der Figuren, oder benennen der entsprechenden Tiere
2. Schritt
- Die Figuren so zusammenstellen, wie sie in einer Gruppe zusammen gehören.
- Die Entfernung der Figuren repräsentiert dabei die persönliche Nähe, in der die Personen zueinander stehen.
- Kennzeichnen mit dem Stift (schwarzen Farbe) durch Umkreisung, wer zu einem gemeinsamen Kreis gehört
- Mit roten Linien werden die Personen verbunden, die einen Konflikt miteinander haben.
- Mit blauen Linien werden die Personen verbunden, die eine private Freundschaft oder Ähnliches verbindet.

Materialien / Hilfsmittel

Kann einfach auf einem Flip-Chart oder Pin-Board gezeichnet werden.
Besser: Holzfiguren oder Tiere repräsentieren die Personen
Noch besser: Tiere und Personenkurzbeschreibung unter der Figur
Stifte mit verschiedenen Farben: Hier: Schwarz: Teamzugehörigkeit, Rot: Konflikt, Blau: persönliche Freundschaft

Coaching Methode: Beziehungen zwischen einzelnen Menschen in einem Zusammenhang darstellen.

{fastsocialshare}

RessourcenVergangenheit

Coaching Methode: Ressourcen der Vergangenheit

Ressorcen, die in der Vergangenheit vorhanden waren, wieder aktivieren und für zukünftige Tätigkeiten nutzbar machen.

Fragen / Vorgehen

1. Teil (Blick zur Gegenwart)
Sehen Sie sich das Bild der Gegenwart noch einmal an. Wie fühlen Sie sich? Was sehen Sie? Was sagen Sie sich selber in der Gegenwart? Was sagen Andere zu Ihnen?
2. Teil (Zurück gehen)
- Drehen Sie sich herum. Sehen Sie diese Rot-Linie. Das ist der Weg zurück in die Vergangenheit. Wir gehen jetzt langsam diesen Weg zurück. Schließen Sie bitte die Augen und konzentrieren Sie sich auf das, was mit Ihnen in diesen Jahren passiert ist.
- Nach ein paar Schritten stehen blieben. Wir sind jetzt ein paar Monate in Ihre Vergangenheit gegangen. Was hat sich ereignet. Was ist Ihnen passiert? Waren Sie zufrieden mit …? Was hat Sie zufrieden gemacht?. Wir gehen jetzt weiter zurück. Lassen Sie die Augen geschlossen. Konzentrieren Sie sich ganz auf das was in Ihnen in Bezug auf … passiert ist. Erzählen Sie mir welche Ereignisse Sie sehen.
- Nach ein paar weiteren Schritten: Wir sind jetzt ein Jahr (mehrere Jahre, im Jahr) angekommen. Was ist passiert? Was hat sich verändert? Waren Sie zufrieden? Was hat Sie zufrieden gemacht? Was hat dazu geführt, dass Sie …? Was hat Ihnen geholfen so zu sein …? Was hat Sie motiviert?
3. Teil (Drehen der Zeit – Gegenwart und Vergangenheit vertauschen)
- Wir sind jetzt im Jahr … angekommen. In der Zeit, wo sie … konnten. Wo sie ... waren. Öffnene Sie bitte die Augen und sehen Sie sich dieses Bild an, das Sie einmal waren. Wie fühlen Sie sich? Was hat sich verändert?
- Jetzt drehen Sie sich bitte um. Sehen Sie das Bild dahinten (der Gegenwart), das Jahre zurück liegt.
- Wie fühlt sich das an, wenn Sie dieses Problem so lange gelöst sehen? Was habe Sie getan um dieses Problem zu lösen? Hat sich die Arbeit gelohnt.

Material / Hilfsmittel

2 Flip-Charts, Klebeband oder Kordel und einen großen Raum.
Bei mir durch das Büro und den Seminarraum spielen
Alternativ zur Kordel geht auch Klebeband
Gegebenenfalls Audio-Recorder zur Aufzeichnung des Weges.

Coaching Methode: Ressourcen die aus der Vergangenheit wieder aktivieren

{fastsocialshare}

StakeholderMatrix

Coaching Methode: Stakeholder Matrix

Die Stakeholder Analyse stammt aus dem klassischen Projektmanagement. Hier werden alle Menschen, die für ein Projekt wichtig sind, analysiert. Diese Fragestellung ist auch für einen Coache häufig wichtig, wenn er eine Verhaltensänderung vornimmt oder eine geschäftliche Entscheidung im Business Coaching treffen muss. Die Stakeholder Matrix ist ein Instrumentarium, das ihn dabei unterstützt.

Ermitteln der Betroffenen, Interessierten und Beteiligten (Stakeholder)
Bewerten von:
- Betroffenheit
- Einflussstärke
- Einflussrichtung
Entwickeln von Maßnahmen, um die Stakeholder positiv zu beeinflussen

Fragen / Vorgehen

1. Schritt:
- Klient benennt die Stakeholder
2. Schritt
- Klient bewertet die Stakeholder nach den drei Kriterien
3. Schritt
- Mit dem Klienten werden Maßnahmen entwickelt, um die aktuelle Einschätzung zu verbessern.

Material / Hilfsmittel

Coaching Methode Stakeholder Matrix

{fastsocialshare}

ZeitstrahlEreignis

Coaching Methode: Zeitstrahl, Ereignisse und Gefühle

Bei der Bewältigung und dem Verstehen einer gemeinsamen Vergangenheit ist es zunächst wichtig, dass die Parteien wissen, welche Ereignisse in der Vergangenheit stattgefunden haben. Das alleine ist schon schwierig, weil zwei oder mehrere Menschen Ereignisse sehr unterschiedlich wahrnehmen. Zum Teil so unterschiedlich, dass ein Ereignis, das in der der Vergangenheit objektiv stattgefunden haben muss, in der Beschreibung der Parteien keine Gemeinsamkeiten erkennbar sind.
Diese Übung dient in ihrer ersten Phase dazu, den Teilnehmern zu helfen, sich auf ein gemeinsames Ereignis zu verständigen.
Der zweite Teil der Übung dient dann dazu, über ihre eigenen Gefühle, im Zusammenhang mit den Ereignissen zu reflektieren, als auch die Gefühle der anderen Teilnehmer dargestellt zu bekommen. Das ganze hilft einem gemeinsamen Verständnis.
Die Gefühle, die hier darstellt werden, sollten nach der jeweiligen Situation variiert werden. Auf der unten stehenden Skala können auch zwei verschiedene Gefühle einer Person dargestellt werden. Z.B. Stimmung und Motivation.

Hilfsmittel

Flip Chart
bei komplexeren Themen: Pin-Board.

Zeitstrahl Ereignis Emotion

{fastsocialshare}

Agile Methode: Team Development - Mindestvoraussetzung

Ein zentraler Punkt aller agilen Ansätze ist die Entwicklung des Teams. Es geht also darum, dass die Leistungsersteller effektiver und effizienter zusammen arbeiten.

Der Aufwand, der dafür betrieben wird ist sehr groß. Ein Agil Master (Scrum Master), der das Team hierbei unterstützt, Retrospektiven in denen die Verbesserungen für die nächsten Sprints erarbeitet werden, Taks Boards, Daily Standups, Product Owner, die dem Team jederzeit als Ansprechpartner zur Verfügung stehen.

Alle diese Maßnahmen und viele Andere zielen darauf auf die Team Velocity im Zeitverlauf zu verbessern.

Wichtig ist hierbei: Im Zeitverlauf.

Menschen als Individuen müssen ihre Arbeitsweise aufeinander abstimmen, Vertrauen zu einander fassen und ein Wir-Gefühl entwickeln wenn sich das Team als Ganzes weiter entwickeln soll.

Die Mindestvoraussetzung damit eine Teamentwicklung überhaupt stattfinden kann, besteht darin, dass ein Team über mehrere Zeitzyklen (also Sprints) zusammen bleibt und innerhalb dieser Zeitzyklen einen Entwicklungsprozess durchlaufen kann. Eine positive Veränderung von Effektivität und Effizienz ist er nach einiger Zeit zu erwarten.

Diese Erkenntnis ist nicht neu und hat auch nicht erst durch die Einführung eines agilen Managements eine Bedeutung bekommen. Das Phasenmodell von Tuckman aus dem Jahre 1965 zeigt uns bereits einen solchen Entwicklungsprozess. Auch die Erkenntnis, das der Teamentwicklungsprozeß wieder von vorne beginnt, wenn neue Menschen in ein Team kommen, ist nicht wirklich neu.

Um so erstaunlicher ist es, dass viele Unternehmen, agiles Management einführen, aber bei dem Einsatz ihrer Mitarbeiter ihren Entwicklerteam aus 20% Mitarbeiter, Zeitpersonalmitarbeiter, die jederzeit ausgetauscht werden können, Testern, die nur für ein paar Tage im Monat für ein Projektarbeiten, etc. zusammen stellen.

Diese Form der Personalplanung und Mitarbeitersteuerung verhindert jegliches Team Development. Die Vorteile, die sich das Unternehmen aus der Einführung eines agilen Managements verspricht können aufgrund diese Personalpolitik höchsten teilweise entstehen, denn die Mindestvoraussetzungen für ein Team Development sind in solchen Unternehmen einfach nicht gegeben.

Entsprechend sind auch die meisten Investitionen, die in eine Veränderung des Managementsytem hin zum agilen von vorne herein "sunk investment".

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

CoachingMethRetros

Agile Methode: Coaching Methoden für die Retrospektive

Die Rolle des Agil Master, bzw. des Scrum Masters beinhaltet das Scrum Team, bzw. Umsetzungsteam zu Coaching und es so zu einer höheren Leistungsfähigkeit zu motivieren. In der Retrospektive schaut das gesamte Team zurück auf seine Arbeit. Viele Methoden, die ursprünglich aus dem Coaching kommen, finden in der Retrospektive Anwendung.

Die nachfolgende ungeordnete Liste verweist auf Methoden, die im Coaching verwendet werden, aber auch in der Retrospektive des Agilen Managements unterstützend eingesetzt werden können.

Einsicht / Änderung / Erwartung
Einsichten
Coaching Methode: Fakten <-> Subjektive Wahrnehmung -> Diskussion -> Handeln
Coaching Methode: Zeitstrahl, Ereignisse und Gefühle
Im Zusammenhang mit einer Retrospektive können Situationen auftreten, in denen das Team erkennt, dass sie in die Vergangenheit besser gearbeitet haben. Diese Coaching Methode dient dazu, diese Ressourcen, die dem Team früher zur Verfügung standen, wieder zu aktivieren. Coaching Methode: Ressourcen der Vergangenheit.
Die Beziehungen inner- und außerhalb eines agilen Teams sind für den Erfolg des Teams von großer Bedeutung. Die Coaching Methode: Beziehungsnetzwerk Coaching Methode: Beziehungsnetzwerk hilft, diese Beziehungen zu analysieren.
In jedem Team gibt es bestimmte Rollen, die von einzelnen Teammitgliedern - mehr oder weniger bewusst - wahrgenommen werden. Die Rollen sind immer mit Erwartungen verbunden. Die Coaching Methode: Rollen klären kann einem einzelnen Teammitglied helfen, eine Rollenklarheit zu erreichen. Sie kann aber auch von einem Team verwendet werden, um Rollenkonflikte zu vermeiden oder deren Ursachen zu analysieren.
Die Coaching Methode: Selbstbild / Fremdbild / Wunschbild, kommt aus dem Einzelcoaching. Sie wird auch genutzt, wenn sich bei einem Team Abweichungen zwischen Selbstbild, Fremdbild und Wunschbild zeigen.
Für das Coaching von Einzelpersonen wurde eine Methode entwickelt um die Ressourcen zu erkennen, die zur Zielerreichung zur Verfügung stehen. Diese Analyse kann auch genutzt werden, wenn ein Team gemeinsam erarbeiten möchte, welche Ressourcen ihm zur Verfügung stehen könnten. Dafür müssen die Fragestellungen etwas umformuliert werden. Coaching Methode: Ressourcen erkennen.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Retrospektive

Die Retrospektive ist der dritte wichtige Steuerkreis des Agilen.

Durch die Arbeit des Product Owner werden die Anforderungen der Stakeholder gesteuert und als Aufgaben an das Leistungserstellungsteam weitergereicht.
Durch das Review werden die Ergebnisse der Leistungserstellung überprüft und gesteuert.
Über die Retrospektiven wird der Leistungserstellungsprozess des Teams von ihm selbst überprüft und gesteuert.

Im Verlauf der Retrospektive untersuchen die Leistungsersteller, incl. Scrum Master und Product Owner, den Prozess, der angewendet wurde, um das Produkt zu erstellen. Wir befinden uns auch hier in dem typischen Plan-Act-Check Vorgehen der agilen Methoden.

In der Retrospektive wird überprüft, ob der Prozeß der Leistungserstellung verbessert werden kann und wie das möglich ist. Dann wird der Plan in dem nächsten Sprint umgesetzt. Mit der nächsten Retrospektive erfolgt die Überprüfung des Planes. Die Retrospektive gehört damit auch zu den Planungsinstrumentarien des agilen Vorgehens.

Während der Retrospektive werden Verbesserungen erarbeitet. Diese werden dann nach der Retrospektive im nächsten Teil des Leistungserstellungsprozesses umgesetzt.

Die Retrospektive bietet die Möglichkeit für eine kurze Zeit aus dem Druck der Leistungserstellung auszusteigen, zu verharren und über das Getane in Ruhe zu reflektieren. In dieser Zeit denkt das Team darüber nach, was es getan hat. Es reflektiert, diskutiert und überprüft so seine Arbeitsweise, Arbeitsmittel und den Prozess in dem es arbeitet, die Kommunikation untereinander und mit den Stakeholdern. Außerdem überprüft es die Werkzeuge, die es verwendet, die Nützlichkeit der Artefakte, etc.

Die Retrospektive findet nach jeder Timebox statt und nicht erst am Ende des Leistungserstellungsprozesses. Das gibt dem Team die Möglichkeit, Verbesserungen frühzeitig in den Leistungserstellungsprozess einfließen zu lassen. So ergeben sich die Möglichkeiten, im nächsten Sprint mit den Veränderungen zu experimentieren. Basierend auf diesen Erfahrungen kann der Leistungserstellungsprozess kontinuierlich verbessert werden.

Möglicher Ablauf einer Retrospektive

Es gibt keinen festen Ablauf einer Retrospektive. Der hier beschriebene Ablauf zeigt lediglich ein mögliches Vorgehen.

Gerade am Anfang, wenn ein Team dabei ist sich zu bilden, gibt es eine Vielzahl an Themen über die gesprochen werden muss. Jeder der Teilnehmer hat viele Themen, die ihm am Herzen liegen und die er aus seiner persönlichen Perspektive betrachtet haben möchten. Das Review liegt in der Verantwortung des Product Owners. Die Retrospektive in der Verantwortung des Scrum Masters. Wie wir schon bei dem Review gesehen haben, bedeutet das aber nicht, dass diese Rolleninhaber die Veranstaltung leiten müssen. Insbesondere bei der Retrospektive ist es extrem wichtig, dass der Scrum Master die Retrospektive nicht dominiert. Jeder Beteiligten muss sich hier voll einbringen können.

Damit hat jede Besprechung zu Retrospektive die besten Chancen genauso zu verlaufen, wie jede andere schlecht vorbereitete Besprechung. Chaotisch, konfliktträchtig und ergebnislos. Zu jeder Retrospektive gehört also eine entsprechende Vorbereitung.

Eine Themensammlung, eine Agenda, ein zeitlicher Ablauf, die Fakten zu den jeweiligen Themen, etc. sollten im Vorfeld der Retrospektive gesammelt werden - oder spätestens am Anfang dieser Besprechung.

Retrospektiven sind zeitlich begrenzt und werden eher kurz gehalten. Es kann also sinnvoll sein, eine Retrospektive auf einen bestimmten Focus, der von dem Team als "besonders regelwert" empfunden wird, zu beschränken. - Allerdings besteht dann auch das Risiko, dass die Menschen, die innerhalb des Teams dominant sind, die Themen bestimmen und die Fragestellungen der anderen Teilnehmer nicht berücksichtigt werden.

Ein möglicher Ablauf könnte so aussehen:

Den Focus bestimmen, z.B. durch eine vorherige Themenauswahl, Punktwertverfahren zum Abstimmen über Themen, Agenda oder sonstigem.
Übung auswählen, die die Teilnehmer in das Thema herein bringt, eine entsprechende Atmosphäre schafft und zum Nachdenken anregt. Beispiele für solche Übungen finden sich in den Moderationsverfahren für große Gruppen. Ein Brainstorming, Ergebnis Zeitstrahl, Emotionaler Seismograph und ähnliche Methoden können hier unterstützen.
(Objektive) Daten sammeln, als Basis für die weitere Diskussion. Der Begriff Objektive ist hier bewusst eingeklammert. Die Wahrnehmung eines Sachverhaltes kann bei unterschiedlichen Teilnehmern durchaus sehr unterschiedlich sein. Auch die Interpretation "objektiver Daten" kann bei den Teilnehmern unterschiedlich sein. Viel wichtiger ist es, zunächst einmal die Unterschiede der Wahrnehmung heraus zu arbeiten. Die Behauptung, dass "dies objektive Daten sind", wird zu häufig benutzt, um jede Diskussion zu verhindern und die eigen Ansicht unangreifbar zu machen.
Subjektive Wahrnehmung der Teilnehmer und das subjektive Erleben der Teilnehmer in Bezug auf die objektiven Daten transparent machen und nach Möglichkeit eine gemeinsame Wahrnehmung erreichen.
Verbesserungsmöglichkeiten, bzw. Änderungsmöglichkeiten diskutieren und eine Auswahl dieser Verbesserungsmöglichkeiten treffen.
Die Verbesserungsmöglichkeiten schriftlich fixieren und dann in den nächsten Prints umsetzen.

Eine gute Möglichkeit, den ganzen Prozess für alle Teilnehmer transparent zu machen, findet sich in der Methode Fakten und Konsens. Damit sich das Team die Entwicklung über den Sprint vergegenwärtig und die Gefühle, die innerhalb dieses Sprints aufgrund der Ereignisse gegenseitig verdeutlicht, kann die Methode Ereignisse und Gefühle genutzt werden. Viele der Coaching Methoden, die sich auf dieser Web-Site finden, können für die Gestaltung der Retrospektive situationsabhängig genutzt werden. Die meisten Methoden sind zwar für ein Einzelcoaching entwickelt worden, lassen sich aber leicht auf Gruppen übertragen.

Ein sehr einfacher, aber wirkungsvoller Ablauf für die Retrospektive kann in vier Fragen bestehen:

Was ist gut gelaufen? Was hat funktioniert?
Was ist schlecht gelaufen? Was hat nicht funktioniert?
Was wollen wir beibehalten?
Was soll wie geändert werden?

Tabelle Gut Schlecht Behalten Verändern

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Kosten

Agile Methode: Kosten ermitteln

Auf den ersten Blick scheinen Kosten in der agilen Produktentwicklung nur eine untergeordnete Rolle zu haben, während sie im klassischen Projektmanagement sehr dominant sind. Dieser Eindruck täuscht allerdings. Wenn wir uns mit der Priorisierung von Anforderungen beschäftigen, dann basiert der Wert einer Funktionalität auf der klassischen kaufmännischen Sichtweise:

Wert = Nutzen - Aufwand.

Der Aufwand wird dabei in Story Points, Idealtagen und ähnlichem geschätzt. Irgendwann innerhalb der Planung, wird dann ein Zusammenhang zwischen einem Personentag und den Story Points, oder anderen Schätzgrößen hergestellt.

Der nächste Schritt von dem Personentag zu den Personentagessätzen ist dann nur noch sehr klein - und damit sind wir wieder in der üblichen Welt der altbekannten Projektkostenrechnung angekommen.

Die Kosten für eine Timebox sind sehr leicht zu berechnen.

Die Dauer einer Timebox ist bekannt und bleibt über die Dauer der Produktentwicklung fix.
Das Team (incl. Product Owner und Scrum Master) bleibt (im Idealfall) über den gesamten Produktentwicklungsprozess zusammen.
Alle Mitarbeiter im Team sind der Produktentwicklung zu 100% ihrer Arbeitszeit zugewiesen.

Damit können die Personalkosten innerhalb einer Timebox leicht ermittelt werden. Die altbewährte Berechnung der Personenstunden kann hier genutzt werden. Über die Zahl der geplanten Timeboxes ergibt sich die Höhe der Gesamtkosten.

Wenn die durchschnittliche Höhe der Story Points pro Timebox als Team Velocity bekannt ist, können auch die erwarteten Kosten pro Story Point errechnet werden.

Die Kostenberechnung ist also recht einfach, soweit primär Mitarbeiterkosten entstehen. Wenn das Produkt, das erstellt werden soll, zusätzlich teure Materialen oder Dienstleistungen benötigt, die bei den einzelnen Funktionalitäten variieren, dann wird die Berechnung der Kosten wesentlich schwieriger.

Nehmen wir einmal die unspezifische Anforderung: "Wir brauchen ein Auslieferungsfahrzeug."

Wenn wir klassisch vorgehen würden, dann würden wir jetzt genau festlegen, wie das Fahrzeug beschaffen sein könnte und dann berechnen lassen, wie hoch die Materialkosten sind. Wir könnten auch verschiedene Kostenvoranschläge einholen, die basierend auf einem genauen Pflichtenheft erstellt werden. Die Unsicherheiten und Ungenauigkeiten und der Aufwand bei der Erstellung und Änderung solcher Berechnungen sind ja hinlänglich bekannt. Ich werde sie hier also nicht erörtern. Wir erhalten als Kalkulationsbasis eine Zahl, die auf der Multiplikation von Wahrscheinlichkeiten mit Wahrscheinlichkeiten basiert. Die genauen Kosten bleiben bis zur Fertigstellung des Daches unsicher.

Wenn wir agil vorgehen, dann steht diese unspezifische Anforderung zunächst einmal im Product Backlog und wird dann genauer spezifiziert, wenn wir wissen, wie genau das Fahrzeug beschaffen sein soll und wie sich die Materialpreise entwickelt haben. Erst dann erfolgt eine genaue Beschreibung. Danach erfolgt eine Kalkulation der Kosten, die wesentlich weniger unsicher ist, als die "frühe Kalkulation". Die genauen Kosten kennen wir auch in dieser Situation erst nach der Fertigstellung des Daches.

Was verändert sich durch das agile Vorgehen?

Kalkulation Kosten Agil Nicht-Agil

In dem klassischen Vorgehen wird, bevor mit dem Projekt begonnen wird, genau spezifiziert und berechnet, was gebraucht werden wird. Die Kosten sind - mit den üblichen Unsicherheiten bekannt. Im Verlauf des Projektes erkennen wir, dass wir etwas anderes brauchen. Spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Dann erkennen wir, dass wir etwas anderes brauchen, spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Und so weiter. In dem letzten Zyklus spezifizieren und kalkulieren wir genau und erstellen die Funktionalität. Ist sie fertig, kennen wir die Kosten genau.

Im agilen Vorgehen leben wir mit der Unsicherheit, berechnen, spezifizieren erst kurz vor der Leistungserstellung mit sehr hoher Sicherheit. Erst wenn die Funktionalität fertig ist, kennen wir sie genau.

Welches Vorgehen ist jetzt besser?

Bei dem klassischen Vorgehen, ist die Unsicherheit kleiner, da wir zumindest eine "grobe Richtung" der Kosten haben. Dafür ist der Aufwand zu Anfang größer.
Im Verlauf des klassischen Vorgehens ändern wir die Spezifikation / Kostenschätzungen mehrmals mit zusätzlichem Aufwand.
Bei dem agilen Vorgehen ist die Unsicherheit größer, denn es gibt noch nicht einmal eine "grobe Richtung". Es entsteht kein Aufwand.

Die letztendliche Spezifikation ist in beiden Fällen sehr ähnlich. Die Endkosten sind identisch. Das agile Vorgehen ist mit weniger Aufwand und einer größeren Unsicherheit verbunden.

Aber: Ist das "agile Vorgehen" genau wie in dem Bild oben beschrieben?

Im Product Backlog wird jede Anforderung in eine Hierarchie gebracht und der Aufwand wird geschätzt. Lediglich die Schätzung ist nicht so genau, wie in dem klassischen Vorgehen.
Erfolgt eine Änderung einer Anforderung, dann wird das Product Backlog geändert. Im agilen Vorgehen reden wir von Backlog Pflege. Im Rahmen dieser Backlog Pflegen, erfolgt natürlich auch eine "Neuschätzung" des Aufwandes.
Die Änderungen im Product Backlog erfolgen in Abstimmung des Product Owners mit den Stakeholdern und den Leistungserstellern.

Und schreibt das "klassische Projektmanagement" (nach PMI, Prince2, GPM-IPMA) das Vorgehen vor, dass in dem Bild oben beschrieben wurde?

Die Anforderungen der Stakeholder werden in einer Leistungsbeschreibung erfasst. Hier folgt eine Hierarchisierung der Ziele und in der Planung ein Schätzung des Aufwandes, der notwendig ist, um diese Ziele zu erreichen.
Der Aufwand der Anforderungen wird im Verlauf des Planungsprozesses geschätzt. Die Anweisung in allen Systemen: "so genau wie nötig, so grob wie möglich". Es wird immer empfohlen bei frühen Schätzungen eine "von ... bis" Spanne anzugeben.
Eine Änderung der Anforderungen und des Planes ist jederzeit möglich, sofern der Änderungsprozess eingehalten wird. Der besagt: Änderungen müssen mit den Stakeholdern besprochen und von den Auftraggebern genehmigt werden. Ein Änderungsantrag beinhaltet: Beschreibung der Änderung, Beschreibung der Folgen der Änderung in Bezug auf Kosten, Budget, Risiken, etc...

Wie unterschiedlich sind die Vorgehensweisen also wirklich? Liegen die Probleme, die in dem klassischen Vorgehen liegen, wirklich in den Projektmanagement-Methoden begründet? Und ist die Problemlösung, die im agilen Vorgehen liegt, so unterschiedlich von dem "klassischen Projektmanagement"?

Oder sind die Probleme in der Interpretation des Vorgehens zu suchen? Und besteht dann nicht das Risiko, dass genau die gleichen Interpretationsprobleme bei der Anwendung der agilen Methoden erneut gemacht werden?

Die Frage, welches Vorgehen jetzt besser ist, bleibt weiterhin bestehen.

Die wesentlichen Fragen reduzieren sich auf die klassische Abwägung, die bei Schätzungen immer im Mittelpunkt stehen:

Wie sicher ist eine Vorhersage?
Wie dringend brauche ich eine sichere Vorhersage?
Mit welchem Aufwand kann ich die Sicherheit der Vorhersage erhöhen?

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: Pressemitteilung

User Stories sind das am häufigsten verwendete Verfahren zur Erstellung von Leistungsbeschreibungen. Eine gute Alternative, wenn die Stakeholder mit dem Erstellen von User Storys Schwierigkeiten haben, besteht darin sie eine kurze Pressemitteilung schreiben zu lassen.

Die Aufgabenstellung an die Anforderer:

"Schreiben Sie eine Pressemitteilung für die Einführung des neuen Releases für die Anwender. Kommunizieren Sie alles wissenswerte über das neue Release auf maximal einer halben Din A4 Seite."

Eine solche Pressemitteilung ist länger als eine User Story. Die Auftraggeber haben damit die Möglichkeit mehr Text zur Beschreibung der von ihnen gewünschten Ergebnisse zu verwenden. Außerdem werden sie nicht in den rechte engen Rahmen der Regeln gedrückt, der für die Erstellung von User Stories vorgegeben ist. Für viele Anforderer ist das Erstellen vom Pressemitteilung damit leichter.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Review

Agile Methode: Review

Die Reviews sind ein fester Bestandteil der agilen Methoden. Sie sind das wichtigste Steuerungsinstrument der Produktentwicklung.

Nach jeder Timebox oder wie in Scrum am Ende jeder Timebox wird ein Review durchgeführt, bei dem die Ergebnisse der Arbeit von den Stakeholdern begutachtet werden.

Basierend auf dieser Begutachtung findet eine Überarbeitung des Product Backlogs statt. Anderes formuliert: bei jedem Review werden die Anforderungen neu betrachtet, verfeinert, verändert und den Gegebenheiten angepasst. Das Review wird damit für alle Beteiligten zur wichtigsten Lernschleife.

Die Stakeholder erhalten Einblick in den realen aktuellen Zustand des bisher fertigen Produktes. Sie erleben konkret die Weiterentwicklung des Produktes. Sie sehen und erleben, wie sich das Produkt durch die Arbeit in der Timebox entwickelt hat.

Sie sehen also nach jeder Timebox die Entwicklung an dem Produkt selber. Das konfrontiert sie mit dem direkten Produkt und dessen Entwicklung. Dieses direkte Erleben des Produktes verhindert böse Überraschungen, erhöhte Erwartungen. Die Stakeholder sehen Fehlentwicklungen unmittelbar und können diese verhindern.

Aus diesem Erleben heraus geben sie ein unmittelbares Feedback und verändern das Product Backlog innerhalb dieses Reviews aufgrund des unmittelbar erlebten.

Auch die Leistungsersteller kommen in einen direkten, persönlichen Face to Face Kontakt zu den Stakeholdern und erhalten ein entsprechend direktes Feedback von den Menschen, für die das Produkt entwickelt wird. Das fördert das gegenseitige Verstehen und schafft das Gefühl für "richtige Menschen" zu arbeiten und diese Menschen als solches zu Verstehen und nicht nur als "abstrakte" Kunden oder "diffuse Gruppe" von Nutzern, die wärend der Produktentwicklung niemals in reale Erscheinung treten.

Die Teilnehmer des Reviews

Das Review lebt von den Teilnehmern und der Interaktion zwischen ihnen. Ohne diese Teilnehmer und zwar Vertreter aller Gruppen, die hier genannt werden, ist ein Review mehr oder weniger wirkungslos. Oder anders formuliert: wie auch immer diese Treffen genannt werden, es ist kein Review im Sinne der agilen Leistungserstellung.

Teilnehmer am Review

An dem Review sollten alle an der Leistungserstellung beteiligten teilnehmen. Also insbesondere alle Mitglieder des Entwicklerteams und der Product Owner. Natürlich auch der Scrum Master, wenn wir in einer Scrum Organisation sind. Das Review ist die Veranstaltung des Product Owners. Er leitet das Review. Die Präsentation der Inkremente sollte nach Möglichkeit von allen Leistungserstellern übernommen werden. Es sind interne Stakeholder, wenn die Produktentwicklung von einer Auftrag nehmenden Organisation durchgeführt wird. Hier sind insbesondere die Stakeholder erwünscht, die für die Finanzierung der Produktentwicklung zuständig sind und die Personen, die fachlich für die Ergebnisse mitverantwortlich sind.

Die externen Stakeholder sind zunächst einmal die Vertreter der Auftraggeber die eine finanzielle Verantwortung haben und die Fachabteilungen, in deren Auftrag das Produkt entwickelt wird. Wenn das Produkt für die Kunden des Auftraggebers hergestellt wird, sollten auch diese Endanwender um ein Feedback gebeten werden. Wenn es weiter externe Stakeholder gibt, dann kann es nützlich sein auch Vertreter dieser Gruppe einzuladen.

Was und wie sollte präsentiert werden?

In dem Review wird das fertige Produktinkrement vorgeführt. Ziel ist es den Teilnehmern ein "Look and Feel" Gefühl des Produktes zu vermitteln. Eine Powerpoint Präsentation verhindert genau dieses Gefühl. Auch eine umfangreiche Präsentation der kaufmännischen Entwicklung des Leistungserstellungsprozesse, abstrakt und mit vielen Charts - wie sie bei den üblichen Präsentationen "Projektleiter präsentiert vor dem Management" Besprechungen gemacht wird, wiederspricht der Idee eines Reviews.

Ziel eines Reviews ist eine intensive Diskussion der Teilnehmer über die Leistungseigenschaften an dem realen Objekt.

Abnahme durch den Product Owner

Der Product Owner bekommt von dem Team das Inkremen, das der Definition of Done entspricht, geliefert. Er prüft dieses Inkrement und bestätigt dem Team, dass das Inkrement der Definition of Done entspricht.

Dieser Prozeß muss vor dem Review stattfinden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: Wert aus Kundensicht

??Dieser Artikel ist noch nicht fertig??

Die Hierarchie des Product Backlogs und damit die Reihenfolge, in der die Anforderungen abgearbeitet werden, werden aus dem Wert ermittelt, den die jeweilige Funktionalität für den Kunden hat.

Das ist eine leicht verständliche Regel. Aber was ist "Wert".

Die ganze Komplexität des Begriffs zeigt sich bei einem Blick in Wikipedia (https://de.wikipedia.org/wiki/Wert_(Philosophie))

Die triviale Antwort ist immer: Was mir der Kunde dafür bezahlt.

Wie hoch ist der Wert des Autos, dass ein Schlosser zum Ausliefern der Leistungen benötigt?

Der Verkaufswert - er soll ja nicht verkauft werden - ist Null.
Der Wert für die Schlosserei ist genauso hoch wie der gesamte Gewinn des Unternehmens, denn wenn er seine Leistungen nicht ausliefert, bezahlt der Kunde sie nicht.
Da der Wert für die Schlosserei also extrem groß ist, muss das Auto bei der Erstellung eines Schlossereibetriebes zuerst angeschafft werden - auch wenn noch keine Schlosserei vorhanden ist, bevor überhaupt Leistungen erstellt werden könnten.

Kommen wir zurück zur Priorisierung bei der Leistungserstellung von Produkten.

Das Kriterium "Verkaufswert" ist schwierig.

Das Kriterium "Wert in dem Leistungserstellungsprozess" ist schwierig.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: Präsentationsfolien "Anwenderkonferen"

Eine Alternative zu den üblichen User Stories. Die Stakeholder erstellen zur Leistungsbeschreibung Präsentationsfolien wie für eine Anwenderkonferenz.

Die Geschichte für die Anforderer:

"Entwerfen Sie maximal drei Präsentationsfolien, die Sie auf einer Anwenderkonferenz nutzen, um Ihr Produkt (oder Funktionalität) einem Fachpublikum in drei bis fünf Minuten zu präsentieren."

Die Zahl der Folien ist dabei auf Zwei bis Drei begrenzt. Die starkt textorientierte Form der User Storys kann durch die Präsentationsfolien aufgelöst werden. Hier können auch Bilder und Zeichnungen genutzt werden um die Anforderungen darzustellen und für das Umsetzungsteam verdeutlicht zu werden. Das Tool ist damit weniger formalisiert, als User Stories. Für vielen Stakeholder sind Präsentationsfolien ein gewohntes Medium. Es fällt ihnen leichter eine aussagefähige Folien zu erstellen und ihre Anliegen damit zu präsentieren.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: Visionsbox

Das Tool Visionsbox ist eine Alternative zu der Leistungsbeschreibung durch User Stories. Sie ist stärker handwerklich/taktil/visuell als intellektuelle abstrakt und unterstützt dabei Menschen mit diese Ausrichtung stärker bei der Beschreibung der Anforderungen.

Die Aufgabenstellung für den oder die Anforderer:

"Malen Sie einen Verpackungskarton (oder basteln Sie einen Verpackungskarton), in dem das Produkt an den Kunden ausgeliefert werden soll. Beschriften Sie den Karton mit den Eigenschaften, die den Kunden, nur durch die Aufschrift der Verpackung zum Kauf motivieren."

Die Zahl der Merkmale sollte dabei nicht größer als 3 bis 5 sein. Die stark visuelle orientieren dieser Methode entspricht der bildhaften Beschreibungen, die im Agilen gerne verwendet wird. Die "Verpackung" steht für den Inhalt und damit für das, was in dem neu zu entwickelnden Produkt enthalten ist. Gerade für kreative und taktil visuell orientierte Menschen ist die Form der Aufgabenbeschreibung ideal.

Alternativ zu einer Visionsbox, kann die Anforderung, bzw. das gewünschte Ergebnis des Leistungserstellungsprozesses auch auf einen Flip-Chart gemalt, bzw. skizziert werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

MagischesDreieck

Agile Methode: Agil Produktentwicklung und das Magische Dreieck des Projektmanagement

Als ich angefangen habe, mich mit agilem Projektmanagement, insbesondere Scrum zu beschäftigen, wurde z.B. in der Scrumguide (http://www.scrumguides.org/download.html) sehr gut beschrieben, wie Scrum gemacht werden sollte und ich fragte mich, warum das Projektmanagement, das ich seit über 10 Jahre lehre, so kompliziert ist.

Mein ganzes Leben wurde leichter. Alle Schwierigkeiten des Projektmanagements, Risiken, Änderungen, Anforderungen, Verträge, Projektcontrolling, Teammotivation, Ressourcenmanagement, Planung, waren auf einmal nicht mehr da. Ich war begeistert.

Stakeholder und Scrum Team erarbeiten gemeinsam das Product Backlog. Das wird in Sprints in einzelnen Inkrementen erstellt. Im Review kommen alle Stakeholder und Scrum Teams wieder zusammen und diskutieren die Änderungen und nach vielen Sprints ist das Product Backlog abgearbeitet und alle sind glücklich.

Insbesondere hat es mich gefreut, dass dieses Magische Dreieck des Projektmanagement, dieser Dreiklang von Scope, Time und Budget, diese Waage mit drei Waagschalen aus Leistung, Zeit und Kosten endlich aus meiner Welt verschwunden war.

Magisches Dreieck des Projektmangements

Kurz formuliert besagt das Magische Dreieck, dass in einem Projekt zumeist drei Zielbereiche gleichzeitig erreicht werden müssen: Eine bestimmte Leistung soll mit eine bestimmten Budget, innerhalb einer bestimmten Zeit erstellt werden. Stimmt die Relation zwischen diesen drei Zielen nicht, dann befindet sich das Projekt im Ungleichgewicht. Mindestens eines der Ziele kann nicht erreicht werden.

Mit Scrum besteht dieses Problem auf einmal nicht mehr.

Ich habe leider den ersten Satz der Scrum Guide überlesen. "Scrum is a framework for developing and sustaining complex products"

Scrum sagt nichts über Projektmanagement. Es beschäftigt sich nicht mit Projektmanagement. Es ist ausschließlich ein Verfahren zur Produktentwicklung.

Anders formuliert: Es beschreibt einen Leistungserstellungsprozess.

Projektmanagement interessiert sich im Gegensatz dazu nicht für den Leistungserstellungsprozess. Es beschreibt nur den Projektmanagementprozess. Und der Projektmanagementprozess ist einer der vielen Unterstützungsprozesse, die den Leistungserstellungsprozess koordinieren sollen.

Leider werfen vielen Menschen agile Leistungserstellungsprozesse und Projektmanagement durcheinander. Dann entstehen Wortkombination von "Agilem Projektmanagement nach Scrum". Diese Wortkombination verbinden Äpfel mit Birnen und der Fellpflege von Katzen. Es sind Wörter, die nichts miteinander zu tun haben.

Trennen wir uns von der reinen Theorie der agilen Methoden und transferieren wir sie in die Praxis, dann klopft der böse Geist des Magischen Dreiecks bei der Visionsentwicklung für das Produkt wieder an die Hintertür, wenn wir von dem Auftraggeber eine Freigabe für die Produktentwicklung erhalten wollen. Spätestens bei der Entwicklung des Product Backlogs hat uns dieser Dämon dann wieder in seinen Klauen.

Der Auftraggeber stellt so unangenehme Fragen wie:

Wieviel kostet das Projekt den jetzt genau?
Wann bekomme ich die Funktionalitäten?
Welche Leistung bekomme ich den jetzt im Detail?

Fragen, die er zunächst beantworte haben möchte, bevor er einen Auftrag vergibt, bzw. einen Vertrag unterschreibt.

Agil hat recht. Es ist fast unmöglich genaue Vorhersagen über alle drei Zielvariablen zu machen. Wie sich diese drei Faktoren in der Zukunft entwickeln werden, ist nicht vorhersehbar.

Das löst allerdings unser Problem in der Verhandlung mit dem Auftraggeber nicht. Auch die meisten Auftraggeber sind darauf angewiesen, diese Informationen zu erhalten.

Die Frage ist jetzt: Gibt es eine "agile Lösung"?

Rubin, K.S. (2014, ISBN 978-3-8266-9047-1, S.351 ff) hat sich dazu einige Gedanken gemacht.

Schauen wir einmal auf den Inhalt einer Timebox, z.B. auf einen Sprint und damit auf die zweitkleinste Einheit der agilen Planung (Tasks sind noch kleinere Einheiten).

So eine Timebox ist zeitlich begrenzt. Sie hat immer die gleiche Dauer.
In einer solchen Timebox arbeitet ein festgelegtes Entwicklerteam. Da alle Entwickler ihre gesamte Arbeitszeit ausschließlich an der Erstellung der Inkremente für dieses Produkt arbeiten, sind die Arbeitskosten festgelegt.
Die User Stories, die als Inkremente erstellt werden sollen, werden für jeden Sprint festgelegt und dürfen über den Verlauf der Timebox nicht mehr verändert werden.
Sollte es einmal dazu kommen, dass doch nicht alle Inkremente erstellt werden können, gehen die damit verbunden User Stories zurück in das Product Backlog.

Damit sind die Variablen des Magischen Dreieckes bestimmt. Die Zeit durch die Dauer der Timebox, die Kosten durch die Personenkosten des Entwicklerteams und die Leistung ist relativ variabel, durch die ausgewählten User Stories, die in seltenen Einzelfällen auch zurück gegeben können.

Berücksichtigen wir zusätzlich, dass die Vorhersagedauer dieser Timebox maximal 4 Wochen lang ist, dann dürfte die Schätzung recht zuverlässig sein. Scrum hat hier ja noch zusätzlich eine Sicherung gegen zu große Wünsche der Stakeholder eingebaut: Die Entscheidung darüber, welche User Stories in dem Sprint aufgenommen werden, liegt exklusiv in den Händen der Leistungsersteller.

Bei den Planungsinstrumenten, in denen größere Einheiten festgelegt werden, ist die Lösung ungleich schwieriger. Bei der Planung des Product Backlogs wird das Problem noch größer. Welche Handlungsmöglichkeiten gibt es:

	Leistung	Zeit	Budget
1	fest	fest	fest
2	fest	fest	variabel
3	fest	variabel	fest
4	variabel	variabel	fest
5	variabel	fest	variabel
6	variabel	variabel	variabel

1. Der erste Fall ist, wie wir gesehen haben, nicht empfehlenswert. Er setzt voraus, dass die Planung über den gesamten Projektverlauf in einem Gleichgewicht steht. Es ist recht unwahrscheinlich, das zu erreichen.

2. Wenn das Budget variabel ist, Leistung und Zeit aber fest stehen, dann bedeutet das meistens, dass wenn "es eng werden sollte" zusätzliche Mitarbeiter in dem Projekt mitarbeiten können, damit die Arbeit auf mehr Menschen verteilt werden kann und damit der Leistungserstellungsprozess schneller durchgeführt wird. Ob diese Möglichkeit in der Realität vorhanden ist, hängt sehr stark von der Gesamtsituation ab. Brooks F. P. (2008, ISBN 978-3826613555) formuliert so schön: "Selbst neun Frauen können nicht in einem Monat ein Baby auf die Welt bringen". Er stellt fest, dass ein verspätetes Sotwareprojekt durch zusätzliche Arbeitskräfte nur noch später fertig gestellt wird. Bevor sich das Management für die zweite Variante entscheiden sollte, lohnt sich also ein sehr genauer Blick auf den Leistungserstellungsprozess des Produktes und die Teamsituation.

3. Auch die dritte Variante bietet nur unter bestimmten Voraussetzungen eine Lösung. Zumeist ist hier kein positiver Effekt zu erwarten. Wenn ein Team mehr Zeit für einen Leistungserstellungsprozess benötigt, dann arbeiten die Menschen zumeist auch länger an diesem Prozess. Das bedeutet aber, dass die Arbeitsleitung über einen längeren Zeitraum bezahlt werden muss, was wiederum zu einer Kostensteigerung führt. Diese Variante ist also nur dann möglich, wenn das Unternehmen die Arbeitskosten der eigenen Mitarbeiter nicht in die Projektkosten einrechnet. Dieses Vorgehen ist kaufmännische allerdings irgendetwas zwischen zweifelhaft und falsch.

4. Die vierte Variante findet sich in der Praxis recht häufig - auch wenn sie meistens "versteckt" praktiziert wird. Einfach können wir auch sagen: "Ist das Geld zu Ende, ist das Projekt zu Ende." Für ein agiles Vorgehen ist das immer dann akzeptabel, wenn viele der User Stories "nice to have" sind. Da die wertmäßig größten Funktionen in der agilen Produktentwicklung zuerst erstellt werden, sollten am Ende der Entwicklung nur noch relativ unbedeutende, wenig wertvolle Anforderungen zu finden sein.

5. Die fünfte Variante stellt ebenfalls einen erfolgversprechenden Lösungsweg dar. Sie ist immer dann zu empfehlen, wenn ein Produkt zu einem bestimmten Zeitpunkt zur Verfügung stehen muss. Wenn das Budget variabel ist, können gegebenfalls mehr Menschen in der Produktentwicklung mitarbeiten (allerdings immer unter der bereits unter 2. genannten Prämisse). Der stärkst Effekt geht von der variablen Leistung aus. Auch hier kommt es zu dem unter 4. beschriebenen Effekt.

6. Die sechste Variante ist die, die in der agilen Produktentwicklung am einfachsten zu realisieren ist. Es ist allerdings sehr unwahrscheinlich, dass ein Kunde einen solchen Auftrag vergeben wird. Für interne Produktentwicklungen kann dieses Vorgehen sehr sinnvoll sein. Hier kann von Timebox zu Timebox im Review entschieden werden, ob die Stakeholder mit den erstellten Funktionalitäten zufrieden sind, oder ob weiterhin an dem Produkt gearbeitet werden soll. Auch der agilen Idee entspricht das am besten. Ausgehend von einer Produktvision und ein paar Epics wird mit der ersten Timebox begonnen, langsam eine optimale Lösung zu erarbeiten. In vielen kleinen Zyklen erfolgt eine Annäherung an ein optimales Ergebnis, das zu Beginn der Produktentwicklung noch nicht bekannt ist.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: Produktdatenblatt

Alternativ zu User Story können auch Produktdatenblätter als Leistungsbeschreibung bei agilen Projekten verwendet werden. Insbesondere bei technischen Produkten kann das sehr vorteilhaft sein.

Die Aufgabe für den Anforderer:

"Erstellen Sie ein Produktdatenblatt für die von Ihnen gewünschte Funktion, die den Umfang einer Din A4 Seite nicht überschreitet und die von Ihnen gewünschte Funktionalität allgemeinverständlich erklärt."

Dieses Produktdatenblatt entspricht dem Eintrag im Product Backlog. Es kann sich dabei um ein festgelegte Formular handeln. Das Produktdatenblatt kann aber von den Anforderern auch frei gestaltet werden. Viele Ingenieure sind an Beschreibungen von Produkten mit Hilfe von Produktdatenblättern gewöhnt. Entsprechend leicht fällt es ihnen ihre Anforderungen in dieser Form zu erstellen. Außerdem sind gerade bei technischen Produkten zukünftige Leistungen mit klaren Datenvorgaben beschrieben. Nehmen wir nur die Entwicklung eines neuen Dieselmotors, der den Vorgaben der neuen Abgasnorm entsprechen muss und natürlich auch den marktüblichen Fahrzeugklassenwerten. Diese Vorgaben in Form von User Stories klar zu formulieren scheint sehr kompliziert. Die Vielzahl an Einzelwerten, die dieser neue Motor erfüllen muss, lässt sich auf ein paar Produktdatenblättern viel einfacher und schneller zusammenfassen.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: Elevator Pitch (Kurzpräsentation)

In einem Elevator Pitch stellt der Vortragende seine Ideen innerhalb von maximal 60 Sekunden dar. Es handelt sich also um eine meist mündliche Kurzpräsentation. In der Präsentationspraxis entwickelt der Vortragende im Vorfeld, seine Präsentation auf maximal einen Flip-Chart und verwendet dieses als Medienunterstützung für seinen Vortrag.

Der Elevator Pitch arbeitet mit folgender Aufgabenstellung:

"Stellen Sie sich vor, Sie befinden sich in einem Aufzug. In diesem Aufzug ist auch ihr potentieller Geldgeber.

Sie müssen ihn von ihrem Investitionsvorschlag überzeugen, bevor er den Fahrstuhl verlässt.

Eine solche Fahrstuhlfahrt dauert 60 Sekunden."

Die daraus entstehende mündliche Kurzpräsentation kann als Video aufgezeichnet werden und dann als Anforderung schriftlich dokumentiert werden. In Agilen Projekten ist die Präsentation nur die Basis für eine spätere gemeinsame Diskussion über die hier beschriebenen Leistungsanforderungen. Wichtig ist, dass zumindest einige Mitglieder des Umsetzungsteams bei dem Elevator Pitch anwesend sind und an der nachfolgenden Diskussion beteiligt werden. Nur so ist sichergestellt, dass sie bei der späten Umsetzung der Leistungsanforderungen, diese auch ausreichend verstanden haben.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

ProductOwner

Agile Methode: Product Owner (Produkt Verantwortlicher, Produkt Eigner)

Die Bezeichnung "Product Owner" wird hier als Rolle verstanden. Analog zu dem üblichen Verständnis des Begriffes "Rolle", kann ein Mensch mehrere Rollen haben.

Der Product Owner ist eine Kommunikationsschnittstelle zwischen den Stakeholdern und dem Entwicklerteam.

Stakeholder sind alle Personen, die

an dem Produkt ein Interesse haben,
von dem Produkt betroffen sind,

Dazu gehören insbesondere: die Auftraggeber, die Kunden, die Nutzer, die Kostenträger, das eigene Management, das Management des Auftrag gebenden Unternehmens, etc. Der Stakeholder Begriff ist hier also sehr weit gefasst. Aufgabe des Product Owners ist es, diese Stakeholder zu identifizieren und sie in die Produktentwicklung zu integrieren. Eine gute Methode zur Identifikation und Bewertung der Stakeholder ist die Stakeholder-Analyse. Da die Stakeholder Analyse aus dem klassischen Projektmanagement kommt, wird sie hier nicht dargestellt.

Wenn ich davon rede, dass der Product Owner etwas macht, bzw. "verantwortlich ist für...", dann bedeutet das immer, dass er die Interaktion und Kommunikation zwischen den Stakeholdern, incl. des Entwicklerteams koordiniert. Anders gesagt: Der Product Owner tut nichts alleine! Er fasst keine einsamen Beschlüsse, erarbeitet keine selbständigen Lösungen oder entwickelt Konzepte alleine an seinem Computer. Alles, was er macht, macht er in Zusammenarbeit mit anderen Menschen und in Abstimmung mit diesen.

Im Focus der Rolle des Product Owners steht die Entwicklung und Weiterentwicklung des Produktes. Dabei erfasst er die Anforderungen der Stakeholder. Er hilft den Stakeholdern diese Anforderungen zu formulieren (z.B. in User Stories), gemäß ihres Wertes zu sortieren (Priorisieren) und den Aufwand des Leistungserstellungsprozesses für die einzelnen Anforderungen zu schätzen.

Die Ergebnisse dieses Prozesses werden im Product Backlog dokumentiert. Die Pflege dieses Product Backlogs ist die Hauptaufgabe des Product Owners.

Die andere Hauptaufgabe liegt in der Durchführung der Reviews. In den Reviews präsentiert das Entwicklerteam den Stakeholdern die erstellten Inkremente. Der Product Owner bleibt auch hier in seiner, die Kommunikation koordinierenden, Rolle. Die Begutachtung und Bewertung erfolgt durch die Stakeholder. Er ist lediglich dafür verantwortlich den Prozess des Reviews zu koordinieren und muss die Ergebnisse des Reviews mit den möglichen Veränderungen in dem Product Backlog dokumentieren. Anders ausgedrückt: Ein Review ohne Stakeholder - nur mit dem Product Owner - ist nicht agil.

Die wichtigsten Eigenschaften eines Product Owners liegen also im Bereich der Kommunikation und Moderation. Er sollte die "Sprache der Leistungsersteller" ebenso gut sprechen wie die "Sprache der Anforderer". Seine Aufgabe wird häufig darin bestehen, für beide Gruppen "zu übersetzen". Wichtig sind auch gute Kontakte zu den Stakeholdern in der Auftrag gebenden und Auftrag nehmenden Organisation. Wenn er Erfahrung mit der Entwicklung ähnlicher Produkte hat, ist auch das hilfreich. - Hilfreich, aber nicht notwendig, da er selber keine Beschlüsse fasst.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

BurnupChart

Agile Methode: Burnup Chart (Burn Up Chart)

Der Burnup Chart wird, genau wie der Burndown Chart, zur Darstellung der erbrachten Leistung innerhalb eines Leistungsentwicklungsprozesses verwendet. Der Unterschied zwischen den beiden Verfahren liegt nur in der optischen Darstellung der gleichen Sachverhalte. Welches der beiden Instrumentarien verwendet wird, ist eine Frage des persönlichen Geschmacks.

Die nachfolgende Abbildung zeigt beispielhaft einen Burnup Chart für einen Sprint, basierend auf der Anzahl der geplanten Task (Arbeitspakete)

Burnup Chart

Die Timebox ist hier auf 19 Arbeitstage begrenzt. Es sind 150 Tasks geplant. Mit zunehmender Abarbeitung der Tasks nähert sich der Burn Up Chart der roten Linie an. Liegt die Team Velocity über der Ideal Linie, dann kommt das Team schneller voran als geplant. Liegen die Werte unter der Ideal Linie, dann erfolgt die Arbeit langsamer.

Wenn der Brunup Chart zur Kontrolle der Produktentwicklung genutzt wird, dann kann der Entwicklungsfortschritt in Story Points gemessen werden. Veränderungen in der Planung der Story Point und der Entwicklungsdauer können mit dem Burnup Chart dargestellt werden.

Burn Up Chart Änderungen

Reduziert sich die Zahl der ursprünglich geplanten Story Point (Basisplan) zu einem bestimmten Zeitpunkt, dann sackt die schwarze Linie nach unten. Erhöht sich die Zahl der Story Points, dann geht diese Linie nach oben.

Ähnlich verhält es sich mit der Dauer der Produktentwicklung. Ausgehend von der schwarzen Linie auf der Zeitachse, verschiebt sich diese nach rechts, wenn die Produktentwicklung länger dauern soll, als ursprünglich geplant. Soll die Produktentwicklung verkürzt werden, verschiebt sich die Linie nach links.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Vision

Agile Methode: Produkt Vision entwickeln

Eine der ganz großen Visionen wurde 1961 von dem amerikanischen Präsidenten Kennedy formuliert:

"Ich glaube, dass das Land sich dem Ziel widmen sollte, noch vor Ende des Jahrzehnts einen Menschen auf dem Mond landen zu lassen und ihn wieder sicher zur Erde zurück zu bringen."

Eine gute Vision besteht aus wenigen, unmissverständlichen Worten. Die Vision ist quasi die oberste Ebene der Produktbeschreibung. Ausgehend von der Vision werden dann die Epics, User Stories, Funktionsbeschreibungen und das erste Product Backlog entwickelt. Aber am Anfang steht immer die Vision.

Es gibt eine Reihe an Formaten, in denen Visionen formuliert werden können.

Die Vision kommt von den Anforderern, bzw. Auftraggebern. Der Product Owner unterstützt diese Stakeholder bei der Entwicklung einer solchen Vision.

In vielen Organisationen ist mit der Entwicklung einer Vision, auch die Aufgabe verbunden, einen Projektauftrag, Projektantrag, Projektfreigabe, Projektgründung oder Projektanbahnung zu entwickeln. Die Genehmigung eines solchen Projektauftrages durch die Auftrag gebende Organisation ist dabei eine Voraussetzung dafür, dass mit der Produktentwicklung begonnen werden darf.

In vielen Unternehmen ist die Erstellung eines Projektauftrages ein aufwendiger, streng formalisierter Prozess, der planungsintensiv ist und häufig sehr detailliert und excessiv durchgeführt wird. Die exzessive Planungsanforderung, bei der die Produktplanung im Vorfeld des Projektes durchgeführt wird, steht häufig im Widerspruch zu einem agilen Vorgehen.

Der Vorgang der Visionsfindung sollte so einfach wie möglich gehalten werden. Die Planung sollte nur soweit durchgeführt werden, dass eine Vertrauensschwelle der Entscheider überschritten werden kann. Es geht nur darum, die Basis für die nächste Finanzierungsentscheidung zu schaffen. Die Produktentwicklung muss gerade soweit spezifiziert werden, dass der wirtschaftliche Filter für die Freigabevorgaben für Produktentwicklungen durchschritten werden kann. Je höher die Freigabeanforderungen sind, bzw. je dichter der wirtschaftliche Filter, umso aufwendiger muss die Planung sein.

Nehmen wir einmal an, der amerikanische Kongress hätte Kennedy geantwortet:

"Wir können dem Vorhaben nicht zustimmen. Zunächst brauchen wir einen genauen Zeitplan für die Produktentwicklung. Bitte sagen Sie uns genau, welche Produktkomponente bis wann entwickelt ist und machen sie uns eine Aufstellung aller Komponentenkosten. Weder der Zeitplan, noch der Kostenplan dürfen überschritten werden. Außerdem brauchen wir eine Auflistung aller Risiken, wobei die Risiken in Risikokosten bewertet werden müssen. Ob die einzelnen Komponenten dann freigegeben werden, das ist natürlich davon abhängig, wie hoch sie die Kosten veranschlagen. Wir behalten es uns vor, diese Komponenten gegebenenfalls aus der Gesamtkonfiguration heraus zu streichen. Sollte der Zeit- oder Kostenplan- überschritten werden oder die Vision nicht verwirklicht werden, dann ist ihre Karriere zu ende."

Glauben sie, dass dieses Vision realisiert worden wäre?

Häufig wird die Schranke zur Freigabe von Produktentwicklungen von dem Auftrag gebenden Unternehmen so hoch gesteckt, dass ein agiles Arbeiten bereits vor der Freigabe des Projektauftrages unmöglich ist. Viele der Vorhersagen, die sich hinter einer frühen Detailplanung und Kostenrechnung verbergen, basieren auf Annahmen, die auf Annahmen beruhen, die dann eine objektive Zahl ergeben. Die Annahme dahinter: 10% Eintrittswahrscheinlichkeit * 25% Eintrittswahrscheinlichkeit * 20% Eintrittswahrscheinlichkeit = 100% Sicherheit.

Ein agiler Weg besteht darin, zunächst nur die Finanzierung für die ersten Timeboxes zu vereinbaren und dann bei dem Review zu entscheiden, ob die Leistungserstellung weiter finanziert werden soll. Das gibt dem Team die Möglichkeit, sich auf die kurzfristigen Planungshorizonte zu konzentrieren und ihre Zeit nicht damit zu vergeuden, Funktionalitäten zu planen, die in dieser Form nie entstehen werden. Die Finanzierung erfolgt dann fließend mit dem Prozess der Leistungserstellung.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Sprintbacklog

Agile Methode: Sprint Backlog (Timebox Backlog)

Das Sprint Backlog ergibt sich aus der Sprint Planung. Das Sprint Backlog beinhaltet die Funktionalitäten, die innerhalb eines Sprints (bzw. einer Timebox) erstellt werden müssen und die Arbeiten (Tasks, Arbeitspakete), die zur Erstellung durchgeführt werden müssen. Zusätzlich werden die Schätzungen Arbeitsstunden, die für die Tasks vorgesehen sind, dargestellt. Wenn eine Umrechnung von Story Points in Arbeitsstunden oder Personentage erfolgt ist, können natürlich auch Story Points verwendet werden.

Product Backlog

Dieses Product Backlog kann dann in Form eines Kanban Board zur Steuerung der Leistungserstellung weiter verwendet werden. Es ist gut mit einer Work Breakdown Structure kombinierbar.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

direkteKommunikation

Agile Methode: "Product Owner" Direkte Kommunikation

Ein Aspekt des agilen Arbeitens liegt darin, dass die Menschen direkt und Face-to-Face miteinander reden. Das ist die beste Form, um zu verstehen, was die andere Seite meint und die schnellste Form des Informationsaustausches.

Ein Aspekt der Rolle des "Product Owners" ist die Kommunikation mit den Stakeholdern. Der Product Owner sammelt die Anforderungen der verschiedenen Stakeholder in direkten Gesprächen ein, Findet heraus, was - ausgehend von diesen Gesprächen für das Produkt als Ganzes von größtem Wert ist (Priorisierung) und schätzt in Interaktion mit dem Team den Aufwand.

Der Product Owner ist eine Kommunikationsschnittstelle und ein Informationsfilter zwischen den Leistungsanforderern und den Leistungsentwicklern. Er ist ein Informationsfilter.

In dieser Funktion als "Informationsfilter" steht er im Wiederspruch zum dem agilen Grundsatz der direkten Kommunikation. Die Rolle dieses Informationsfilters ist nur darin begründet, dass die direkte Kommunikation von Team und Stakeholdern dazu führen würde, dass das Team nicht gleichzeitig mit allen Stakeholdern kommunizieren und eine Leistung erstellen kann.

Totz der Rolle des Product Owner ist der direkte Kommunikationsweg zwischen Team und Stakeholdern offen und gewünscht. Innerhalb einer Timebox der Leistungserstellung kann jedes Mitglied Unsicherheiten über eine direkte Nachfrage an den Product Owner klären, aber wenn es schneller oder einfacher geht, kann es auch direkt bei dem jeweiligen Stakeholder nachfragen.

Auch wenn die Pflege des Product Backlogs in der Verantwortung des Product Owners liegt, bedeutet das nicht, dass er diese Aufgabe alleine macht. Vielmehr koordiniert er die Interaktion von Stakeholdern und Leistungserstellungsteam. Wenn z.B. User Stories im Product Backlog verwendet werden, dann ist die aufgeschriebene Story nur ein Platzhalter für das Verstehen der User Story durch das Team.

Ebenso ist es natürlich, mit der Weiterentwicklung von User Stories von größeren zu kleineren Einheiten und dem Verstehen der Akzeptanzkriterien der Stakeholder durch die Leistungsersteller. Hier ist die direkte Face-to-Face Kommunikation zwischen Anforderer und Leistungsersteller der agile Weg des Verständnisses.

Spätestens beim Review kommen Leistungstersteller und Anforderer wieder zusammen und diskutieren über die Ergebnisse und damit über das gemeinsame Verständnis des Ergebnisses.

Ein Kernelement des Agil richtet sich gegen Kommunikationsfilter. Natürlich kann das Filtern von Informationen den Kommunikationsaufwand für jeden Einzelnen verringern. Auch die Informationsbeschaffung für die nachfolgenden Einheiten ist einfacher, weil die Informationen bei jedem Filter stärker verdichtet werden. Dem entgegen steht das Risiko einer Fehlinterpretation.

Kommunikationsfilter

Ganz langsam und schwierig wird es, wenn das Team zwar verstanden hat, dass der Kunde "rot" möchte, aber ein Detail nachfragen möchte.

Der rote Filter fragt dann den orangen Filter, der dann einen der Stakeholder fragt.

Der antwortet gelb, soweit bei dem gelben Stakeholder nachgefragt wird. Sonst antwortet er vielleicht blau oder pink.

Der grüne Leistungsersteller wartet in der Zeit auf die Information, ohne die er nicht weiter arbeiten kann.

Der orange Filter versteht gelb. Er meldet das dem roten Filter weiter. Der wird jetzt auch gelb und meldet das dem Team weiter.

Das Team verwirft die Ergebnisse und macht jetzt gelb.

Was passiert, wenn den Stakeholdern, in der Mehrheit blau und pink, das Ergebnis irgendwann präsentiert wird?

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Release Backup

Das Release Backup ist ein Planungstool, das bei der Aufteilung der Funktionalitäten eines Produktes unterstützt und hilft diese Entwicklung der Funktionalitäten im Zeitverlauf über mehrere Releases zu verteilen.

Die Bezeichnung für die Release Planung unterscheiden sich innerhalb der Organisationen. Sie wird auch als langfristige Produktplanung oder meilensteingesteuerte Planung bezeichnet. Wenn nach jedem Sprint eine Auslieferung erfolgt, kann die Aufteilung in Releases auch als Sprint Mapping bezeichnet werden.

Die Fragen der Stakeholder, die mit der Release Planung beantwortet werden:

"Wann werden wir welche Inkremente geliefert bekommen?"
"Welche Funktionen werden wir bis zum Ende des Jahres bekommen?"
"Bis wann müssen wir wieviel Geld bereitstellen?"

Mit einem Release werden Funktionalitäten an den Kunden ausgeliefert. - So zumindest der Zusammenhang, in dem ich den Begriff Release hier verwende.

Je nach Vertragssituation, Stakeholder Wünschen und Produkteigenschaften, muss eine Entscheidung über die Kadenzen mit denen die Leistungen an den Kunden ausgeliefert werden, vereinbart werden. Die agilen Prinzipien empfehlen diese Auslieferungszyklen möglichst klein zu halten. Einerseits, um frühzeitig ein Feedback zu erhalten und so Fehlentwicklungen zu vermeiden, andererseits damit die (Teil-)Produkte am Markt möglichst früh einen Deckungsbeitrag generieren können.

Denkbar sind folgende Kadenzen:

Kadenzen Zyklen von Releases

Bei manchen Produktentwicklungen werden Minimum Relesable Features (MRFs) festgelegt. Es handelt sich um minimal freigegebene Funktionen, also um die Funktionen, die pro Release mindestens als Inkremente erstellt werden müssen. Das ganze Konzept dieser MRFs ist etwas schwierig, weil es nur dann realisierbar ist, wenn die Funktionen in einem Product Backlog alle vergleichbar sind. Außerdem sollen die User Stories, die in einer Timebox erstellt werden, ja nach Möglichkeit verbindlich sein. Das MRFs Konzept beinhaltet das Risiko, dass Timeboxes über die bearbeitbaren Anforderungen hinaus vollgestopft werden, so nach dem Motto: Vielleicht sind sie ja schneller. Wichtig sind ja sowieso nur die MRFs.

Ein Produkt, das in dem Portfolio Backlog steht, ist zumeist nur sehr ungenau beschrieben. Die Beschreibung wird eben ausreichend sein, um die wirtschaftlichen Kriterien zu überprüfen und daraus die Priorität zu bestimmen, die das Produkt in Relation zu den anderen Produkten im Portfolio Backlog haben.

Wahrscheinlich werden einige Funktionalitäten beschrieben sein und andere eher unklar bestehen. Die Genauigkeit der Schätzung für die einzelnen Funktionen und für den Aufwand der Produkterstellung kann sehr unterschiedlich sein. Das ist immer davon abhängig, wie genau der Auftraggeber und das eigene Unternehmen eine Kosten-Leistungsschätzung haben möchte und welche Kriterien in dem Unternehmen zur Wirtschaftlichkeitsprüfung von Investitionen zugrunde gelegt werden.

Für die Erstellung des Release Backups ist das zunächst nicht wichtig. Wir nehmen die Informationen die bisher erarbeitet wurden. Für das Release Backlog werden sie weiter entwickelt, überprüft und verfeinert.

vom Portfolio Backlog zum Release Backlog

Zunächst wird festgelegt:

Wie viele Releases gemacht werden sollen.
Wie lange die einzelnen Releases dauern sollen. Die Dauer der Releases kann auch als Timebox für die Produktentwicklung verstanden werden.
Wie viele Aufwandspunkt, z.B. Story Points innerhalb eines Release abgearbeitet werden kann. Dafür können z.B. die Erfahrungen mit der Team Velocity genutzt werden.

Wenn zusätzliche Anforderungen dazu gekommen sind, werden diese Anforderungen ergänzt. Anders Ausgedrückt: es müssen neue User Stories geschrieben werden. Auch der für das Gesamtprojekt geschätzte Aufwand muss für jede Funktion oder User Story neu geschätzt werden.

Die Prioritäten, die jetzt aus Perspektive der Funktionalitäten basierend auf dem Wert der jeweiligen Funktionalität aus Stakeholder Sicht ermittelt werden, sind ausschlaggebend für die Reihenfolge, mit der die Funktionalität in den Releases bearbeitet wird.

Daraus entsteht ein Release Plan, der den Leistungserstellungsprozess des Produktes in mehrere große Einheiten unterteilt. Genau wie alle anderen Backlogs muss dieses Backlog regelmäßig überprüft und an die neueste Entwicklung angepasst werden.

Priorisierung

Agile Methode: Priorisierungsmethoden Übersicht

Etwas zu priorisieren, ist an vielen Stellen der agilen Arbeit notwendig. So z.B. beim Ordnen des Portfolio Backlogs, des Product Backlogs.

Es gibt eine Vielzahl an Möglichkeiten, oder Priorisierungsmethoden, um zu so einer Priorisierung zu kommen.

Ich zeige hier nur einige Vorgehensweise. Letztendlich kommt es immer darauf an, dass das Kriterium den Wünschen des Auftraggebers entspricht.

Das führt uns dann zu einem Problemfeld, das allgegenwärtig ist.

Der Kunde muss sich entscheiden, das Team muss sich festlegen. Und jede Entscheidung für ein Kriterium ist auch gleichzeitig die Entscheidung gegen eine andere Alternative, die objektiv nicht schlechter ist.

Übersicht über die Priorisierungmethoden

Wert aus Kundensicht (aktuell in Bearbeitung)
Kosten kalkulierenKosten kalkulieren
Return of Investment (ROI)
WSJF (Weighted Shortest Job First)

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

PortfolioBackup

Agile Methode: Portfolio Backlog

Das Portfolio Backlog ist eine Ideensammlung für neue Produkte, die erstellt werden könnten. Die Ideen, die hier enthalten sind, sind nach Prioritäten bewertet. Die Bewertung erfolgt nach wirtschaftlichen Kriterien. Neben der Priorität wird auch der Aufwand abgebildet, der für die Umsetzung der Produkte geschätzt wird.

Portfolio Backlog

Wenn ein Produkt in den Leistungserstellungsprozess übernommen wird, rückt das nächste Produkt eine Priorität nach oben.

Wenn wir das Vorgehen als agilen Prozess verstehen, dann wandert das Produkt jetzt in die Release Planung und wird dann mit Release Backlog weiter verarbeitet.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

UnternehmensplanungEbenen

Agile Methode: Agile Unternehmensplanung auf mehreren Ebenen

Wenn wir die agilen Planungsprinzipien betrachten, dann wird deutlich, dass Planung auf mehreren Ebenen ansetzt. Die meisten agilen Systeme beschäftigen sich primär, mit einer sehr niedrigen Planungsebene, etwa auf der Ebene eines einzelnen Projektes, das mit einem kleinen Team realisiert wird. Diese Perspektive verschleiert, das Agil auf allen Unternehmensebenen angewendet werden kann.

Leider herrscht hier die übliche Begriffsverwirrung und Mehrdeutigkeit, wie sie in der Betriebswirtschaftslehre üblich ist.

Beginnen wir also oben, bei der Unternehmensstrategie. Ich möchte hier nicht weiter darauf eingehen, ob und wie diese Agil gestaltet werden kann oder sollte. Wichtig ist für mich an dieser Stelle nur, dass aus dieser Unternehmensstrategie abgeleitet wird, welches Unternehmensportfolio an Produkten erstellt werden soll.

Das Portfolio enthält die Leistungen, die neu erstellt werden sollen oder an denen umfangreiche Veränderungen vorgenommen werden sollen. Diese Begriffsauffassung weicht von einer Reihe an anderen Definitionen von Produkt Portfolio ab. Im Marketing würde ich eine andere verwenden. Nach meiner Auffassung sind agile Methoden ideal für eine Neuentwicklung von Leistungen geeignet. Für eine kontinuierliche Weiterentwicklung eines Produktes sind andere Methoden besser geeignet. Z.B. ein Lean Management-Ansatz.

Die agile Methode die hier dafür vorgestellt wird, ist das Portfolio Backlog.

Mit Hilfe dieser Methode werden die Fragen beantwortet:

Welche Produkte werden in der Zukunft in unserem Unternehmen mit höchster Priorität und möglichst bald entwickelt werden?
Welchen Aufwand erwarten wir für die Entwicklung dieser Produkte?
Welche Haupteigenschaften sollen diese Produkte haben?

Betrachten wir die Ebene der einzelnen Produkte, dann treffen wir hier auf das nächste Abgrenzungsproblem. Nehmen wir das Beispiel Microsoft Office. Sind die Komponenten des Office Paketes (Word, Excel, Powerpoint, etc.) Komponenten eines Produktes oder sind es eigenständige Produkte? Ist das Produkt Word 10 ein eigenständiges Produkt oder nur ein weiteres Release von Word 7? Wie auch immer dieses philosophische Problem gelöst wird, wichtig ist hier, dass die meisten komplexen Produkte nicht in einem Zyklus entwickelt werden, sondern in mehreren Releases.

Das kann mit der Methode des Release Backlogs geplant und in der zeitlichen Abfolge in der Produkt Roadmap dargestellt werden.

Eine Ebene tiefer betreten wir die Betrachtungsebene von Scrum. Hier geht es um die Planung und Umsetzung eines Release oder eines kleinen Produktes mit einem Team. Natürlich gibt es auch agile Vorgehensweisen um auch Scrum Projekte mit mehreren Teams zu organisieren. Die Scrum Guide betrachtet diese aber nur am Rande.

Zur Planung der Leistungserstellung wird hier das Product Backlog verwendet. Mit dieser Methode werden die Timeboxes oder in der Scrum Terminologie "Sprints" geplant. Aus dem Product Backlog werden die Leistungen ausgewählt, die in den einzelnen Sprints erstellt werden sollen.

In dem Product Backlog werden die gleichen Fragen beantwortet, wie in den vorhergehenden Backlogs, nur auf einer niedrigeren Ebene:

Welche Funktionalitäten sind von dem größten Wert und bekommen so eine höhere Priorität?
Welchen Aufwand erwarten wir für die Entwicklung der Funktionalitäten?
Welche Eigenschaften sollen die Funktionalitäten haben?

Erst auf Ebene der Timeboxes, bzw. Sprints nähern wir uns der Ebene der Leistungserstellung. Aber wir haben sie noch nicht ganz erreicht. Auch bei der Planung der Sprints wird nur geplant. Während des Sprint Planing wird festgelegt, was innerhalb einer Timebox geleistet werden soll und mit welcher Priorität - natürlich wieder unter Berücksichtigung des geschätzten Aufwandes. Gesteuert wird der Sprint über ein Kanban Board.

Bisher wurde nur geplant. Erst nach dem Sprint Planing beginnt die eigentliche Leistungserstellung. Hier erfolgt die Steuerung dann über und in dem Daily Standup Meeting.

Wieviel Planung ist in Agil?

Wenn ich das oben gesagte im Zusammenhang lesen, dann liegt der Schluss nahe, dass agilem arbeiten ein mehrstufiger Planungsprozess vorausgeht, der sehr komplex ist. Auf jeder Planungsstufe werden die gleichen Fragen beantwortet - nur immer bezogen auf kleinere Einheiten:

Was ist von größtem Wert und sollte zuerst gemacht werden?
Welche Anforderungen werden an die Leistung gestellt?
Welchen Aufwand erwarten wir bei der Leistungserstellung?

Die präferierte agile Methode ist dabei das Backlog. In diesem Backlog werden allerdings nur die Ergebnisse festgehalten. Es ist also ein reines Tool zur Abbildung von Ergebnissen. Mit welchen Methoden die Ergebnisse entstehen, z.B. mit einer klassischen Risikoanalyse oder einer Schätzung des Kapitalwertes sind von den agilen Methoden nicht vorgegeben.

Die präferierte Methode für Feststellung von Anforderungen ist die User Story. Jede andere Methode zum Beschreiben der Anforderung ist aber auch möglich.

Die Basis für die Schätzung des Aufwandes erfolgt in Story Points. Die Schätzung erfolgt nicht in absoluten Kosten oder Zeitwerten, sondern in einer Schätzung der relativen Größenverhältnisse der User Stories. Wobei das natürlich nicht zwingend vorgeschrieben ist. Die Story Points können in Personentage und darüber in Kosten umgerechnet werden. Die Leistungsfähigkeit eines Teams wird als Team Velocity ermittelt und in Story Points pro Sprint gemessen. Die durchschnittlich erstellten Story Points pro Sprint bilden die Basis für die Zahl an Funktionalitäten, die innerhalb der nächsten Sprints erstellt werden sollen.

Die Pläne der verschiedenen Ebenen werden ständig überprüft und neuen Gegebenheiten angepasst.

Wenn jetzt einige Leser sagen: "Schön, - wenn wir jetzt mal die ganzen neuen Worte weglassen -, so haben wir doch immer schon gearbeitet. Was soll ich jetzt agil besser machen?" Dann fällt mir nur die Antwort ein: "Lerne die neuen Worte". Wenn Sie bisher anders gearbeitet haben, dann liegt im agilen Arbeiten ein großes Verbesserungspotential.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

AgilPlanlos

Agil = planlos? - Planung auf mehreren Ebenen

Eine der gängigsten Annahmen zum agilen Arbeiten: Jetzt müssen wir nicht mehr planen. Wir können alles spontan entscheiden und jederzeit ändern. Wir fangen einfach an und die Details werden nebenher geklärt.

Nichts könnte falscher sein. Wenn Sie agil arbeiten, planen Sie mindestens so viel wie vorher - nur zu anderen Zeiten und an anderen Stellen.

Die agile Planung

geht von einer Reihe von Grundannahmen aus. (Quelle: Rubin, K.S.: Essential Scrum (ISBN 978-3-8266-9047-1)

Glauben Sie nicht an im Voraus erstellte Pläne

Ein Plan ist immer eine Zukunftsvorhersage. Zukunftsvorhersagen sind, wie wir alle wissen, sehr schwierig und erweisen sich als fehlerhaft, je weiter in die Zukunft wir schauen und umso unsicherer die Umweltsituation ist.

Oder anders ausgedrückt: Wir können die Zukunft nicht vorhersagen. Darum kann kein Plan richtig sein.

Bedeutet das, dass wir keinen Plan brauchen? Was wollen wir mit einem Plan?

Wir wollen unser gemeinsames Vorgehen auf unserem Weg hin zu einem Ziel koordinieren. Wir geben uns also eine Richtung, in die wir gemeinsam gehen wollen.

Haben wir diesen Plan nicht, dann laufen und handeln alle Menschen in unterschiedlichen Richtungen. Jeder für sich (und Gott gegen Alle).

Erst durch einen Plan wird eine Handlungsrichtung festgelegt und ein gemeinsames Handeln koordiniert.

Pläne sind also notwendig für ein gemeinsames koordiniertes Handeln.

Da wir aber die Zukunft nicht kennen, dürfen wird nicht blind auf den Plan vertrauen. Wir müssen bereit sein, ihn jederzeit der Realität anzupassen.

Plane hilfreich, aber nicht exzessiv

Wenn Sie spazieren gehen oder Auto fahren, planen Sie dann die ganze Strecke?

Wenn ja, wie genau?

Planen sie jede Abzweigung? Jede Kurve? Jedes Ausweichen oder Bremsen?

Was würde denn passieren, wenn sie so genau planen würden und sich an diesen Plan halten würden, ganz exakt halten würden? Wie lange würden Sie überleben?

Viele Pläne in Unternehmen sehen genau so aus, wie ein Streckenplan, auf dem jedes Ausweichen und Bremsen im Voraus bestimmt wird.

Das ist genau das, was ich unter exzessiver Planung verstehe. Eine solche Planung ist:

aufwändig und damit teuer,
sinnlos, weil nicht einhaltbar ist und
gefährlich, wenn sie sich daran halten.

Genau hier sind wir der agilen Welt angekommen. Planung ja, aber nicht zu detailliert. "Wir gehen in diese Richtung, weil wir dahin wollen. Alles andere wird "vor Ort" entschieden.

Planungsoptionen bis zum letzten Augenblick offen halten

Haben sie schon einmal mit einem Bogen geschossen?

Einen Pfeil den sie abgeschossen haben, können sie nicht mehr zurückholen.

So funktioniert eine Timebox, bzw. ein Sprint in der agilen Denkweise. Sehr deutlich wird das im Scrum.

Ein Sprint - meines mehrere- wird vorgedacht (geplant). Hierfür wird das Product Backlock verwendet.

Ein Sprint beginnt im Scrum immer mit dem Sprint Planing. Erst zu diesem Zeitpunkt wird festgelegt, welche Inkremente genau innerhalb dieses Zeitfensters von dem Team erstellt werden wird. Das ist festgelegt und wenn man sich einmal darauf geeinigt hat, dann kann auch kein Außenstehender das mehr ändern. Ein Sprint ist fast - aber nur fast, wie ein Pfeil der abgeschossen wurde. Der Plan ist festgelegt.

Aber nur fast, denn was ganz genau wann gemacht wird, das wir viel später entschieden. So spät wie möglich, nämlich von einem Tag auf den anderen Tag. Im Daily Meeting. Hier wird, basierend auf den was gestern passiert ist, festgelegt, was jeder einzelne heute tut. Für morgen wird noch nichts geplant. Wir wissen ja noch nicht, was heute passiert.

Wird das Ziel, das im Sprint Planing angestrebt wurde, erreicht? - vielleicht. Wir überprüfen das im Sprint Review. Wenn ja, dann haben wir gelernt, das wir gut geplant haben. Wenn nicht, dann haben wir gelernt, dass wir anders planen müssen. Was wir anders machen müssen, das klären wir dann in der Sprint Retrospektive. Erst nachdem wir diese neuen Erkenntnisse gewonnen haben, machen wir den nächsten Plan für den nächsten Sprint.

Wenn wir agil arbeiten, dann planen wir viel. Wir planen sogar sehr viel und sehr viel mehr als bei allen anderen Methoden, in denen wir einen großen komplexen detaillierten Plan entwickeln, dem wir dann, egal was passiert, bis zum Ende folgen. Wir planen ständig neu und um.

Neuplanung und Anpassung

ist das Planungskonzept im Agilen. Natürlich versuchen wir so viel vorherzusagen wie möglich. Aber wir wissen, dass unsere Vorhersagen falsch sein werden. Wir überprüfen sie ständig und passen sie an. Ein Plan ist nur ein Zwischenzustand bis zur nächsten Veränderung. Da wir das wissen, sind wir gegenüber dem Plan immer misstrauisch.

Oder anders ausgedrückt: Wir vertrauen unserer Landkarte nicht absolut. Wir vergleichen die Landkarte immer mit dem Gelände auf dem wir uns bewegen - und wenn das Gelände anders aussieht, als die Karte, dann richten wir uns nach dem Gelände, welches wir sehen. Vertrauen sie ihrem Navi? Das ist begrenzt klug. In den meisten Fällen stimmt es und in einigen Fällen sind Navi Benutzer in den Rhein gefahren, weil das Navi glaubte, es gäbe an dieser Stelle eine Brücke. Fazit: selber denken und nicht auf einen Plan vertrauen.

Das richtige Maß - zu viel ist Gift

Agil versucht die Balance zu halten zwischen einem "zu viel an Vorausplanung", die eine falsche Sicherheit über das "was passieren wird und das, was zu tun ist" schafft und damit die Menschen davon abhält, selber zu denken. Der Aufwand, der in eine Planung investiert wird, sollt im richten Verhältnis zu der Wahrscheinlichkeit stehen dass er wieder geändert werden muss. "Keine Medizin ist schlecht - zu viel Medizin aber".

Je unsicherer der Weg, umso kleiner die Schritte

Wie gehen sie über eine ebene Straße in einer Fußgängerzone? Wie gehen sie über eine unbefestigte Wiese irgendwo auf einem Feld?

In dem einen Fall machen sie wahrscheinlich große Schritte und achten wenig darauf, wohin sie ihre Füße setzen. In dem anderen Fall überlegen sie jeden Schritt sorgfältig und achten bewusst darauf, wohin sie treten.

Also wie groß sollen die Timeboxes sein, die sie für den Leistungserstellungsprozess planen?

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

DefinitionReady

Agile Methode: Definition of Ready (Definition von Bereit)

Die Definition of Done beschreibt, wann ein Product Backlog Item (PBI) nach der Auffassung des Entwicklerteams fertig ist und darum innerhalb einer Timebox nicht weiter bearbeitet werden muss.

Die Definition of Ready steht genau auf der anderen Seite einer Timebox. Sie beschreibt, wann ein Product Backlog Item (PBI) umfassend und genau genug beschrieben ist, dass es in einer Timebox bearbeitet werden kann.

Definition of Ready und Timebox Sprint

Die Definition of Ready wird vom dem Entwicklerteam bestimmt. Sie entsteht in der Zusammenarbeit mit den Product Owner und allen Anforderern. Es handelt sich dabei um eine Checkliste. Mögliche Punkte auf diese Checklisten können sein:

Der Geschäftswert ist klar benannt.
Das Entwicklerteam hat die Einzelheiten der Anforderungen verstanden.
Es gibt keine internen und externen Abhängigkeiten, die der Fertigstellung des PBI entgegenstehen.
Alle Teamressourcen für die Fertigstellung sind vorhanden.
Das PBI kann innerhalb eines Sprints fertig gestellt werden.
Die Akzeptanzkriterien sind bekannt, verstanden und testbar.
Das Team hat verstanden, was beim Sprint Review demonstriert werden soll.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Personas

Personas, sind prototypische Personen, die die Kernmerkmale einer Rolle repräsentieren.

??Marketing DHBW und Beispiel??

StoryMapping

Agile Methode: Story Mapping

Jeff Patton entwickelte diese Technik im Jahr 2009. Das Story Mapping ist eine anwenderzentrierte Perspektive zur Entwicklung eines Satzes von User Storys. Es ist damit eine Kombination des anwenderzentrierten Designs mit der Story-Zerlegung. Es zeigt den Aktivitätsfluss aus Sicht des Benutzers und den Kontext der Storys.

Die Aktivitäten, die ein Benutzer mit einer Leistung durchführt, werden in einen oder mehrere Arbeitsabläufe zerlegt. Dieser Arbeitsablauf wird dann in eine Reihe von detaillierten Aufgaben zerteilt.

Wie geht es?

Eine Aktivität (Epic) wird in
Aufgaben (Themen, Tätigkeiten) aufgeteilt und dann in
Teilaufgaben (sprintfähige Storys) zerlegt.

Story Mapping

Auf dem höchsten Abstraktionsniveau befinden sind die Epics. Sie müssen einen messbaren Wert für den Auftraggeber repräsentieren. (Beispiel: Einkauf von Lebensmitteln in einer Verkaufsstätte)

Daraus entsteht dann, entlang einer Zeitachse, die Abfolge der Aufgaben, bzw. Tätigkeiten. Links die erste Tätigkeit, usw.

Aus diesen Tätigkeiten werden die User Storys entwickelt. So wird jede Aufgabe in eine Reihe von umsetzbaren User Storys zerlegt.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

UserStoryWorkshop

Agile Methode: User Story Workshop

Ein gerne vorgeschlagener Weg User Storys zu bekommen, besteht darin, die Anwender und Stakeholder in Einzelgesprächen zu fragen, was sie von einer neuen Leistung erwarten. Das kann in Einzelgesprächen gemacht werden - aber es ist für die meisten Stakeholder der schwierigere Weg.

Besser und durch den interaktiven Austausch der Teilnehmer effizienter sind User Story Workshops. In diesem Workshop soll kein vollständiger Satz von User Storys entwickelt werden. Es geht also nicht darum - wie im klassischen Projektmanagement - alle Anforderungen zu Erfassen und detailliert auszuarbeiten. Es geht darum, Richtungen festzulegen und auf einem hohen Abstraktionsniveau zu arbeiten.

Ein solcher Workshop muss sich nicht auf ein Release beziehen. Es kann durchaus sinnvoll sein, das Endergebnis über mehre Releases durchzudenken. Die Teilnehmer beschäftigen sich dann mit der Frage: Wie soll das Produkt in fünf Jahren genutzt werden?

Wie geht es?

In einer User Story Workshop werden der Product Owner, die Stakeholder, die Auftraggeber und das Entwicklerteam einbezogen. Häufig ist es sinnvoll, zusätzliche Experten einzuladen, die ihr spezifisches Wissen in die Entwicklung mit einbringen.

Die Dauer eines Workshops erstreckt sich über mehrere Stunden, bis hin zu 2 Tagen. Immer in Abhängigkeit der Teilnehmerzahl und der Komplexität der Aufgabenstellung.

Das Ziel von User Story Workshops besteht darin nach Geschäftsfeldern, bzw. Bereichen zu suchen, in denen ein Wert für die Auftraggeber geschaffen werden soll.
Danach werden die Benutzerrollen festgelegt. Es werden die Perspektiven entwickelt, unter denen die zukünftige Leistung betrachtet werden soll. ("In meiner Rolle als ..."). Diese Rollen lassen sich gut als Personas beschreiben.
Top Down oder Botton Up: Die Workshop Teilnehmer entwickeln die User Stories dann ausgehend von einer hohen Metaebene hinab zu einem höheren Detailreichtum. Es gibt aber auch Gruppen, die genau mit dem umgekehrten Verfahren - also von dem Detailreichtum hin zu einem höheren Abstraktionsniveau besser zurechtkommen. Es gibt hier kein richtiges oder falsches Vorgehen. Typischer für das Vorgehen ist jedoch die Progressive Verfeinerung also das Top Down Verfahren.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

DefinitionReady

Agile Methode: Definition of Done (Definition von fertig, Done)

Innerhalb jeder Timebox, bzw. innerhalb jedes Sprints sollte mindestens ein potentiell auslieferbares Produktinkrement erstellt werden.

Durch die Definition of Done wird festgelegt, was das Entwicklerteam unter "potentiell auslieferbar" versteht. Das "Done" beschreibt den angestrebten Zustand der Arbeit, der am Ende des Sprints erreicht werden soll.

Diese Definition of Done wird von dem Entwicklerteam gemeinsam festgelegt.

Die Definition of Done basiert also auf einer Entscheidung des Entwicklerteams. Natürlich findet hier ein Abstimmungsprozess mit dem Product Owner und anderen Stakeholdern statt. Aber es handelt sich hier um eine Festlegung des Entwicklerteam. In der Philosophie des Agil gibt es keine unternehmensweite Definition of Done, die auf Vorgaben von außen beruht und von allen Teams angewendet werden muss. Dabei werden funktionale und nicht funktionale Anforderungen des Unternehmens natürlich berücksichtigt.

Die Definition of Done ist kein starres Dokument, das am Anfang einmal definiert wurde und anschließend nicht weiter verändert werden darf. Es ist ein Living Document, das sich im Zeitverlauf entwickelt, den Gegebenheiten und der Erfahrung des Teams angepasst wird und im Zeitverlauf meistens genauer und detaillierter wird.

Die Minimalanforderung einer Definition of Done orientiert sich daran, was unter einem Inkrement zu verstehen ist. Ein Inkrement ist ein komplettes "Stück Funktionalität", dass:

entworfen,
gebaut,
integriert,
getestet und
dokumentiert wurde und
nachweislich einen Wert erbringt.

Klingt einfach - ist es aber nicht. Nehmen wir das Beispiel "getestet". Was versteht das Team jetzt genau unter "getestet". Bedeutet das, dass das Modul einmal funktioniert hat - oder dass es im Zusammenhang mit allen anderen Modulen einmal funktioniert hat. Oder das es z.B. einem Motor, über 1000 Stunden bei Höchstleistung nur einmal innerhalb der Laufzeit ausfällt und dann innerhalb von 2 Minuten wieder repariert werden kann? Und wie geht das Team mit dem Test von Modulen um, die zusammenarbeiten sollen, von denen aber einige erst in einem späteren Sprint erstellt werden?

In Tests, die einen längeren Zeitraum benötigen, liegt eine besondere Herausforderung. Ein Test, der über 1500 Stunden läuft, kann kaum innerhalb einer Timebox von 14 Tagen durchgeführt werden. Der Test muss zwangsweise außerhalb der Sprints stattfinden. Sonst müsste mit dem Beginn eines neuen Sprints gewartet werden, bis der Test abgeschlossen ist, was die Produktentwicklung ziemlich in die Länge ziehen würde. Aber wie geht das Team dann damit um, wenn dieser Test Fehler erkennen lässt.

Natürlich ist es extrem Aufwändig, solche Leistungstests in jedem Sprint durchzuführen. Einfach wäre es, einen Testsprint zu planen und dann alles zusammen zu testen. Aber was macht das Team dann, wenn sich heraus stellt, dass es doch einige Fehler gibt, so das Technische Schulden aufgebaut wurden?

Eine Definition of Done sinnvoll zu erstellen, setzt viele Vorentscheidungen voraus und kann ausgesprochen komplex werden. Eine eineindeutig beste Lösung wird sich wohl nicht ergeben. Ein Kompromiss zwischen verschiedenen Alternativen ist hier eher wahrscheinlich.

Bei einer Definition of Done handelt es sich zumeist um eine Checkliste.

Was führt zu einer Veränderung der Definition of Done?

Manchmal bestehen am Anfang eines Projektes organisatorische Hürden, z.B. für die Durchführung von Nutzertests, weil die Nutzer nicht zur Verfügung stehen, oder weil es keine ausreichenden Testdaten gibt, etc. Im Verlauf der Leistungserstellung können diese Hürden beseitigt und damit die Definition of Done verändert werden. Es ist aber auch möglich, dass das sich eine bestehende Definition of Done als nicht detailliert genug erweist und darum geändert werden muss.

Wichtig ist hierbei, dass die Veränderung in der Entscheidung des Teams liegt und nicht von außen vorgeschrieben wird.

Definition of Done und Akzeptanzkriterien

Die Definition of Done legt fest, wann ein Inkrement vorliegt. Also welcher Zustand vorliegen muss, damit das Team etwas für "potentiell auslieferbar" hält. Die Definition of Done gilt dabei für alle Inkremente. Ob die Definition of Done erfüllt ist, prüft das Team vor dem Review durch den Product Owner.

Akzeptanzkriterien werden für jede User Story vom Product Owner formuliert. Sie gelten für eine bestimmte Funktionalität, die sich aus der User Story ergibt. Damit bekommt jedes User Story ihre eigene Checkliste mit Akzeptanzkriterien. Ob die Akzeptanzkriterien erfüllt sind, wird durch den Akzeptanztest geprüft, der spätestens im Review durch den Product Owner stattfindet.

Die Definition of Done und die Akzeptanzkriterien sind also unabhängig von einander und existieren bei der Leistungsentwicklung nebeneinander.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

SprintZiele

Agile Methode: Sprint Ziele (Timebox Ziel)

Es hat sich als sinnvoll erwiesen für jeden Sprint, bzw. für jede Timebox ein Ziel zu formulieren, dass durch diese Timebox erreicht werden soll.

Ein solches Ziel kann die Umsetzung einer User Story sein, oder das Erstellen von einer oder mehrerer Funktionalitäten. Es kann aber auch nur einen Teilbereich einer User Story oder eine Teilfunktionalität sein, die in einer Timebox fertig gestellt werden soll.

Das zentrale Element eines solchen Ziels ist der Aspekt des Wertes. Innerhalb einer Timebox muss etwas erstellt werden, dass einen Wert für den Product Owner, bzw. die Stakeholder darstellt. Dieses Inkrement muss einen selbständigen Wert darstellen. Der Wert muss also als solcher - unabhängig von allen Funktionalitäten die die Leistung sonst noch hat - entstehen.

Am Ende der Timebox muss in einem Review von den Stakeholdern überprüft werden können, ob das Ziel erreicht wurde.

Gegenseitige Verpflichtung von Team und Product Owner

Das Sprint Ziel ist eine gegenseitige Verpflichtung zwischen dem Team, das die Leistung erstellt und dem Product Owner als Vertreter der Auftraggeber und sonstiger Stakeholder.

Das Team verpflichte sich am Ende der Timebox das Ziel zu erfüllen.
Der Product Owner verpflichtet sich das Ziel nicht zu verändern und das Team zu unterstützen.

Das Ziel muss also über den Zeitraum des Sprints konstant bleiben, damit das Team konzentriert auf dieses Ziel hinarbeiten kann.

Zwischen "Änderung" und "Klärung"

Das Ziel darf nicht verändert werden. Wenn ein Ziel verändert wird, dann bedeutet das, dass neue Tasks hinzu kommen, alte Tasks entfernt werden, Funktionalitäten geändert werden, User Stories neu geschrieben werden und insgesamt ein Neuplanung des Sprint stattfinden muss.

Eine Klärung bedeutet, dass z.B. eine User Story detaillierter erläutert wird, so dass das Team besser versteht, was damit gemeint ist. Dabei dürfen dann aber keine zusätzlichen Tasks auftauchen, Funktionalitäten zusätzliche Eigenschaften bekommen oder ähnliches Zusätzliches entstehen, dass über die geplante WIP (Work in Process) der Timebox hinaus geht.

Entstehen bei der "Klärung" solche zusätzlichen Arbeiten, dann sind sie in Form einer neuen User Story zu formulieren und werden Teil des Product Backlogs - und in einem späteren Sprint bearbeitet.

Abnormaler Abbruch

Natürlich gibt es immer die Möglichkeit, dass ein Sprint abgebrochen werden muss, weil das gesetzte Ziel seinen ökonomischen Wert verloren hat. Hierbei handelt es sich jedoch um eine äußerst seltene Ausnahme. Wie häufig kann es vorkommen, dass ein Product Owner innerhalb von 4 Wochen erkennt, dass ein von ihm festgesetztes, mit den Stakeholdern abgesprochenes Ziel seinen ökonomischen Sinn verliert?

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

DailyStandup

Agile Methode: Daily Standup Meeting (Daily Scrum)

Das tägliche Treffen von fünf bis 20 Minuten Dauer für die Koordination des Teams innerhalb eines Tages gehört zum festen Bestandteil des agilen Arbeitens. Hier findet die Feinabstimmung des Arbeitsprozesses statt. Scrum Master und Product Owner können anwesend sein, um Fragen zu beantworten. Die Koordination und die Vorgehensentscheidungen liegen ausschließlich in der Hand des Teams.

DailyStandup Das Team verwendet zumeist ein Taks Board um sichtbar zu machen wer an welcher Aufgabe arbeitet.

Es hat sich eingebürgert, dass alle Teilnehmer bei diesen Treffen stehen.

Im Scrum sind drei Fragen festgelegt, die jedes Mitglied des Entwicklerteams zu beantworten hat:

Was habe ich seit dem letzten Daily Scrum für das Team geleistet?
An was möchte ich bis zum nächsten Daily Scrum arbeiten?
Welche Hindernisse behindern mich bei meiner Arbeit?

Was wird hier nicht besprochen?

Abstimmungen zwischen den einzelnen Teammitgliedern über technische Fragen, das Klären von internen und externen Konflikten und ähnliche komplexe Themen werden innerhalb des Daily Standup Meetings nichts besprochen. Dieses Meeting dient nur der Koordinination des Arbeitsprozesses. Für alle anderen Themen werden - auch auf diesem Treffen - andere Termine vereinbart.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

UserStoryFunktion

Agile Methode: User Story, Funktion, Task, Inkrement

Die Begriffe User Story, Funktion, Tasks und Inkrement gehen in der Literatur ziemlich durcheinander und werden je nach Autor unterschiedlich verwendet. Ebenso unklar ist die Meinung über die Beziehung zwischen den verschiedenen Begrifflichkeit.

Zusammenhang zwischen User Story, Funktion, Task und Inkrement

Der einfachste - aber selten gegebene Zusammenhang besteht darin, dass eine User Story einer Funktion entspricht und diese Funktion wird in einem Task hergestellt. Es entsteht ein Inkrement, das von dem Kunden selbständig nutzbar ist.

Häufiger Zusammenhang besteht in einer 1:N Beziehung. Eine User Story kann durch mehrere Funktionen erfüllt werden. Zur Erstellung einer solchen Funktion sind mehrere Tasks notwendig. Die Erstellung von einigen Tasks ist für mehrere Funktionen notwendig. Mehrere Funktionen zusammen genommen, ergeben ein Inkrement.

Beachten wir zusätzlich, dass jede User Story in Story Points geschätzt wird und mit einem Akzeptanzkriterium versehen ist und dass die Funktionen, bzw. Funktionalitäten der Leistung erst zu findende Problemlösungen sind, die basierend auf der User Story entwickelt werden, wobei hier auch wieder eine Schätzung auf Basis von Story Points vorgenommen werden muss und dann für jede Funktionalität die Arbeiten ermittelt werden müssen, die getan werden müssen (Task) und diese Tasks auf höchstens einen Arbeitstag heruntergebrochen und dann geschätzt werden müssen, dann ist der Planungsaufwand in den Agilen Methoden nicht gering.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

ProductBacklog

Agile Methode: Product Backlog

Ein Product Backlog ist eine priorisierte Liste der gewünschten Produktfunktionalitäten. Aus Sicht der Leistungsersteller ist es eine gemeinsame Vereinbarung, welche Leistung erstellt werden soll. Die Prioritäten legen fest, in welcher Reihenfolge diese Funktionalitäten gebaut werden sollen.

Product Backlog Inhalte

Das Product Backlog enthält die Leistungsbeschreibung, die erstellt werden soll. In Scrum ist der Product Owner für die Zusammenstellung, Organisation und Koordination des Product Backlogs zuständig. Er stimmt sich mit den Stakeholdern und dem Team ab.

Der Product Owner ist verantwortlich für das Product Backlog und er hat die letztendliche Entscheidungsgewalt darüber, was im Product Backlog steht - aber er erstellt und entwickelt das Product Backlog nicht alleine und bestimmt auch nicht exklusiv, was in ihm steht. Die Entwicklung des Product Backlog ist eine Gemeinschaftsaufgabe von Stakeholder, Auftraggebern, Entwicklern, Nutzern und anderen Menschen. Ohne die aktive Mitarbeit dieser Menschen ist der Product Owner nicht in der Lage, seine Aufgabe zu erfüllen.

Das Product Backlog wird ständig weiter entwickelt. Es ist ein living Document. Die Leistungsbeschreibungen werden verfeinert, ergänzt, ersetzt und entfernt. Natürlich werden sie auch priorisiert, bzw. geordnet. An diesem progressiven Prozess müssen sich alle oben genannten beteiligen. - Und zwar nicht nur einmalig, sondern über den gesamten Prozess der Leistungserstellung.

Ein Product Backlog hat nicht zwangsweise eine bestimmte Form. Insbesondere ist es nicht zwangsweise eine Sammlung von Moderationskarten auf einem White Board. - Und wer einmal versucht hat, ein Product Backlog für ein umfangreicheres Produkt auf einem Whiteboard zu erstellen, wird sehr schnell an die "Kapazitätsgrenzen" dieses Mediums gestoßen sein. Der zur Verfügung stehende Platz reicht einfach nicht aus. Ein Product Backlog kann eine Vielzahl von umfangreichen ergänzenden Dokumenten haben. Beispiel: Der Anforderer formuliert: "Ich erwarte, dass das Haus einen Dachstuhl hat." Soweit, so unklar. Es gibt mehrere Möglichkeiten mit dieser Unklarheit umzugehen. Wir können den Anforderer bitten, diese User Story so umzuformulieren, dass alle gesetzlichen Bestimmungen, bautechnischen Notwendigkeiten, statischen Voraussetzungen, etc. in der User Story genannt werden. Ich vermute, die meisten Bauherren werden damit überfordert sein. Und die meisten Whiteboards auch. Der andere Weg besteht darin einen Statiker und einen Architekten und andere Fachleute zu bitten, die Din Normen, gesetzlichen Vorschriften, etc. zusammenzustellen und von der User Story auf diese "Anhänge" zu referenzieren. Damit erhalten wir dann einfaches Product Backlog und mehrere Ordner an Unterlagen, die alle Bauvorschriften, statische Berechnungen, Architekturzeichnungen, etc. enthalten. Das Leistungserstellungsteam erhält so eine genaue Anweisung was es erstellen soll - diese ist allerdings nicht mehr "Leichtgewicht",

Es gibt keinen bestimmten Zeitpunkt, an dem eine Weiterentwicklung des Product Backlogs erfolgt. Sowohl das Team, das die Leistungserstellung umsetzt, als auch alle anderen Beteiligten arbeiten "immer mal wieder" an dem Product Backlog. Aber bevor eine neue Timebox beginnt, müssen die zu bearbeitenden Product Backlog Items einer Definition of Ready entsprechen, damit das Team mit der Leistungserstellung beginnen kann.

Ein Product Backlog besteht aus Product-Backlog-Elementen (Product Backlog Items, PBIs) Ein solches PBI kann eine User Story sein, soweit User Stories von den Beteiligten und insbesondere von den Leistungserstellern als ideal für die Beschreibung der Aufgabenstellung angesehen werden.

Ein PBI kann eine Funktion sein.
Es kann aber auch eine Änderung an einem bestehenden Produkt
oder ein Defekt der behoben werden soll,
oder eine technische Verbesserung,
oder eine Wissenserweiterung sein,
oder was auch immer von den Leistungserstellern getan werden soll.

Die Product Backlog Items müssen keine User Stories sein. Es kann auch jede anderer Form der Anforderungsbeschreibung gewählt werden. Auch wenn hier von User Stories gesprochen wird. Diese sind nur ein Beispiel für eine Vielzahl an Möglichkeiten. Hauptsache alle Beteiligten haben ein gemeinsames Verständnis.

Ein Product Backlog enthält alle funktionalen Anforderungen. Die nicht funktionalen Anforderungen können Teil des Product Backolgs sein, oder Teil der Definition of Done. Die nicht funktionalen Anforderungen müssen auf jeden Fall in einem dieser beiden Dokumente aufgeführt sein.

Das Product Backlog ist am Anfang wenig detailliert. Es entwickelt sich im Zeitverlauf in einem interaktiven Prozess der Diskussion zwischen Entwicklerteam, Product Owner und Stakeholdern. Aus einer recht oberflächlich formulierten kleinen Zahl an Anforderungen entwickelt sich mit der Zeit eine große Zahl an kleinstrukturierten detaillierten Anforderungen. In der nachfolgenden Grafik wird davon ausgegangen, dass die Backlog Elemente als User Stories formuliert sind. Das ist nicht zwingend. Jedes andere Format für die Beschreibung der Anforderungen kann ebenso gewählt werden.

Entwicklung der PBI im Zeitverlauf

Backlog Items werden mit zunehmender Zeit, durch die Gespräche zwischen Stakeholdern, Product Owner und Entwicklerteam detaillierter. Der Detaillierungsgrad wächst mit der zunehmend klareren Vorstellung der Beteiligten über das erwünschte Endergebnis des Entwicklungsprozesses.

DEEP-Kriterium für gute Product Backlogs

Für gute User Stories gibt es das INVEST-Kriterium. Für das Product Backlog wurde das DEEP-Kriterium entwickelt. DEEP bedeutet:

Detailed aporopiately (ausreichend detailliert),
Emergent (emergent),
Estimated (geschätzt),
Prioritized (priorisiert).

Detailed aporopiately (ausreichend detailliert)

Oben wurde ja bereits dargestellt, dass sich die Product Backlog Items im Zeitverlauf entwickeln. Die PBI sind nicht alle zum gleichen Zeitpunkt gleich detailliert. PBI, die in der nächsten Zeit abgearbeitet werden sollen, stehen im Product Backlog weiter oben und sind detaillierter. PBI´s, die erst zu einem späteren Zeitpunkt bearbeitet werden, können weiter unten stehen und können wesentlich unspezifischer sein.

Es ist sinnvoll, die später zu bearbeitenden PBI zunächst unspezifisch zu lassen. Je geringer die Detailtiefe, umso geringer ist der Änderungsaufwand. Bevor mit der Bearbeitung begonnen werden kann, muss das PBI allerdings der Definition of Ready entsprechen. Vorher darf es nicht in den Sprint Backlog aufgenommen werden. Erfolgt die Aufnahme in das Sprint Backlog, bevor der Detailierungsgrad ausreichend ist, kommt es während der Leistungserstellung ständig zu Rückfragen zwischen Anforderer und Leistungserstellungsteam. Das verhindert einen effizienten Arbeitsfluss (Flow). Im schlimmsten Fall erstellt das Entwicklerteam etwas, das an den Bedürfnissen der Anforderer vorbei geht. Das kann dazu führen, dass die gesamte Arbeitsleistung eines Sprints verloren geht. Die Team Velocity wird extrem negativ beeinflusst.

Emergent (emergent)

Emergent wird hier in der Bedeutung "ständig aktualisiert und gepflegt" verwendet. Das Product Backlog soll basierend auf einem ständigen Fluss von wirtschaftlich wertvollen Informationen weiterentwickelt werden. Wenn sich Kundenwünsche, Konkurrenzverhalten, etc. verändern, muss das Product Backlog angepasst werden. Neue Elemente müssen hinzugefügt und alte ständig verfeinert werden. Die Prioritäten passen sich ständig den veränderten Verhältnissen an.

Estimated (geschätzt)

Für jedes Product Backlog Element findet eine Größenschätzung statt. Diese Schätzung spiegelt den Aufwand wieder, der notwendig ist um das Element zu entwickeln. Basierend auf dieser Schätzung und dem geschätzten Wert des Inkrements wird die Priorität und damit die Position des PBI im Product Backlog ermittelt.

Die Schätzung erfolgt meisten in Story Points oder Idealtagen. Diese Größenschätzungen sollten relativ richtig, aber nicht extrem genau sein. Je weiter an der Spitze des Product Backlogs ein Element steht, umso weiter werden die Elemente in kleine Einheiten unterteilt und umso genauer muss auch die Schätzung werden.

Prioritized (priorisiert)

Auch die Priorisierung der Elemente muss genauer werden, je weiter sie nach oben rücken. Die Priorisierung der Elemente, die erst nach vielen Timeboxes erarbeitet werden sollen, kann eher grob bleiben.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

AbstimmungLinie

Agile Methode: Abstimmen auf einer Linie oder im Raum

Wenn verschiedene Meinungen oder Meinungsverteilungen sichtbar gemacht werden sollen, dann ist die "Abstimmung auf einer Linie" ein gutes Verfahren. Es geht schneller und ist dynamischer, also das übliche "Heben der Hand", wie es in den normalen Besprechungen üblich ist. Außerdem bekommt das Wort "Standpunkt" hier wieder einer reale Bedeutung.

Wie geht es?

Abstimmung auf Linie oder Abstimmung im Raum

Der Moderator markiert mit einem Seil oder einem Klebeband eine Linie innerhalb eines Raumes. Eine Zustimmungs-Ablehnungsskala - oder verschiedene Meinungen werden auf dem Boden, z.B. mit Moderationskarten sichtbar gemacht. Die Teilnehmer ordnen sich entsprechend ihrer Meinung in dem Raum.

Variante

Wenn sich die verschiedenen Meinungen nicht eindeutig auf einer Skala anordnen lassen, können auch Bereiche im Raum gekennzeichnet werden, denen sich die Teilnehmer dann zuordnen.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Murmelgruppe

Agile Methode: Murmelgruppe (Kleingruppenarbeit)

Ein großes Thema wird zunächst in Kleingruppen von drei bis fünf Personen erarbeitet. Die kleinen Gruppen bringen ihre Diskussionsergebnisse anschließend in einem Big-Picture zusammen.

Die Diskussion in Kleingruppen hat den Vorteil, dass jeder Teilnehmer seine Meinung einbringen kann. Die Hemmschwelle in einer Kleingruppe zu reden ist zumeist kleiner, als vor einer großen Gruppe. In der Kleingruppe kommen Ergebnisse schneller zustande, als in einer Großgruppendiskussion.

Wie geht es?

Murmelgruppe Moderationstechnik Kleingruppenarbeit

Der Moderator stellt das Thema vor.
Es werden Kleingruppen mit drei bis 5 Personen gebildet. Die Gruppen erarbeiten das Ergebnis innerhalb von 5 bis 15 Minuten. Die Diskussionszeit wird von dem Moderator vorgegeben. Die Diskussionsergebnisse werden von den Kleingruppen auf Moderationskarten notiert.
Der Moderator ruft die Gruppen zusammen. Ein Teilnehmer der jeweiligen Murmelgruppe stellt die Ergebnisse vor. Der Moderator sortiert die Ergebnisse auf einem Pin Board.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

WorldCafe

Agile Methode: World Cafe

Das World Cafe ist eine Moderationstechnik, bei der alle Teilnehmer in mehreren Gruppen eine Vielzahl an Themen bearbeiten. Im Gegensatz zum Open Space ist die Mitarbeit an allen Themen für die Teilnehmer möglich und erwartet. Die Themen werden an einzelnen Tischen bearbeitet. Auf jedem Tisch ist ein großes Blatt Papier, auf dem die Ergebnisse von allen Teilnehmern gesammelt werden. Für jedes Thema gibt es einen Moderator, der den neu ankommenden Gruppen die bisherigen Zwischenergebnisse präsentiert.

Ein Word Cafe dauert eine Stunde oder auch mehrere Stunden.

Wie geht es?

Moderationstechnik World Cafe

Die Themen werden vorbereitet. Für jedes Thema gibt es einen Tisch - meistens einen Stehtisch und eine Schreibunterlage auf dem Tisch, auf dem die Diskussionsergebnisse notiert werden.
Die Teilnehmer werden ausgelost oder wählen einen Themen-Tisch. Die Gruppen, die an dem jeweiligen Thementisch starten, sollten möglichst gleich groß sein.
Die Teilnehmer bearbeiten ein Thema über einen Zeitraum von 10 bis 30 Minuten.
Danach wechselt die Teilnehmergruppe zum nächsten Thementisch. Der Themen-Moderator (Gastgeber) stellt die bisherigen Ergebnisse kurz vor. Dann beginnt die Bearbeitung durch die Teilnehmer.
Die Teilnehmer bearbeiten alle Themen, bis sie wieder an ihrem ursprünglichen Tisch angekommen sind.
Dann werden die Ergebnisse von den Themen-Moderatoren zusammengefasst und allen Teilnehmern vorgestellt.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

OpenSpace

Agile Methode: Open Space

Die Moderationstechnik Open Space wird verwendet, wenn mit vielen Teilnehmern mehrere Themen bearbeitet werden soll. Open Space als Moderationstechnik ist geeignet, wenn alle Teilnehmer die Möglichkeit erhalten sollen, an allen Themen mitzuarbeiten, soweit ein Interesse an dem Thema besteht. Der Unterschied zum World Cafe: Alle Teilnehmer können, wenn sie wollen, an mehreren Themen teilnehmen. Sie können die Themen bearbeiten, sie sollen aber nicht.

Da die Teilnehmer die Möglichkeit bekommen sollen, sich in verschiedenen Themen einzubringen und mitzudiskutieren, sollte die Bearbeitungsdauer bei vier Themen mindestens ein Stunde betragen. Bei einer größeren Anzahl, wenn diese sehr umfangreich sind und die Teilnehmergruppe groß, auch gerne länger.

Ein Themen Owner ist für jedes Teilthema verantwortlich. Der Themen Owner:

Stellt den Teilnehmern das Thema vor.
Moderiert die Diskussion zu dem Thema.
Stellt die Diskussionsergebnisse am Ende der Veranstaltung allen Teilnehmern vor.

Die Teilnehmer können frei entscheiden, an welchen Themen sie mitarbeiten. Sie können während der Themenbearbeitung zwischen den Arbeitsgruppen wechseln.

Wie geht es?

Moderationstechnik Open Space

Open Space erfordert vier Vorgehensschritte:

Die Themen werden den Teilnehmern von dem Themen Owner vorgestellt.
Eine Agenda für die Themen wird festgelegt.
Die Themen werden von den Teilnehmern bearbeitet
Die Ergebnisse werden von dem Themen Owner zusammengefasst.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Dialogpyramiede

Agile Methode: Dialogpyramide

Mit der Dialogpyramide werden Arbeitsergebnisse schrittweise verdichtet. Alle Gruppen arbeiten an der gleichen Aufgabenstellung.

Die jeweils diskutierenden Gruppen bestehen aus 3er oder 4er Gruppen. Die Gruppen sollten nach Möglichkeit gleich groß sein.

Die Dialogpyramide besteht aus zwei bis drei Schritten.

Hilfsmittel

Pro Gruppe ein Hilfsmittel um die Diskussionsergebnisse aufzuzeichnen - am besten einen Flip Chart. Es kann aber auch ein großes Stück Papier auf dem Tisch genutzt werden, wie beim World Cafe.

In der zweiten Runde muss die Möglichkeit bestehen, diese Diskussionsergebnisse für alle Diskussionsteilnehmer sichtbar zu machen.

Jede "Ebene" sollte eine Diskussionszeit von mindestens 20 Minuten umfassen, so dass die Teilnehmer zunächst zu einem Ergebnis kommen müssen und dann die Ergebnisse auf Flip Chart formulieren müssen. Bei kontroversen oder schwierigen Themen ist es sinnvoll, eine Timebox für die Diskussionen zu setzen. Sonst besteht das Risiko, dass die Diskussionen sehr lang werden und / oder ergebnislos enden.

Beispiele für Aufgabenstellungen

Wie kann unsere Organisation agiler gemacht werden?
Welche Aufgabe sollen die früheren Projektleiter zukünftig in Projekten haben?
Wie soll das neue Leitbild unseres Unternehmens aussehen?

Dieses Diskussionsverfahren ist also immer dann geeignet, wenn viele Menschen ein aktives Interesse an den Ergebnissen haben und in die Diskussion eingeschlossen werden sollten.

Wie geht es?

Aufbau einer Dialog Pyramide

Im ersten Schritt erarbeiten dreier oder vierer Gruppen ein Ergebnis für die Aufgabenstellung. Das Ergebnis wird auf einem Flip Chart festgehalten.
Im zweiten Schritt kommen die Mitglieder der Kleingruppen zu einer größeren Gruppe zusammen. Die Ergebnisse, die von beiden Gruppen erarbeitet wurden, werden nach einer Diskussion auf einem neuen Flip Chart zusammengefasst.
In einem dritten Schritt kommen jetzt alle Teilnehmer zusammen und erarbeiten, basierend auf den Ergebnissen der zweiten Ebene, ein Gesamtergebnis.

Variante für die Dialogpyramide

Die Zahl der Diskussionsteilnehmer ist allerdings - wegen der sehr großen Diskussion-End-Runde - begrenzt. Bei über 20 Teilnehmern ist eine aktive Diskussionsteilnahme aller Menschen kaum noch möglich.

Dann ist es sinnvoller, wenn aus jeder Diskussionsrunde nur ein oder zwei Mitglieder als Repräsentanten entsendet werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Fischbowl

Agile Methode: Fishbowl-Diskussion

Die Bezeichnung "Fishbowl" beschreibt die Sitzaufstellung der Moderationstechnik. Die Diskussionsplätze sind in der Mitte der Teilnehmer angeordnet. Die Mehrheit der Teilnehmer beobachtet die Diskutierenden. Die Diskutierenden sitzen in der Mitte, werden also von allen Seiten beobachtet, wie die Fische in einem Goldfischglas.

Aufbau der Fishbowl Diskussion

Alle Teilnehmer können so der Diskussion folgen. Die Zahl der Redenden ist auf die Personen begrenzt, die in dem Goldfischglas sitzen. An der Diskussion können bis zu 100 Personen teilnehmen - soweit das Goldfischglas mit Mikrofonen ausgerüstet ist.

Wie geht es?

Basis Aufbau

In dem Goldfischglas befinden sich drei bis fünf Stühle.
Die Teilnehmer stehen um diese Stühle herum oder sitzen ebenfalls auf Stühlen. Bei großen Gruppen kann das Goldfischglas auch auf einer kleinen Bühne stehen.
Es werden, der Anzahl der Stühle entsprechend, Teilnehmer benannt, die das Goldfischglas zunächst füllen. Die Teilnahme sollte natürlich freiwillig sein.
Das Publikum hört der Diskussion zu.

Variante 1: Diskussion mit offenem Goldfischglas

Ein Stuhl in der Mitte ist immer frei.
Jedes Mitglied des Publikums darf diesen Stuhl jederzeit einnehmen. Dann muss ein anderes Mitglied der Diskussionsrunde seinen Stuhl räumen. Wenn die Diskutierenden sich uneinig sind, wer die Diskussion verlassen muss, dann ist der, der bereits am längsten in der Runde sitzt, verpflichtet, seinen Stuhl zu räumen.

Variation 2: Diskussion mit Zeitscheibe im geschlossenen Goldfischglas

Alle Plätze im Goldfischglas sind besetzt.
Wenn die Diskussionszeit abgelaufen ist, wird die ganze Gruppe der Diskussionsteilnehmer ausgetauscht und neu besetzt.
Die Diskussionszeit sollte dann die Dauer von 10 Minuten nicht übersteigen.

Variation 3: 3-5-8 dann 5

Jeder Diskussionsteilnehmer hat eine Timebox. Danach muss er die Diskussion verlassen. Jeder Teilnehmer darf nur einmal an der Diskussion teilnehmen.

Zum Start des Prozesses: Per Los wird entschieden, welcher der ersten drei Teilnehmer eine Zeitschiene von 3, 5 von 8 Minuten hat.
Nach 3 Minuten verlässt der erste Teilnehmer die Diskussion. Ein neuer Teilnehmer kommt dazu, der jetzt fünf Minuten in der Diskussionsrunde bleibt.
Nach 5 Minuten verlässt der zweite Teilnehmer der ersten Runde die Diskussion und wird durch einen neuen Teilnehmer ergänzt. Dieser neue Teilnehmer hat jetzt 5 Minuten Zeit, an der Diskussion teilzunehmen.
Nach 8 Minuten verlässt der letzte der ersten Teilnehmerrunde die Diskussion. Ein neuer Teilnehmer bleibt in einer Timebox von 5 Minuten in der Diskussionsrunde.

Hilfsmittel für Variante 3:

Eieruhr oder an andere Zeitmesser pro Diskussionsteilnehmer

In Variante 3 hat jeder Teilnehmer die Möglichkeit, über einen Zeitraum von 5 Minuten seine Meinung in die Diskussion einzubringen. Bei nicht so großen Gruppen kann also jeder seine Meinung einbringen. Eine solche Diskussionsrunde dauert pro Teilnehmer dann ca. 5 Minuten. Hier kommen auch Minderheiten zu Wort, ohne das ein Teilnehmer die Diskussion dominieren kann.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Grossgruppen

Agile Methode: Kommunikation in Großgruppen

Wenn mit agilen Methoden gearbeitet wird, dann vergrößert sich die Zahl der Personen, die gemeinsam kommunizieren sollen sehr schnell, sobald die Leistungserstellung von mehreren Teams durchgeführt werden und zusätzlich Nutzer, Auftraggeber und andere Stakeholder hinzugezogen werden.

Hier werden sechs Techniken vorgestellt:

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Von der User Story zum Task

Hier wurde bewusst ein Beispiel gewählt, in der ein Task mehr als einen Story Point haben kann und auch nichts innerhalb eines Tages abgearbeitet werden kann.

In der Literatur findet sich häufig die Forderung dass die Relation: 1 Story Point = 1 Tag eingehalten wird. Das hat ein paar Vorteile:

Ein Task kann zwischen zwei Daily Standups erledigt werden. Wenn es zu Verzögerungen kommt, ist diese Verzögerung sofort sichtbar.
Im Burdown Chart verläuft das Projekt genau über die Ideallinie, soweit alles funktioniert, wie geplant.
Wenn die Zahl der Tasks durch die Zahl der Personentage geteilt wird, die in einem Sprint zur Verfügung stehen, dann kann leicht errechnet werden, ob die Arbeitsmenge zur Sprintzeit passt.

Genau dieses Vorgehen hat aber auch einige Nachteile

Nehmen wir einmal an, wir haben ein Team von 7 Personen und eine Timebox von 20 Arbeitstagen. Das gibt dann 140 Tasks, die am Anfang eines Sprints auf dem Kanban Board sind.
Der Planungsaufwand für eine Timebox wird extrem groß.
Warum wird überhaupt in Story Points gerechnet, wenn ein Story Point = 1 Personentag ist?

KanbanBoard

Agile Methode: Kanban Board für einen Leistungserstellungsprozess

Auf diesem Kanban Board wird ein Leistungserstellungsprozess abgebildet. Diese Form des Kanban Boards spielt bei der Neuprodukterstellung nur eine untergeordnete Rolle. Bei der Durchführung von Wartungsprojekte oder im Zusammenhang mit einer Lean Produktion ist es das Mittel der Wahl um Prozesse transparent zu machen zu optimieren.

In der ersten Spalte werden die Aufgaben (Task, Arbeitspakete) gesammelt, die abgearbeitet werden müssen.
In den drei nachfolgenden Spalten wird der Prozess der Leistungserstellung durchlaufen. Die einzelnen Prozessschritte können nur eine unterschiedliche Zahl an Tasks aufnehmen. In der Spalte "Freigabe" könnte noch ein Task mehr bearbeitet werden.
In der vierten Spalte werden die abgeschlossenen Tasks gesammelt.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

KanbanTimebox

Agile Methode: Kanban Board für eine Timebox bzw. für einen Sprint

In der ersten Spalte steht die Priorität der User Stories die für den Sprint ausgewählt wurden.
In der zweiten Spalte die Tasks (Arbeitspakete), die zur Umsetzung der User Stories notwendig sind. In grüner Schrift findet sich auf den Karten der Tasks die Schätzung der Story Points für die einzelnen Tasks. Die maximale Zahl der Story Points für diese Timebox ist auf der roten Moderationskarte verzeichnet.
Die dritte Spalte enthält die Tasks, die zurzeit von dem Team bearbeitet werden. Auch hier ist die maximale Zahl der Story Point auf der roten Moderationskarte genannt. Erst wenn die Tasks, die in der Spalte in Arbeit in die Spalte Done wandern, darf ein neuer Task gewählt werden. Die Tasks, die zu der User Story mit der obersten Priorität gehört, werden zuerst abgearbeitet, soweit, damit die maximal Zahl an Story Points des Spalte nicht überschritten werden. Sonst wird ein Task mit einer niedrigeren Priorität gewählt.
Die vierte Spalte enthält die Tasks, die bereits abgearbeitet wurden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

KanbanBoardubersicht

Agile Methode: Kanban Board

Kanban wurde zunächst im Lean Management entwickelt. Hier geht es aber nicht um Kanban und die dahinter liegenden Prinzipien und Handlungsweisen. Es geht nur um die Nutzung von verschiedenen Kanban Board Techniken, die sich im agilen Umfeld als nützlich erwiesen hat.

Es gibt keine Vorgaben, wie genau die Wände aufgebaut werden sollen. Alle hier vorgestellten Varianten sollen als nur Anregungen für die eigene Auswahl geben.

Die Aufgaben, die immer in der linken Spalte stehen, werden von Außen vorgegeben oder in einer gemeinsamen Planung des Teams und der Anforderer bestimmt. Diese Aufgaben sind noch nicht begonnen. Das Entwicklungsteam arbeitet die Aufgaben dann von links nach rechts ab. In der rechten Spalte werden die fertigen Ergebnisse gesammelt.

Die Anzahl der Aufgaben die in einer Spalte stehen dürfen ist nach vorher festgelegten Regeln begrenzt um paralele Arbeiten zu begrenzen. Erst wenn ein Arbeit abgeschlossen ist, darf eine neue Task von links nach rechts nachrücken (One Pice Flow). Damit entsteht ein Arbeitsprozess nach dem Pull-Prinzip.

Es gibt vielen Software Programme, die ein solche Planung mit Signalkarten unterstützen. Ein gute Beispiel hierfür ist Trello (https://trello.com/platforms). Das ist für Teams, die über keine Möglichkeiten verfügen ein großes Pin-Board über den gesamten Leistungserstellungsprozess nutzen zu können hilfreich und für verteilte Team eine Notwendigkeit. Für alle Teams, die ihre Daily Meeting in einer Face to Face Situation durchführen und die über die entsprechende Raumkapazitäten verfügen, hat es sich bewährt die Wände physikalisch zu gestalten. Das bietet einen besseren Überblick. Das Team kann davor stehend gemeinsam planen.

Eine Kombination mit einem Work Breakdown Chart ist ideal.

Kanban Board werden in vielen Zusammenhängen genutzt. Eine Nutzung für einen einfachen Prozeß in mehreren festgelegten Schritten ist ebenso üblich, wie die Nutzung für die Organisation und Steuerung einer Timebox.

Wir Kanban für die Organisation von Dienstleistungen, z.B. der Wartung von Software genutzt, dann können die einzelnen Aufträge mit Prioritäten versehen sein, die den Prozess schneller durchlaufen müssen, als die Aufgaben mit einer niedrigeren Priorität.

Auch für die Organisation von mehreren aufeinanderfolgende Relases oder mehrere aufeinanderfolgenden Sprints ist ein Kanban Board ein gutes Instrument. Hier kann dann abgebildet werden, welche User Stories in welchem Release oder welchem Sprint erarbeitet werden.

Verbesserungen die viel Zeit in der Umsetzung erfordern können als User Stories in das Kanban Board eingefügt werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Qualitssicherung

Agile Methode: Methoden zur Qualitätssicherung

Eine der Prinzipien einer agilen Leistungserstellung besagt, dass eine Leistung nur dann von Wert ist, wenn sie fehlerfrei ist. Jedes Inkrement, das erstellt wird, sollte sofort getestet und somit fehlerfrei übergeben werden. Es gibt ein Reihe an Techniken, um eine optimale Produktqualität zu erreichen, die von einer agilen Umgebung verwendet werden.

Kontinuierliche Integration

Alle Ergebnisse, des Leistungserstellungsprozesses werden kontinuierlich in die Gesamtleistung integriert.

Die integrierten Ergebnisse werden durch automatisierte Tests überprüft. Sollten Fehler auftreten, dann werden diese zuerst beseitigt, bevor die Arbeit fortgesetzt wird.

Gemeinsame Eigentümerschaft

Alle Ergebnisse gehören allen Teammitgliedern, bzw. allen Teams. Damit sind auch alle für das Ergebnis verantwortlich und dürfen Fehler an jedem Teilergebnis beseitigen.

Teamverantwortung für die Integration

Jedes Team und jedes Teammitglied ist selber dafür verantwortlich, dass seine Ergebnisse in das Gesamtergebnis integrierbar sind.

Ermächtigung zur direkten Kommunikation

Jedes Teammitglied kann auf jedes andere jederzeit zugehen und Fragen klären oder Behinderungen beseitigen. Das gilt auch teamübergreifend, wenn mehrere Teams an einer Leistung arbeiten.

Test zuerst

Bevor mit der Erstellung der eigentlichen Leistung begonnen wird, werden die Tests entwickelt, die zur Überprüfung der Ergebnisse dienen. Das zwingt die Entwickler, den Prozess der Entwicklung vom Ergebnis aus durchzudenken. D.h. von Hinten nach vorne. Bei der Leistungserstellung unterstützt das Vorhandensein des Testes die Produktion von Qualität.

Restrukturierung und Überarbeitung (Refactoring)

Leistungen werden schnell und regelmäßig geliefert, überprüft und angepasst. Dabei wird die Arbeitsweise regelmäßig durchdacht und angepasst. Durch die regelmäßige Überprüfung wird das Gesamtsystem robust gegen Änderungen.

Gemeinsames Arbeiten (Pair Work, Pair Working)

Das Arbeitsergebnis wird von zwei Personen gemeinsam erstellt. Beim Pair Programming arbeiten beispielweise zwei Entwickler an einem Computer. Während der eine programmiert, kontrolliert der Anderen den Code. Dadurch wird in vielen Fällen die Arbeitsgeschwindigkeit erheblich erhöht und die Zahl der Fehler reduziert.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Timebox

Agile Methode: Timebox (Sprint)

Eine Timebox ist eine festgelegte Dauer, in der etwas getan wird. Abgeleitet aus Scrum wird hierfür häufig der Begriff "Sprint" verwendet.

Eine Timebox darf in ihrer Länge nicht verändert werden. Verändert werden darf aber die Zahl der Tasks, Story Point, Inkremente, etc. die innerhalb der Timebox abgearbeitet werden sollen, soweit das Team nicht in der Lage ist, die Arbeit zu schaffen. Das ist dann ein Indikator dafür, dass das Team sich verschätzt hat und nicht in der Lage ist, die gesteckten Ziele zu erreichen.

Innerhalb eines Sprint muss mindestens ein Inkrement - also ein Stück Leistung, das selbständig einen Wert darstellt, geschaffen werden.

Meistens wird die Zahl der Timeboxes zu Beginn der Leistungsentwicklung festgelegt. Es ist sinnvoll, dass Timeboxes immer die gleiche Länge haben. Innerhalb einer Timebox sollten:

keine das Ziel beeinflussenden Veränderungen vorgenommen werden.
die Mitarbeiter im Team nicht verändert werden.

Welche Vorteile hat das Arbeiten mit Timeboxing?

WIP-Limit festlegen

Für eine Timebox wird die Work in Process (WIP) festgelegt. Dabei ist die WIP die Menge an Arbeit, die innerhalb einer Timebox angefangen wurde, aber noch nicht fertig gestellt. Das Entwicklerteam wählt nur die Arbeiten für eine Timebox aus, die er glaubt innerhalb dieser Timebox fertigstellen zu können.

Priorisierung erzwingen

Da nur ein Teil der Arbeit in einer Timebox erarbeitet werden kann, wird für die Timebox nur die Arbeit ausgewählt, die einen Wert schafft.

Fortschritt erkennbar machen.

Innerhalb einer Timebox muss mindestens ein wichtiger Teil der zu erstellenden Leistung fertig sein. Dadurch, dass innerhalb einer recht kurzen Timebox ein Teil der Arbeit an der Gesamtleistung fertig sein muss, wird ein Arbeistfortschritt erkennbar. Auch wenn große Funktionalitäten nicht innerhalb einer Timebox fertig gestellt werden können, werden diese Funktionalitäten so aufgeteilt, dass Teilfunktionalitäten fertig sind. So wird der Gesamtfortschritt der Funktionalitäten sichtbar.

Unnötigen Perfektionismus verhindern

Es gibt immer wieder Ergebnisse, die wir versuchen möglichst perfekt zu machen und die wir darum nicht fertig bekommen. Das Timebxing zwingt dazu "zu einem Ende zu kommen", da ein fester Zeitpunkt bestimmt ist, zu dem wir das Ergebnis, dass "gut genug" ist, als Lösung abgeben müssen.

Zur Fertigstellung motivieren

Wenn Menschen den Endzeitpunkt kennen und diese in einer nicht so großen Ferne liegt, dann sind sie motiviert an der Fertigstellung zu arbeiten. Ein bekannter Endtermin macht auch nicht so beliebte Arbeiten dringend.

Verbesserung der Prognose

Durch das WIP-Limit der einzelnen Timeboxen und die Erfahrung mit diesem WIP-Limit über mehrere Timeboxen lässt sich leichter vorhersagen, was innerhalb von z.B. einem Jahr noch fertig werden wird.

Schnelles Feedback

Wenn die Ergebnisse eines Sprints am Ende des Sprints begutachtet und die Arbeitsweise innerhalb des Sprints überprüft wird, erhält das Team schnell ein Feedback und kann sein Verhalten entsprechend ändern, bzw. in einem späteren Sprint nachbessern.

Begrenzte Fehler / Begrenztes Risiko

Wenn die Ergebnisse jedes Sprints überprüft und bewertet werden, kann im schlimmsten Fall die Arbeit eines Sprints verloren sein. Das begrenzt das Risiko für den Auftraggeber auf die Leistungen eines Sprints.

Konstante Begeisterung

Kurze Sprints helfen die Begeisterung der Leistungsersteller aufrecht zu erhalten. Die meisten Gruppen verlieren die Begeisterung für eine Aufgabe, wenn die "Belohnung", bzw. Anerkennung für die erbrachte Leistung in weiter Ferne liegt. Durch die Anerkennung, die das regelmäßige Review der innerhalb eines Sprints geleisteten Arbeit, bleibt die Begeisterung für die Aufgabe bestehen.

Arten von Timeboxes

Umsetzungs Timebox (Umsetzungs Sprint)

In einer Umsetzungs Timebox werden die Tasks zur Leistungserstellung abgearbeitet. Diese Art der Timeboxes sind der "Normalfall". In Scrum gibt es nur diese Form der Timebox.

Innovations-Timebox und Planungs-Timebox (IP-Sprints)

werden auch als Innovations- und Planungs-Sprints bezeichnet. Insbesondere in dem Scaled Agile Framework (SAFe) wir die Nutzung dieser Timeboxes empfohlen. IP-Sprints sollen dem Umsetzungsteam Gelegenheit geben Aufgaben abzuarbeiten, die sich nur schwer in die "normalen Sprints" integrieren lassen.

Außer zur Planung können sie auch für folgende Aufgaben genutzt werden:

Etappen Ergebnisse: Um die Länge der Sprints gleich zu halten, können Etappenergebnisse, die aus den Ergebnissen mehrerer parallel arbeitender Team bestehen, die nach einer Etappe zusammen gefügt werden, in einem IP-Sprint bearbeitet werden. Hier könnten dann folgende Aufgaben durchgeführt werden: Etappen-Review, Etappen Retrospektive und Etappen Planung.
Fortbildungsmaßnahmen: In einer normalen Timebox kann das Team nur schwer auf einzelne Mitglieder verzichten. Aus- und Weiterbildung ist aber eine Notwendigkeit, wenn sich das Team weiter entwickeln soll. Ein IP-Timebox bietet hier eine gute Möglichkeit, diese Weiterbildungsmaßnahmen zu ermöglichen, ohne den Teamflow in einem normalen Sprint negativ zu beeinflussen.
Innovation: Ein IP-Sprint bietet den Raum für Innovationstage, in denen die Teammitglieder andere Projekte einbringen können, die das ganze Projekt weiterbringen.
Infrastruktur: Es können neue Basistechnologien implementiert werden oder Restrukturierungsaufgaben durchgeführt werden.

Härtungssprints gegen technische Schulden

Diese Timeboxes dienen dazu Qualitätsmängel, die sich in den vorherigen Sprints eingeschlichen haben, zu beseitigen. Im Idealfall sind solche Härtungssprints bei einer agilen Leistungserstellung nicht notwendig, da die Qualitätssicherung innerhalb des Leistungserstellungsprozess stattfinden soll. Wenn die Definition of Done jedoch nicht ideal ist oder nicht vollständig erfüllt wurde, können solche Härtungstimeboxes notwendig sein, bevor sich zu viele technische Schulden aufhäufen.

Inhalte einer Timebox

Eine Timebox ist zunächst einmal ein Zeitraum, in dem etwas passiert, dessen Anfangs- und Endzeitpunkte festgelegt werden. Sie ist also von einer festen Dauer.

Bei Scrum wird innerhalb einer Timebox:

Der Sprint geplant (Sprint Planing),
Inkremente erstellt,
Inkremente von den Stakeholdern überprüft (Sprint Review),
Die Leistung des Teams und die Arbeitsprozesse verbessert (Sprint Retrospektive).

Bei anderen Agilen Methoden findet die Planung für die Timebox zeitlich vor der Timebox statt. Auch Review und Retrospective können außerhalb der Timebox, zeitlich später stattfinden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

BurndownChart

Agile Methode: Burndown Chart (Burndownchart, Burndown Graphic)

Burndown Chart ist eine Methode, mit der die Fortschritte der Leistungserstellung innerhalb einer Timebox abgebildet werden kann.

Hilfsmittel / Voraussetzungen

Ein Flip-Chart oder Pin Board, das über den Verlauf der Timebox nicht benötigt wird und für alle Beteiligten sichtbar ist.

Voraussetzung:

Die Tasks (Arbeitspakete) oder Inkremente, die in der Timebox abgearbeitet, oder erstellt werden sollen, sind benannt und der Timebox zugewiesen.
Die Arbeitspakete sind so skaliert, dass sie nicht länger als einen Tag dauern.

Wie geht es?

Vertikale (y-Achse): Die Gesamtzahl der Arbeiten, die innerhalb der Timebox zu erledigen sind.

Horizontale (X-Achse): Die Tage, die die Timebox dauern soll.

Das Umsetzungsteam aktualisiert jeden Tag beim Daily Standup Meeting den Burndown Chart. Für den jeweiligen Tag wird die Zahl der noch offenen Arbeitspakete eingetragen.

Liegt die Zahl der verbleibenden Arbeitspakete unter der Ideallinie, wird mehr Arbeit geleistet als geplant. Liegt die Zahl der Arbeitspakte über der Ideallinie, dann ist das Team langsamer als geplant.

Burndown Charts werden in vielfältigem Zusammenhang genutzt. Es gibt:

Sprint Burndown Chart
Etappen Burndown Chart
Product Backlog Burndown Chart
usw.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

FeaturePoints

Agile Methode: Feature Points

Die Schätzung erfolgt analog zur Schätzung mit Story Points. Im Unterschied zur Stories werden hier die "Features" geschätzt. D.h. es wird die Komplexität von einzelnen Inkrementen relativ geschätzt. Mit den Feature Points kann das Team bestimmen, wie viele und welche Features in eine Timebox passen. Die Team Velocity kann ebenso aus Feature Points ermittelt werden.

Hilfsmittel / Voraussetzungen

Die Features (Funktionalitäten) müssen vorher aus dem Product Backlog entwickelt werden.

Wie geht es?

Aus dem Product Backlog, einer Etappe oder eines Sprints, wird ein Feature ausgewählt, das von dem Team für relativ klein gehalten wird.
Dieses Feature bekommt den Wert 1 zugewiesen.
Alle weiteren Features werden relativ zu diesem Feature geschätzt.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

NormalisierteSchatzung

Agile Methode: Normalisierte Schätzung (Normalized Estimation)

Mit der normalisierten Schätzung wird versucht, eine gemeinsame Schätzbasis zwischen verschiedenen Teams zu erarbeiten.

Bei der Schätzung auf Basis von Story Points wählt jedes Schätzteam eine individuelle User Story als Referenzwert für den Schätzwert 1. Da jedes Team seinen eigenen Referenzwert auswählt, sind die Story Points der einzelnen Teams nicht vergleichbar.

Damit ist auch die Team Velocity nicht vergleichbar. Die Story Points verschiedener Teams dürfen nicht addiert werden. Dieses Problem versucht das Scaled Agile Framework (SAFe) zu lösen.

Wie geht es?

Jedes Team wählt eine Referenzstory, die ungefähr einen halben Tag Aufwand zur Umsetzung benötigt. Oder die Teams einigen sich auf eine Story als Referenz. Eine weitere Möglichkeit besteht darin, mehr als eine Story als Referenz zu nutzen.
Alle anderen Storypoints werden anschließend auf Basis dieser Referenzschätzung geschätzt.

Hier wird eine Übertragung gemacht. 1 Storypoint = 1 Personentag. Die Schätzung findet faktisch nicht auf Basis von Storypoints, sondern auf Basis von Personentagen statt, die jetzt als Storypoints bezeichnet werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

TeamVelocety

Agile Methode: Team Velocity (Team Performance)

Über die Team Velocity kann die Arbeitsgeschwindigkeit eines Teams und die Weiterentwicklung eines Teams gemessen werden. Außerdem kann eine Prognose gemacht werden, wie viele Story Points von einem Team innerhalb einer Timebox geleistet werden. Außerdem kann der Product Owner damit den Fortschritt der Leistungsentwicklung innerhalb einer Timebox verfolgen.

Hilfsmittel / Voraussetzungen

Der erwartet Aufwand für die Leistungserstellung der einzelnen User Stories oder Inkremente muss in Storypoints geschätzt sein.

Die verwendeten Timeboxes müssen gleich groß sein.

Wie geht es?

Die Zahl der Storypoints, die ein bestimmtes Team innerhalb einer Timebox abgearbeitet hat, wird ermittelt.
Die Erwartung, wenn sich das Team weiterentwickelt: Es arbeitet in der nächsten Timebox mindestens so viele Story Point ab, wie in der vorherigen. Unter dieser Annahme ist die Zahl der Storypoints für die nächste Timebox als Basis für die auszuwählenden User Stories, die in die Timebox passen, recht einfach.
Mit zunehmender Zahl der durchlaufenen Timeboxes kann die durchschnittliche Zahl an Storypoints berechnet werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

PlaningPoker

Agile Methode: Magic Estimation - die magische Schätzung

Ziel / Nutzen

Die Magic Estmation ist eine relative Schätzung, d.h. alle zu schätzenden User Stories, Tätigkeiten, etc. werden in eine Rangfolge des Aufwandes gebracht.

Hilfsmittel

Planning Poker Karten oder andere Schätzwerte

Wie geht es?

Die Schätzwerte werden auf dem Tisch ausgelegt.
Das Schätzteam sortiert die User Stories oder was sonst geschätzt werden soll, zu den jeweiligen Schätzwerten.
Sind sich die Teammitglieder nicht einig, dann erläutern sie ihre Entscheidung mit allen anderen.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

PlaningPoker2

Agile Methode: Schätzen mit Planning Poker

Ziel / Nutzen

Mit dem Planning Poker kann alles geschätzt werden. Die Ergebnisse von einem Planning Poker werden realistischer, wenn die Schätzenden gleichzeitig die Leistungserbringer sind, die mit den Schätzergebnissen leben müssen.

Hilfsmittel

pro Schätzer einen Satz Planning Poker Karten

Wie geht es?

Jeder Schätzende hat einen Satz an Planinng Poker Karten. Auf den Karten stehen die Werte: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Diese Zahlen können je nach Planning Pokersatz auch abweichen. Typisch ist, dass die Differenz der Zahlen größer wird, wenn die Zahlen größer werden.
Für jedes zu schätzende Element, schätzt jeder Schätzer verdeckt wieviel Aufwand er erwartet.
Die Vertreter des niedrigsten Werte und des höchsten Wertes erläutern die Gründe für ihre Schätzung.
Danach erfolgt eine neue Schätzung.
Dieser Prozess wird fortgesetzt, bis sich die Schätzungen auf einen Schätzwert angenähert haben.

Auch hier besteht natürlich die Möglichkeit, die Schätzergebnisse wieder in Personentage umzurechnen, wenn die Personentage für die kleinste Einheit zusätzlich geschätzt werden. Problematisch kann es werden, wenn die Ergebnisse von mehreren Planning Poker Runden mit unterschiedlichen Teilnehmern zusammen genommen werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Schatzen

Agile Methode: Schätzen im agilen Umfeld

Im klassischen Projektmanagement ist das Schätzen für die Projektplanung von Bedeutung. Von vielen Menschen, die in Projekten arbeiten, wird das Schätzen von Dauer, Arbeitsstunden und Kosten als der aufwendigste und unangenehmste Teil des Planungsprozesses empfunden.

Da die Planung in agilen Methoden scheinbar keine so große Rolle spielt, entsteht hier schnell die Erwartung, "nicht mehr schätzen" zum müssen. Diese Hoffnung deckt sich aber nicht mit der Realität. Auch hier müssen die Beteiligten und insbesondere die Menschen, die die Leistungen entwickeln, ständig schätzen.

Exaktheit vor Genauigkeit

Die wichtigste Schätzregel, wenn sie agil arbeiten:

Was bedeutet das?

Stellen sie sich vor, jemand schätzt und kommt zu folgender Aussage:

"Am ersten Dienstag im Februar des nächsten Jahres in Frankfurt wird es zwischen 17:00 und 17:15 genau 2 mm Niederschlag am Bahnhof geben."

Diese Aussage ist sehr genau.
Wie viel Aufwand steckt in dieser Aussage: Der Schätzende hat die Wetterdaten des Frankfurter Bahnhofs über die letzten zehn Jahre in seine Analyse einfließen lassen. Er hat Wahrscheinlichkeiten für die Niederschlagswahrscheinlichkeit und Niederschlagsmenge berechnet. Er hat zusätzlich ein globales Langzeit Wettermodell bemüht uns außerdem die Temperaturkurve für Frankfurt in Kombination mit der Niederschlagswahrscheinlichkeit statistisch kombiniert. Er hat sich also alle Hilfsmittel, die ihm zur Verfügung standen, genutzt und alles getan, damit diese Schätzung so exakt wie möglich wird. Dafür hat er natürlich viel Arbeitszeit aufwenden müssen. Es hat sich gelohnt. Oder?
Würden sie dieser Schätzung vertrauen? Würden sie sich darauf verlassen, dass dieses Ereignis genauso eintritt?

Nehmen wir im Vergleich ein andere Aussage:

"Im Frühjahr des nächsten Jahres wird es am Frankfurter Bahnhof regnen."

Diese Aussage ist sehr exakt.
Der Aufwand, der hinter dieser Schätzung liegt, ist kaum messbar. Die Kausalität, die der Schätzende genutzt hat, war: Im Frühjahr innerhalb von drei Monaten irgendwann Regen => also auch am Frankfurter Bahnhof. Hat sich der Aufwand gelohnt?
Würden Sie dieser Schätzung vertrauen? Würden Sie darauf vertrauen, dass dieses Ereignis eintritt?

Genauigkeit vor Exaktheit

Die erste Schätzung ist sehr genau. Das Eintreten ist sehr unwahrscheinlich. Der Aufwand sehr groß. Der Nutzen der Schätzung ist sehr gering.

Die zweite Schätzung ist sehr exakt. Das Eintreten der Schätzung extrem wahrscheinlich. Der Aufwand minimal. Aber der Nutzen der Schätzung ist nicht vorhanden.

Irgendwo zwischen diesen beiden Extremwerten liegt eine Schätzung, die einen guten Kompromiss zwischen den beiden Schätzungen darstellt. Diese gilt es zu finden.

Es gibt eine Reihe an Schätzverfahren, die in einem agilen Umfeld bevorzugt werden. Allerdings können auch alle anderen Schätzverfahren, die sich im Projektmanagement etabliert haben, eingesetzt werden. Umgekehrt gilt aber auch, dass alle Schätzverfahren die typisch für ein agiles Vorgehen sind, im klassischen Projektmanagement verwendet werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

StoryPoints

Agile Methode: Schätzen mit Story Points (Storypoint)

Ziel / Nutzen

Story Points werden verwendet, um die relative Umsetzungskomplexität von User Stories zu schätzen. Dieses Schätzverfahren abstrahiert von der Aufwandsschätzung in Stunden. Das kann vorteilhaft sein, weil das Team mit zunehmender Erfahrung lernt und damit die Umsetzungsgeschwindigkeit zunimmt.

Außerdem findet eine Abstraktion von den verschiedenen Arbeitsgeschwindigkeiten der Teammitglieder statt. Die Schätzung wird also auch für Menschen unterschiedlicher Verfahren vergleichbar.

Hilfsmittel

keine

Wie geht es?

Das Team wählt aus den Uster Stories eine Geschichte, die relativ klein ist. Diese Geschichte bekommt den Wert 1 zugewiesen.
Alle weiteren User Stories werden relativ zu dieser Referenzstory geschätzt. Wenn eine Story z.B. 4 Storypoints hat, dann ist die Umsetzungskomplexität 4-mal so groß wie die Referenzstory.
In weiteren Verlauf können die Storypoint auch auf Personenstunden um skaliert werden, wenn der User Story, der ein Wert 1 zugewiesen wurde, zusätzlich Personenstunden zugewiesen werden. So können alle weiteren Schätzungen leicht in Personenstunden ungerechnet werden.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

ROI

Agile Methode: Priorisierung nach dem Return of Investments (ROI)

Der Return of Investment ist ein klassisches Instrumentarium der Investitionsrechnung. In seiner einfachsten Form wird er in der folgenden Form berechnet:

Retrun of Investment ROI auf Basis des Gewinns

Hier wird eine rein ökonomische Betrachtung zugrunde gelegt. Zunächst erscheint dieses Vorgehen recht einfach, weil Gewinn und investiertes Kapital objektiv leicht messbar sind. Bei der Priorisierung reden wir aber immer von erwartetem zukünftigen Gewinn und erwartetem zukünftig zu investierendem Kapital. Zukünftige monetäre Werte zu schätzen ist allerdings nicht nur sehr aufwendig, sondern auch von großen Unsicherheiten geprägt.

Eine am Nutzen des Auftraggebers oder des Nutzers oder anderer Stakeholder orientierte Perspektive des ROI errechnet sich nach der folgenden Formel:

Die Berechnung des ROI aus diesen Variablen ist allerdings noch schwierige, weil sowohl Nutzen, als auch Aufwand keine skalierbaren Dimensionen haben und häufig in verschiedenen Einheiten gemessen werden. Der Aufwand einer Funktionalität kann z.B. in den Personenstunden gemessen werden, die für seine Erstellung aufgewendet werden. Wenn keine Äpfel durch Birnen geteilt werden sollen, müsste der Nutzen auch in Personenstunden angegeben werden. Das ist aber nur in wenigen Fällen sinnvoll.

Behalten wir auch in Erinnerung, dass hier alle z.B. User Stories nach dem gleichen Kriterium priorisiert werden soll, dann wir muss die gleiche Skalierung für Nutzen und Aufwand in allen Userstories gleich sein. Das wird jedoch nur in wenigen Fällen möglich sein.

Außerdem sollten wir auch berücksichtigen, dass einer der Vorteile der bei der Verwendung von agilen Methoden darin besteht, dass mit einer Leistungsentwicklung ohne umfangreiche und lang dauernde Vorbereitungen begonnen werden kann. Wenn zur Priorisierung jeder einzelnen User Story umfangreiche Schätzungen und damit verbunden Planungsvorgänge verbunden sind, bevor klare Prioritäten festgelegt werden können, geht einer der Hauptvorteil des agilen Vorgehens bereits verloren, bevor das erste Inkrement entwickelt wird. Das leichtgewichtige agile wird zu einem schwergewichtigen analytischen Verfahren.

Aus kaufmännischer Sicht ist eine solche Form der RIO Berechnung eher minderwertig. Der Return of Investment wird hie meistens über mehre Perioden betrachtet, wobei erwarteter Gewinn in der Zukunft auf einen Gegenwartswert abgezinst wird. Eine Anwendbarkeit in der Priorisierung ist hier natürlich auch gegeben. Die oben bereits genannten Probleme vergrößern sich damit aber zusätzlich um die Prognose der zukünftigen Zinssätze.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

WSJF

Agile Methode: Weighted Shortest Job First (WSJF)

Diese Priorisierungstechnik entstammt dem Lean Production Development. Sie wird im Scaled Agile Framework vorgeschlagen.

Die Grundidee ist der Return of Investment (ROI) Rechnung ähnlich. Es erfolgt eine Erweiterung der Kriterien:

Zeitkritikalität
Risikoreduzierung, bzw. Chancenwahrnehmung.

Der WSJF wird dann so berechnet:

WSJFFormel

Je größer der WSJF Wert ist, umso größer ist die Priorität.

Zeitkritikalität:

Product Owner, Stakeholder und / oder das Entwicklerteam schätzen, wie dringend dieses Inkrement benötigt wird.

Risiko und Chance:

Product Owner, Stakeholder und / oder das Entwicklerteam schätzen, wie groß das Risiko ist, dass sich bei der Erstellung eines Inkrements ergibt und wie groß die Chancen sind, die sich daraus ergeben.

Bei allen hier genannten Variablen stellt sich die Problematik der Einheiten, in denen gemessen, bzw. geschätzt wird. Die Mathematik stellt gewisse Grundanforderungen, wie Berechnungen durchgeführt werden sollen, Insbesondere dürfen nicht Äpfel durch Birnen geteilt werden. Werden alle Faktoren in Euro berechnet ist das relativ unkritisch - aber hier ist die Umrechnung sehr zeitaufwendig.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Agile Methode: User Story (User Story, Nutzergeschichte, User Storys)

User Storys werden in allen agilen Systemen verwendet. Wenn ein Unternehmen agil arbeitet, dann ist die Verwendung von User Storys schon fast eine Pflicht. Die Methode der User Story kann auch in vielen anderen Zusammenhängen genutzt werden, so z.B. in dem Anforderungsmanagement des klassischen Projektmanagements oder Produktmanagements.

Die Aussage, die sich im Zusammenhang mit Agilen Methoden ständig findet: "Anforderungen dürfen im klassischen Projektmanagement nicht geändert werden", ist einfach falsch. In allen Projektmanagement Systemen gibt es ein Anforderungsmanagement. Teil dieses Anforderungsmanagements ist immer ein Änderungsmanagement, in dem ein Prozess für das Ändern von Anforderungen festgelegt wird. Im "klassischen Projektmanagement" dürfen Anforderungen also durchaus geändert werden. Es besteht lediglich eine Notwendigkeit, diese Anforderungsänderungen von den Entscheidern genehmigen zu lassen. Das ist, wenn agil gearbeitet wird, aber nicht anders.

Anforderungen stellen in den Agilen Systemen einen Handlungsspielraum dar, der verändert werden kann, um geschäftliche Ziele zu erreichen. Wenn neue Erkenntnisse während der Entwicklung entstehen, die darauf hinweisen, dass das Kosten-Nutzen Verhältnis einer Anforderung ungünstiger ausfällt als ursprünglich gedacht, muss diese Anforderung angepasst werden. Genau diese Forderung findet sich auch in allen klassischen Projektmanagement Systemen.

Im Scrum muss am Anfang eines Leistungserstellungsprozesses nur ein geringer Aufwand betrieben werden, um die Anforderungen im Voraus zu entwickeln. Alternativ können auch Platzhalter im Product Backlog festgelegt werden, die erst im Verlauf des Projektes mit Inhalten gefüllt werden.

User Storys sind nur ein "Platzhalter" in einem Product Backlog für Anforderungen. Diese Anforderungen sind für ein gemeinsames Verständnis zwischen Team und Stakeholdern über die zu erstellende Leistung notwendig. Dieses Verständnis entsteht durch die Kommunikation über die zu erstellende Leistung in einer Face to Face Kommunikation und häufige Feedback Schleifen in Form von Rückfragen und Reviews.

Hier liegt der große Unterschied zwischen dem "klassischen Umgang mit Anforderungen" und einem agilen Vorgehen. Viele Anforderungen in "klassischen Projekten" werden von Spezialisten in Zusammenarbeit mit den Stakeholdern geschrieben. Leider verändern diese sich mit der Zeit oder sind für Entwickler nicht zu verstehen. - Aber die Anforderer haben ihre Arbeit getan und wollen mit Rückfragen nicht mehr belästigt werden. Die Entwickler haben gefälligst das zu tun, mit dem sie beauftragt sind und die Anforderer nicht mehr zu stören. Immerhin haben die Anforderer viel Geld ausgegeben, um die Anforderungen von Beratern richtig formulieren zu lassen.

Wenn der Anforderer jetzt im Sinnes des Agilen Managements von den detaillierten Anforderungen zu leicht und schnell zu erstellenden User Storys wechselt, dann glaubt er, alles getan zu haben - und lehnt sich, seinen bisherigen Gewohnheiten entsprechend, zurück, in der Erwartung, das geliefert zu bekommen, was er glaubt bestellt zu haben. User Storys sind für ihn das ideale Mittel, um seinen eigenen Aufwand zu minimieren, denn User Storys sind wesentlich schneller und leichter erstellt als "klassische Anforderungsbeschreibungen".

Durch den Einsatz agiler Methoden ist das Kommunikationsproblem von Entwickler und Anforderer eher größer geworden. Das Kommunikationsproblem, das bei Einsatz der "klassischen Methoden" darin bestanden hat, dass der Anforderer nicht mit dem Kunden reden möchte und ihm die Teilnahme an einem Review viel zu kompliziert und eine Überarbeitung seiner Anforderungen zu aufwendig ist. Agil oder "klassisch", keiner der Methoden ist das Problem - oder löst irgendein Problem. Das Problem liegt in der nicht vorhandenen Kommunikation zwischen Anforderer und Leistungsersteller - und es kann auch nur an dieser Stelle gelöst werden.

User Storys sind also Platzhalter, die Entwickler und Anforderer daran erinnern, dass sie über dieses Thema noch häufiger reden müssen und die durch genauere, spezifischer User Storys ersetzt werden, wenn über die Gespräche und die Erfahrungen aus diversen Reviews die Erkenntnisse über die zu erstellende Leistung im Verlauf des Leistungserstellungsprozesses besser geworden sind.

Der Zeitbedarf bei der Arbeit mit User Storys ist zumindest für die Seite der Anforderer nicht kleiner geworden. Im Gegenteil. Der Unterschied besteht lediglich darin, dass das Risiko geringer wird, das eine Leistung erstellt wird, die nachher nicht den Wünschen der Anforderer entspricht. - Ein Risiko, dass auch bei den klassischen Methoden erheblich reduziert werden würde, Anforderer und Leistungsersteller häufiger und klarer miteinander kommunizieren würden.

Ziel / Nutzen

User Storys werden zur Beschreibung der Anforderungen aus Perspektive eines Nutzers verwendet. Hierfür wird die Alltagssprache verwendet. Eine User Story beschreibt, was ein Benutzer mit einem Produkt erreichen will.

Hilfsmittel

User Storys sollten mündlich formuliert werden. Sie müssen anschließend schriftlich fixiert werden. Das geschieht zumeist in zwei Schritten:

die schriftliche Ausformulierung in einer Langfassung.
Kurzform, so dass sie auf eine Moderationskarte passt.

Die Kurzfassung wird in eine Product Backlog oder in einem Work breakdown Chart verwendet. Die "Langfassung" ist eine notwendig Voraussetzung, damit mit einer User Story gearbeitet werden kann.

Wie geht es?

User Storys sollten vom Auftraggeber oder vom späteren Anwender formuliert werden. Eine Hilfslösung besteht darin, dass ein Spezialisten Team, welches die Zielgruppe sehr gut kennt, die User Storys formuliert.

Das Erstellen von User Storys ist ein interaktiver, mehrzyklischer Prozess. Zumeist entstehen "übergeordnete User Storys" (Metaebene), aus denen dann untergeordnete User Storys entstehen, die zu kleineren "Problemlösungen" führen. Es entstehen sehr schnell Strukturpläne aus User Storys. Das zeigte uns auch das INVEST-Kriterium

Eine der gerne gewählten Irrtümer besteht in der Annahme, dass der Aufwand der Umsetzung der Kundenwünsche in einem agilen Umfeld nicht geschätzt werden muss. Betrachten wir uns das INVEST-Kriterium ist das Gegenteil der Fall.

Die drei C´s der User Story:

Card (Karte)

User Storys können direkt auf Karteikarten oder Klebezettel (Post it) geschrieben werden. Dabei wird der unten beschriebene Satzbau verwendet.

Conversation (Gespräch)

In einem interaktiven Kommunikationsprozess von Feedback Schleifen wird zwischen den Beteiligten geklärt, wie die User Story zu verstehen ist. Natürlich dürfen dabei auch Dokumente verwendet und bei Bedarf erstellt werden. Ebenso selbstverständlich kann in der User Story auf andere Dokumente verwiesen werden.

Confirmation (Bestätigung, Akzeptanzbedingungen)

Zumeist auf der Rückseite der Karte werden die Akzeptanzkriterien aufgeführt. Das sind die Bedingungen, unter denen der Anforderer bereit ist, die User Story als erfüllt anzusehen. Häufig zeigt sich hier deutlicher als in der User Story, was genau der Anforderer haben möchte. Gleichzeitig legt sich der Anforderer damit fest. Wenn diese Kriterien erfüllt sind, dann hat das Team die Leistung im Sinne des Anforderers erstellt.

Dieser Ansatz wird auch als Spezikation nach Beispiel oder Acceptance-Test-driven Development (ATTD) bezeichnet.

Eine User Story kann auch eine längere Geschichte sein und sich über mehrere Textseiten ziehen. Wichtig ist nur, dass:

Sie in einer kürzeren Form dem nachfolgendem Satzbau entsprechend umformuliert wird.
Sie von der Entwicklerseite umfassend verstanden wird.

Satzbau

Eine User Story ist immer nach dem folgenden Schema aufgebaut:

Als <Rollen, die der Anforderer in der Story hat> will ich <Eigenschaft der Leistung>, damit < folgender Nutzen> entsteht.

Eine alternative Möglichkeit:

In meiner Rolle als <....>, ist mir folgendes passiert <....>. Dadurch sind folgende Probleme entstanden <...>. Eine Beseitigung dieser Probleme würde mir folgenden Nutzen generieren <...>.

Im ersten Fall, muss der Anwender die Eigenschaften einer Leistung, die er benötigt, bereits kennen. Im zweiten Fall, liegt es in der Verantwortung des Projektteams, eine Lösung zu entwickeln.

In beiden Fällen ist die Formulierung der Nutzenerwartung des Anderen wichtig. Nur dadurch ist es möglich, zu überprüfen, ob ein Wert für den Anwender geschaffen wurde.

Kriterien für eine gute User Story

INVEST-Kriterium

[I]ndependent

Eine gute User Story ist unabhängig von anderen User Storys. Die Entwicklung der Lösung für diese User Story sollte möglich sein, ohne dass zuerst andere User Storys umgesetzt werden müssen.

[N]egotiable

User Storys sollten im Verlauf der Entwicklung verhandelt werden können. Entwickler und Anfordere verhandeln diese User Storys im Verlauf der Entwicklung und können sie auf die jeweilige Situation und den jeweiligen Erkenntnisstand anpassen.

[V]aluable

Der Mehrwert der User Storys sollte für den Anforderer erkennbar sein. Am besten existiert ein skalierbares Kriterium für den Wert, der aus der Problemlösung entsteht. Ein skalierbares Kriterium kann in Geldeinheiten, aber auch in eingesparter Zeit, messbarer Zufriedenheitssteigerung oder ähnlichem bestehen.

[E]stimatabel

Der Arbeitsaufwand für jede User Story muss von dem Entwicklerteam schätzbar sein.

[S]mall

Die Umsetzung der Problemlösung sollte in möglichst kurzer Zeit möglich sein. Eine komplette Umsetzung sollte mindestens einen halben Personentag und maximal zehn Personentage erfordern. Auf jeden Fall sollten sie in einem Sprint abgeschlossen werden können. Das bedeutet auch, dass User Storys, die nur in größeren Arbeitseinheiten lösbar sind, in kleinere Einheiten herunter gebrochen werden.

[T]estable

Das Entwicklerteam muss anhand irgendwelcher vorher festgelegten Kriterien überprüfen können, dass die User Story erfolgreich abgeschlossen ist.

Zusätzlich zu jeder User Story müssen vom Anforderer die Akzeptanzkriterien formuliert werden, unter denen er die entwickelte Lösung der User Story als erfüllt ansieht.

Über die User Story hinausgehende Informationen

Oben wurde bereits gesagt, dass eine User Story ein Platzhalter ist. Auf dem Product Backlog ist auch kaum Platz für weitere Informationen.

An diese User Story können und sollen aber detaillierte technische Spezifikationen, etc. soweit bekannt "angehangen" werden. Das bedeutet in der praktischen Umsetzung auch, dass es eine Vielzahl an Spezifikationsdokumenten geben kann, die zu einer User Story gehören, aber in einem entsprechenden Ordner abgelegt sind, die den Entwicklern ebenso zur Verfügung stehen müssen, wie den Anforderern.

Detailierungsgrad

Eine User Story unterliegt einer Geschichte, bis so detailliert ist, dass sie klein genug strukturiert ist, damit sie in einem Sprint abgearbeitet werden kann. User Stories werden im Verlauf des Leistungserstellungsprozesses immer weiter detailliert (siehe hierzu auch den Artikel Product Backlog). Die Verfeinerung der User Story erfolgt progressiv, also spätestens zu dem Zeitpunkt zu dem sie benötigt wird, in einem iterativen Prozess.

Agile Methoden: Übersicht

Alle Seminarangebote

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org

{fastsocialshare}

Seite 2 von 3