Bildwelten – wie Sie eine Retrospektive zur visuellen Reise machen

Die Retrospektive dient im Scrum-Prozess vor allem dazu, aus den Erfahrungen des aktuellen Sprints zu lernen und so die Zusammenarbeit nachhaltig zu verbessern. Der Ablauf einer Retrospektive ist immer ähnlich und besteht im Wesentlichen aus fünf Schritten:

Dass es trotz vergleichbarer Abläufe eine Vielzahl an Gestaltungsmöglichkeiten für Retrospektiven gibt, zeigt sich auf Websites wie Fun Retrospectives oder Retromat.

Wenn ich Teams durch eine Retro begleite, so nutze ich gerne Bildwelten, um die Kreativität im Raum zu stärken und die Teammitglieder zu neuen Sichtweisen anzuregen. Wie das funktioniert, möchte ich in diesem Blog-Beitrag am Beispiel der „Sailboat-Retro“ veranschaulichen.

Willkommen an Bord

Als sehr bildhafte Variante der Retrospektive eignet sich die Sailboat-Retro hervorragend, um von Beginn an zu signalisieren, dass alle Teammitglieder im selben Boot sitzen – und auf ein gemeinsames Ziel zusteuern. Der Name des Teams am Rumpf des Segelbootes unterstreicht das zusätzlich. In der Praxis bereite ich den Rahmen und die Grundstruktur bzw. wichtige Grundelemente der Bildwelt gerne schon vor dem Termin vor, um direkt starten zu können.

Zurückblicken, um voranzukommen

Nach dem Check-in, dem Ankommen im Raum, reflektiert das Team zunächst, was gut gelaufen ist. Für diesen positiven Rückblick bietet sich folgende Fragestellung an: Was ist der Wind in unseren Segeln? Was bringt uns voran? Was macht uns schneller?

Wenn das Team nun die Antworten auf Post-its gesammelt hat, macht es Sinn, diese direkt auf dem Flipchart zu clustern.

Es geht immer noch besser

Nachdem wir jetzt wissen, was gut funktioniert hat, geht es in weiterer Folge darum, Verbesserungspotenziale zu identifizieren. Auch hier steige ich gerne mit Fragestellungen in die Bildwelt ein:

Der Anker steht in diesem Fall für Verlangsamung, für ein Hindernis des Vorankommens, während der Hai aufkommende, in der Zukunft liegende Gefahren symbolisiert.

Das Team überlegt, schreibt seine Antworten auf Post-its und klebt diese auf die Freifläche am Flipchart. Was thematisch zusammenpasst, wird direkt geclustert, um Muster zu erkennen. Wenn sich ein großes Thema ablesen lässt, ist der Fokus der Maßnahmenfindung für den nächsten Sprint einfach zu setzen. Ansonsten nütze ich gerne Dot-Votings, um zu priorisieren. Jedes Teammitglied bekommt dabei zwei Punkte, die je nach individuell empfundener Dringlichkeit an die vorhandenen Themen vergeben werden können.

Volle Kraft voraus – mit konkreten Maßnahmen

Im nächsten Schritt soll das Team nun sinnvolle, umsetzbare Maßnahmen für den kommenden Sprint definieren. Wie können wir Hindernissen ausweichen und Gefahren vermeiden? Was müssen wir tun, um noch schneller zu werden? Die Maßnahmen, die sich aus diesen Fragen ergeben, nimmt das Team aus der Retrospektive mit. Und versucht, diese sofort in den darauffolgenden Arbeitstagen umzusetzen. Nach dem Check-out ist der aktuelle Sprint abgeschlossen.

Visualisierung wirkt

Meiner Erfahrung nach sind Bildwelten eine tolle Möglichkeit, damit sich Teams besser auf die Fragestellung einlassen können. Durch das Verankern der Antworten auf dem Flipchart lassen sich Muster schnell erkennen, was das Stimmungsbild im Team meist noch besser sichtbar macht. Außerdem kann dieser visuelle Ansatz dazu führen, dass Teams gewisse Aspekte ihrer Zusammenarbeit noch einmal unter anderen Blickwinkeln betrachten.

Alles, was Sie dazu brauchen, sind ein Flipchart, zwei dicke und ein dünnerer Marker in unterschiedlichen Farben sowie Post-its oder statisch haftende Notizzettel. Probieren Sie es aus, es macht Spaß. Und lohnt sich.

 

Foto: CCO Creative Commons – Pixabay

Mysterium Motivation – so motiviere ich mein Scrum-Team

Kürzlich stellte einer unserer Trainingsteilnehmer am Ende des Trainings folgende Frage: „Wie schaffe ich es als ScrumMaster, alle Leute in meinem Team für Scrum zu begeistern oder überhaupt zu motivieren, Teil dieses Teams zu sein?“ Mit dieser Frage ist er nicht alleine. In fast jedem Team begegnen wir der Problematik, dass nicht alle von Anfang an mitziehen und die agile Transformation unterstützen. Was tun?

Das Motivations-Tagebuch

Als ScrumMaster sollten Sie auch Widerstände als Chancen betrachten, weil darin Optimierungspotential sichtbar wird. Ich empfehle ScrumMastern, ein Motivations-Tagebuch zu führen, in dem konkrete, motivierende und kurzfristig umsetzbare Maßnahmen aus den Beobachtungen des Tages abgeleitet werden. Welche Einträge ins Tagebuch kommen und wie diese aussehen können, schauen wir uns in diesem Blog-Artikel gemeinsam an. Begleiten Sie unseren fiktiven ScrumMaster durch seinen Sprint. Er macht sich zu jeder Situation Notizen und hält konkrete To-dos zur Motivation und Weiterentwicklung seines Teams fest.

Montag, 09:00 Uhr – Verantwortung übertragen

Der ScrumMaster steht mit seinem neuen Team vor dem Taskboard. Er ist seit zwei Wochen im neuen Projekt unterwegs, es gibt viel zu tun. Jeder nimmt sich reihum Tasks und schreibt sein Kürzel auf die einzelnen Aufgaben. Es sind immer die gleichen Personen, die sich die gleichen Tasks ziehen. Und es gibt ein Teammitglied, das scheinbar an derselben Aufgabe arbeitet wie in der Woche zuvor. Das Worst-Case-Szenario: Am Ende werden die User Storys bis zum Review am Freitag nicht fertig. Es gibt kein Feedback vom User und der Product Owner sieht die abgeschlossenen User Storys im Review zum ersten Mal. Eine Konsequenz, wenn nicht geliefert wird? Fehlanzeige.

Hier braucht es dringend einen aktiven ScrumMaster. Das Team muss lernen, Verantwortung für die Qualität der Lieferungen zu übernehmen, und braucht echtes Feedback von einem Endanwender sowie ausreichend Support vom Product Owner.

Der ScrumMaster erstellt eine Liste mit konkreten To-dos für den Tag und versucht, diese direkt umzusetzen: 

Dienstag, 10:00 Uhr – Wertschätzung fördern

Eine sehr knifflige User Story ist endlich fertig geworden. Zwei Teammitglieder bekommen kräftigen Applaus vom gesamten Team. Der ScrumMaster klatscht am Anfang noch am lautesten. Zur Abnahme der Story bringt der Product Owner zwei seiner selbstgebackenen Muffins vorbei. Ein Teammitglied steht halb abgewandt zum Taskboard und betrachtet diese Zeremonie skeptisch: „Mit so einer billigen Nummer kriegt ihr mich nicht“, denkt er sich. Es waren seine Lieblingsmuffins.

Die Scrum-Master-Notiz am Dienstag: 

Mittwoch, 14:00 Uhr – Fokus setzen

Der ScrumMaster hat drei neue Teammitglieder. Einer der drei Kollegen scheint sich mit Scrum auszukennen. Er hält sich sehr bedeckt. Der ScrumMaster ist nun nicht mehr der einzige Verfechter der Methode und sieht die Chance, etwas zu verändern. Er bittet den Kollegen, mit ihm gemeinsam einen Workshop zum Thema „User Storys schreiben“ durchzuführen. Im gemeinsamen Austausch berichtet der Mitarbeiter, dass ihm einige Dinge aufgefallen sind, die er gerne ändern würde – z. B. könnte man das Taskboard anpassen. Es sprudelt nur so aus ihm heraus. Er hat bereits in zwei erfolgreichen Teams gearbeitet und möchte sein Wissen weitergeben.

Der ScrumMaster notiert in seiner Liste:

Donnerstag, 12:30 Uhr – Wissen vermitteln

Der ScrumMaster hat ein gemeinsames Mittagessen organisiert. Einen Teamraum gibt es nicht, daher sieht sich das junge Team bis auf die Meetings nicht so häufig. Im gemeinsamen Austausch kommen unterschiedlichste Themen auf, welche die Teammitglieder noch nicht verstanden haben. Scrum sei doch sehr kompliziert. Ein Kollege erzählt, dass er gerade gemeinsam mit dem ScrumMaster einen User-Story-Workshop plant. Die anderen Teammitglieder machen Vorschläge, welche Themen sich noch eignen würden.

Weitere Vermerke kommen auf die Liste:

Freitag, 15:00 Uhr – mit Begeisterung anstecken

Das Review beginnt. Sechs von sieben Storys sind fertig geworden. Nur sechs Storys werden gezeigt. Hier gibt es Verbesserungspotential, aber für die nächsten 90 Minuten widmet sich der ScrumMaster vor allem dem Erfolg des Teams. Ein neues Gesicht ist in der Runde. Eine Mitarbeiterin aus dem Vertrieb ist vorbeigekommen, um sich anzusehen, was das Team entwickelt hat. Sie hat einen Tipp bekommen und wollte sich das nicht entgehen lassen. Sie kann die Endanwender zwar nicht ersetzen, ist aber ziemlich nahe dran. Der PO hält sich zurück und das gesamte Team präsentiert. Die Mitarbeiterin ist begeistert. Sie hat zwar ein paar Anmerkungen, ist aber sonst sehr zufrieden. Das nächste Mal bringt sie einen weiteren Kollegen mit. Vielleicht kann sie sogar mal einen richtigen User organisieren. Den Applaus erhalten am Ende alle. Auch der eine Kollege, der etwas abseits von der Gruppe steht. Überzeugt ist er (noch) nicht, aber ein Lächeln konnten wir ihm abgewinnen.

Der letzte Eintrag diese Woche: 

Sie kennen alle Tipps und Tricks zum Thema Motivation von Scrum-Teams und lassen nichts unversucht, um Ihre Teams zu motivieren? Dann sind wir gespannt auf Ihre Erfolgsgeschichte.

 

Backlog Refinement – Or Why we still need an Estimation Meeting

There is an old saying within the scrum scene: “A Product Owner should never show up in a Sprint Planning #1 Meeting without a prioritized and estimated backlog.” But the PO must talk to the team to create a proper backlog. Therefore, early “scrummers” came up with the idea of a Backlog Refinement Meeting. I did a short tutorial to give you a closer look at what this meeting is all about.

Warum E-Government in Deutschland nicht vom Fleck kommt

Bund, Länder und Kommunen haben sich bereits an einigen Aspekten des E-Governments versucht. Und doch wird Deutschland in allen einschlägigen internationalen Rankings im regelmäßig auf die hintersten Ränge verwiesen. Was passiert da?

Selbst Nicht-Experten fallen wahrscheinlich die folgenden Projekte ein: DeMail, eAusweis mit elektronischer Signatur oder die beliebten Behördenportale wie ServiceBW in Baden-Württemberg. Auch verwaltungsinterne Projekte wie die eAkten-Einführung kommen nicht wirklich voran, obwohl sie seit Jahren auf der Agenda stehen. Sie alle sind als Ankündigungstiger gestartet und drohen als Bettvorleger zu enden. Aus meiner Sicht kranken diese Projekte daran, dass sie eines nicht sind: anwenderorientiert und kundenfokussiert.

Im ganzen Entwicklungsprozess beziehen sie selten bis gar nicht die Sicht der Anwender mit ein. Sie bleiben außen vor und spielen keine Rolle. Und daher werden Schwachstellen und Denkfehler auch erst dann sichtbar, wenn die Umsetzung abgeschlossen ist und das Angebot nicht angenommen wird.

Wenn Bürger lieber Schlange stehen

Zwei Beispiele aus der Praxis zeigen das Dilemma treffend auf: Ein bayrischer Landkreis hat sich auf die Fahnen geschrieben, die Kfz-Abmeldung online abzuwickeln. Sehr gute Idee, denn die Warteschlangen in den Kfz-Zulassungsstellen sind immer recht lang, auch wenn man einen Termin vereinbart hat. Mit Engagement und viel Einsatz wurde der Prozess digitalisiert. Doch am Ende wunderte man sich im Landratsamt, warum gerade mal ein Prozent der Bürger die Möglichkeit nutzt und die restlichen 99 Prozent lieber weiterhin in der Warteschlange am Schalter stehen.

Die Antwort ist einfach: Bei der Umsetzung hatten die Projektentwickler zwar – vorbildlicherweise – immer die Rechtssicherheit und den Datenschutz im Fokus, aber nie die Anwender mit ihren Bedürfnissen. Sie saßen nicht mit am Tisch, sie konnten kein Feedback geben. Heraus kam ein rechtssicherer, wasserdichter digitalisierter Verwaltungsprozess, der vom Anwender verlangte, zig Zahlencodes auf seinen Fahrzeugpapieren freizurubbeln und mehrfach in den PC zu tippen. Statt den Weg zu vereinfachen, wurden zusätzliche Hürden geschaffen. Das wäre vermeidbar gewesen, hätte man die Anwender frühzeitig eingebunden.

Verwaltung retro-digital

Ein weiteres Beispiel erreichte mich dieser Tage auf Twitter. Da erzählte mir ein Twitterati, dass er – nur um eine Adressänderung zu übermitteln – telefonisch einen Zahlencode beim Bezirksamt anfordern musste, der ihm per Post zugeschickt wurde. Erst danach konnte er die Adresse über das Internet übermitteln und bestätigen. Ja, richtig gelesen. Er musste allen Ernstes telefonisch einen Code anfordern, der ihm in Papierform zugeschickt wurde, damit er die Adresse über ein Internetportal weiterleiten konnte. Ähnlich verhält es sich oft mit Digitalisierungsprojekten, die verwaltungsintern ausgerichtet sind. Die berühmte eAkte ist so ein Beispiel. Die potenziellen Fachanwender werden im Entwicklungsprozess selten gefragt, was sinnvoll ist und was nicht, wie er oder sie arbeitet, welche Arbeitsschritte stattfinden. Die Entscheidungen werden in Gremien getroffen, in denen kaum tatsächliche Endanwender sitzen, sondern Fachvorgesetzte, deren Aufgaben wenig Berührungspunkte mit der alltäglichen Arbeit aufweisen.

7 Thesen zum E-Government in Deutschland

Diese Beobachtung verleitet mich dazu, folgende Thesen in Bezug auf das Thema Digitalisierung und E-Government in Deutschland aufzustellen:

  1. Die Digitalisierung der öffentlichen Verwaltung kann nur gelingen, wenn sie anwenderorientiert und kundenfokussiert ist.
  2. Voraussetzung ist eine ganzheitliche Betrachtung der bestehenden Prozesse, der Infrastruktur und Architektur.
  3. Damit die Digitalisierung im Verhältnis „Bürger – Verwaltung“ gelingen kann, muss die Digitalisierung im Inneren der Verwaltung zuerst umgesetzt werden. Was bringt das schönste Bürgerportal, wenn im Hintergrund die Prozesse analog und Medienbrüche der Normalzustand sind.
  4. Iteratives und inkrementelles Vorgehen verringert die Wahrscheinlichkeit eines Scheiterns der Digitalisierungsprojekte der öffentlichen Hand. Fehler werden früh entdeckt und es kann frühzeitig gegengesteuert werden.
  5. Die klassische funktionale Arbeitsteilung der Behörden funktioniert in solchen Projekten nicht. Digitalisierungsprojekte müssen crossfunktional, über Zuständigkeitsgrenzen hinweg gedacht und umgesetzt werden.
  6. Die klassische, hierarchische Denkweise schadet diesen Projekten. Sie blockiert die Anwenderorientierung, indem sie Sachbearbeiter als eigentliche Anwender aus dem Entscheidungsprozess ausklammert. Die Expertise der Fachleute an der Basis bleibt ungenutzt.
  7. Digitalisierung ist nicht die Fortführung der Papierakte auf elektronischem Wege, sondern eröffnet neue Möglichkeiten und Sichtweisen. Erst wenn die Entscheider „out-of-the-box“ denken, wird sie gelingen.

Die Geisteshaltung des agilen Manifests und die Anwendung der entsprechenden Methoden können zwar keine Wunder bewirken, aber sie können dazu beitragen, dass E-Government-Projekte erfolgreicher werden.

Foto: CC0 Creative Commons – pixabay, Alexas_Fotos

Agile Transformation: Mit dem Transition Team Canvas durch die Veränderung navigieren

Wer sich inmitten einer agilen Transformation befindet, kennt gegebenenfalls folgendes Szenario:

Einige Produktentwicklungsteams im Unternehmen arbeiten bereits agil mit Kanban, Scrum, Design Thinking oder anderen Methoden. Die anfängliche Euphorie über die Taskboards, die Rollen von ScrumMaster und Product Owner sowie über die sogenannte „Selbstorganisation“ hat sich gelegt. Die Realität hat die Organisation eingeholt. Selbst bei vermeintlich einfachen Aufgaben, wie dem Bereitstellen eines Teamraums oder dem Anpassen der Stellenbeschreibungen geht es keinen Schritt voran. Es fühlt sich an wie in einer Sackgasse und die Organisation scheint trotz bester Absichten paralysiert.

Um so einem Szenario vorzubeugen, empfehlen wir, vor dem Start der agilen Transformation ein Transition Team zu bilden, das die Transition wie ein Schiff nach vorne navigiert, Stürme meistert und an Klippen und Eisbergen vorbei manövriert. Die Mitglieder des Transition Teams agieren als Change Agents und sorgen dafür, dass Stakeholder rechtzeitig abgeholt werden, unternehmensweite Impediments gelöst werden und der Rahmen für die Produktentwicklungsteams optimiert wird.

Agile Transformation

(c) Sabina Lammert

Doch wer sollte Teil des Transition Teams sein? Diese Frage habe ich mir auch in meinem ersten Transformationsprojekt gestellt. Die richtige Antwort darauf ist: Jeder, der ins Transition Team gehört. Allerdings half mir diese Antwort damals nicht weiter, also habe ich die Frage in ihre Bestandteile zerlegt. Das Ergebnis ist ein Transition Team Canvas, das als Orientierung dabei unterstützt, die potentiellen Mitglieder des Transition Teams zu ermitteln.

(c) Sabina Lammert

Wer sind die Treiber der Agilität im Unternehmen?

Ich habe sie bisher in jedem Unternehmen erlebt: Jene Mitarbeiter, die lange bevor sie das Wort „agil“ gehört haben bereits nach agilen Werten und Prinzipien gearbeitet und gelebt haben. Nach Everett M. Rogers‘ Diffusionstheorie würde man sie als die agilen „Innovators“ und „Early Adopters“ bezeichnen. Sie sind der neuen Führungsphilosophie und den neuen methodischen Ansätzen gegenüber sehr aufgeschlossen. Sie agieren lösungsorientiert und halten nicht verbissen an alten Strukturen fest. Unabhängig davon, wer von ihnen letztendlich im Transition Team sein wird, ist es gut, sich ihrer Existenz bewusst zu sein.

Wer ist der Visionär der Transition?

Mit dieser Frage starten wir die Suche nach dem Product Owner des Transition Teams, der als Visionär das Ziel der Transformation stets vor Augen hat. Er begeistert und motiviert das Transition Team und darüber hinaus die restlichen Mitarbeiter und Führungskräfte des Unternehmens. Er ist dafür verantwortlich, dass die Transition auf Kurs bleibt und überlegt sich die nächsten richtigen Schritte in Absprache mit den Stakeholdern. Zu diesem Zweck pflegt er sein Transition Team Backlog auf den Ebenen der Architektur, der Infrastruktur, der Skills, der Produktentwicklung, der Methode und der fraktal skalierten Organisation (siehe Pyramide „Bausteine der agilen Skalierung“ in „Scrum Think big“ von Boris Gloger).

Wer sind die Treiber im Top-Management?

Die Unterstützung der Geschäftsführung ist für eine erfolgreiche agile Transformation essentiell. Entscheidungen werden schneller getroffen und man sichert sich die Unterstützung bei kritischen Konfrontationen, wenn man das Top-Management einbezieht. Zum Beispiel kommt es vor, dass es zwischen der IT und den Produktentwicklungsteams Formen des passiven Widerstands gibt: Absprachen zur Optimierung der Releasezyklen werden nicht eingehalten und die benötigte Software wird nur langsam beschafft. „Ansagen von oben“ können in solchen Fällen Berge versetzen.

Welche Abteilungen sind am stärksten von der Transition betroffen?

Das eben genannte Beispiel der IT möchte ich an dieser Stelle noch einmal aufgreifen. Wenn man früh in der Transformation feststellt, dass in einer Abteilung an vielen Stellschrauben gedreht werden muss, ist es durchaus sinnvoll, einen entscheidungsbefugten Vertreter genau dieser Abteilung in das Transition Team zu integrieren. Idealerweise findet man jemanden, der das richtige Mindset hat und lösungsorientiert Impediments bearbeitet. Sind zum Beispiel viele Umzüge notwendig, hat es sich als sinnvoll erwiesen, jemanden aus dem Facility Management im Transition Team zu haben.

Welche Stakeholder möchte man im Transition Team wissen?

Stakeholder, die den Change-Prozess ohnehin unterstützen, kann man hier direkt auflisten. Auf jeden Fall sollte man sich über jene Stakeholder Gedanken machen, die dem Transition Team Steine in den Weg legen könnten. Manchmal lohnt es sich, genau diese Stakeholder ins Transition Team holen, damit sie in die Verantwortung genommen werden und den Weg zur erfolgreichen Transformation ebnen.

Wer sind geeignete Vertreter für ScrumMaster und/oder Product Owner?

Die Produktentwicklungsteams gehören zu den „Usern“ der Transformation. Zu Beginn einer Transformation gibt es in der Regel Pilotprojekte, bei denen erste Erfahrungen mit der agilen Methode gesammelt und dem Transition Team jene Impediments gemeldet werden, die die Scrum Teams nicht selbst lösen können. Damit sich die Organisation am Anwender orientiert entwickeln kann, ist hier ein regelmäßiger Austausch notwendig.

Wen sonst möchte man im Team nicht missen?

Natürlich kann es vorkommen, dass manche Personen(-gruppen) für das Transition Team in Frage kommen würden, aber zu keiner der genannten Fragen als Antwort passen. Jedes Unternehmen ist anders und aus diesem Grund lohnt es sich, immer kurz zu überlegen, wer noch fehlen könnte.

Wer ist in der Lage, den gewählten Kreis lateral zu führen?

Nachdem man die potentiellen Mitglieder aufgelistet hat, muss man noch folgende Kriterien prüfen: Freiwilligkeit, Kapazität und agiles Mindset. Die Teammitglieder werden im Vergleich zu einem Scrum Team nicht zu 100 Prozent für das Transition Team arbeiten und hauptsächlich strategisch tätig sein. Operative Tätigkeiten werden an sogenannte Fokusgruppen übergeben (siehe hierzu „Scrum Think Big“ von Boris Gloger). So wie ein Scrum Team sollte auch ein Transition Team nicht mehr als neun feste Mitglieder haben. Eines dieser Mitglieder ist ein Agile Coach, der die laterale Führung übernimmt. Er sollte sowohl mit dem Top-Management als auch mit den Vertretern der Scrum Teams auf Augenhöhe reden können und eine Hands-on-Mentalität haben, da er die Meetings organisiert, strukturiert und Konflikte im Team frühzeitig adressieren muss. Daher sollte die Wahl auf jemanden fallen, der auch dann durchsetzungsstark und standhaft ist, wenn das Top-Management mit unbequemen Wahrheiten konfrontiert werden muss.

Meine bisherigen Erfahrungen mit dem Transition Team Canvas in Zusammenarbeit mit Kunden waren sehr positiv. Durch die klare Fragestellung in den verschiedenen Feldern kann man sich beim Bilden des Transition Teams systematisch und strukturiert vorarbeiten und man erreicht verhältnismäßig mühelos das ursprüngliche Ziel: Jene Leute ins Transition Team zu holen, die ins Transition Team gehören.

 

Meine Präsentation anlässlich der Agile Tour Vienna 2018 zu diesem Thema gibt es hier als Download

Lean Coffee – der Koffeinkick für Ihre Meetings

Morgens, halb zehn in Deutschland. Ein freundlicher Blick von Kollegen, ein leckerer Cappuccino und eine quadratische Waffel mit Milchcreme, Schokolade und Haselnüssen. Großartig – ich bin dabei!
Morgens, halb zehn in Deutschland. Für die meisten in den Büros zwischen Flensburg und Füssen bedeutet dies eher Regelkommunikation, Statusmeeting oder Abstimmungstermin. Im besten Fall gibt es eine Agenda, die dem Termin eine Struktur geben soll – ziemlich fremdbestimmt, aber immerhin. Im schlimmsten Fall gibt es keine Agenda, die Teilnehmer kommen unvorbereitet und einige sind erst Minuten nachdem die Türe geschlossen wurde wirklich präsent.
Wenn das die Realität ist, warum dann nicht damit umgehen? Warum nicht den Meetings eine Struktur, eine Agenda geben in dem Moment, in dem sie gebraucht wird? Zu Beginn! Lean Coffee bietet dafür ein großartiges Format: Einfach, pragmatisch und effektiv. Morgens um halb zehn, nachmittags um vier, am späten Abend, am frühen Morgen und jederzeit dazwischen.

Was Sie für ein effektives Kaffeekränzchen brauchen

Für ein Meeting im Lean Coffee Format benötigen sie nur Post-its, Stifte und einige Teilnehmer. Zuerst werden drei Spalten auf den Tisch gelegt. Links „Themen“, in der Mitte „In Diskussion“ und rechts „Erledigt“. Schon steht die äußere Struktur. Wie das Ganze noch besser geht, kommt in einigen Zeilen.
Im zweiten Schritt erhalten die Anwesenden fünf Minuten Zeit, um ihre Themen, die bei diesem Termin besprochen werden sollen, niederzuschreiben. Nach Ablauf der fünf Minuten werden diese Themen in die Spalte „Themen“ gelegt und nach Inhalten geclustert. Anschließend wird abgestimmt. Jede Person erhält fünf Stimmen und vergibt diese als Punkte (engl. Dot-Vote) auf die Themencluster. Nun werden die Themen oder Themencluster entsprechend der Anzahl der Punkte von oben nach unten in der Spalte „Themen“ priorisiert.

Diskutieren in der Timebox

Das wichtigste Thema wird anschließend direkt in die Spalte „In Diskussion“ gezogen und besprochen. Um die Diskussionen kurz zu halten, werden feste Zeiträume verwendet. Die erste Runde dauert acht Minuten. Nach Ablauf der acht Minuten stoppt der Moderator die Diskussion und fragt, ob noch weitere Zeit benötigt wird. Die anwesenden Personen entscheiden per Mehrheitsentscheid – Daumen hoch oder Daumen runter (engl. Roman-Vote). Senkt die Mehrheit den Daumen, dann ist die Diskussion zu dem Thema beendet und das Post-It wandert in die Spalte „Erledigt“. Gehen die Daumen der Mehrheit nach oben, gibt es Zusatzminuten – nämlich vier. Nach den vier Minuten wird die Prozedur wiederholt und es werden noch zwei Minuten, eine Minute und… dann hoffe ich für Sie, dass die Diskussion ein Ende findet.
Die Unterbrechung der Diskussion nach Ablauf der Timebox ist der kritischste Moment beim Meeting im Lean Coffee Format. Respektieren Anwesende die Timebox nicht, sprechen weiter, möchten nur noch diesen einen letzten Aspekt einbringen, dann verliert das Format seine Kraft und seine Effektivität. Diese wenigen Sekunden Selbstdisziplin sind die neuralgischen Momente, in denen sich entscheidet, ob das Lean Coffee in ihrem Team ein Erfolg wird oder ob es wie bisher weitergeht.
Persönlich finde ich das Lean Coffee Format super! Richtig gut wird es, wenn noch zwei weitere Spalte hinzukommen: „Aha-Effekte“ und „Aufgaben“. Diese beiden Spalten werden mit etwas Abstand rechts von „Erledigt“ angefügt. In „Aha-Effekte“ kommen die neuen Erkenntnisse, die Geistesblitze und neuen Perspektiven, die sich während des Austauschs ergeben haben. Und wenn Aufgaben entstehen, finden diese ihren Platz in To-Dos.

Ein Format, das alle einbezieht

Auf den ersten Blick ist es bereits ein tolles Format. Wenn man noch tiefer blickt, entfaltet es seine wahre Schönheit. Alle Teilnehmer werden gehört, Hierarchiestufen werden aufgehoben, Beiträge kommen gleichermaßen von extrovertierten Personen wie introvertierten, es spielt keine Rolle, ob die Person ein Junior ist oder bereits viele Jahre Berufserfahrung hat, und wortstarke Personen haben keinen Vorteil gegenüber denen, die eher leise Töne anschlagen. Allein die Qualität und Relevanz der Beiträge ist entscheidend und das Team erhält ein großes Stück Selbstorganisation und Demokratie. Gleichzeitig können Führungskräfte (lateral wie funktional) trotzdem Themen, die ihnen wichtig sind, einbringen. Die Spalte „In Diskussion“ trägt dazu bei, den Fokus zu halten. Das aktuelle Thema ist transparent und plakativ, wodurch abschweifende Diskussionen leicht identifiziert werden können. Und am Ende des Termins kann über ein Foto sehr schnell protokolliert werden. Testen Sie hierzu die kostenlose App „Office Lens“ von Microsoft. Diese App bearbeitet die Bilder automatisch auf optimale Lesbarkeit und schneidet sie entsprechend zu.
P.S.: Lassen Sie uns wissen, wie das Lean Coffee bei Ihnen aussieht. Für die ersten fünf Posts auf den Accounts von borisgloger bei Facebook oder Twitter oder per Mail mit einem Bild von Ihrem Lean Coffee gibt es eine kleine Überraschung und diese quadratischen Waffeln mit Milchcreme, Schokolade und Haselnüssen.

Scrum vs. Wasserfall: Auch Agilität braucht Planung

Nach wie vor passiert es, dass wir im Projektalltag den Unterschied zwischen Wasserfall und Agilität erklären müssen. Viele Mythen ranken sich vor allem um die Frage: „Wird denn in Scrum überhaupt geplant, und wenn ja, für welchen Zeitraum?“ Bei den Erklärungsversuchen wird schnell klar: Die Unterschiede zum agilen Projektmanagement werden viel einfacher ersichtlich, wenn es ein Verständnis für das gibt, was Scrum nicht ist. Machen wir also einen kleinen Exkurs in die Welt des klassischen Projektmanagements, um diesem Unterschied auf den Grund zu gehen.

Wasserfall: Genaue Spezifikation vorab

Das Wasserfallmodell gilt als charakteristisch für das klassische Projektmanagement der vergangenen Jahre. Dabei werden sequentielle Projektphasen gebildet, die in einer klar definierten Reihenfolge verlaufen. Umgangssprachlich wird das Wasserfallmodell auch “Over-The-Wall-Ansatz” genannt: Es werden aufeinander aufbauende Teilergebnisse geliefert, die auf ein vorab vollständig spezifiziertes Projektziel einzahlen. Diese Teilergebnisse sind klar voneinander abgegrenzt und werden meist wie über eine Mauer in den nächsten Bearbeitungsschritt „geworfen“. Die Mitarbeiter sind bei dieser Vorgehensweise ausschließlich für einen kleinen Bereich des Gesamtprodukts verantwortlich – den Gesamtzusammenhang müssen sie nicht zwingend verstehen.

Scrum: Mit kontinuierlichem Feedback zum passgenauen Ergebnis

Agile Vorgehensweisen basieren auf einem iterativen und inkrementellen Ansatz, es wird mit Feedbackschleifen und Teilprodukten als Lieferungen gearbeitet. Schnelles Kunden- und Nutzerfeedback, kontinuierliche Verbesserung und das Liefern vollständig abgeschlossener Produktfunktionalitäten stehen dabei im Fokus der Entwicklung. Im Gegensatz zum Wasserfallmodell ist es eine Aneinanderreihung vieler PDCA-Zyklen, es gibt also ein kontinuierliches „Plan – Do – Check – Act“ entlang der gestellten Anforderungen. Das ständige Abgleichen des erreichten Status Quo spitzt das Ergebnis besser auf das zu, wofür der Kunde letztendlich wirklich bezahlen möchte. Somit kann es nicht vorkommen, dass lange Zeit in eine falsche Richtung gearbeitet wird, denn Änderungen in den Anforderungen und in der strategischen Stoßrichtung können kurzfristig berücksichtigt und umgesetzt werden. Sinnvoll wird diese Vorgehensweise gerade dann, wenn man sich in einem sehr dynamischen Umfeld befindet, in dem Anforderungen und Technologie noch unbekannt sind oder sich häufig ändern.

Wie plant man eigentlich agil?

Wenn wir nun also die Kollegen fragen, was sie am Wasserfall so sehr schätzen, berufen sich viele auf die Möglichkeit der langfristigen Planung. Das sei mit Scrum schließlich nicht möglich, dort würde nur in Sprints mit einem Horizont von zwei Wochen gedacht. Weit gefehlt. Natürlich wird auch in Scrum in Form eines Releaseplans ein Planungsausblick über eine längere zeitliche Einheit hinweg gewährleistet. Trotzdem wird in Sprints gedacht und der Releaseplan ist in Zwei-Wochen-Abschnitten getaktet. Ein massiver Unterschied zur Wasserfallplanung ist aber die Tatsache, dass es sich stets um eine lebendige Planung handelt und diese, je nach Umständen und Rahmenbedingungen, zu gegebener Zeit angepasst werden sollte. Gerade in dynamisch hochkomplexen Märkten können sich die Anforderungen innerhalb kurzer Zeit ändern, sodass eine agile Anpassung der Planung überlebenswichtig wird.
Denn im Vordergrund steht das Produkt, mit dem man einen möglichst hohen Geschäftswert erzeugen möchte. Die Frage lautet also: Welche Funktionalitäten müssen wir in den nächsten Sprints in jedem Fall entwickeln, sodass wir die richtigen Funktionalitäten und damit den maximalen Mehrwert bieten, mit dem wir Käufer gewinnen können?
Viel Erfolg in euren Projekten wünschen euch Jessica und Marcel!

Foto: CC0 Creative Commons – Pixabay, Pexels

Scrum als Managementrahmen für bürgerschaftliches Engagement

Warum ist gerade Scrum für bürgerschaftliches Engagement geeignet? Dazu lohnt ein Blick darauf, was bürgerschaftliches Engagement überhaupt ist und unter welchen Rahmenbedingungen bürgerschaftliches Engagement entstehen bzw. gedeihen kann.
An den Anfang dieses Beitrags möchte ich eine kurze Geschichte stellen. Eine Geschichte über den Amtsleiter in einer Stadtverwaltung, der den Auftrag bekommen hat, das Thema Bürgerschaftliches Engagement voranzutreiben und eine Freiwilligenagentur aufzubauen. Nennen wir ihn Klaus.
Klaus freut sich auf seine neue Aufgabe. Eine Herausforderung, bei der er hofft, sein Steckenpferd Projektmanagement voll ausleben zu können. Und so startet er euphorisch durch. Innerhalb kürzester Zeit entsteht eine Projektskizze mit einer echten Projektorganisationsstruktur, einem Projektstrukturplan und einer ersten Meilensteinplanung. Parallel arbeitet er in einem Bürgerbeteiligungsprojekt mit, das ein erfahrener externer Moderator begleitet, und lässt sich – zusammen mit einem ehrenamtlichen „Pendant“ – zum Bürgermentorentrainer ausbilden. Nach einigen Monaten merkt er jedoch, dass er mit den klassischen Projektmethoden nicht weiterkommt. Immer wieder wird ihm von interessierten Bürgerinnen und Bürgern signalisiert, dass die Begrifflichkeiten eher erschrecken und sie nicht bereit sind, sich durch enge Vorgaben und Strukturen binden zu lassen. Klaus folgert daraus, dass der von ihm angestrebte Projektmanagementrahmen nicht mit den Bedürfnissen bürgerschaftlich engagierter Menschen vereinbar ist. Aber wie kann er die Projektarbeit in diesem Themenfeld professionalisieren, ohne die intrinsische Motivation bürgerschaftlich Engagierter durch zu viele Vorgaben und Beschränkungen zu gefährden? Der Gedanke lässt ihn nicht los und er beginnt zu recherchieren und sich umhören. Ein befreundeter Softwareentwickler bringt ihn auf die Idee: Scrum. Das könnte doch etwas sein. Selbstorganisierte Teams mit klar umrissenen Rollen, wenigen Regeln, enger Zusammenarbeit … er wird neugierig.

Bürgerschaftliches Engagement – eine kurze Einordnung

Bürgerschaftliches Engagement bezeichnet freiwilliges bzw. ehrenamtliches Engagement in einem breiten Spektrum. Vom klassischen Ehrenamt bis hin zu vergleichsweise kurzfristigen, auf konkrete Projekte bezogenem Engagement, bei dem die Motivlage eng mit Themen wie Verantwortung für andere, dem Lernen von Gemeinschaftsfähigkeit oder aktiv werden als Mitbürger verbunden ist. (Vergl. hierzu: Bericht der Enquete-Kommission des Deutschen Bundestags, 2002, S. 34) Bürgerschaftlich Engagierte sind primär intrinsisch motiviert. Für sie spielt die Teilhabe am sozialen und gesellschaftlichen Leben eine zentrale Rolle. Verschiedene Studien legen auch nahe, dass es eine hohe Korrelation zwischen Bildungsstand und Engagement gibt, d. h. bürgerschaftlich engagierte Menschen sind überdurchschnittlich hoch qualifiziert, verfügen über ein ausgeprägtes Fach- und Allgemeinwissen. Auch zeichnen sie sich durch eine hohe Wissbegier aus und bevorzugen selbstbestimmtes Arbeiten.
Die Selbstentfaltung, aber auch der soziale Kontakt, sind zentrale Motive für ihr Engagement. Sie entsprechen damit weitgehend dem Typus des sogenannten Wissensarbeiters. Bürgerschaftliches Engagement entfaltet sich daher insbesondere dann, wenn diese Menschen einen Rahmen zur Verfügung gestellt bekommen, der ihnen den Freiraum lässt, sich selbst zu entwickeln. Die Engagierten können innerhalb dieses Rahmens selbstbestimmt arbeiten, ihre Kenntnisse und ihr Wissen einbringen und weitgehend selbst entscheiden, in welchem Umfang sie sich einbringen möchten. Kurzfristige Verpflichtungen sind ebenso möglich, wie langfristiges Engagement – je nach Motivlage und persönlichen Möglichkeiten der Engagierten. Ein solcher Rahmen muss den Raum lassen, der nötig ist, damit die Engagierten selbst entscheiden, wohin die Reise gehen soll.

Die wesentlichen Merkmale von Scrum

Scrum ist ein Managementrahmen, der ursprünglich aus der Softwareentwicklung stammt und auf den Prinzipien des „Agilen Manifests der Softwareentwicklung“ basiert. Wesentliches Kennzeichen von Scrum ist das iterativ-inkrementelle Vorgehen in kurzen Planungszyklen, bei denen am Ende mithilfe der empirischen Überprüfung die nächste Iteration geplant wird. Scrum „tastet“ sich dabei Schritt für Schritt, Iteration für Iteration an das optimale Ergebnis heran. Im Vergleich zu anderen Projektstandards wie Prince 2.0 ist der Scrum Leitfaden ein „Leichtgewicht“, in dem der Rahmen auf das Wesentliche reduziert und von allen unnötigem Ballast befreit wird. Die klassischen Führungsrollen gibt es in Scrum nicht. Scrum-Teams sind hochgradig selbstorganisiert. Die Führung im Team ist auf drei Rollen verteilt, die unterschiedliche Schwerpunkte wahrnehmen. Der sogenannte Produkteigentümer (Product Owner) fokussiert auf das WAS aus Sicht des Ergebnisses, das angestrebt wird. Der Scrum Master achtet auf die Produktivität des Gesamtteams und seiner Mitglieder, während das Entwicklerteam sich auf das WIE und die Qualität des Ergebnisses fokussiert ist. Das Prinzip der Freiwilligkeit ist fester Bestandteil der Scrum-Prinzipien. Dies befördert die enge Zusammenarbeit im Team und zwischen den drei verschiedenen Rollen. Boris Gloger erweitert das Rollenmodell zusätzlich um den Auftraggeber/Kunden (Geldgeber), das Management (Rahmenbedingungen) und den Anwender/Nutzer.
Daher ist der Scrum-Prozess insbesondere auf eine gute Kommunikation ausgerichtet, die sich um fünf Ereignisse bildet:

Der Scrum-Leitfaden schlägt drei Artefakte für die Prozesssteuerung vor:

Wichtig: Scrum-Teams arbeiten nicht im stillen Kämmerlein, sondern binden Anspruchsberechtigte (Management, Auftraggeber, Anwender) in jedem Sprint ein. Unter anderem beim Sprint Review, bei dem Anspruchsberechtigte, insbesondere die Anwender ausdrücklich gebeten werden, Feedback zu geben. Durch die maximale Länge einer Iteration erhalten so die Scrum-Teams frühe Rückmeldung, die unmittelbar in die Planung und Umsetzung der nächsten Iteration einfließen kann.

Für welche bürgerschaftlichen Projekte ist Scrum geeignet?

Scrum spielt seine Stärken in ergebnisoffenen „Entwicklungsprojekten“ aus, bei denen zu Beginn nur eine grobe Vision dessen besteht, was erreicht werden soll. Gerade bei komplexen Fragestellungen, bei denen mit vielen Unbekannten zu rechnen ist, bietet der Scrum-Rahmen die Möglichkeit, risikoarm Lösungen zu erarbeiten. Daher bietet sich Scrum bei umfangreicheren, bürgerschaftlichen Projekten an, bei denen oft nur eine grobe Vorstellung dessen vorhanden ist, was am Ende des Prozesses entstehen soll. Der Managementrahmen von Scrum wird dabei den besonderen Bedürfnissen, mit denen bürgerschaftlich Engagierte an Projekte herangehen, besonders gerecht. Hierarchien sind flach, die Möglichkeit zur Selbstentfaltung ist gegeben. Die Mitglieder des Scrum-Teams können erheblichen Einfluss auf die Entwicklung nehmen. Und selbst Interessierte, die nicht Teil des Scrum-Teams sind, haben die Möglichkeit, im Projekt zu partizipieren statt nur „Objekte“ des Projekts zu sein. Durch den Fokus auf gute Kommunikation wird der soziale Faktor des bürgerschaftlichen Engagements ebenso antizipiert. Die meisten bürgerschaftlichen Projekte entstehen im kommunalen Umfeld. Häufig tritt daher die öffentliche Hand in Form der Gemeinde- bzw. Stadtverwaltung als Finanzier auftritt, und hier bietet es sich an, diese als Auftraggeber bzw. Kunden des Projekts zu definieren. Die Herausforderung für den Produkteigentümer besteht dann darin, sowohl die Sicht der Verwaltung als auch der Kommunalpolitik im Auge zu behalten.

Wie könnte ein scrumgeführtes bürgerschaftliches Projekt aussehen – ein fiktives Beispiel

Anhand eines Beispiels, mit realen Bezüge zu verschiedenen Projekten aus der kommunalen Praxis, lässt sich im Folgenden aufzeigen, wie ein bürgerschaftliches Projekt mit Scrum aussehen könnte. Es handelt sich um ein Projekt, das aus der Bürgerschaft initiiert und von der Stadtverwaltung logistisch und finanziell unterstützt wird. Die Idee ist, einen Ort der Begegnung für alle Generationen zu schaffen. In einer ersten Vision ist von einer Begegnungsstätte die Rede, die unter anderem ein bestehendes Jugendhaus einbinden soll. Der Gemeinderat übernimmt die Rolle des Auftraggebers, die Rolle des Scrum Masters wird einem moderationserfahrenen Mitarbeiter des Sachgebiets Bürgerschaftliches Engagement übertragen. Die Rolle des Managements wird durch die Stadtverwaltung ausgefüllt. In die Rolle des Produkteigentümers schlüpft der Initiator des Projekts aus der Bürgerschaft. Dem Entwicklerteam gehören Vertreter des Jugendhausträgervereins, des Seniorenrats, der örtlichen Vereine und der örtlichen Bürgerstiftung an. Das Entwicklerteam umfasst insgesamt fünf Personen.
Nach anfänglichen Anlaufschwierigkeiten während der ersten drei Sprints, die in erster Linie der fehlenden Erfahrung mit Scrum geschuldet sind, hat sich das Scrum-Team etabliert. Alle vier Wochen findet zum Sprintende eine öffentliche Präsentation der Sprintergebnisse im kleinen Sitzungssaal des Rathauses statt, zu der die Bürgerschaft herzlich eingeladen ist. Zwar nutzt nur eine Handvoll Einwohner die Möglichkeit, aber seitens des Gemeinderats ist aus jeder Fraktion jeweils mindestens ein Vertreter beim Review anwesend. Auch der Bürgermeister nimmt an den Review-Terminen teil. Regelmäßig wird über die Ergebnisse im örtlichen Amtsblatt sowie auf der städtischen Website berichtet.
Die anfängliche Skepsis städtischer Mitarbeiter und einiger Bürger ist zwischenzeitlich einer anerkennenden Wahrnehmung gewichen. Befürchtungen, dass im Zuge des Projekts utopische Luftschlösser entwickelt würden, sind nicht eingetreten. Durch die enge Zusammenarbeit der Beteiligten bildet sich zunehmend ein besseres Verständnis der Rahmenbedingungen und Bedürfnisse heraus, das bis weit in die Bürgerschaft und die Verwaltung ausstrahlt. Neun Monate später liegt ein Konzept mit Finanzierungsplanung zum Umbau eines bestehenden städtischen Gebäudes vor, das im Zuge der Haushaltsberatungen ohne weitere Diskussion durch den Gemeinderat beschlossen wird. Vereine und Institutionen haben sich bereit erklärt, die Umsetzung ebenso – in Form von Arbeitsleistungen – zu unterstützen und die Kosten für die bauliche Maßnahme zu reduzieren.

Fazit

Auch wenn im ersten Moment die von der Softwareentwicklung geprägten Begriffe irritieren mögen, passt der Rahmen von Scrum bestens zum bürgerschaftlichen Engagement. Dahinter verbergen sich nämlich Prinzipien und Haltungen, die jenen des bürgerschaftlichen Engagements nicht unähnlich sind und dieses daher im Sinne einer Professionalisierung des Arbeitsrahmens unterstützen, ohne den Charakter des bürgerschaftlichen Engagements zu gefährden.

Scrum for dating – one step at a time

Dating apps like Parship, Elite Partner, Lovoo, Badoo,Tinder (you name them) and some pseudo dating apps like Bumble and the inner circle are on the rise in Germany and internationally.
But what does the increase in those apps and platforms tell us? Are we more prone to fall at the mercy of algorithms and spreadsheets to e-meet people of the opposite or same sex? Or has dating actually become complex / difficult because we can’t estimate the outcome and might potentially make a trade-off?
No brainer, but individuals in the Northern hemisphere are increasingly becoming individualistic and self-centered. Keeping ourselves happy, creating memories, pursuing a healthy lifestyle is pretty far up on our priorities. Hence, why should one forgo these aspirations and deal with a complete stranger, where getting to know him or her means doing less of what we love to do. Getting to know someone takes TIME! Yap, the time we invest to get to know another self-loving, neo-liberal, weird, sometimes depressive yet longing for love and attention seeking person is scary but worth a contemplation.
How do we deal with this intricate situation? I believe that the Scrum methodology can unfold its power in any sort of complex situation.
The Stacey Matrix is a good tool to evaluate whether it is feasible to use an agile method like Scrum or not. Imagine being in a prospective and sustainable relationship is our vision, starting a relationship with a suitable and complementing partner is our end product. Deploying this to the Stacey Matrix, working on a prospective and sustainable relationship is WHAT we produce incrementally (product) and opening up and spending time are examples of how we want to reach the goal (functionalities).

Stacey Matrix

The Stacey Matrix for dating

In Scrum, a potentially shippable product (sub product) is incrementally produced in a timeboxed period and is called a “Sprint”. In each sprint we decide how many functionalities we want to implement in order to develop a potentially shippable product increment. Let’s go through a possible “Scrum Flow of Dating”.
Scrum Flow
Product Idea: I don’t want to be alone anymore
Product Vision: Being in a prospective and sustainable relationship OR I want to get married
The team: The Dating-Scrum team consists of the persons pursuing a relationship. In a heterosexual endeavor, the woman might collaborate with her female squad to solve occurring impediments ☺
Prioritized Product Backlog: All items (functionalities / requirements) written in the form of user stories necessary to reach the end goal. The items are prioritized according to the return of invest:

*Example User Story: We want to make ourselves available so that we can spend maximum time getting to know one another.
Release Plan: Wow, we could actually estimate what date the annual celebration will be. The day we will finally start officially dating as an approved couple.
Sprint Planning 1: We decide WHAT we want to do. Along our prioritized product backlog, we now choose the user stories we want to implement in our first sprint. These should be the user stories, which have the highest value for our endeavor – the “business value”. Hence, which functionalities will most likely deliver a high return of investment? For example, if we go on a short trip we might quickly find out the “highs” and the “lows” of the person in investigation. We have invested a concentrated piece of time and have a high outcome. Anyways, this could also go wrong. So, think of what functionalities you are best taking up in your first sprint. The selected items cumulate in the so-called “Sprint Backlog”.
Sprint Planning 2: We decide HOW we want to do it. Here, we take up each user story from the “Sprint Backlog” and deduce tasks as to how to implement the selected user stories. This is a technical meeting where we talk about how to do what. So, if we took the travelling user story again, we will write tasks such as: book flight, book hotel, decide on day and nighttime activities, plan budget, mobility, choose restaurants etc.
Sprint: We set a timebox in which we want to have implemented the selected user stories and hence have produced our first increment. A sprint should not be any longer than 1 month in order to ensure quick feedback cycles.
Daily: TALK DAILY. Communication is key!
Sprint Review: The Sprint Review is where we present what we have achieved in the Sprint. It’s the success meeting (hopefully) where we showcase our first potentially shippable product. Here, the team could showcase to each other, what they have learnt about each other during the holidays and how they feel more comfortable with each other. The new level of familiarization should be the product increment here.
Sprint Retrospective: The meeting which scrutinizes how the team worked together. This meeting does not focus on the product but solely on the working relationship. Hence, did the team like their communication while planning the vacation, what went well and what can be improved during the Sprint? What should we change or adapt? Or are we on the right lane in the way we work together reaching the common goal?
The Retrospective meeting closes a sprint and is also the prelude to the next sprint. We choose new product backlog items, write tasks, start the sprint, showcase the outcome and discuss our working relationship.
This mirrors the plan, do, check and act cycle.

Why is it beneficial to date agile?

In our fast-paced world, where time always comes at the expenses of other things that could have been done, I think that dating iteratively can be a promising model to pursue a sustainable relationship while managing our so important duty-stuffed life’s. It allows for adaption while pursuing a loving relationship. Key elements are the stipulation and constant reiteration of the common goal and the constant communication among the committed team. No concession should be made around these elements.
Foto: CC0 Creative Commons – pixabay, StockSnap

Von Löwen und dem Mut, sich auf Scrum einzulassen

Verschränkte Arme, kritischer Blick und einen spöttischen Zug um den Mund – so steht er mal wieder in unserem Sprint Planning 2. Manchmal lauert er auch wie ein Löwe, lauert auf die nächste Gelegenheit zum Angriff. Er ist schon sehr lange dabei. Er weiß, wie der Laden läuft und er ist Experte auf seinem Gebiet. Stolz wie ein Löwe nutzt er nur zu gerne jede Gelegenheit, um zu präsentieren, wie bisher alles gemacht wurde und welche Erfolge er dabei verzeichnen konnte. Wozu er jetzt mich – diesen sogenannten ScrumMaster – brauchen sollte, der ihm sagt, wie er noch effizienter arbeiten kann, versteht er nicht. Warum er ständig an diesen Meetings teilnehmen muss und transparent machen soll, woran er gerade arbeitet, versteht er noch weniger. Und was ist eigentlich dieses Scrum? Wer hat sich das schon wieder ausgedacht? Er beobachtet argwöhnisch jeden meiner Schritte und gibt mir zu verstehen, dass ich ein Eindringling in seinem Herrschaftsgebiet bin.
Jeder kennt sie, diese Art von Kollegen. Veränderung fällt ihnen schwer. Sie können sich nicht so leicht wie die anderen darauf einlassen. Eine neue Methode wie Scrum in den Arbeitsalltag zu integrieren, ist eine solche Veränderung. Manche Menschen können damit umgehen, manche nicht. Was man dabei immer im Hinterkopf behalten sollte: Jede Veränderung bringt auch einen größeren oder kleineren Verlust mit sich. Und jeder Mensch begegnet diesem Verlust unterschiedlich.

Verlust verstehen mit den fünf Phasen der Trauer

Mir hat die Beschreibung der fünf Phasen der Trauer von Elisabeth Kübler-Ross – Verleugnung, Verärgerung, Verhandlung, Depression und Akzeptanz – dabei geholfen, die möglichen Reaktionen auf Verlust und damit die unterschiedlichen Reaktionen von Menschen auf Veränderungen besser zu verstehen. [vgl. Kübler-Ross, Kessler 2005, S. 7-24] Das Leugnen der Veränderung hilft uns durch den ersten Schockzustand, indem wir uns nur so weit auf die Realität einlassen, wie wir es im Moment aushalten können. Der Ärger, den wir fühlen, sobald wir das gesamte Ausmaß der Veränderung realisieren, kann auf ganz unterschiedliche Ziele gerichtet sein: Kollegen, Management oder auch die Familie. Manchmal versuchen wir, über die Folgen der Veränderung zu verhandeln, um einen Ausweg aus der Situation zu finden. Eine typische Frage, die für mich die Unsicherheit in der Depressionsphase deutlich macht, lautet: „Warum soll ich mich denn überhaupt noch anstrengen, ergibt das noch Sinn?“ Und irgendwann gelangen wir an den Punkt, an dem wir die Veränderung Stück für Stück akzeptieren können und lernen, mit ihr zu leben.
Anzunehmen, dass jede einzelne Phase linear durchlaufen wird und Wochen ja vielleicht sogar Monate fortwährt, ist falsch. Wir reagieren in diesen Phasen auf Gefühle, die Stunden oder auch nur Minuten andauern und sich an keine vorgeschriebene, rationale Abfolge halten!

Wie ScrumMaster durch den Verlust führen können

Doch zurück zu unserem Löwen. Wie helfe ich ihm als guter ScrumMaster jetzt durch diese Situation? Mein erster Impuls bei einer solchen ablehnenden Haltung ist immer, den Kollegen darauf anzusprechen. Ich möchte verstehen, was das Problem ist, es aus der Welt schaffen und ihn dazu befähigen, sich auf diese Reise in die Agilität einzulassen. Doch genau das ist es, worauf der Löwe wartet: Wertschätzung im Sinne von Aufmerksamkeit zu erhalten und dadurch in seiner ablehnenden Haltung bestärkt zu werden.
Wieso also sollte ich ihm genau das geben, was er möchte und ihn wertschätzen, wo er sich doch dem ganzen Team gegenüber respektlos benimmt? Deshalb konzentriere ich mich auf die Teammitglieder, deren motiviertes und offenes Verhalten zum Erfolg des Projekts beiträgt. Getreu dem Motto: Ich konzentriere mich auf die Einstellung, von der ich mehr möchte. Ich ignoriere den Löwen auf der anderen Seite des Raums und schenke dem restlichen Team meine Aufmerksamkeit. Ich bestärke die Haltung des Löwen nicht und signalisiere ihm, dass er die Phasen der Trauer weiter durchlaufen muss. Dadurch versuche ich, ihn dazu zu bringen, über sein Verhalten zu reflektieren und er lernt, dass nur jene Teammitglieder eine Belohnung in Form von Aufmerksamkeit bekommen, die mir und der Methode offen begegnen und respektvoll miteinander umgehen. Jedoch achte ich wachsam darauf, wann er sich der Methode und dem Team gegenüber öffnet. Dann bin ich da, um ihm dabei zu helfen, wieder zum Team aufzuschließen – inhaltlich, aber auch emotional. Ich beantworte seine Frage und nehme ihn mit auf unsere Reise. Und dabei ist mir stets bewusst, dass man einen wilden Löwen nie ganz zähmen kann.

[Kübler-Ross, Kessler 2005]
Kübler-Ross, Elisabeth; Kessler, David: On Grief and Grieving: Finding the Meaning of Grief Through the Five Stages of Loss. Simon and Schuster 2005.
Foto: CC0 Creative Commons – pixabay, IanZA