Das Ziel von Scrum sind hochproduktive Teams. Doch wie sieht ein hochproduktives Team aus? Wie wird es zusammengestellt, und wie organisiert es sich selbst? Welche Verantwortlichkeiten hat es, und woran erkennt man ein erfolgreiches Scrum-Team? Und ist Scrum möglicherweise der Anfang vom Ende der Arbeitsteilung in Software-Entwicklungsteams?

Ein Scrum-Team ist ein Produkt-Entwicklungsteam. Es hat die Aufgabe, ein Produkt zu liefern, nicht nur Code. Natürlich liefert das Team auch die Software. In den meisten Fällen benötigt man aber weit mehr für die Erstellung eines Produktes als nur die Software. Die Teammitglieder sind in Scrum im Rahmen ihrer Möglichkeiten für alles, was für die Produkterstellung zu tun ist, selbst verantwortlich. Ein Scrum-Team besteht also aus den Personen, die die Kenntnisse haben, um das Produkt in seiner Gesamtheit zu liefern. Jedes Mitglied eines hochproduktiven Teams übernimmt die Verantwortung für das Gelingen des Projektes. Teams haben die Verpflichtung zu liefern, was sie sich selbst vornehmen. Jedes einzelne Teammitglied ist für seine Leistung im Team verantwortlich, und gemeinsam sind alle dafür verantwortlich, das Versprechen, das sie als Team gegeben haben, zu halten.

Zusammenarbeit in einem Scrum-Team ist nicht das Ende der Arbeitsteilung, sondern bringt zusammen, was zusammengehört. Statt entlang der Aufbauorganisation arbeiten Menschen in Scrum horizontal entlang der Wertschöpfungskette des Unternehmens. Sie arbeiten mit ihren Fähigkeiten als Spezialisten zusammen und über ihre enge Zusammenarbeit entwickeln sie gemeinsam Talente im Team, auch außerhalb ihrer Spezialfähigkeit.

System Teams versus Feature Teams

Teams sollten immer nach Funktionalitäten oder Produktteilen aufgestellt werden. Scrum-Teams sollten Produkte oder Applikationen liefern, nicht nur sogenannte Basis-Komponenten (technisch notwendige Aspekte des Systems, die nur für andere Entwickler bedeutsam ist). Wenn wir gewachsene Unternehmen betrachten, stoßen wir immer wieder auf Systemlandschaften, die sich entlang ihrer Aufbauorganisation entwickelt haben. Hier ist die Suche nach einem Produkt mitunter nicht ganz so einfach.

Ein Tipp: Suchen Sie Ihren Kunden, dann finden Sie auch Ihr Produkt. Ihr Kunde sollte sich außerhalb Ihres Unternehmens befinden und nicht die selbst erstellten Bedürfnisse befriedigen. Suchen Sie den Kunden am echten Markt, nicht am internen.

Wie gesagt, starten wir in einem gesamten IT-Bereich mit dem agilen Vorgehen, dann sieht die Lage oft anders aus. Wir treffen auf Kopfmonopole, komplexe Systeme mit großen Abhängigkeiten, mittelmäßigen bis schlechten Code und alles hat sich über Jahre hinweg aufgebaut.

Aus dieser verstrickten Lage kommen wir nicht mit einem Schritt alleine heraus! Wir müssen uns Schritt für Schritt einen Weg aus dem Moloch herausbahnen.

Schritt für Schritt

Zentrale Aspekte bei einer agilen Transition sind der Aufbau von Zusammenarbeit und Entscheidungen im Konfliktfall, klare Führungsaufgaben. An dieser Stelle wird auch schnell klar, warum eine Unterstützung aus dem Management notwendig ist. Kommen wir zurück zu unserem eingangs erwähnten Beispiel für hochproduktive Teams, anhand eines Feature-Teams:

In einer Organisation kann oder soll die Zusammensetzung der Teams nicht sofort komplett umgestellt werden, um cross-funktionale Teams zu erzeugen. Es werden also nicht die Menschen zusammengebracht, die schon gemeinsam, allerdings in verschiedenen Teams, die Produkte erzeugen. Wenn das nicht von Anfang an gelingt, dann darf man nicht den Kopf in den Sand stecken, sondern muss die Reise beginnen lassen. Gehen wir den ersten Schritt: Wir stärken die Zusammenarbeit und den Wissenstransfer im Team und bringen die Menschen zusammen, die einen gemeinsamen Auftrag haben, auch wenn sie ihn noch nicht gemeinsam wahrnehmen können. Wie gesagt, ein Schritt.

Ein weiterer, kleiner Schritt auf dem Weg in die für uns richtige Richtung wäre folgender: Okay, wir entwickeln eine Komponente, aber wenn schon, dann auch richtig. Unseren Teil des Features haben wir fertiggestellt und getestet bis zur Schnittstelle (mit oder ohne Versionierung, je nach Unternehmensstandard) und richtig fertig, ohne Kompromisse.

Die Demut der kleinen Schritte

Wir können nicht alles sofort umkrempeln und blitzend machen, das verbietet uns schon allein die Demut. Ein Unternehmen ist gewachsen, komplex und ist nicht reduzierbar auf Ursache-/Wirkungsprinzipien. Vielmehr arbeiten wir anhand eines empirischen Prozesses, bei dem wir unsere Erwartungen kenntlich machen und dann nach kurzer Zeit messen, ob das Erwartete eingetreten ist (inspect & adapt). So lässt sich zum einen messen, ob wir mit dem nächstmöglichen Schritt, der nächsten Schraube, an der gedreht wurde, das Gewünschte erreicht haben. Wenn nicht, dann gehen wir einen Schritt zur Seite, schräg nach vorne oder auch einen Schritt zurück.

Wenn wir begreifen, dass wir als Menschen nicht unfehlbar sind und nicht unsere Würde an unsere Entscheidungen hängen, dann haben wir die Chance, kleine Schritte zu gehen und uns selbst am eigenen Schopf aus dem Moloch herauszuziehen. Dafür müssen wir akzeptieren, dass wir nicht alles kontrollieren können, sondern wir müssen vertrauen, loslassen und genau das kontrollieren, was kritisch für das gesamte Unternehmen wird.

Related posts:

1. Bug Fixing
2. Christbaumschmücken Advanced
3. Wir leiden an Selbstüberschätzung – und das ist auch gut so!

Ja, wir glauben!

• Wir glauben, dass agile Werte und Vorgehensweisen ein Unternehmen zum Erfolg bringen können.
• Wir glauben, dass Ermächtigung zu Verantwortung führt, die wiederum zu Ergebnissen führt.
• Wir glauben, dass Organisationen keine Maschinen sind, sondern ein Menschensystem.
• Wir glauben, dass die Personen, die am nähesten am Problem sind, auch am nähesten an der Lösung sind.
• Wir glauben, dass es in unserer heutigen Welt ein Schlüssel zum Erfolg ist, auf Veränderung und Unsicherheit reagieren zu können.
• …

In einem früheren Blog hatte ich schon ein paar gute Argumente gelistet (In Scrum we trust!) und es gibt  auch gute Tipps, wie man am besten ein Evangelist wird (How to be a successuflu agile development evangelist).

Nun, andere Leute auf dem Weg zur Veränderung zu begleiten, bleibt weiterhin eine schwere Aufgabe!!

Mike Cohn („Succeeding with agile“) fasst die fünf Schritte zur erfolgreichen Einführung agiler Vorgehensweisen mit dem Akronym ADAPT zusammen:

Awareness – das Bewusstsein, dass der derzeit verwendete Prozess nicht die gewünschten Ergebnisse  bringt

Desire – das Verlangen, die bestehenden Probleme mit Hilfe agiler Methoden zu adressieren

Ability – die Befähigung, eine agile Methode erfolgreich einzusetzen

Promotion – das (interne) Marketing für die agile Vorgehensweise in Form von Erfahrungsberichten

Transfer – die Ausweitung der agilen Methoden auf andere Unternehmensbereiche (aus Sicht einer IT-Projektabteilung)

Eine (positive) Erfahrung zählt mehr als alle schönen Worte. Der Hirnforscher Gerald Hüther erklärt in der österreichischen Tageszeitung “Der Standard”, warum man durch günstigere Erfahrungen seine Haltung verändert.

„Der Frontallappen ist der Bereich im Gehirn, in dem unsere sogenannten Metakompetenzen, unsere Überzeugungen, Glaubenssätze, inneren Einstellungen und schlussendlich die daraus hervorgehenden Haltungen verortet sind. Sie bestimmen, was ein Mensch denkt, wie er Dinge bewertet, wie er handelt. Der springende Punkt dabei ist: Wir können die dort entstandenen Haltungen nicht einfach ändern. [...] Erfahrungen gehen buchstäblich unter die Haut – mit anderen Worten, der Mensch fühlt. Das emotionale Netzwerk im Hirn verknüpft sich mit dem kognitiven Netzwerk zu einer festen Struktur. Diese lässt sich nicht durch noch so viele Anfeuerungen und Ermunterungen in all den flammenden Ansprachen bei Betriebsfesten oder durch sonstige Belehrungen und Ermahnungen verändern. Das gelingt wie gesagt nur durch neue Erfahrungen, mit denen dann die alten, eingefahrenen Netze im Gehirn überschrieben werden. Mit den besseren können also dann die weniger guten Erfahrungen gelöscht werden. Am besten gelingt das, wenn der Mensch begeisternde Erfahrungen macht. Die reißen ihn dann in des Wortes wahrstem Sinne mit und aus alten Haltungen heraus.“

Related posts:

1. Führung in Scrum | Manager | Teil 4
2. Vom Glauben und sich Einlassen
3. Scrum eine Sekte?

Hiermit meine Top 5 und ein paar Wörter zum Thema „INSPIRATION“.

• Don Tapscott: Four principles for the open world 
  Ein wunderschöner Beitrag über unsere Welt.
• Best motivational video ever for creative people and startups:  http://bit.ly/wWtbTP
  Macht sofort Lust was zu tun, oder?
• Steve Johnson: Where good ideas come from 
  Ideen zu haben allein reicht nicht. Man muss sie auch anderen vermitteln und noch viel mehr mit anderen entwickeln wollen.
• MOVE (http://bit.ly/oUeLOJ) und LEARN (http://bit.ly/pa2JUT) by Rick Mereki
  Entdecken, sich mit anderen Kulturen, Blickwinkeln, aber auch anderen Aufgaben konfrontieren, das gehört zu Inspiration. Dazu kommt auch die Bewegung: Inspiriert zu sein oder sich inspirieren lassen bewegt mich. Ich gehöre selten zu den stillen Beobachtern.
• Marc Cutts: Try something new for 30 days

Related posts:

1. Education Paradigms & Softskills
2. Scrum Alliance mal wieder führungslos – Donna Farmer geht
3. Self Organization

Das Transition Backlog ist eine Kombination aus Impediments, Pilotprojekten und Maßnahmen. Es enthält für die Umsetzungsreihenfolge priorisierte Ziele, Aktivitäten und Probleme.

Beispiele für Backlog Items:

• Vision und Ziele der Implementierung festlegen und kommunizieren
• Infrastruktur und Arbeitsmittel
• Kommunikation nach innen und nach außen
• Information und Kooperationsbereitschaft anderer Abteilungen
• Pilotimplementierung
• Klärung aktueller Anforderungen und Bedingungen
• Analyse der Organisationsstruktur und -kultur
• Teamzusammenstellung, Personenauswahl
• Scrum-Trainings, Identifikation des Bedarfs
• Einstellung von Scrum-Mastern / Teammitgliedern
• Scrum Räumlichkeiten
• Architektur und Qualitätssicherung

Um einen optimalen Rahmen zu schaffen, soll das Transition Team Sicherheit geben bzw. die Angst vor Veränderung reduzieren. Es muss jedem die Chance geben mitzumachen und damit den größten Erfolg zu sichern.

Hier ein paar einfache Grundprinzipien:

• Sicherheit schaffen: KOMMUNIZIEREN! Auf dem Weg zu Veränderung sind nicht alle gleich weit und nicht alle gehen gleich schnell. Jeder soll sich wohl fühlen, Zeit und Rahmen bekommen, um seine Fragen, Emotionen und Ängste mitzuteilen. Jede Meinung muss ernstgenommen, wertgeschätzt, wahrgenommen und respektiert werden. In solchen Zeiten es ist auch wichtig, klar zu kommunizieren, dass vor dem Anfang nicht alle Lösungen bekannt sind oder zuzugeben, dass man Kommunikationsfehler gemacht hat. Gegebenenfalls  kann es sehr hilfreich sein, einen Moderator beizuziehen.
• Teams vor Störungen schützen: Lasst eure Mitarbeiter nicht alleine vor der Veränderung stehen, noch dazu mit den alten Problemen und Interventionen der Außenwelt. Schafft Rückhalt, damit nicht auf einzelne Mitarbeiter Druck ausgeübt wird.
• Fokus und Priorisierung: Um Chaos und Verwirrung zu verhindern, hilft es den Mitarbeitern, sich auch eine reduzierte Vielfalt von Aufgaben und Ziele zu konzentrieren.
• Managing bei Example: Die Einführung einer Methode muss mit der Methode erfolgen, die eingeführt werden soll. Das Transition Team sollte denselben Prinzipien und Methoden wie alle Scrum Teams folgen. Es bedeutet vor allem: Transparenz über was ihr tut und was ihr liefert und natürlich über die Impediments, die ihr aufräumen müssen.

Die Zusammenstellung der Transition Teams selbst kann Probleme auflösen. Es ist wichtig, dass ihr euch Zeit nehmt, um euch kennenzulernen. Damit ihr in diesem neuen Gefüge feststellt, wie ihr als Team agieren wollt und könnt. Dass ihr euch wirklich einen Vertrauensrahmen aufbaut und die verschiedenen Sichtweisen und Erwartungen aufnehmt. Die erste Aufgabe ist, gemeinsam die Ziele festzulegen. Man vergisst manchmal, dass eine Veränderung einen Zweck hat und dass die Methode z.B. Scrum NUR Mittel zum Zweck ist.

Related posts:

1. Langfristig verändern
2. Scaling Scrum is simple but very hard | 10 Tipps
3. Der ScrumMaster – Wirklich ein Weichei?

Schreibt dazu zunächst das Alphabet von A bis Z auf. Nehmt dann jeden Buchstaben und überlegt, was euch zu ein bestimmte Begriff einfällt, welche Assoziationen der Buchstabe also in euch auslöst. Schreibt  einfach auf, was euch ganz spontan zu einem Buchstaben durch den Kopf geht. Ihr könnt die Buchstaben der Reihe nach bearbeiten oder wild springen. Sie könnt zu jedem einzelnen Buchstaben etwas schreiben oder – wenn euch nichts einfallen sollte – auch einige weglassen. Wie ihr genau vorgeht, ist egal. Lasst es fließen.

Was läuft in eurem Kopf ab, wenn ihr an SCRUM denkt? Welche Assoziationen habt ihr persönlich zu SCRUM?

Macht mit!

Übrigens kann das auch ein gute Kennenlernen-Übung für die Retrospektive sein. Jedes Teammitglied zieht den Namen eines anderen und schreibt ein ABC Liste über ihn oder sie!Agile!

Related posts:

1. Entscheidungshilfen aus dem Alltag
2. Österreich hat eine Scrum Mailing Liste
3. ScrumMaster Checkliste

• klare Visionen, gemeinsame Zielsetzungsprozesse
• Kooperations- und Konfliktlösungsfähigkeit, wechselseitiges Vertrauen
• Prozessorientierung und Selbstregulation in Gruppen, Teamgeist
• demokratischer und partizipativer Führungsstil, Unterstützung neuer Ideen (v. a. durch die Führung), Integration von Personal- und Organisationsentwicklung
• Belohnung von Engagement und Fehlertoleranz bei riskanten Vorhaben
• Fähigkeit zur (Selbst-) Beobachtung und Prognose (gut funktionierende Informations- und Kommunikationssysteme – rascher und genauer Überblick über die Wirkung der wichtigsten Prozesse)

In agilen Prozessen ist die Retrospektive das ideale Mittel zur kontinuierlichen Verbesserung des Entwicklungsprozesses. Um aus der Vergangenheit zu lernen, schauen die Teammitglieder gemeinsam zurück und bewerten, was gut und was schlecht gelaufen ist. Vor allem analysieren sie, WARUM Dinge gut oder schlecht gelaufen sind, um so zu Verbesserungsmaßnahmen zu gelangen. Diese Verbesserungen können in vielen Bereichen stattfinden: effizientere Zusammenarbeit, höhere Produktivität, weniger Fehler, besseres Einhalten von Regeln etc.

Verschiedene Phasen, verschiedene Maßnahmen

Hochleistungsteams oder Spitzenteams fallen allerdings nicht vom Himmel – sie müssen sich erst als solche entwickeln. Dabei gibt es unabhängig vom Kontext eines Teams immer wieder die gleichen Building-Phasen, die ein Team durchlaufen muss: Forming – Storming – Norming – Performing.  Für „Außenstehende“ – zum Beispiel das Management – sind diese Phasen nicht immer gleich erkennbar. Für sie ist das Team bereits ein Team, während es aus der Innensicht noch immer nur eine Gruppe von Menschen ist, die zumindest den guten Vorsatz hat, erfolgreich zusammenzuarbeiten. Mit dem Wissen um die Phasen der Teambildung im Hinterkopf wird auch klar, dass Retrospektiven nicht immer die gleichen Schwerpunkte haben können und für einen Teamcoach wie den ScrumMaster ist es wichtig, zu erkennen, welche Maßnahmen das Team gerade weiterbringen und welche nicht. Welche Maßnahmen haben sich in welchen Phasen bewährt?

Forming – Orientierungsphase

• Kick-off Workshop
• Zeit fürs Kennenlernen (fachlich & persönlich)
• Festlegen formeller Spielregeln
• Klärung der formellen Rollen und Aufgaben
• Ängste und Erwartungen klären
• Ziele und Aufgaben klären
• Strukturen und Methoden definieren
• Infrastruktur schaffen

Storming – Konfliktphase

• Konflikte offen ansprechen
• Auf der Sachebene bleiben
• Einhalten oder festlegen von Teamregeln
• Ergebnisse fortlaufend transparent machen
• Ziele und Aufgaben in Erinnerung rufen
• Strukturen/Methoden implementieren
• Externe Moderation und Supervision nutzen
• Erfolgserlebnisse schaffen

Norming – Stabilisierungsphase

Wenn die Konfliktphase durchlebt ist, sollte gewürdigt werden, was bisher geleistet wurde. Jetzt ist auch die Zeit, um Ziele und Strategien weiterzuentwickeln, Rollenflexibilität zu üben und sich mit der Teamleistung am Benchmark zu orientieren.

• Ergebnisse würdigen und feiern
• Persönliche Stärken der einzelnen Teammitglieder entwickeln und Lösungen für ihre Schwächen suchen
• Ziele weiterentwickeln
• Rollenflexibilität üben
• Strukturen und Methoden verfeinern
• Strategien überprüfen
• Orientierung am Benchmark/Best Practice

Performing – Hochleistungsphase

Teams, die die Hochleistungsphase erreichen, sind in der Lage, durch optimierte Zusammenarbeit Synergieeffekte zu realisieren. Oft werden Hochleistungsteams als Katalysatoren eingesetzt, indem man ihr Know-how und ihre Methodenkompetenz auch anderen Teams zugänglich macht.

• Setzen neuer Benchmarks
• Steigern der Effizienz durch Realisierung von Synergien
• Rollenflexibilisierung
• Private Ebene fördern
• Ziele und Aufgaben weiterentwickeln
• Strukturen und Methoden anderen zur Verfügung stellen
• Erfolgsstrategien reflektieren

Erfolgskriterium Moderation

Egal, in welcher Phase sich ein Team befindet: Das Führen des Teams – oder besser gesagt das Coachen in dieser Rückschau – ist immer eine sensible Aufgabe, weil sich der aktuelle Entwicklungsstand auch in der Meetingsituation „atmosphärisch“ abbildet. Beispielsweise bei einer Retrospektive  muss der ScrumMaster das Gefühl für den Fortschritt des Teams entwickeln und in der Retrospektive selbst den Prozess des Teambuildings fördern. Das kann er, indem er darauf achtet, dass alle Teilnehmer aktiv und gleichberechtigt teilnehmen. Die ideale Retrospektive verläuft angstfrei und energiegeladen. Auch in schwierigen Phasen darf nicht das Jammern im Vordergrund stehen, sondern die Ursachenanalyse der Probleme. Und schließlich soll die Retrospektive nicht nur gute Absichten, sondern umsetzbare Maßnahmen generieren. Wann und von wem etwas umgesetzt werden soll, ist daher die entscheidende Frage, auf die es am Ende jeder Retrospektive eine Antwort geben sollte.

Related posts:

1. Die Retrospektive macht das Team, das Team macht die Retrospektive
2. Ordnung im Bewusstsein.
3. Website | Der Wandel wird sichtbar, Notizen inklusive

Wie relevant ist die Estimation, wenn unterschiedliche Leute mit unterschiedlichen Erfahrungen und Schwerpunkten eine User Story schätzen? Viele von diese Fragen zeigen schon, daß die Leute die Estimation nicht verstehen oder wie Boris sogar auch schon geschrieben hat, daß sie Estimation nicht verstehen wollen.

Wer versucht, krampfartig sichere Prognosen durch Estimation zu erreichen, kann nur enttäuscht werden. Scrum basiert auf der Erkenntnis, dass komplexe Projekte ab einer gewissen Größenordnung nicht mehr vorab vollständig planbar sind. Für diejenigen, die Aufwand oder Ideal Day schätzen, ist die Gefahr noch höher –  parallel mit traditioneller Planung wird man nicht umhinkommen seine Erwartungen zu verfehlen.

Denn schätzen ist ein iterativer Prozess. Schätzen ist relativ.

Der Release Plan ändert sich im Lauf des Projekt z.B. wegen einem Plus an User Stories. Die Velocity des Teams steigert oder verändert sich z.B. wegen neuer Teammitglieder.

Estimation Meetings sind vor allem da um Missverständnisse zu identifizieren und  auszuräumen, um PO’s zu warnen wenn die gewünschte Funktionalität nicht klar genug dargestellt ist.

Es geht hier vor allem um Verständniss und Relationen aber bitte NICHT um Aufwand!

Related posts:

1. …denn wenn Anna größer als Tom ist und Tom größer als Friederike…
2. Ich schätze was, das du nicht schätzt …
3. Agile Estimation | Grundlagen

Heißt das etwa: Gespräche mit dem Geschäftsführer, mit den Ex-Projektleitern, Product Owner oder einzelnen Team-Mitgliedern? Ja – mit allen! Es kann allerdings lang, mühsam und schwierig werden, bis alle überzeugt sind.

Letztendlich wünschen wir uns dabei nur, dass sie es ernsthaft versuchen. Wie Ken Schwaber („agile software development with Scrum“) immer gesagt hat: “Most people really understand Scrum only when they begin to use it.“

Es gibt allerdings meiner Meinung nach auch viele Argumente, die für die agile Methode und für Scrum sprechen. Ich habe mich einmal gefragt: Welche Argumente haben bei mir besondere Interesse für Scrum geweckt?

• Einfache Spielregeln, die Zusammenarbeit in komplexen Projekten ermöglichen (tja, ich komme aus dem traditionellen Projektmanagement von Forschungsprojekten mit wunderschönen 3-Jahres-Plänen, die ich ständig angepasst habe, mit aufwändigen Berichten, um zu erklären, warum es anders lief als im Plan etc.)
• Ständiger Verbesserungsansatz
• Raum für Querdenker und kreative Menschen
• Verbesserung der Teamfähigkeit, auf Änderungswunsche des Kunden flexibel zu reagieren
• (endlich) Transparenz des Projektstatus
• Die Kundeneinbeziehung
• Spaß!

Und viele mehr! Welches Argument war für euch das bedeutendste?

Related posts:

1. Agile Contracts – An Open Project
2. People needs to “hear and view” colleagues.
3. People needs to "hear and view" colleagues.

Warum?

Die Retrospektive macht das Team

Die Retrospektive ist der Moment, wo das Team nach einem erfolgreichen, stressigen, ruhigen oder nicht so gut gelaufenen Sprint auf Pause drückt. Retrospektive als Sprint-Konzentrat. Das Team kann sich jetzt anschauen, was passiert ist und Eindrücke untereinander austauschen. Meistens gibt es schnell Verbesserungsvorschläge. Als ScrumMaster kann man sehr gut beobachten, ob ein Team ein Team ist, wie ein Team zusammen hält, z. B. das Wörtchen „WIR“ oft benutzt wird oder, im Gegenteil, Einzelne sich Vorwürfe an den Kopf werfen. Während dieser Stunde kann man als ScrumMaster sehr genau einschätzen, ob die Hauptprinzipien von Scrum verstanden und gelebt oder gar missbraucht werden. Selbstorganisation braucht Dialog, Dialog braucht Respekt. Transparenz braucht Mut und Offenheit, Qualität und Effizienz braucht Verantwortung.

Das Team macht die Retrospektive

Die Retrospektive ist definitiv ein phantastisches Barometer. Ich bin als ScrumMaster gerade ziemlich frustriert. Mein Team macht derzeit allgemein bei Scrum nicht mit. Mein Team macht deswegen besonders bei der Retrospektive nicht mit.

Bei anderen Teams konnte ich genau während dieses Meeting die Fortschritte der Implementierung von Scrum beobachten. Der Wille, der Einsatz, das Verständnis. Identifizieren der wichtigsten Punkte zum bearbeiten. Fokussierung. Lösungsvorschläge. Vereinbarungen. Diese Vereinbarungen halten.

Zusammen halten. Zusammen wachsen.

In diese Sinne lege ich als ScrumMaster immer viel Wert auf Vorbereitung. Gute Bedingungen sichern den Erfolg der Retrospektive, einem der entscheidensten Grundsteine von Scrum.

Hélène Valadon
bor!sgloger Consulting

Related posts:

1. Management in Scrum Organisationen
2. Education Paradigms & Softskills
3. Phänomenologie des Impediments