Der agile Baum als Orientierungshilfe im Dschungel der agilen Begrifflichkeiten

Ein Beitrag von Carsten Rasche & Constanze Rieß

Die Startphase in der Auseinandersetzung mit agilen Methoden kann schnell zu einer überfordernden Erfahrung werden. Es gibt eine Vielzahl von agilen Frameworks wie Scrum, Kanban, Design Thinking oder Lean Start-up. Jedes Framework hat seine eigenen Praktiken, Prinzipien und Werte. Die Anzahl neuer Begrifflichkeiten ist groß.

In unserer Arbeit begegnen wir Menschen mit unterschiedlichem Vorwissen in Sachen Agilität: Manche haben sich bereits intensiver mit einer Methode auseinandergesetzt und fragen sich vielleicht, wie diese in Beziehung zu einer anderen Methode steht. Andere haben einzelne Begriffe aufgeschnappt. Was oft fehlt, ist das Verständnis des groben Zusammenhangs zwischen Begriffen und Methoden. Statt einem Bild davon, was Agilität umfasst, herrscht Wirrwarr.

Um hier Orientierung zu schaffen, stellen wir die Zusammenhänge gerne mithilfe eines Baumes dar. Dieser Baum eignet sich zum Beispiel dafür, mit einer Gruppe von bis zu 30 Personen ein gemeinsames Bild davon zu erzeugen, was Agilität bedeutet.

Das erste Mal haben wir den agilen Baum bei einem Trainertreffen von bikablo® „wachsen lassen“. Wie wir dabei vorgegangen sind und welche Inhalte sich hinter den einzelnen Bereichen des Baums verbergen, veranschaulichen wir in diesem Blogbeitrag.

Eins noch vorab: Der Baum erhebt natürlich keinen Anspruch auf Vollständigkeit, sondern ist, wie jedes agile Artefakt, eine Visualisierung gemeinsamen Kontextes als Einladung zu weiterer Konversation.

Der agile Baum im Überblick

Der agile Baum, eine Verortung von agilen Werten, Prinzipien, Frameworks und Praktiken. In Einführungsworkshops fragen wir die TeilnehmerInnen, was sie bereits über Agilität wissen, und ordnen die Begrifflichkeiten dem jeweiligen Bereich zu.

In der Baumkrone befinden sich agile Praktiken. Das sind konkrete Werkzeuge, wie zum Beispiel eine Definition of Done, User Storys oder eine Persona. Sie entstammen meist aus einem der agilen Frameworks, wo sie genauer beschrieben werden. In der Praxis werden in der Regel mehrere dieser Werkzeuge kombiniert und die Teams suchen sich die Praktiken heraus, die zu ihrem aktuellen Kontext passen. Praktiken helfen Teams, Agilität handhabbar und ausführbar zu machen. Sie sind eine Sammlung von Good Practices, die Teams beim iterativen Entwickeln von Produkten helfen. Praktiken können zudem wie Kirschen einzeln vom Baum gepflückt und eingesetzt werden und auch unabhängig vom Einsatz ganzer Frameworks Nutzen stiften.

Unterhalb der Baumkrone gibt es den Bereich der agilen Frameworks. Die Frameworks fassen verschiedene Praktiken zu einem genauer beschriebenen Vorgehensmodell zusammen. Das Scrum-Framework besteht beispielsweise aus dem Ineinandergreifen bestimmter Rollen, Meetings und Artefakte und ist dadurch viel mehr als die situative Kombination verschiedener Praktiken.

Wie bereits erwähnt haben viele der einzelnen Praktiken ihren Ursprung in einem der großen Frameworks. Die Arbeit mit Taskboards kommt beispielsweise aus dem Lean Management und die Arbeit mit User Storys aus dem Extreme Programming. Interessant ist, dass die beiden Praktiken so gut funktioniert haben, dass sie im Zuge der Weiterentwicklung von Scrum auch Teil des Scrum-Frameworks geworden sind.

Im und um den Baumstamm sind die agilen Prinzipien wie Face-to-face-Kommunikation, Kundenzentrierung und Selbstorganisation zu finden. Die Prinzipien dienen Teams als konstante Erinnerung daran, was wichtig für die eigene Zusammenarbeit und die Organisation ist. Der Baumstamm dient hier auch als gute Metapher. Wenn die Prinzipien nicht eingehalten und gelebt werden, kann man zwar einzelne agile Praktiken verwenden. Sie werden aber nicht ihre volle Wirkung entfalten, weil die solide Grundlage dazu fehlt. Ein Team kann mit den schönsten Scrum Boards arbeiten und dennoch das Prinzip Kundenfokussierung komplett missachten, indem beispielsweise kein Feedback eingeholt wird. Die Zusammenarbeit im Team kann in dem Fall als extrem positiv wahrgenommen werden. Das entwickelte Produkt erfüllt am Ende aber womöglich nicht seinen Zweck.

Die Wurzeln des Baums bilden die agilen Werte. Die Werte sind der Nährboden und die Basis für die Prinzipien und Praktiken. Werte sind für Gruppen grundsätzlich als wünschenswert anerkannte Vorstellungen, die Menschen Orientierung geben. Im agilen Kontext beschreiben die Werte eine gemeinsame Grundhaltung, auf die sich die Beteiligten für ihre Arbeit einigen. Bei den ersten Berührungspunkten müssen MitarbeiterInnen und deren Organisationen miteinander aushandeln, ob und wie sie die Werte leben wollen. Der gemeinsame Aushandlungs- und regelmäßige Reflexionsprozess ist dabei das Entscheidende.

Die ursprünglichen vier Wertepaare stammen aus dem Agilen Manifest:

Individuen und Interaktionen stehen über Prozessen und Werkzeugen
Funktionierende Software steht über einer umfassenden Dokumentation
Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
Reagieren auf Veränderung steht über dem Befolgen eines Plans

Scrum fußt auf den fünf Werten Fokus, Mut, Offenheit, Respekt und Commitment. Die Werte dienen Teams und Organisationen als Reflexionsinstrument. Die Leitfrage ist: „Werden die Werte gelebt? Und wenn nicht, was können wir tun?“ Eine kontinuierliche Betrachtung und Reflexion der Werte – beispielsweise in Retrospektiven – unterstützt die nachhaltige Anwendung von Scrum.

Ein weiteres Beispiel für einen agilen Wertekanon findet sich bei Kanban. David Anderson ist davon überzeugt, dass Kanban nur erfolgreich ist, wenn die Anwender aus der Überzeugung der Werte agieren (1). Die neun Kanban-Werte sind Transparenz, Balance, Kollaboration, Kundenfokus, Arbeitsfluss, Führung, Verständnis, Vereinbarung und Respekt.

Agiles Mindset beschreibt die innerste Einstellung und Überzeugung, die Menschen bei ihrem beruflichen Handeln antreibt. Im Vergleich zu den Werten, die von der Gruppe gelebt werden, ist das Mindset eine persönliche, innere Einstellung. Personen, die ein agiles Mindset verinnerlicht haben, kann man als lösungsorientierte Personen beschreiben, die in ihrem Umfeld alles dafür tun, dass sie sich selbst und die Strukturen, in denen sie sich bewegen, weiterentwickeln. Sie schrecken nicht vor bestehenden Hierarchien zurück und haben Mut, auch mal provokative Lösungen auszuprobieren. Grundsätzlich ist ein solches Mindset nicht einfach da. Es erfordert Arbeit und Reflexion, um es zu entwickeln. Der Einzelne prägt das Unternehmen. Agile Organisationen zeichnen sich dadurch aus, dass es in ihnen viele Personen gibt, die so handeln.

Auf der vertikalen Ebene hat der Baum noch eine Achse: Sie geht vom Pol Being Agile, der bei Mindset und den Wurzeln startet, bis hin zu Doing Agile in der Baumkrone und bei den Praktiken. Die Metapher des Baums verdeutlicht, dass die Wurzeln des Baumes – das agile Mindset und die Werte – die Grundlage von agilem Arbeiten bilden. Sie machen den Kern aus. Wenn Individuen und Teams versuchen, nach dem agilen Mindset und den Werten zu handeln, ist es fast egal, welche Prozesse und Praktiken sie anwenden. Sie werden über die Zeit zu den für sie richtigen Elementen kommen.

In der Agile Community wird die reine Anwendung von agilen Praktiken und Prozessen ohne die Berücksichtigung des dahinterliegenden Kerns auch als Fake Agile oder Cargo Cult bezeichnet.

Es ist aber nicht falsch, agile Praktiken und Prozesse wie aus dem Lehrbuch auszuprobieren, ohne von Beginn an genau zu wissen, was agiles Mindset bedeutet und damit einige der Werte zu missachten. Wir ermutigen unsere Kunden, je nach Bedarf und Situation, beispielsweise Scrum in seiner Reinform auszuprobieren. Dadurch findet eine wichtige Kontextveränderung statt. In einem Team funktionieren Dinge auf einmal nicht mehr so wie früher. Auf einmal gibt es einen Product Owner und einen ScrumMaster sowie eine Reihe von Meetings, in denen jedes Teammitglied gleichberechtigt ist. Über das Ausprobieren, das Fehlermachen und das Weiterentwickeln der Praktiken und Prozesse beispielsweise in Retrospektiven stoßen Teams darauf, was Being Agile bedeutet. Being Agile bedeutet Anpassungsfähigkeit. Die Prozesse und Praktiken werden auf den eigenen Kontext adaptiert. Agilität breitet sich organisch aus, wird weiterentwickelt und über die Zeit von einer größeren Anzahl an Personen verstanden.

So könnt ihr die Methode in einer Workshop-Einheit verwenden

Was ihr dafür braucht

Vorbereitung

Durchführung

Die Anzahl der agilen Praktiken, Frameworks und Methoden ist groß. Falls ihr Anregungen braucht, womit der agile Baum gefüllt werden könnte, empfehlen wir euch den Talk von Craig Smith 40 Agile Methods in 40 Minutes und eine dazu erstellte Grafik von Lynne Cazaly.

Wir wünschen euch viel Erfolg beim Verwenden des agilen Baums und beim Schaffen eines gemeinsamen Bildes von Agilität und freuen uns, wenn ihr eure Erfahrungen mit uns teilt!

 

Lust auf eigene Artefakte aus Papier – aber du kannst doch gar nicht zeichnen? Das ändern wir binnen zwei Tagen im Visual Scrum Training.

Mehr Storys aus der Visualisierungs-Praxis und mehr Beispielbilder? Gibt’s hier auf youtube.

 

Literatur:

(1) Anderson, D.J., & Carmichael, A. (2016). Essential Kanban Condensed. Blue Hole Press.

 

Scrum4Schools: Wie führt man Scrum in der Schule ein?

Wir (Vera und Julia) haben eine weitere Schule gefunden, die anders lernen möchte. Am 15.03.2019 startete eine 9. Jahrgangsstufe des Gymnasiums in Trudering bei München im Fach Religion, mit Scrum4Schools zu lernen. Warum im Fach Religion? Die beiden Lehrerinnen wollten eine neue Methode ausprobieren, welche die Gestaltung des Lernprozesses in die Hände der SchülerInnen übergibt und die Persönlichkeitsentwicklung fördert. Wie man Scrum in der Schule einführen und das Kick-off gestalten kann, möchten wir im Folgenden veranschaulichen.

Vorbereitung

Im Vorfeld des Kickoff-Termins bekamen die 41 Schülerinnen und Schüler die Aufgabe, über Scrum zu recherchieren, damit diese einen ersten Kenntnisstand der Methode gewinnen konnten. Daraus entstanden viele schöne Onepager.

Scrum Flow

Scrum Loop

Start und Check-in

Nun stand der Kickoff-Tag bevor. Der Zeitplan war straff, denn in einer 90-minütigen Timebox zählt jede Sekunde. Deshalb haben wir uns intensiv auf diesen Tag vorbereitet, um einen reibungslosen Ablauf sicherzustellen. Wir starteten mit einer kurzen Vorstellung und gaben zunächst einen ersten Überblick über die Agenda.

Agenda Scrum4Schools

Danach folgte ein kurzer Check-in – der sogenannte Klatschkreis. Alle 41 SchülerInnen und zwei Lehrerinnen standen mit uns Beratern in einem großen Kreis. Nun ging es darum, ein Klatschsignal an seinen Nachbarn zu senden, der es wiederum seinem Nachbarn weitergibt. Als Ergebnis soll ein immer schneller werdender Fluss entstehen. Ein schönes Aufwärmspiel und gleichzeitig eine wunderbare Rhythmusübung, die frische Energie in die Runde bringt.

Inhaltlicher Einstieg

Anschließend lernten die SchülerInnen mit teils evangelischem und teils katholischem Glauben, was Scrum überhaupt ist, wo es herkommt und wie wir von borisgloger consulting eigentlich auf Scrum4Schools gekommen sind. Die SchülerInnen und Lehrerinnen hörten gespannt zu und durften Fragen stellen.

Formierung der Lernteams

In der zweiten Hälfte der Unterrichtseinheit teilte sich der evangelische und katholische Unterricht in die jeweiligen Klassen auf. Nun ging es darum, Lernteams zu bilden, die aus jeweils 4–5 Schülern bestehen. Im katholischen Unterricht durften die SchülerInnen die Teams selbst zusammenstellen. In der evangelischen Religionslehre hingegen gingen SchülerInnen und Lehrerin einen Kompromiss ein. Es konnten freiwillig Zweier- bzw. Dreier-Teams gebildet werden, die dann im Anschluss durch die Lehrerin zu vollständigen Lernteams formiert wurden. Die erste Variante der Teamzusammenstellung hat den Vorteil, dass die SchülerInnen frei wählen können, mit wem sie am liebsten zusammenarbeiten wollen. Dies hat allerdings die Kehrseite, dass die sozial schwächeren SchülerInnen am Ende übrigbleiben könnten und somit auch eine crossfunktionale Verteilung nicht mehr sichergestellt wäre.

Die zweite Variante der Teamzusammenstellung ist daher ein schöner Kompromiss, um etwas von beidem zu gewährleisten.

Die Aufgabenstellung

Die Teams erhielten daraufhin ein Arbeitsblatt mit Lernzielen, die sie sich selbst auswählen durften. Die SchülerInnen mit evangelischem Glauben bekamen Lernziele zu den Themen Berufsorientierung und weltweite Arbeitsbedingungen aus evangelischer Sicht. In der katholischen Religionslehre erhielten die SchülerInnen Lernziele zum Themengebiet der Auseinandersetzungen des 20. Jahrhunderts, in denen auch die Kirche in Frage gestellt wurde.
Das Arbeitsblatt enthielt zudem wichtige Informationen bezüglich der Rahmenbedingungen für die Erfüllung der Lernziele. Am Ende sollen die Schüler eine ca. 60-minütige Präsentation abhalten, die eine Umfrage, ein Interview und ein oder mehrere Fallbeispiele umfasst.

Strukturierung des weiteren Arbeitsprozesses

Pro Team wurde außerdem ein/e StrukturheldIn gewählt, der/die für die Einhaltung des Prozesses zuständig ist. Darunter fallen Aufgaben wie die Einhaltung der Zeit, die Moderation der Meetings und die Besprechung von Hindernissen der Teams mit dem Lerncoach.

Zu guter Letzt wurden die nächsten Schritte besprochen. In der darauffolgenden Einheit lernen die Schüler, Storys zu schreiben, ein Taskboard zu bauen und sich die Planung für die Sprintphase zu erarbeiten.

Wir dürfen gespannt sein, wie es hier weitergeht. Vorab ein kleiner Teaser:

Scrum in der Schule

Scrum und Kanban als Betriebssysteme für Planungsabteilungen

Heute unterstütze ich als Management Consultant Teams und Organisationen bei der Einführung agiler Arbeitsmethoden und bei der agilen Gesamttransformation. Dabei bin ich in ganz unterschiedlichen Branchen unterwegs. Die Baubranche kenne ich aufgrund meines beruflichen Werdegangs von innen, blicke aber mittlerweile auch von außen – aus der Perspektive anderer Branchen – auf diesen Bereich.

Dabei komme ich zu einer klaren Einsicht: Ich wäre froh gewesen, wenn ich vor zehn Jahren die agilen Frameworks Scrum und Kanban schon gekannt hätte, mit denen ich mittlerweile täglich arbeite. Dabei geht es nicht darum, dass ich beispielsweise Scrum 1:1 umgesetzt hätte. Nein, das agile Mindset, die Selbstorganisation eines Teams mit Klebezetteln, die Scrum- und Kanban-Prinzipien, all das hätte mir geholfen, mein Team besser zu organisieren und produktiver zusammenzuarbeiten.

Aber wie hätten die damaligen Projekte nach heutigen Maßstäben aussehen können? Im Folgenden möchte ich euch einige hypothetische Szenarien vorstellen, um zu veranschaulichen, welches Potenzial agiles Denken auch in der Baubranche entfalten kann.

Ausgangssituation 1: Gründung und Führung eines Planungsteams

Worum ging es damals? Ich war in einem Generalbauunternehmen tätig. Wir hatten gewisse Probleme mit der Gebäudetechnikplanung und waren auf externe Fachplaner angewiesen, die ihren Job mehr schlecht als recht machten. Also beschlossen wir, die Technische Gebäudeausrüstung (TGA) künftig in Teilen selbst zu planen. Da auch wir aufgrund des Fachkräftemangels keine TGA-Fachingenieure aus dem Hut zaubern konnten, bestand unser Team aus jungen lernwilligen, doch fachfremden Ingenieuren sowie ein paar alten Hasen, die als Freelancer ihre Erfahrung einbrachten.

Die Aufgaben und Herausforderungen für das Planungsteam

Was hätte ich im Rückblick anders gemacht, jetzt da ich agiles Arbeiten kenne?

Wir hätten uns intensiver darum gekümmert, im Team und mit dem Vorgesetzten ein gemeinsames Verständnis davon zu entwickeln, was wir erreichen wollen. Wir hätten uns sogar auf Fertigungskriterien geeinigt, wie wir Step by Step zum gemeinsamen Ziel gelangen wollen (zum Beispiel mit User Storys und einem Backlog). Wir hätten uns zudem regelmäßig und funktionsübergreifend die nächsten Schritte angesehen (z. B. mit Hilfe eines Refinement bzw. Estimation Meetings).

Statt uns im Team auf unsere jeweilige Spezialisierung zu konzentrieren, wäre es hilfreich gewesen, wenn wir ganz bewusst zu zweit an Aufgaben gearbeitet hätten, um gegenseitig mehr voneinander zu lernen. Dadurch hätten wir zum einen das Denken in TGA-typischen Silos, wie z. B. Ingenieur vs. Technischer Zeichner, begrenzt und wären flexibler in der Aufgabenbearbeitung geworden. Zum anderen wäre es leichter gewesen, für eine gleichmäßige Auslastung der Teammitglieder zu sorgen. Auf jeden Fall hätten wir Spaß daran gehabt, cross-funktional an und mit unseren „T-shaped Skills“ zu arbeiten.

Um unsere Aufgaben zu organisieren, nutzten wir ein Online-Kollaborationstool. Das funktionierte zwar technisch wunderbar, jedoch hatten wir Schwierigkeiten damit, die richtige Granularität der Aufgaben zu finden. Hier hätten uns übergeordnete User Storys (d. h. aus Nutzersicht formulierte Funktionalitäten) geholfen, uns nicht zu sehr im Klein-Klein des Aufgabenmanagements zu verlieren, sondern uns auf das große Ziel zu fokussieren.

Ein tägliches Stand-up-Meeting vor einem physischen Taskboard hätte unsere Kommunikation und Selbstorganisation zudem verbessert.

Ausgangssituation 2: Gründung und Führung der Planungsabteilung

Springen wir nun in eine andere berufliche Situation, ein paar Jahre nach der eben beschriebenen Erfahrung mit meinem ersten TGA-Planungsteam. Mein damaliger „jugendlicher“ Leichtsinn trieb mich dazu, das unter dem schützenden Dach eines Generalunternehmers erprobte Arbeitsmodell auf die neu zu gründende TGA-Planungsabteilung eines freien Ingenieurbüros zu übertragen. Dies brachte weitere Herausforderungen mit sich.

Die Aufgaben und Herausforderungen für die Planungsabteilung

Was hätte ich im Rückblick anders gemacht, jetzt da ich agiles Arbeiten kenne?

Im Rückblick hätte ich gemäß den Scrum-Prinzipen feste Teams mit fester Zuordnung zu einem Teamleiter gebildet, damit die Teammitglieder voneinander lernen und (zusammen-)wachsen können. Anstatt Ressourcen zwischen Projekten hin- und herzuschieben, hätten die Projekte und Teilaufgaben zwischen den Teamleitern koordiniert und priorisiert werden müssen. Die Teams hätten dann gemäß ihrer Gesamtkapazität Projekte und Aufgaben bearbeitet.

Aufgaben wären somit nicht ad hoc und kleinteilig auf die Bearbeiter verteilt worden, sondern das ganze Team hätte gemeinsam Aufgaben Zug um Zug gemäß Priorisierung fertiggestellt. Es wäre Aufgabe der Teamleiter gewesen, die Priorisierung gemeinsam zu verhandeln.

Durch die gemeinsame Bearbeitung von Aufgaben wären diese schneller und mit direkter Qualitäts-Kontrolle abgeschlossen worden. Dadurch wäre Last von den Schultern der erfahrenen Wissensträger genommen worden.

Wir hätten daran gearbeitet, Vertrauen und Zutrauen statt Misstrauen als Basis der Zusammenarbeit im Team zu stärken. Es wäre gar nicht notwendig gewesen, Aufgaben detailliert vorzugeben, wenn statt einer Ressourcensteuerung eine inhaltliche Steuerung der Bearbeitungsfolge umgesetzt worden wäre.

Schließlich hätten wir Prozesse projektübergreifend wiederholbar definieren und diese visualisieren können (z. B. mit einem Kanban-Board).

Fazit

Teamorganisation, Aufgabenverteilung und vieles mehr hätten besser funktioniert, wenn ich schon damals das Wissen über Scrum und Kanban und die Erfahrung mit agilem Arbeiten gehabt hätte. Ich bin davon überzeugt, dass agile Methoden einen ganz wichtigen Beitrag zur Organisation von Bauplanung und Planungsabteilungen sowie zur Qualitätssicherung leisten können. Und es ist an der Zeit, diesen Methoden auch in der Baubranche zu mehr Bekanntheit zu verhelfen.

Meine Empfehlung lautet daher: Ingenieure und Architekten, beschäftigt euch mit Scrum und Kanban und baut Elemente davon in eure Prozesse ein!

Das Potenzial von Scrum außerhalb der Software-Entwicklung

Während agiles Arbeiten mit Methoden wie z. B. Scrum oder Design Thinking für viele noch Neuland darstellt, ist es für uns bei bg nicht nur Teil unserer täglichen Arbeit, sondern auch unseres Denkens und Seins.

Ich selbst bin über Design Thinking (DT) zum agilen Arbeiten gekommen – damals völlig fasziniert von den Möglichkeiten, neue Produkte in einem kurzen Zeitraum zu entwickeln und zu verproben. Wie viele andere neue Dinge kann DT im ersten Moment regelrecht euphorisieren. Eine Kollegin sagte mir sogar, dass sie DT-Methoden ständig auch im Privaten nutzen würde: zur Urlaubsplanung, Wochenendgestaltung oder um eigene Ideen zu entwickeln.

Kann man nun agile Methoden wirklich in allen möglichen Situationen nutzen? Im ersten Moment eine vielleicht eher schwierige Vorstellung. Doch es gibt einen schlüssigen Grund, warum immer mehr Unternehmen agiles Arbeiten für sich entdecken und sich diese Arbeitsweisen über die letzten Jahre und Jahrzehnte immer mehr etabliert haben: Sie befähigen Teams dabei, schneller und produktiver zu arbeiten. Ein gutes Beispiel dafür ist Scrum – ursprünglich aus der Software-Entwicklung kommend, nun auch in der Hardware-Entwicklung im Einsatz und sogar von großen Kaufhäusern und Online-Shops genutzt.

Doch was, wenn man kein physisches Produkt entwickelt, sondern z. B. beratend tätig ist oder sein Geld mit Ideenentwicklung verdient? Schließen sich Agilität und bestimmte Branchen aus? Nicht unbedingt! In fast jedem Team und Unternehmen kann man „Bausteine“ von Scrum nutzen, um produktiver zu arbeiten und den Kunden schnellere und sichtbarere Ergebnisse zu liefern. Ähnlich wie meine Kollegin Elemente aus den DT-Methoden für ihre Urlaubsplanung genutzt hat, bewerte ich die Grundidee der Scrum-Meetings auch abseits des Entwicklungsumfelds als vorteilhaft.

Planung und iteratives Arbeiten

Viele gehen fälschlicherweise davon aus, dass es in Scrum keine Planung gäbe – ein Irrglaube, denn zur Planung kommt es nur an anderen Stellen: Anstatt ein Projekt vorab monatelang abzustimmen, arbeitet man in Iterationen (“Sprints”), zu deren Beginn ein Sprint Planning stattfindet. In diesem Meeting geht es darum, die Ziele des Sprints sowie den Weg der Zielerreichung zu besprechen. Durch Sprints erhalten Teams einen Rhythmus und eine Struktur, die nicht zu unterschätzen ist, da sie dem Team Orientierung geben. Man kann sich ein Scrum Team ähnlich wie ein Orchester vorstellen: Es gibt unterschiedliche Instrumente, aber alle folgen einem gemeinsamen Rhythmus, um ein zusammenhängendes, wohlklingendes Stück zu erzeugen.

Bei Scrum arbeiten Teams inkrementell und iterativ, d. h. die Entwicklung erfolgt in kleinen Schritten, deren Ergebnisse umgehend in das Gesamtprojekt oder -produkt eingebunden werden. Sprich: Am Ende jedes Zyklus’ wird ein Produkt oder Teil davon geliefert. Der Kunde bekommt in kurzen Abständen regelmäßig „Teile“ seines Produktes geliefert, anstatt erst nach Monaten das fertige Produkt zu sehen, das seine Ansprüche dann vielleicht gar nicht in vollem Umfang widerspiegelt. Die zyklische Abstimmung mit dem Kunden hat den Vorteil, dass Anpassungswünsche schnell umsetzbar sind und keine monatelange Arbeit verloren geht – ein Benefit, den mehr Unternehmen für sich nutzen sollten.

Die Voraussetzung von Scrum: den Fokus finden

Bevor wir mit Scrum und den Meetings starten, ist es wichtig, dass wir uns fokussieren. Warum sollte man agil arbeiten? Was wollen wir erreichen? Wenn wir uns nicht auf das Wesentliche konzentrieren, besteht (auch im agilen Bereich) die Gefahr, dass wir dem “Shiny Object Syndrome” verfallen: Wir überladen uns, wollen immer informiert sein, alles Neue und Aufregende ausprobieren, gehen zu allen (Agile) Meetups, hören Podcasts über Scrum, abonnieren diverse Newsletter und melden uns für 4 Agile-Konferenzen an.

Zuerst sind wir berauscht von all den Informationen, den neuen Ideen, den scheinbar unendlichen Möglichkeiten und der Inspiration. Doch die Ernüchterung folgt auf schnellem Fuße: Was fange ich wirklich mit all diesen Informationen an? Wie viel Zeit brauche ich, um sie zu verarbeiten? Wo fange ich an? Um diese Ernüchterung zu vermeiden, ist das WHY vor der Einführung von Scrum und anderen agilen Methoden so wichtig. Ist das Warum geklärt, können wir uns auf die Meetings konzentrieren.

Das Ziel und der Weg dorthin: Sprint Planning 1 und 2

Auch wenn ein Unternehmen keine neue Software entwickelt, sondern z. B. beratend tätig ist, kann ein Sprintziel wichtiger Bestandteil des täglichen Doings werden: Wo möchte ich in zwei Wochen stehen? Was sind meine (kurz- und mittelfristigen) Ziele? Ein Sprintziel festzulegen, schafft Orientierung, Motivation und Messbarkeit. Die große Frage des WHY sollte man am Ende des Sprint Plannings beantworten können. Im Sprint Planning 2 geht es dann klassischerweise um das HOW, also die Frage, wie ich die gesetzten Ziele erreiche.

Die tägliche Abstimmung im Daily

Das Daily dient dazu, die tägliche Arbeit des Teams zu synchronisieren, einen Überblick zu haben, wer gerade woran arbeitet und ob es zu bewältigende Herausforderungen (sog. Impediments) gibt.

Da selbst kleine Teams oft einen hohen Kommunikationsaufwand haben, kann dieses Meeting auch wunderbar außerhalb von (Software-)entwickelnden Teams eingesetzt werden. Die Teamleiterin oder der Teamleiter kann hierbei die Funktion des ScrumMasters übernehmen oder die Rolle des ScrumMasters kann in einem regelmäßigen Rhythmus weitergereicht werden. Durch das Daily erspart man sich E-Mails, regelmäßiges Nachfragen, was andere Kolleginnen und Kollegen machen oder wo sie sind, und es eröffnet einen Raum, in dem man Impediments aufzeigen und Unterstützung finden kann. Zusätzlich kann man das Daily nutzen, um mithilfe eines Burn-Down-Charts die bereits geschaffte Arbeit bzw. den Fortschritt zu dokumentieren.

Feedback in Review & Retrospektive

Jeder Sprint wird mit zwei Meetings abgeschlossen: Review und Retrospektive. Im ersten wird das Ergebnis des Sprints präsentiert. Während in der Software-Entwicklung hier normalerweise die Entwickler den Kunden durch die entwickelte Plattform führen, können Teams und/oder Unternehmen mit anderen Leistungsschwerpunkten dem Auftraggeber/Kunden andere Ergebnisse präsentieren: Prototypen, Materialmuster, Konzepte, Design- und Gestaltungsentwürfe – kurzum: alles, was man für den Kunden bewirkt hat.

Durch das Review und das gemeinsame Betrachten der Arbeitsergebnisse kommt es zu einem wertvollen Austausch zwischen Auftraggeber/Kunden und den Umsetzern, im Zuge dessen Erwartungen abgeglichen werden können. Es entsteht Raum für Feedback und die Möglichkeit, auf die geschaffte Arbeit zurückzublicken sowie (gemeinsam) Erfolge zu feiern.

In der Retrospektive, die nur innerhalb des Teams (d. h. ohne Kunden) durchgeführt werden soll, nehmen die Teammitglieder die Prozesse unter die Lupe und denken darüber nach, was verbessert werden kann. Das Themenspektrum reicht dabei von den Kommunikationsstrukturen bis zum Umgang mit Fehlern – alle Anregungen, die das Team weiterbringen, sind hier erwünscht. Wer sein Team erfolgreich führen will, nutzt diese Gelegenheit für Feedback und Prozessoptimierung und somit für kontinuierliche Verbesserung.

Fazit – ist Scrum für jedes Team geeignet?

Mit Scrum zu arbeiten oder Methoden wie Design Thinking zu nutzen, scheint zunächst verführerisch und leicht umsetzbar. Dennoch braucht es Disziplin, um den Fokus zu halten und iterativ zu arbeiten.

Wie eingangs erwähnt, sollte sich jedes Team bzw. Unternehmen zunächst Gedanken um das Warum machen, sodass Scrum oder einzelne Meetings zielgebunden eingeführt werden können und sich neue Meetings nicht mit den bereits vorhandenen überschneiden oder sogar zu gefühlten “Pflichtveranstaltungen” entwickeln.

Die Vorteile von Scrum sind jedoch nicht von der Hand zu weisen: Zielorientierte Planung, welche die aktuellen Umstände mit in Betracht zieht (Sprint Planning), regelmäßiger Austausch (im Daily), Feedback zur Projektentwicklung und zum Prozess (Review & Retro) schaffen nicht nur im Software-Umfeld bessere Rahmenbedingungen, sondern können auch in anderen Bereichen dazu beitragen, schneller, flexibler und kundenorientierter zu arbeiten.

Backlog schreiben – eine Aufgabe für das Entwicklungsteam

Was haben alle großen Erfindungen gemeinsam? Sie wurden nicht von Leuten kreiert, denen vorgeschrieben wurde, was sie zu liefern haben, sondern diese haben sich selbst überlegt, was der User wirklich braucht. Oder den User zumindest sehr gut gekannt.

Wer schreibt also nun das Backlog? Im Optimalfall bringt man das Development Team selbst dazu, sich mit dem User auszutauschen und auf Basis dieser Erkenntnisse das Backlog zu produzieren. Wie das funktionieren kann? Das erfährst du im folgenden Erklärvideo:

Produktentwicklung am Beispiel des Scrum Flows in 25 Schritten erklärt

„Wir machen jetzt Scrum!“ Diesen Satz hört man häufig, wenn Unternehmen ihre Produktentwicklungsprozesse agil gestalten wollen. Doch was steckt hinter diesem Ansatz und wie funktioniert der Scrum Flow überhaupt? Eine Frage, mit der sich viele Projektbeteiligte, welche bislang nur wenig bis gar keine Erfahrung mit Scrum haben, oft schwertun.

Macht sich auch in dir gerade das Gefühl von Überforderung breit, weil du nicht weißt, wo du anfangen sollst? Den Scrum Flow zu verstehen ist dabei eine Sache, ihn zu erklären eine ganz andere. Die nachfolgenden 25 Schritte sollen dir dabei helfen, eine gedankliche Struktur zu schaffen, an der du dich im Arbeitsalltag orientieren kannst. Den Scrum Flow gekonnt erklären? Für dich ab sofort kein Problem!

Der Scrum Flow

Scrum Flow

1. Am Anfang steht der Product Owner (PO) mit einer Idee. Sein Ziel ist es immer, ein Produkt auf den Markt zu bringen, welches sowohl sinnstiftend für den Nutzer als auch gewinnbringend für die Organisation ist.

2. Eine Produktidee alleine reicht aber nicht aus. Man braucht ein genaues Bild davon, was man erreichen möchte – die „Vision“.

3. Dieses Bild, die „Vision“, hat einen Rahmen und dieser Rahmen spiegelt den Kontext wider.

4. Der Kontext ist insofern wichtig, da sich die Produktvision immer in einem Rahmen bewegt, welcher durch die Organisation vorgegeben wird (z. B.: Passt die Produktvision zur Unternehmensvision/dem Geschäftsmodell? Werden regulatorische Anforderungen eingehalten?)

5. Der PO ist zudem für den Return on Investment (ROI) verantwortlich. Er steht in engem Kontakt mit dem Auftraggeber und berücksichtigt dessen Interessen, da dieser das Projekt finanziert.

6. Zurück zur Vision! Diese sollte möglichst mitreißend und motivierend sein. Warum? Weil der Product Owner ein Team braucht, das mit ihm gemeinsam an der Umsetzung dieser Produktvision arbeiten möchte („Prinzip der Freiwilligkeit“).

7. Und hier kommt das Entwicklungsteam ins Spiel. Das crossfunktional aufgestellte Expertenteam ist Teil des Scrum-Teams, welches durch sein Können für die praktische Umsetzung und die Qualität des Produkts verantwortlich ist (z. B. Fachleute, Developer und Tester).

8. Das Entwicklungsteam bildet dabei den Link zum User. Es geht darum, in fest definierten Zyklen Feedback zum Produkt einzuholen und dieses in die weitere Entwicklung einfließen zu lassen.

9. Damit die intensive Zusammenarbeit zwischen dem PO und dem Entwicklungsteam gut funktioniert, wird das Scrum-Team durch den ScrumMaster (SM) vervollständigt. Seine Hauptverantwortung liegt darin, dass das Scrum-Team insgesamt produktiv arbeiten kann und die Scrum-Regeln eingehalten werden.

10. Der SM arbeitet dabei kontinuierlich mit dem Management zusammen, da das Management für die Entwicklung und die Verbesserung von Strukturen und Richtlinien in der Organisation verantwortlich ist.

11. Zurück zur Vision! Nun muss sich der PO Gedanken darüber machen, welche Nutzerbedürfnisse durch das Produkt adressiert werden sollen. Kurzum: Welche Funktionalitäten müssen wir liefern, die auf unsere Vision einzahlen und gleichzeitig einen Nutzen für unsere Nutzergruppe schaffen?

12. Dazu schreibt der PO, entweder alleine oder gemeinsam mit dem Entwicklungsteam, erste User Storys (US). Diese User Storys werden in einem Product Backlog erfasst. Da der PO für den ROI verantwortlich ist, priorisiert er diese nach dem jeweiligen Nutzenwert.

13. In einem nächsten Schritt führt das Entwicklungsteam eine erste initiale Schätzung des priorisierten Backlogs durch. Das Entwicklungsteam beurteilt dabei, wie viel Funktionalität/Mehrwert eine US bringt (Es wird nicht der Aufwand geschätzt, da dieser vom Erfahrungsschatz und Können der jeweiligen Person abhängig ist). Als Ergebnis der Schätzung liegen nun sämtliche, mit Story Points bewertete US vor.

14. Der PO erstellt nun einen initialen Release Plan, indem er die US entlang einer Zeitachse in die Sprints verteilt, in denen diese voraussichtlich bearbeitet werden. Der Release Plan ermöglicht eine Vorschau bzw. Prognose, in welcher Zeit welche Funktionalität geliefert werden kann. Hierin ist vermerkt, wann voraussichtlich genug Funktionalität entwickelt wurde, um einen Release durchzuführen.

15. Wichtig ist, dass genug US vorliegen, die innerhalb eines Sprints erledigt werden können, damit der erste Sprint beginnen kann. Das Ziel an dieser Stelle ist nicht eine monatelange Planung, sondern so schnell wie möglich mit der Entwicklung loszulegen, um rasch Feedback zum Produkt generieren zu können.

16. Ist der erste initiale Release Plan erstellt, können wir nun von der strategischen Ebene (strategische Planungsebene) auf die taktische Ebene wechseln, auf der die tatsächliche Produktentwicklung in Form von Sprints vonstattengeht.

17. Das erste Meeting auf der taktischen Ebene ist das Sprint Planning 1 (SP1). In diesem ersten Sprint Planning wird die Frage geklärt, was im bevorstehenden Sprint erledigt werden soll. Der PO erläutert sein Ziel für den Sprint und erklärt konkret, was er sich unter den einzelnen US vorstellt. Das Entwicklungsteam stellt Fragen und entwickelt ein Gefühl dafür, was es in diesem Sprint bearbeiten kann.

18. Am Ende des SP1 steht das Commitment des Entwicklungsteams. Dieses Commitment ist ein „Akt der Freiwilligkeit“, weshalb das Entwicklungsteam bei seiner Entscheidung nicht durch den PO beeinflusst werden darf. Es ist Aufgabe des ScrumMasters, darauf zu achten, dass diese Regel nicht verletzt wird. Das Ergebnis ist das Selected Product Backlog.

19. Das nächste Meeting ist das Sprint Planning 2. Hier bespricht das Entwicklungsteam, wie die einzelnen US, welche für den gegenwärtigen Sprint committet wurden, umgesetzt werden sollen. Es entstehen erste konkrete Tasks, welche auf dem Taskboard festgehalten werden.

20. Im Laufe des Sprints gibt es ein tägliches Synchronisationsmeeting, das Daily Stand-up Meeting. Hier organisiert sich das Entwicklungsteam selbst und jedes Mitglied erläutert kurz und knapp, welchen Task es gestern erledigt hat, welchen Task es am aktuellen Tag erledigen möchte und welche Impediments (Hindernisse) es gibt. Ziel ist es, den Austausch im Team zu fördern, Entwicklungsfortschritte transparent zu machen und Impediments direkt zu identifizieren.

21. Der SM hört beim Daily Stand-up Meeting aufmerksam zu und nimmt die Impediments in sein Impediment Backlog auf. Seine Aufgabe ist es, dass alle Impediments, welche außerhalb der Verantwortlichkeiten des Entwicklungsteams liegen, gelöst werden. Hierzu steht er in engem Kontakt mit dem Management, da dieses die Entscheidungsgewalt über organisationsinterne Strukturen und Richtlinien hat. Indem der SM die Impediments gemeinsam mit dem Management löst, kann der Wandel zur agilen Organisation stetig vorangetrieben werden.

22. Am Ende des Sprints wird das vom PO abgenommene Produktinkrement vom Entwicklungsteam im Review vorgestellt. Das Review ist ein öffentliches Meeting, an dem jeder teilnehmen kann. Im Kern geht es darum, dem Kunden sowie dem Nutzer das fertige Produktinkrement vorzustellen und Feedback zu bekommen. Dieses Feedback wird vom PO im Product Backlog als neue US aufgenommen.

23. Direkt darauf folgt die nicht öffentliche Retrospektive. Dieses Meeting ist das Herzstück des Scrum-Prozesses, denn das Scrum-Team analysiert hierbei den eigenen Arbeitsprozess. Es geht darum, herauszufinden, wie das gemeinsame Arbeiten verbessert werden kann, um im nächsten Sprint noch produktiver zu werden. Die Impediments werden nach Wichtigkeit und Nutzen priorisiert und es wird geklärt, ob diese im Verantwortungsbereich des Teams oder der Organisation liegen. Letztlich werden (konkrete) Verbesserungsmaßnahmen abgeleitet.

24. Während des Sprints, der optimalerweise eine Woche dauert, findet das Backlog Refinement statt. Hierbei geht es primär darum, das Product Backlog mithilfe der gewonnenen Erkenntnisse aus dem Review (Kundenfeedback) zu aktualisieren. Die bereits vorhandenen User Storys werden überprüft und gegebenenfalls geschnitten (eine US wird in kleinere US unterteilt). Völlig neue User Storys werden vom PO vorgestellt und durch das Entwicklungsteam wiederum initial geschätzt. Bereits vorhandene User Storys werden in der Schätzung angepasst.

25. Dabei folgt der Scrum Flow dem Zyklus Plan-Do-Check-Act (Deming Cycle), welcher eine kontinuierliche Optimierung von Produkt und Prozess ermöglicht.

Auf den Punkt gebracht.

Die 25 Schritte des Scrum Flows machen deutlich, worum es bei der agilen Produktentwicklung geht. Es geht um das permanente Liefern von fertigen Produktinkrementen und darum, möglichst schnell Feedback zu generieren, um Produkte stets auf die Bedürfnisse des Kunden auszurichten. Der PO hat dabei eine besonders wichtige Position inne, denn er ist für die Value Proposition des Produktes verantwortlich. Er muss den Markt kennen, ihn verstehen und er muss wissen, was sich der Endnutzer des Produktes wirklich wünscht, ohne dabei die Wirtschaftlichkeit des Produktes aus den Augen zu verlieren.

Tool versus Mindset: Warum bei Agilität die Haltung entscheidet

Agile Managementframeworks wie Scrum, Kanban, Design Thinking und Co. haben viele Gemeinsamkeiten – darunter leider auch die Tatsache, dass sie nach all den Jahren teilweise noch immer als Tools missverstanden werden. Dabei ging es von Anfang eher darum, einen neuen Zugang zu finden, wie man vorhandene Probleme in den Griff bekommt. Worauf man sich dabei konzentrieren sollte? Das erfährst du in diesem Video.

Was die Pharmaindustrie von der Erfolgsgeschichte agiler Methoden lernen kann

Gerade in Branchen wie der Pharmaindustrie, die stark von außen reguliert werden, sind es Teams gewohnt, dass Prozesse und Abläufe klar definiert sind, dass es eine eindeutige Zuordnung von Zuständigkeiten gibt und die Entscheidungsbefugnisse ebenso klar verteilt sind. Dabei haben die Mitarbeiterinnen und Mitarbeiter innerhalb der täglich zu durchlaufenden Prozesse kaum Gestaltungsfreiräume, da die Entscheidungskompetenzen auf Gremien oder Managementebenen verlagert sind. Als Endresultat tragen die einzelnen Mitarbeiterinnen und Mitarbeiter kaum Verantwortung. Und auch die Produktentwicklung bleibt hiervon nicht verschont.

Wie Einzelkämpfer im Staffellauf

Ikujiro Nonaka und Hirotaka Takeuchi haben dieses Phänomen bereits 1986 in ihrem berühmten Artikel „The New New Product Development Game“ sehr treffend beschrieben. Sie verglichen das mehrheitlich in Unternehmen genutzte Produktentwicklungskonzept mit einem Staffellauf, bei dem ein Läufer den Staffelstab an den nächsten übergibt.

Wer schon einmal eine Staffel bei einem Marathon gelaufen ist, weiß, dass gerade die Übergabe gewisse Risiken mit sich bringt: Hat die vorherige Läuferin, der vorherige Läufer eine gute Zeit erzielt, so möchte man diesen Vorsprung natürlich ausbauen. Auch umgekehrt verhält es sich ähnlich: Liegt man bereits zurück, will man nicht noch mehr Zeit verlieren. Als Konsequenz findet die Übergabe des Staffelstabs – bzw. heute des Zeitmessers – immer unter enormem Zeitdruck statt und häufig gehen wertvolle Informationen zwischen den LäuferInnen verloren.

Was bei der Staffel Streckenverlauf oder Windbedingungen sind, können in der pharmazeutischen Produktentwicklung Informationen zu Spezifikationen oder Formulierung sein. Zudem verleitet eine so klare Trennung der Verantwortlichkeiten dazu, nicht über den eigenen Tellerrand hinauszusehen. Beim Staffellauf beispielsweise wird jede Läuferin, jeder Läufer für sich an der eigenen Kondition und der persönlichen Bestzeit auf dem jeweiligen Streckenabschnitt des Marathons arbeiten. In Unternehmen wird die Auswirkung dieser klaren Trennung zwischen den Expertenteams noch deutlicher. Das Team, das mit der eigentlichen Entwicklung beschäftigt ist, optimiert diese Phase so für sich, dass der Staffelstab möglichst kurz im eigenen Team verweilt und schnell zur nächsten Entwicklung übergegangen werden kann. Bei diesen Verbesserungen haben die Teams selten den gesamten End-to-End-Prozess im Blick, sondern häufig nur ihren Zuständigkeitsbereich. Die Resultate sind nicht mehr optimal funktionierende Schnittstellen und ein fehlendes Verantwortungsbewusstsein für den gesamten Prozess, den das Produkt durchlaufen muss.

Der Rugby-Ansatz für selbstorganisierte Teams

Die beiden Autoren Ikujiro Nonaka und Hirotaka Takeuchi schlagen in ihrem Artikel den sogenannten Rugby-Ansatz als Lösung vor. Sie referieren hier auf jene Phase beim Rugby, in welcher der Ball innerhalb des Teams immer wieder übergeben wird, während das Team auf dem Spielfeld Raum gewinnt. Das gesamte Team arbeitet somit Hand in Hand, hat jederzeit alle Informationen verfügbar und kann innerhalb des Spielzugs sofort auf Aktionen des Gegners reagieren. Auf den Entwicklungsprozess übertragen zielt dieser Ansatz auf möglichst weit überlappende Phasen mit selbstorganisierten und selbstlernenden Projektteams ab, die den gesamten Prozess in ihrer Verantwortung haben.

Basierend auf diesen Erkenntnissen errichteten die beiden Autoren nicht nur einen wichtigen Grundpfeiler für das Framework Scrum, sondern waren in ihrer Denkweise so manchem Unternehmen des 21. Jahrhunderts voraus. Für die pharmazeutische Industrie hieße das, dass es beispielsweise keine klare personelle Trennung mehr nach einzelnen Phasen wie Forschung, Entwicklung, Präklinik, Produktion, klinisches Studiendesign gibt, sondern sich das Team von Anfang an aus allen Expertinnen und Experten zusammensetzt, die zur Produktentwicklung benötigt werden. So wie es beispielsweise bei Biotech-Startups oft der Fall ist.

Stellen Sie sich vor, Sie müssen nicht mehr wochenlang auf Meetings mit den Expertinnen und Experten warten, sondern haben diese zu 100 % im Team und damit jederzeit verfügbar!

Mit Scrum die Marktanforderungen an Ihr Unternehmen befriedigen

Jeff Sutherland und Ken Schwaber bauten vor 23 Jahren diesen Ansatz durch das Framework Scrum noch weiter aus. Sie wollten weg von überladenen Projektmanagement-Methoden – hin zu einem „leichtgewichtigen“ Ansatz, der Unternehmen dabei hilft, die an sie gestellten Marktanforderungen wieder befriedigen zu können. Denn unsere Welt wird immer schnelllebiger. Meiner Erfahrung nach ändern sich die Rahmenbedingungen so rasant, dass die Anforderungen an ein Projekt nach 6 Monaten schon ganz anders aussehen können und eine mehrjährige Produktentwicklung nach einem festen Plan nur selten das eigentliche Bedürfnis der Nutzer befriedigen kann.

Heute arbeiten die Scrum-Teams mit kurzen Iterationen, in denen sie inkrementell, also in kleinen Schritten, Produkte entwickeln, zu denen sie direkt Feedback der Nutzer einholen können. Sie entwickeln nicht mehr hinter verschlossenen Bürotüren fernab von den eigentlichen Anwendern des späteren Produkts, sondern befinden sich im stetigen Austausch mit ihnen und nähern sich so Iteration für Iteration dem finalen Produkt. Dieses schrittweise Vorgehen erlaubt den Teams, sich ändernde Rahmenbedingungen flexibel in die Entwicklung einfließen zu lassen. Zudem werden Entscheidungen dort getroffen, wo die Informationen liegen: direkt im Entwicklungsteam. Das lange Warten auf Ansagen des Managements oder der Gremien würde der Produktivität des Teams nur im Weg stehen.

Scrum erfordert ein Umdenken

Die Einführung von Scrum in einer Organisation geht jedoch über die Veränderungen der operativen Prozesse hinaus und erfordert auch eine veränderte Haltung aller Beteiligten. In Bereichen wie dem Bankensektor und der Automobilbranche ist das bei den führenden Unternehmen bereits passiert. Die Pharmaindustrie befindet sich unserer Erfahrung nach noch ganz am Anfang dieses Wandels, auch wenn sich erste Unternehmen wie Böhringer-Ingelheim der Herausforderung bereits stellen.

Aufgrund der langen Entwicklungszeiten und des stark regulierten Umfelds, sind besonders kreative Köpfe für die Verwirklichung eines cross-funktionalen Arbeitens gefragt. Doch die Erfolgsgeschichte agiler Methoden zeigt sehr schön, dass es sich heute rentiert, den Anwender und Kunden wieder in den Fokus zu rücken. Zudem wird es für Unternehmen immer überlebenswichtiger, schnell auf Änderungen am Markt reagieren zu können. Unflexible Prozesse, das Warten auf Entscheidungen und Teams, die sich nicht für das Endprodukt und den Gesamtprozess verantwortlich fühlen, stehen dem eindeutig entgegen. Dabei sollten wir alle doch ein vorrangiges Interesse haben: in kürzester Zeit für den Kunden werthaltige Produkte auf den Markt zu bringen.

Der Kunde

Die Scrum-Rollen werden mitunter sehr stark diskutiert. Dabei gerät häufig gerade der Kunde in Vergessenheit, obwohl dieser einen sehr wesentlichen Teil zum Projekt beiträgt: die Finanzierung. Boris Gloger widmet sich in diesem Erklärvideo der Rolle des Kunden, spricht über dessen Aufgaben und darüber, in welchem Verhältnis der Kunde mit den weiteren Rollen steht – und das alles anhand eines spannenden, aktuellen Beispiels: der Deutschen Bahn.

 

The Pull of the Retro

The Retrospective is perhaps the most challenging part of the Scrum process for a ScrumMaster. Although there are several ways to run a retro, the basic idea is very simple. You want to find out what went well and what could be improved, to gather information that will help you to improve the team’s performance. The Retro essentially gives the ScrumMaster ‘material’ to work with; as the change agent, you need to know what the team wants to have changed. Engaging in discussions with the team to understand what the problems are and how they can be addressed are key parts of the process.

Getting a ‘feel’ for the team

For me, the Retro is primarily a barometer for a team’s mood. You can focus your attention on the tone in which the team members speak, how they express their opinions and what the contents are. Their openness and engagement are what you want to see, but maybe you realize that they are holding back a bit. In that case, the team members might lack a clear understanding of the main point of the Retro; or they might not feel comfortable enough to speak out and raise difficult (and potentially controversial) issues. Consequently, you have to ask yourself: What is preventing the team from being open, and therefore fulfilling the purpose of the meeting? What is required to give them more confidence?

One of my teams had already gone through several Retro cycles. Nevertheless, there was this feeling that we are going around in circles. The Product Owner was always present, and the team would not really speak about problems at the team level. Even after organizing categories to specify whether problems (and successes) are at team, sector or organization-wide levels, the problems at team-level remained underrepresented and would often boil-down to difficulties that actually lay in cooperation with other teams.

Individuals becoming a Team

Although the team had been performing very well, the Product Owner did not want to take the further steps recommended by the SM to improve the team’s performance further. Instead, the PO turned up for the Backlog Refinement and questioned the concept of the meeting; and what is more, he had no proper Backlog for the team to refine. Similar problems have been encountered in other meetings, including Dailys where the PO was openly dismissive of the pull principle by actively staring at a person whom he believed should take a particular User Story during the Sprint Planning 1.

Of course, there are many ways to address this. However, in order to ‘empower’ the team it is important to keep a cool head and not to argue during joint meetings, but rather explain the roles, the aim of the particular meeting and the principles of Scrum – day in, day out, if required. The team got the ideas and had a pretty clear picture of how things should run in an agile environment. After one particularly poor showing at the Backlog Refinement, I decided to communicate more openly and strongly what the team needs, and what the role of the PO consists of. At first glance, it seemed that this didn’t work out very well. The meeting ended without anything resembling a half-decent Backlog, with the PO throwing User Stories on the table in the shape of tasks, and a team visibly annoyed.

The Grassroots Retro

It was not entirely surprising to receive an update several hours later. The team held a spontaneous ‘crisis meeting’ and wanted to make these issues a subject in the next Retro. I welcomed this news with arms wide open, particularly because the team had developed a pull principle to Scrum itself.

Although the PO used to join those meetings, I offered to exclude him this time. The team agreed. We started the Retro with two boards. One symbolized the United Nations. All the topics on this wall would be directly discussed with the PO. The other one was Las Vegas. What happens in Vegas stays in Vegas. The logic behind it was to encourage the team members to show commitment and also become aware when they are not courageous.

To my positive surprise, everything ended up at the UN, while the themes were almost entirely focused on the dynamics within the team. After 1 hour we realized that we need more time, so we organized a second part to go through the themes and find potential solutions. The vast majority of the themes challenged the PO, how he is fulfilling the obligations towards the team, and produced concrete steps forward. The next steps were to formulate the points, prioritize them and for me to present them to the PO who needs to commit to them.

Discovering Openness

Overall, and irrespective of the possible outcome of the meeting between the PO and the SM, the team has succeeded in formulating and openly speaking about problems. Initially, they were not able to challenge the PO directly. By now, the team members have committed themselves to use Retros to raise essential questions to improve their ability to work effectively. I’ve realized that feeling the pulse of the team and reading between the lines are important, and I’ve also learned that it is crucial to invest time in change and provide clarity on roles and responsibilities. The results speak for themselves. In the next sprint, the team nearly completed the entire committed Sprint Backlog, and the members have also begun sparring to learn new skills from one another. When culture change is in focus, openness does go a long way.

You want to use Scrum? Watch Lord of the Rings first.

Disclaimer: This post will be most enjoyable to you if you have read the books or at least watched the movies of the Lord of the Rings. If you are that guy/girl, who has no clue, I invite you to read the plot first. Needless to say; this blog post contains a heavy load of spoilers.

J. R. R. Tolkien started working on the books in the 1930s, so no way he plagiarized Jeff Sutherland’s or Ken Schwaber’s ideas, but agility has been around since the 1930s in Bell Labs too, so maybe he got a little inspiration there?!

The whole storyline of the Lord of the Rings (LotR) follows the same pattern like building up an agile team. To show you what you can learn from LotR for your work in an agile environment, I’ll guide you through the plot and show you seven steps that make agile teams successful.

In the first chapters of the LotR Gandalf visits an old friend of his, the Hobbit Bilbo, who is the owner of the “One Ring”; a powerful artifact that could destroy the world when held in the wrong person’s hands. The dreaded, evil wizard Sauron seeks the power of this ring to expand his territorial dominion over Middle-earth. In order to prevent this tragic fate, the ring needs to be destroyed and thus becomes the Product Vision of the book plot. However, who delivers this Product Vision?

Step 1: You need someone who commits to a vision.

In the agile world, this someone is called Product Owner. In LotR, this is the subject area of Gandalf the Wizard. He has the greater vision of defeating the greatest evil in the world, Sauron. He is also responsible for stakeholder management; for instance getting in touch with Saruman with the aim to build an alliance with him, convincing the Riders of Rohan or rallying the troops of Gondor. Further, he knows what needs to be delivered and how the tasks have to be prioritized to reach the goal. Speaking in agile you could say, he is responsible for keeping the product backlog in shape.

All in all, one can observe that he is strongly committed to his vision of defeating the evil at all costs. However, he can not execute it alone and needs a team, which takes us to the next step.

Step 2: Recruit a badass team.

The first team members of the agile team are Frodo, who in the meantime inherited the Ring from his uncle Bilbo, and Sam, his gardener. These two are Hobbits or halflings and therefore well versed with two skills: luck and stealth – skills, which come in handy for the first part of their mission, getting to the human city of Bree to find a guardian for their journey. In the first part, they get support from Merry and Pippin to navigate through the lands where they already encounter the evil forces of Sauron, only able to flee from the danger partially through wit and sheer luck. They reach Bree and meet their guardian.

Let’s recap this section in agile jargon: The Product Owner recruits a team that will bring his vision to life and makes sure that the team members have the required competences to deliver the first product increment. But he needs support for that, which brings us to the role of the guardian the four Hobbits meet in the city of Bree.

Step 3: Find a person willing to defend and unite the team.

In LotR the guardian’s name is Aragorn. In the agile world, Aragorn would be the ScrumMaster of the team. He protects the team from impediments and leads them as a servant leader. For example, after the expanded team leaves Bree, Aragorn hunts food, protects the team from the evil forces of Sauron and leads the Hobbits to Rivendell so that they can focus on their mission “to protect the ring.” In the subsequent sections of the book, the servant leadership traits of Aragorn become clearer as he recruits the Dead Men of Dunharrow to ensure that the team protects Gondor in one of the big fights at the end of the book.

Aragorn embodies the ScrumMaster throughout the book, he demonstrates servant leadership, ensures solutions to impediments and practices a retrospective meeting with the team after the “death” of Gandalf in the Mines of Moria. In short, he meets all expectations of a good ScrumMaster and supports the team’s path towards success.

Step 4: Upgrade your team “T-shaped style”.

After getting to Rivendell, Aragorn and the Hobbits take part in the circle of Elrond where the overall goal of the team becomes even clearer; through further deliberations and a lecture by Elrond. They have to destroy the ring in the fires of Mount Doom, a project that needs more and broader resources than only getting the ring in a safe haven like Rivendell. So, during the discussion the team around Gandalf, the Hobbits and Aragorn joins forces with

Together, they form a T-shaped team, each one having a rough understanding of the skills of the other team members but specialized in one specific skill. For example, in the Mines of Moria, the small Hobbits widen their skillset by engaging in fights. Although they are much less effective than the other combat-approved team members, they were able to learn from them.

It also seems to be no coincidence that they are nine team members, holding their needed communication and coordination at a manageable level; a size for a team that is also highly recommended in the agile world. So, in this form of an agile team, T-shaped and small, they start from Rivendell to realize the team’s vision.

Step 5: Embrace self-organization.

The team that sets off at Rivendell to put the “One Ring” into the fires of Mount Doom is certainly a non-hierarchical team. Each member of the team is at eye level with the other members, even the small Hobbits. Helping each other when needed, e.g., when the team opens the gates to the Mines of Moria. Nobody is forced to stay in the team and is free to leave at any time. The team members are bound by the vision and their commitment to accomplishing the goal. This cohesion gives the team the strength to overcome danger and reevaluate their strategy. In two instances this becomes crystal clear. The first is the “killing” of Gandalf in the fight against the Balrog: Every member of the team knows what to do bearing in mind the overall vision. Even in the face of the death of their Product Owner, they are still able to execute the plan. The second is the voluntary splitting of Frodo and Sam from the rest of the team after the battle on the hill of Amon Hen. The other part of the team recognizes the benefits of this drastic action for their mission’s success and chooses to embrace actions more suited for them, like pursuing or fighting the enemy troops.

Step 6: Iterate in small increments and get rid of impediments.

Our heroes deliver increments of their overall mission along their way. Every major fight in LotR is their way to deliver an end-to-end increment of their battle against the evil forces. They analyze the enemy’s weaknesses and adapt their fighting strategies before each fight but react to small changes during the fight. In short: They use an iterative approach to deliver their “fights” and simultaneously get rid of impediments during their mission, mainly led by Aragorn, their ScrumMaster. The concept of iteration is also unfolded in other scenes throughout the book. For example, when they use the passage through the Mines of Moria because Saruman blocks the Redhorn pass through the mountains. Or when Sam takes the ring from Frodo in dire need of protecting it. Every team member is truly committed to continuous improvement throughout the whole book.

Step 7: “Put a ring on it” a.k.a. hold on to your vision.

If there is no need from a market perspective to overhaul your vision – don’t do it. The vision of LotR grants the team a bigger picture, which gives them strength in distress and enables them to stand fast against the forces of Sauron. Especially the last part of the journey of Frodo and Sam makes this apparent. Only with the destruction of the ring, they can accomplish their vision, and the people of Middle-earth are free to live their lives peacefully. The vision of the team helps them to deliver a great product – the liberation of the world from all evil.

Reaching your goal is a unique experience. Agile frameworks like Scrum provide you with effective tools to iteratively achieve your set goals. Of course, your vision does not have to be the liberation of the world from all evil, although it is a great one. As the comparison with LotR shows, reaching your vision is a journey of hardship and struggle but also great joy and friendship. Keep that in mind if you are working in your teams the next time and try to support one another like the fellowship of the Ring.

Warum die Rollenfindung Teamsache sein sollte

„Wir wollen agil werden“ – so oder so ähnlich lautet die Maßgabe in vielen Unternehmen. Bei der Einführung von Scrum braucht es dazu unterschiedliche Rollen wie den ScrumMaster und Product Owner. Den Führungskräften ist oft schon im Vorfeld klar, wer diese Rollen im späteren Verlauf ausführen soll. Dabei vergisst man aber häufig, auch das Team zu fragen, wen es in dieser Rolle sieht. Aufgrund hierarchischer Machtverhältnisse und Weisungsbefugnissen werden neue Rollen einfach zugewiesen, ohne auf die Anforderungen und Befähigung der Erwählten einzugehen. Auch wie die Bedingungen innerhalb des Teams aufgestellt sind, spielt tendenziell eine eher untergeordnete Rolle.

Aber wie kann man das besser machen? Meiner Meinung nach ist zunächst die Unterscheidung von Macht und Status essenziell für die Etablierung und Akzeptanz der neu geschaffenen Rollen. Denn Macht bekommt man manchmal geschenkt, Status muss man sich erarbeiten.

Status vs. Macht

Sozialer Status zeichnet sich durch Respekt und Wertschätzung aus, die einer Person von anderen entgegengebracht werden. Er entsteht somit durch die Beurteilung von Außenstehenden und bezieht sich auf den Wert, den sich eine Person in einem sozialen System erarbeitet hat. In weiterer Folge heißt das, dass man sich Status nicht selbst verleihen kann, sondern das soziale Umfeld diesen zuschreibt.

Genau darin unterscheidet sich der Status auch im Wesentlichen von der Macht. Sie kennzeichnet sich vor allem durch die Fähigkeit, eigene Interessen durchzusetzen, auch wenn das Umfeld anderer Meinung ist. Die Art und Weise, wie Macht schließlich ausgeübt wird, kann dabei völlig unterschiedlich sein – sei es durch den alleinigen Zugang zu Wissen oder durch eine höhere soziale Stellung.

Aus diesen unterschiedlichen Konzepten von Status und Macht lassen sich allgemein drei mögliche Szenarien ableiten:

  1. Macht ohne Status
    Fehlt der Status, so kann Macht alleine immer noch ausreichen, um seine eigenen Vorstellungen auch gegen den Willen oder die Interessen anderer durchzusetzen. Allerdings macht man sich dabei oft keine Freunde, da man zwar Autorität besitzt, die anderen aber nur kontrolliert.
  2. Status ohne Macht
    Auch ohne Macht kann man als Führungsperson fungieren, wenn der Status, also der Respekt und das Ansehen im sozialen Umfeld stimmen.
  3. Macht gepaart mit Status
    Wer sowohl über Macht als auch über Status verfügt, kann beide nutzen, um seinen Einfluss geltend zu machen. Entweder kann man sich auf seine Macht berufen und seine Ansichten durchsetzen oder seinen Status einbringen, um andere zu überzeugen.

Was bedeutet das beispielhaft für die ScrumMaster-Rolle?

Übertragen auf die Besetzung eines ScrumMasters können sich folgende Szenarien ergeben:

  1. Klassisch besetzt der Teamleiter die Rolle des ScrumMasters im neu etablierten Scrum-Team. Dadurch besitzt die Rolle zwar die notwendige Rückendeckung, um Entscheidungen im Sinne des Teams zu treffen (technische Voraussetzungen, Anschaffungen, Entwicklungsmaßnahmen für Teammitglieder etc.). Jedoch fehlt die notwendige Akzeptanz der Rolle im Team, wodurch die Entscheidungen nicht immer auch vom Team mitgetragen werden.
  2. Der ScrumMaster wird als Teil des Teams akzeptiert und ist in der Lage zu wirken, kann aber in der Beseitigung von Impediments durch organisationale Hürden ausgebremst werden.
  3. Der ScrumMaster wurde gemeinsam im Team gewählt, akzeptiert und genießt die Rückendeckung seines hierarchisch Vorgesetzten bei der Lösung von Impediments.

Um in dieser Rolle im agilen Umfeld tatsächlich wirksam werden zu können, braucht es sowohl Macht wie auch Status. Szenario 3 stellt für mich daher die optimale Ausprägung dar.

Das Team weiß, was es braucht

Zur Förderung dieser Entscheidung aus dem Team heraus hat sich folgende Herangehensweise als praktikabel erwiesen:

  1. Klare Darstellung der Rollenanforderung und Erwartung
  2. Selbstwahrnehmung der beteiligten Personen zur dargelegten Rolle
  3. Fremdwahrnehmung der einzelnen Gruppenmitglieder: Wen kann ich mir in der dargestellten Rolle vorstellen?
  4. Reflexion in der Gruppe zur Teamaufstellung
  5. Gemeinsames Commitment

Festzuhalten bleibt: An vielen Stellen bedarf es keiner klassischen Rollenbesetzung, da die Teammitglieder durchaus in der Lage sind, eine objektive Aussage darüber zu treffen, wer die beste Rollenpassung aufweist. Und wem ich das Vertrauen schenke, die Rolle auszufüllen. In der Praxis sieht das oft aber leider noch ganz anders aus. Beim Entscheidungsverhalten wie auch bei der Rollenfindung hält man noch stark am klassischen Verständnis fest und schreibt die Verantwortung für diese Bereiche einer hierarchisch vorgesetzten Person zu. Meiner Meinung nach sollte sich das Verständnis wandeln, um mit der sich verändernden Arbeitswelt Schritt halten zu können.

Pfläging¹ zeigte auf, dass man viel schneller auf die Marktbedürfnisse reagieren kann, wenn die Entscheidungsmacht aus dem Zentrum in die Peripherie, also an die marktnächste Instanz gegeben wird, wo die entsprechenden Informationen vorhanden sind. Äquivalent dazu sollte es sich mit der Rollenfindung verhalten – nur eben in die andere Richtung. Die Information bzw. das Wissen liegen hierbei im Kern, also im Team. Dementsprechend sinnvoller ist es, dass auch das Team die Rollenfindung innehat.

 


Literaturhinweis:

¹Nils Pfläging: Komplexithoden: Clevere Wege zur (Wieder)Belebung von Unternehmen und Arbeit in Komplexität. Redline Verlag 2015.

Scrum or Kanban? That is here the question

It may seem a bit ironic to cite Shakespeare in a post that outlines the difference between Scrum and Kanban. Of course, there is no such drama in the Agile scene. Nevertheless, many people still perceive these two Agile Frameworks as opponents. When I look at Scrum and Kanban, I rather see two sides of one coin. Why? Watch my new video to find out.

Remote-Retrospektive mit der Hero’s Journey: ein Erfahrungsbericht

In der Rolle als Agile Coach ist es nur eine Frage der Zeit, bis man vor folgender Herausforderung steht: Das Team sitzt nicht zusammen am selben Ort und braucht eine Retrospektive, die mithilfe von Videotelefonie und Screensharing remote umsetzbar ist. Nun kommt natürlich auch noch der eigene Anspruch dazu: Die Retrospektive soll trotzdem außergewöhnlich sein und das Team zu einer Betrachtung der Zusammenarbeit aus einem anderen Blickwinkel anregen.

Mit einem hochmotivierten und aufgeschlossenen Kundenteam führte ich deswegen eine etwas andere Art der Retrospektive durch – inspiriert durch einen Blogbeitrag von Steffen Hartmann von Mayflower (Retrospektive – The Hero’s Journey).

Die Hero’s Journey im Überblick

Bei dieser Variante der Retrospektive betrachten die Teammitglieder ihre bisherige Zeit im Projekt als eine Heldenreise. Diese umfasst zwölf verschiedene Etappen – beginnend beim Leben als „Normalo“ über das Meistern von Herausforderungen bis hin zur Transformation zu einer neuen Persönlichkeit. Der selbst gestaltete Held ist dabei eine Abstraktion eigener und fremder Wünsche sowie Sorgen im Team. Die Teammitglieder können so geschützter als in einer klassischen Retrospektive auch diejenigen Punkte thematisieren, die sie aus der Ich-Perspektive heraus vielleicht nicht ansprechen würden.

Vor allem bei dezentralen Teams, die nur über Videotelefonie kommunizieren können, beschränken sich klassische Retrospektiven tendenziell auf ein oberflächliches Abarbeiten der üblichen drei Fragen:

Genau diesen immer gleichen Ablauf wollte ich verhindern. Wie ich dabei vorgegangen bin, möchte ich im Folgenden veranschaulichen.

1. Das Team vorbereiten

Um die Bereitschaft im Team für die doch eher ungewöhnliche Retrospektive zu erhöhen, versuchte ich zunächst, die Teammitglieder mental darauf vorzubereiten. Dazu stellte ich nach dem Daily einfach vorab die Frage: „Hättet ihr Lust auf ein Experiment bei der Retrospektive?“ Glücklicherweise schreckte dieses Team vor keinem Abenteuer zurück und schon kam das Commitment für die etwas andere Retro.

2. Vorbereitung der Hero’s Journey für eine Remote-Retrospektive

Damit die Retrospektive des dezentralen Teams in der vereinbarten Zeit von 90 Minuten durchführbar war, musste ich diese entsprechend anders vorbereiten als im genannten Blogbeitrag von Steffen Hartmann beschrieben. Die Entscheidung fiel auf ein PowerPoint-Format. Dafür habe ich die SAP-Scenes-Figuren einzeln in PowerPoint kopiert und bereits vorab alle Sprechblasen und Felder eingefügt, die in der Retrospektive abgefragt werden sollten.

Fragen für Retrospektive

Abbildung 1: Fragen für die Retrospektive

Insgesamt konnten die Teammitglieder zwischen neun verschiedenen Charakteren wählen, die in SAP Scenes zur Verfügung standen. Der Grund ist einfach nachzuvollziehen: Nicht jeder kann sich mit einem Superhelden mit Krawatte identifizieren. Um eine klare Ausgangslage zu schaffen, habe ich außerdem die Etappen der Hero’s Journey als erste einleitende Folie in die PowerPoint-Präsentation eingefügt:

Hero's Journey

Abbildung 2: die Hero’s Journey

Die Teammitglieder bekamen die vorbereitete Präsentation noch nicht vor, sondern erst während der Retrospektive. Sie wurden aber rechtzeitig informiert, dass sie jeweils einen Laptop zum Termin mitnehmen sollten.

3. Der spannende Teil: die Durchführung

Nun war es so weit. Das Experiment konnte beginnen. Nach einem kurzen Check-in per Video-Konferenz bedankte ich mich beim Team, dass es so offen für diesen Versuch war. Bevor ich die PowerPoint an alle Teammitglieder weiterleitete, erklärte ich in ein paar einleitenden Worten, warum ich mich für dieses Format entschieden habe. Aus meiner Sicht bietet es mehrere Vorteile.

Die Hero’s Journey:

Wie von Steffen Hartmann empfohlen zeigte ich nun das Video der Hero’s Journey.

Bevor es an die Arbeit ging, gab es noch ein paar letzte Hinweise:

Anschließend bekamen alle Teammitglieder die Präsentation per E-Mail und sollten die Fragen innerhalb von 15 Minuten beantworten.

4. Das Ergebnis

Nach Ablauf der Timebox schickte jedes Teammitglied die ausgefüllte PowerPoint-Folie von seinem Helden an mich zurück. Anschließend stellte einer nach dem anderen seinen Charakter vor. Da ich den Bildschirm teilte, wussten die zugeschalteten Teammitglieder immer genau, über welchen Charakter wir gerade sprachen.

Ich zeige in diesem Beitrag bewusst keine Original-Beispiele eines Helden, weil meiner Meinung nach gilt: Was in der Retrospektive passiert, bleibt in der Retrospektive. Stattdessen eine von mir zusammengestellte Form zur Veranschaulichung, die Teile der Wahrheit beinhaltet:

Antworten Retrospektive

Abbildung 3: die Antworten des fiktiven Helden Rubyman

Beim fiktiven Rubyman handelt es sich um einen erfahrenen Entwickler, der die Programmiersprache Ruby in Perfektion beherrscht. Seine Aussage „Nobody wants me“ rührt daher, dass das Unternehmen keinen entsprechenden Entwickler für das Team einstellen möchte. Also ist Rubyman ein Held, der dem Team aktuell noch fehlt, um die bevorstehenden Herausforderungen erfolgreich zu meistern.

Meine Aufgabe als Agile Coach war es dabei, zwischen den Zeilen zu lesen. Ich notierte die Erfolge und Herausforderungen auf Post-its und stellte sie dem Team im Anschluss vor. Wir wählten daraufhin zwei Maßnahmen aus, die wir im nächsten Sprint umsetzen wollten.

Das Fazit des Experiments

Das war definitiv eine etwas andere Retro, aber für das Team war es durchaus erfrischend. Das Teammitglied, das Rubyman vorgestellt hat, sagte ganz begeistert: „Endlich thematisiere nicht mehr nur ich, dass wir einen erfahrenen Entwickler benötigen, sondern Rubyman macht das selbst“. Wir haben viel gelacht und über die Kreativität im Team gestaunt. Als Moderator konnte ich auch sehr viel aus den Stärken, Schwächen und Aussagen der Helden über die aktuelle Stimmung im Team herauslesen, wodurch ich die Teammitglieder schließlich zielführender und individuell unterstützen konnte.

 

Titelfoto von Fredrick Kearney Jr auf Unsplash
Figuren von SAP Scenes

Von der Story Map ins Backlog – eine Wegbeschreibung

Wie in meinem letzten Blog-Beitrag angekündigt, möchte ich nun genauer darauf eingehen, wie aus einer Story Map mithilfe von Epics und User Storys ein initiales Product Backlog wird.

Die Story Map ist also fertig. Nachdem die Wand nun in bunten Post-its erstrahlt, ist es an der Zeit, ein minimal funktionierendes Produkt (engl. Minimum Viable Product – MVP) festzulegen. Dazu nimmt man am besten ein dickes, leuchtendes Klebeband und zieht eine Linie von links nach rechts. Jetzt geht es ans Aussortieren und Priorisieren. Oben bleiben die wirklich essenziellen Funktionen sowie Ideen und nach unten wandert alles, was vorerst Zukunftsmusik ist. Das heißt: Man sollte hier danach fragen, was es wirklich braucht, damit man das Produkt End-to-End funktionsfähig vor dem Kunden präsentieren und Feedback einholen kann.

Sobald wir festgelegt haben, was ein erster Prototyp (MVP) beinhalten soll, können wir die User Storys schreiben.

Dazu nimmt man sich den ersten Post-it und legt los. Man schreibt die User Story nach der bekannten Syntax: „Als … (User) möchte ich … (Funktion), sodass ich … (Nutzen) habe.“ Meine Kollegin Andra hat dieser Thematik einen ausführlicheren Blog-Artikel gewidmet, den ich an dieser Stelle sehr empfehlen kann.

Was gute User Storys ausmacht

Für gewöhnlich kommt man schnell an einen Punkt, an dem die User Story, welche gerade geschrieben wird, irgendwie zu groß wirkt. Wir sprechen in diesem Fall von einem Epic, aus dem wir mehrere kleinere User Storys ableiten. Dafür haben sich unter anderem folgende Maßnahmen bewährt:

Ein praktischer Indikator für die richtige User-Story-Qualität sind die INVEST-Kriterien. Dazu schaut man sich die User Storys an und analysiert diese nach folgenden Kriterien:

Starten Sie mit einem kompakten Product Backlog

Ich empfehle, zunächst mit maximal 60 User Storys und einer eindeutigen Priorisierung zu starten. Warum? Sobald es nach dem ersten Sprint Feedback gibt, erübrigen sich ggf. viele User Storys und durch das Feedback kommen neue hinzu. Und da beim agilen Arbeiten immer das Kundenfeedback im Mittelpunkt steht, sind genau diese neuen Storys die entscheidenden.

Mit diesem Vorgehen entsteht in kürzester Zeit ein initiales und kompaktes Product Backlog. Dieses kann im Nachgang geschätzt und geschärft werden und dient so als perfekte Grundlage, um einen ersten Forecast zu erstellen und das minimal funktionierende Produkt in die Realität umzusetzen.

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.

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).

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”.

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

Scrum4Schools: Agiles Arbeiten im verteilten Hochschulprojekt

Ein weiteres SCRUM4SCHOOLS-Projekt nimmt Fahrt auf. Gemeinsam mit der FH des BFI in Wien, einer berufsbegleitenden Studieneinrichtung, mit der wir schon frühere Produktentwicklungserfolge wie unsere Scrum-Checklist für Android und iOS feiern konnten, entwickeln wir nun eine Lernplattform, auf der wir das Wissen unserer Consultants an einem Ort im Internet konsolidieren und als Open Source anbieten. Als Product Owner des Projekts bin ich natürlich sehr gespannt, wie den Studenten das Arbeiten mit Scrum gefällt. IT-Genie Sebastian Mühlbauer ist nicht nur unser Kollege bei borisgloger consulting, sondern auch Teil des studentischen Entwicklerteams schon machen konnte. Welche Erfahrungen er in diesem Projekt gemacht hat, verrät Sebastian Mühlbauer im folgenden Interview.
Hi Sebastian, welche Rahmenbedingungen gelten für das Projekt?
Im Rahmen unseres Studiums müssen wir ein zweisemestriges Projektpraktikum absolvieren. Dabei sollen wir neben dem regulären Studium gemeinsam mit einem echten Auftraggeber ein Projekt durchführen. Unsere Projektgruppe hat sich für borisgloger consulting entschieden, weil es der einzige Auftraggeber war, der uns angeboten hat, agile Methoden auszuprobieren. Zurzeit sind wir fünf Personen exklusive FH-Projektbetreuer und dir als Product Owner.
Hast du vor diesem Projekt schon einmal mit agilen Methoden gearbeitet?
Nicht wirklich. Sowohl in meinem jetzigen als auch in meinem letzten Studium habe ich immer mit traditionellen Projektmanagementmethoden gearbeitet. Unter anderem haben wir ein fiktives Projekt nach den Regeln des IPMA/PMA Projekthandbuchs durchgespielt.
Wie hast du den Einstieg in Scrum empfunden?
Vor allem die vielen Scrum-spezifischen Begriffe waren anfangs nicht leicht merkbar – Eselsbrücken haben aber recht gut geholfen. Dadurch, dass wir in Scrum mit dem Prinzip “Learning by Doing” eingestiegen sind, hat es nicht allzu lange gedauert bis zumindest der Scrum-Flow gesessen hat. Man lernt aber immer noch jeden Tag etwas Neues dazu. Das Spannendste, was ich mitnehmen konnte, war die Fokussierung auf ein funktionierendes Minimum Viable Product statt auf das komplett fertige Produkt. Die Methodik stammt aus dem Lean-Startup-Konzept. Man entwickelt nur das Mindeste, das man braucht, um das Produkt zum Fliegen zu bringen. Wenn wir nur unser Endprodukt als Ziel gehabt hätten, hätten wir wohl um einiges länger dafür gebraucht, einen funktionierenden Prototyp zu erstellen.
Das Projektteam arbeitet an verteilten Orten. Wie bekommt ihr das mit der Synchronisation hin?
Unsere Kommunikation und Kollaboration findet größtenteils über das frei zugängliche Slack und Trello statt. Für Dateien verwenden wir eine Google Drive, die auch in der kostenlosen Version mit den zwei Tools verbunden werden kann. Die Lernplattform entwickeln wir zentral auf einem Webspace, der uns von borisgloger consulting zur Verfügung gestellt wurde. Da alle unsere Teammitglieder nebenbei berufstätig sind, mussten wir die Scrum-Meetings auf unsere speziellen Bedürfnisse anpassen: Wir haben alle zwei Wochen ein eineinhalb- bis zweistündiges Skype-Meeting, bei dem das Entwicklerteam aus Wien mit dem Product Owner in Stuttgart die Synchronisation abwickelt. Darüber hinaus sieht sich das Entwicklerteam auch immer wieder auf der Fachhochschule. Wir versuchen Besprechungen also in unseren FH-Alltag einzubinden, um effizient arbeiten zu können.

Dein Studium ist berufsbegleitend. Konntest du agile Methoden schon in deine Arbeit einfließen lassen?
Da ich durch das Projekt meinen Weg zu borisgloger consulting gefunden habe: ein ganz klares Ja. Auch darüber hinaus konnte ich in diversen ehrenamtlichen Projekten, in denen ich mitarbeite, bereits Teile des agilen Projektmanagements umsetzen – sei es die Visualisierung auf Taskboards oder die Verbesserung der Meetingkultur mit dem, was wir in der Scrum-Einschulung von Damla Nalbant gelernt haben. Ich versuche hier, konstant Neues zu probieren und meinen Horizont in diesem Bereich zu erweitern. Bis jetzt hat es gut geklappt.
Sebastian, vielen Dank für das Interview – ich wünsche dir noch viel Erfolg im Projekt.

ScrumMaster: Mastering conflict

Although conflict sometimes leads to violence, it also leads to the development of new ideas and solutions without descending into violence. One of the key advantages of many contemporary democratic societies is their ability to manage conflict without escalation of violence. This concept is largely built on a premise that conflict is unavoidable, and even good, but that violence should be avoided. In an organisational context violence rarely takes physical form, but is rather more passive and could be better defined as conflict. It manifests itself in terms of refusal to cooperate and mobbing as well as failure to deliver necessary preconditions for focused work (e.g.. information). System inherent conflict management – or conflict navigation – is key to ensuring that problems are identified and addressed in order for conflict to have a constructive focus.
Scrum recognises the importance of conflict, and the scrum master role is very much like the one of a conflict ‘navigator’. The scrum master is required to establish a system which recognises and encourages engaging in conflict, facilitating it and navigating through it. Indeed, the scrum master working in an environment where change is needed often takes the role of a conflict initiator, but needs to be wary of how to navigate it to support the change process.

Creating a trustful atmosphere

Considering that teams are often composed of people with different personal characteristics and different experiences, there will be those who are inclined to try new approaches and those who will be more cautious or even rejective of new ideas. Introducing any new management style will lay down the groundwork for conflict. In this instance the scrum master needs to be able to build confidence with her/his team and an understanding that Scrum is worthwhile trying out, but that the process requires commitment. While defining and removing obstacles is a key part of the scrum process, it is important to define ‘conflict’ lines that the team will engage in with the agents/structures that are creating, or are themselves the obstacles. To be the change agent, the scrum master looks to create an atmosphere where this ‘conflict’ can be outspoken and defined in order to find new solutions and improvements, e.g. an impediment backlog. Therefore, as such, it is her/his role to instigate conflict, and as a navigator find ways to solve this on a systemic or interpersonal level.
The reason why a scrum master benefits from conflict (at internal or organisational levels) is the ability to show that he or she can conceptualise a road map and devote efforts towards solving it. By engaging in and being able to solve problems the scrum master introduces not only new ways of thinking, but also builds confidence in the team while being able to show that values such as openness, courage, respect and commitment work for the benefit of the team. The tricky bit is knowing how to be a skilful conflict navigator and choosing conflicts that will build confidence, which subsequently allows for more complex conflicts to be addressed and solved. The goal is for the team to reach a level of openness that teams see ‘conflicts’ as being a constructive part of a development process. By building a ‘system’ and starting with gaining trust and confidence of the team, the scrum master will transform an ordinary workplace into a place where individuals are valued and motivated to move forward. Ultimately, the scrum master will have laid down the groundworks for building a real team.

Regeln und Prozesse im agilen Umfeld? Nein! Doch! Oh!

In vielen selbstorganisierten Umfeldern gibt es zwei böse Wörter: das R-Wort und das P-Wort. Benutzt man diese Worte, kann man sich auf einen wilden Mob und viel Widerstand einstellen. Wild ist der Mob vielleicht nicht, aber er ist bereit, sich mit allen Mitteln gegen die Regeln und Prozesse zu wehren. Denn die vielen Freigeister fühlen sich durch das R-Wort auf einmal eingeengt und ihrer Freiheit beraubt. Meiner Meinung nach brauchen wir aber Regeln und Prozesse. Ein selbstorganisiertes System endet schnell im Chaos, wenn es keine Regeln und Prozesse gibt. Die Effizienz sinkt und die Produktivität geht in den Keller. Aus unternehmerischer Sicht ein Desaster.
Vorweg sei also gesagt: Auch in der agilen Welt brauchen wir Regeln und Prozesse. Es kommt aber darauf an, um welche Regeln und Prozesse es sich handelt und wie viele es davon gibt. Hier greift ein bekannter Satz: So wenig wie möglich, aber so viel wie nötig! Der Inhalt ist wichtiger als die Menge. Jede Organisation sollte daher ihre eigenen Regeln und Prozesse genau analysieren und auf folgende vier Aspekte untersuchen:

  1. Nutzen: Eine Regel, die keinen Nutzen stiftet, ist eine schlechte Regel. Beschützt die Regel etwas, was beschützt werden muss? Ja – super, diese Regel behalten wir! Nein – diese Regel kann weg. So einfach können Sie Ihre Regeln aussortieren.
  2. Nachvollziehbar: Eine Regel muss nachvollziehbar sein. Was bringt mir eine Regel, die von den Mitarbeitern nicht verstanden wird? Sie bringt Widerstand. Besonders in selbstorganisierten Organisationen kann dieser groß werden. Die Kollegen werden die Regel hinterfragen und sich zur Wehr setzen, also gestalten Sie die Regel transparent und kommunizieren sie den Nutzen (s.o.), damit der Angestellte sie verstehen und vor allem akzeptieren kann.
  3. Effizienz: Eine Regel oder ein Prozess muss effizienzsteigernd sein. Was bringt mir ein Nutzengewinn durch einen Prozess, wenn ich diesen wesentlich schlanker gestalten könnte und somit effizienter arbeiten könnte? Genau, er bringt Opportunitätskosten mit sich und einen Effizienzverlust! Übrigens: Ist ein Prozess nicht effizient, wird er in der Regel nicht akzeptiert, weil er nur bedingt nachvollziehbar ist!
  4. Flexibel: Eine Regel oder ein Prozess muss agil sein. Ist diese(-r) nicht anpassbar, werden alle drei Punkte zuvor nicht erfüllt. In einem dynamischen Umfeld ist es also unabdingbar, sich regelmäßig mit seinen Regeln und Prozessen auseinanderzusetzen.

Das Wichtigste, was Sie über Regeln wissen müssen, ist die folgende Regel: Reden Sie im Unternehmen regelmäßig über Ihre Regeln. Sorgen sie für Verständnis, stellen Sie den Effizienzgewinn dar und passen Sie dann bei Bedarf ihre Regeln an. Kommunizieren Sie ständig und immer weiter Ihre Regeln. Es muss deutlich werden, dass diese Regeln nicht da sind, um den Freigeistern Ihre Freiheit wegzunehmen, sondern um sie zu schützen oder um ihre Produktivität zu erhöhen. Nur durch Kommunikation kann ein harmonisches und effizientes Miteinander in einer Selbstorganisation mit Regeln und Prozessen garantiert werden.
Ein relevantes und aktuelles Beispiel gefällig? Bitte sehr: Auch wir bei borisgloger consulting haben Regeln und Prozesse, an die sich meine Kollegen und ich halten müssen. Gerade aber neue Kollegen verstehen die Regeln nicht immer und wollen sie in Frage stellen. Was passierte also speziell bei uns? Einige Kollegen versuchten eine Regel zu umgehen, weil sie sich um Teile ihrer Freiheit beraubt fühlten. Sie sahen in dieser Regel vor allem eine Hürde, bedachten aber gleichzeitig nicht, dass die Regel einen tieferen Grund hatte. Dieses Nichtwissen kann man ihnen gewiss nicht vorwerfen, denn der Grund der Regel wurde ihnen nie wirklich nahegebracht. Was dann aber passierte, ist unserer lebendigen Diskussionskultur zu verdanken. Regelaverse und regelfreudige Kollegen diskutierten miteinander. Das Ergebnis: eine Anpassung der Regel und vor allem eine klare Kommunikation der Regel. Gut, dass wir darüber gesprochen haben!

Foto: CC0 Creative Commons – pixabay, taniadimas

Agiles Manifest: 12 Prinzipien für eine agile Verwaltung

Die vier Grundsätze des agilen Manifests lassen sich problemlos auch auf die öffentliche Verwaltung übertragen. Hinter diesen Grundsätzen stehen 12 Prinzipien, die diese Wertehaltung dezidiert ausformulieren (zum besseren Verständnis habe ich die Softwarebegrifflichkeiten entsprechend ersetzt):

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung unseres Produkts/unserer Dienstleistung zufrieden zu stellen.
    Im klassischen Projektmanagement bekommt der Kunde das fertige Produkt erst am Ende des Projekts präsentiert. Agile Methoden folgen einem anderen Ansatz: Hier werden kontinuierlich, d. h. in regelmäßigen Abständen, fertige Teilentwicklungen präsentiert. Bereits in der Entwicklungsphase werden so Rückmeldungen des Auftraggebers oder der Zielgruppe gewonnen, die wiederum in die Entwicklung einfließen. So sollen Missverständnisse minimiert, neue Erkenntnisse berücksichtigt und veränderte Rahmenbedingungen bereits im Entwicklungsprozess antizipiert werden. Der Entwicklungsprozess beginnt also ergebnisoffen. Stellen wir uns einen Stadtplanungsprozess vor, bei dem das jeweilige Zwischenergebnis in regelmäßigen Abständen in einem öffentlichen Rahmen vorgestellt wird. Die Projektentwickler holen sich in diesem Rahmen immer wieder die Rückmeldung des Gemeinderats und interessierter Bürger, die ihnen zurückspiegeln, ob sie – als Betroffene – Verbesserungsbedarf sehen. Auf diese Weise lassen sich frühzeitig konfliktträchtige Themenfelder identifizieren.
  2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
    Folglich sind Änderungen der Anforderungen jederzeit willkommen, sie werden nicht als lästig empfunden. Ganz im Gegenteil: Das Ziel ist es, unter den gegebenen Rahmenbedingungen möglichst das Beste zu schaffen, das zum aktuellen Zeitpunkt für den Kunden/Auftraggeber den maximalen Nutzen stiftet. Ein agiler Grundsatz lautet: Scheitere früh, scheitere schnell. Je früher wir erkennen, dass etwas nicht zielführend ist, desto früher können wir den Kurs neu bestimmen.
  3. Liefere funktionierende Produkte/Dienstleistungen regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
    Die Punkte 1. und 2. können nur funktionieren, wenn die Ergebnisse in regelmäßigen und möglichst kurzen Abständen präsentiert werden. Scrum sieht einen solchen Zyklus mit einer Gesamtlänge von maximal vier Wochen vor. Je kürzer desto besser. In jedem dieser Abschnitte wird ein voll „funktionsfähiger“ Teilaspekt präsentiert, getestet und begutachtet, der einen echten Nutzwert stiftet. Daraus lässt sich für die folgenden Schritte ableiten, ob und inwieweit Anpassungsbedarf besteht, um am Ende eine bessere Leistung zu liefern. Das Risiko, das „Falsche“ zu entwickeln, wird minimiert. Sie erinnern sich vielleicht an das Beispiel aus Punkt 1?
  4. Fachleute aus verschiedenen Bereichen müssen während des Projekts täglich zusammenarbeiten.
    Agile Teams sind interdisziplinäre Teams. Alle erforderlichen Funktionen, die zur Erstellung eines Produkts oder einer Dienstleistung erforderlich sind, sind Teil des Projektteams. Damit die Abstimmung im Team funktioniert, treffen sich die Teammitglieder täglich zu einer kurzen Abstimmungsrunde. Auf diese Weise wird sichergestellt, dass jeder vom jedem weiß, was dieser gerade macht und wo es eventuell Überschneidungen, Probleme oder Unterstützungsbedarf gibt. Das Team „synchronisiert“ sich selbst. In aller Regel reicht dafür eine Timebox von ca. 15 Minuten. Gerade bei den Problemstellungen, denen sich die öffentliche Verwaltung zu stellen hat, ist Interdisziplinarität extrem wichtig geworden. Statt Fachbereiche wie bisher in Silos abgekapselt Teilbereiche abarbeiten zu lassen, geht es darum, gemeinsam das große Ganze im Auge zu behalten. Mögliche Probleme werden in einer frühen Phase erkannt und können bearbeitet werden.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
    Agile Methoden gehen davon aus, dass jeder von sich aus motiviert und deshalb in der Lage ist, nach bestem Wissen seine Fähigkeiten in das Team einzubringen. Alles, was es hierfür braucht, ist ein Umfeld, das den Rahmen bietet. Ein solches Team muss nicht an die Hand genommen werden. Es braucht nur eine klare „Produktvision“, einen klar umrissenen Auftrag. Das Team spricht von sich aus Probleme an und wird entsprechend an die Verwaltungsführung (Management) herantreten, das die Rahmenbedingungen schafft, die das Team zur Erfüllung seines Auftrags braucht. Im Gegenzug kann die Verwaltungsführung darauf vertrauen, dass das Team die Aufgaben meistert. Das Management wird entlastet und kann sich auf das konzentrieren, was seine eigentliche Aufgabe ist. An dieser Stelle noch der Verweis, dass die Verwaltung eben jene vertrauensvolle Zusammenarbeit im Bereich der Bürgerbeteiligung anstrebt. Werden entsprechende Werte nach innen gelebt, werden sie auch in der Außenwirkung selbstverständlich.
  6. Die effizienteste und effektivste Methode, Informationen an ein und innerhalb eines Teams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht.
    Auch wenn es banal klingen mag: Die Kommunikation von Angesicht zu Angesicht ist nach wie vor der effektivste und effizienteste Weg. Agile Methoden legen daher einen besonders hohen Wert auf Kommunikation. Statt über Aktenvermerke im Umlauf und E-Mails langwierig zu kommunizieren, treffen sich agile Teams täglich. 15 Minuten reichen aus. Was ist seit gestern passiert, was ist für heute geplant und wo gibt es Herausforderungen sowie Bedarf für vertiefenden Informationsaustausch? So ist jeder im Team im Bilde. Gemeinsam wird am Ende der Woche geplant und eine in einer gemeinsamen Rückschau überlegt, was künftig verbessert werden kann. Informationen fließen schneller, das gemeinsame Verständnis wird verbessert.Durch die enge Kommunikation mit den Betroffenen – also auch mit dem Auftraggeber, Kunden, Beteiligten aus anderen Abteilungen – und durch regelmäßige Rückblicke auf einen bestimmten Zeitraum erschließen sich Informationsquellen, die Rückschlüsse über Verbesserungspotenziale, Anpassungsbedarfe und mögliche Herausforderungen liefern. Aber auch das gemeinsame Verständnis aller Beteiligten verbessert sich, weil alle Beteiligten die Hintergründe besser verstehen. Das Verhältnis Bürger zu Verwaltung oder Verwaltung zu Gemeinderat verbessert sich eklatant. Vergessen wir nicht, dass Verwaltung oft mit komplexer Rechtsmaterie befasst ist, die für Laien schwer verständlich ist.
  7. Funktionierende Dienstleistungen/Produkte sind das wichtigste Fortschrittsmaß.
    Hier geht es darum, möglichst einen Nutzen für den Auftraggeber bzw. für den Kunden zu schaffen. Dieser ist das Maß aller Dinge. Nicht die überkorrekt ausgefüllte Dokumentation, das exakte Reporting, der sauber dokumentierte Vorgang ist das Maß guter Projektarbeit, sondern einzig und allein das Ergebnis. Was haben wir von dem erreicht, was wir in diesem Planungszeitraum erreichen wollten? Wie oft wird gemessen, wie lange wer wofür braucht und wie oft etwas von a nach b geschafft wird – ohne jedoch drauf zu achten, was am Ende dabei herauskommt? Das Dokumentieren von Arbeitsschritten erscheint oft wichtiger als das erzielte Ergebnis. Diesem Ungleichgewicht stellt sich das 7. Prinzip entgegen. Dabei darf natürlich das Prinzip der Rechtmäßigkeit des Verwaltungshandelns nicht leiden. Aber die Erfüllung von Verwaltungsvorschriften als alleiniges Fortschrittsmaß allein wird dem öffentlichen Auftrag, den Verwaltung hat, nicht gerecht. Sie ist Dienstleisterin des Bürgers, autorisiert und finanziert vom Bürger.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, das Team und die Nutzer der Dienstleistung sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
    Agilität vermeidet falsches Heldentum, im Sinne von „Verausgaben“ (Überstunden, 12-Stunden-Arbeitstage oder gar nachts durcharbeiten sind tabu). Sämtliche agile Methoden und Ansätze gehen davon aus, dass ein kontinuierlicher, gleichbleibender Rhythmus gesünder und produktiver ist und bessere Ergebnisse zeitigt als „Hauruckverfahren“, die dazu führen, dass die Beteiligten ausbrennen. Der regelmäßige Rhythmus gibt darüber hinaus die Möglichkeit, ein gewisses Maß an Verlässlichkeit zu schaffen und unnötigen Arbeitsdruck zu vermeiden. In diesem Sinne werden Arbeitsspitzen als Warnsignale verstanden, die darauf hindeuten, dass etwas nicht funktioniert. Einer der Vorteile gleichbleibender Arbeitsrhythmen ist die Erhöhung des Durchflusses: die Bearbeitungszeiten verkürzen sich. Ein echter Mehrwert für den Bürger, aber auch für den einzelnen Mitarbeiter, der Erfolg in Form abgeschlossener Vorgänge erleben darf, statt wachsender Aktenberge.
  9. Ständiges Augenmerk auf fachliche Exzellenz und gute Gestaltung der Arbeitsabläufe fördert Agilität.
    Damit das alles funktionieren kann, muss jedes Teammitglied über einen hohen Grad an sozialem und organisatorischem Können verfügen. Nur so erkennt das Team Handlungsmöglichkeiten sowie Herausforderungen und kann adäquate Lösungen erarbeiten. Die kontinuierliche Weiterentwicklung der Teamfähigkeiten, der internen Arbeitsabläufe und die permanente Weiterentwicklung der „Werkzeugkiste“ ist Voraussetzung für Agilität, da nur so auf Veränderungen reagiert werden kann. Fachliche Exzellenz ist für das Selbstverständnis einer öffentlichen Verwaltung Teil des Anspruchs. In der Realität zeigt sich, dass diese jedoch allzu oft durch die Fokussierung auf die Einhaltung von Formvorschriften zu wenig Beachtung erfährt. Wie oft bekommen junge, enthusiastische Mitarbeiter von den älteren Kollegen zu hören: „Haben wir schon immer so gemacht und es hat funktioniert. Es gibt also keinen Grund etwas zu ändern.“ Und dies, obwohl alle spüren, dass Veränderungen längst überfällig sind und sie Ballast, der irgendwann seine Daseinsberechtigung hatte, am effizienten und effektiven Arbeiten hindert.
  10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
    Es mag im ersten Moment kurios klingen, dass die Kunst darin besteht, die Menge nicht getaner Arbeit zu maximieren. Aber beim genaueren Überlegen wird klar, was damit gemeint ist: Es geht darum, Nutzen zu stiften und unnötige Arbeiten zu vermeiden, die keinen Nutzwert schaffen. Statt vieler unnötiger Zwischenschritte sollen Dinge möglichst einfach gemacht und „verschlankt“ werden, wenn es möglich ist. Sprich: Alles „über Bord“ werfen, was nicht zum gewünschten Ergebnis beiträgt. D. h. auch zu hinterfragen, ob das, was Verwaltung tut, tatsächlich zum Ergebnis beiträgt oder nur aus Tradition gemacht wird. In eine ähnliche Richtung geht auch das 12. Prinzip, auf das wir noch eingehen werden.
  11. Die besten Arbeitsrahmen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
    Agile Teams sind selbstorganisiert. Da sich das Team täglich mit dem gemeinsamen Thema auseinandersetzt, hat es auch die nötige Expertise, um Anforderungen, Entwürfe und Arbeitsrahmen so zu gestalten, dass am Ende ein für alle befriedigendes Ergebnis herauskommt. Das Team fixiert sich nicht auf Stellenbeschreibungen, sondern definiert sich über Rollen. Nehmen wir Scrum, eine der bekanntesten Methoden der agilen Produktentwicklung. Dort wird zwischen drei Rollen unterschieden. Mehr nicht. Es gibt einen sogenannten Scrum Master, der das Team begleitet, unterstützt und berät. Es gibt den Produkteigentümer, der innerhalb des Teams die Interessen des Auftraggebers vertritt und den Kontakt zum Auftraggeber sicherstellt, und es gibt das Entwicklerteam.Das Entwicklerteam setzt sich aus allen Funktionen zusammen, die zu Erfüllung der Aufgaben erforderlich sind. Alle verfügen im Idealfall über eine breite Grundkenntnis und jeweils Spezialkenntnisse, sodass jeder im Team andere Teammitglieder unterstützen kann. Gemeinsam mit dem ScrumMaster und dem Produkteigentümer bildet das Entwicklerteam ein Scrum-Team. Ein Beispiel: Bei einem Projekt zur Einführung der eAkte übernimmt der Sachgebietsleiter des Fachbereichs zentrale Dienste die Rolle des Produkteigentümers. Der Produkteigentümer ist nicht disziplinarischer Vorgesetzter des Teams. Dem Team gehören Vertreter der verschiedenen Fachbereiche an, die als Kommunikatoren in ihre Fachbereiche wirken sowie ein Vertreter des Personalrates. Die Rolle des Scrum Masters wird von einem erfahrenen Kollegen der EDV-Abteilung ausgefüllt, der bereits in scrumgeführten Projekten gearbeitet wird. Da die Stadt vier Fachebereiche hat, gehören damit sieben Personen dem Team an. Der Bürgermeister und die Fachbereichsleiter stehen in der Rolle des Managements. Die jeweiligen Kollegen, die später mit dem System der eAkte arbeiten, sind als Anwender die wichtigsten Feedbackgeber für das Team.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und es passt sein Verhalten entsprechend an.
    Die kontinuierliche Verbesserung des Teams und seiner Zusammenarbeit ist von zentraler Bedeutung. Ein neues Team funktioniert nicht von Anfang an perfekt. Es muss sich finden. Es muss sich mit den sich verändernden Rahmenbedingungen entwickeln, wenn es sich einmal gefunden hat. Im Lean Management wurde der Begriff Kaizen, der ständigen Verbesserung, geprägt. Die Idee des Kaizen spiegelt sich im agilen Manifest wieder: Es gibt keine perfekte, sondern immer nur die im Augenblick beste Lösung. Zusammengefasst: Verbesserung heißt hier nicht, einfach nur Prozesse und Strukturen fortzuentwickeln, sondern im ganzheitlichen Sinne voranzuschreiten. Die Zusammenarbeit zwischen allen Beteiligten, die soziale Ebene miteinzubeziehen und als eine der wichtigsten Stellschrauben zu sehen.

Agilität und öffentliche Verwaltung schließen sich nicht aus, wie so mancher „Meinungsmacher“ postuliert. Im Gegenteil. Die agile Verwaltung, die sich an den agilen Werten und Grundsätzen ausrichtet, ist als öffentlicher Dienstleister nicht nur effektiv, sondern auch effizient im Meistern von Herausforderungen. Es mag gewagt klingen, aber für mich ist die agile Verwaltung eine Rückbesinnung, die Renaissance der Ursprungsidee, die ihren Ausdruck in der kommunalen Selbstverwaltung gefunden hat. Mithilfe der agilen Prinzipien, Werte und Vorgehensweisen können wir der Idee der bürgerorientierten Selbstverwaltung wieder mehr Lebendigkeit einhauchen.

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Als ScrumMaster werde ich in Unternehmen geholt, um zur Produktivitätssteigerung Scrum „einzuführen“. Relativ schnell begegne ich dabei folgendem Umstand: Viele Product Owner haben nicht im Blick, was ihr Team eigentlich genau liefern soll. Jedenfalls beantworten sie diese Frage selten aus Kundensicht. Meistens treffe ich auf Product Owner, die durch ihre lange Erfahrung und ihr umfangreiches Wissen zwar Experten für ihre Produktsparte geworden sind, aber ihr Blick hängt am eigenen Tun und Denken fest. Letzteres ist folglich zu wenig nach draußen gerichtet, in die Erlebniswelt des Kunden und des Nutzers. Für mich als ScrumMaster bedeutet das, den Product Owner und das Entwicklungsteam zu dieser Sicht- und Denkweise hinzuführen, was viel umfassendere Implikationen hat, als einfach mal eine neue Methode „einzuführen“. Genau genommen sprechen wir von der Entwicklung hin zu einer kundenorientierten Organisation, und das wirkt sich gleich auf mehreren Ebenen aus:
Ein wichtiger erster Schritt ist, eine agile Produktentwicklung zu etablieren. Das heißt im Idealfall, dem Scrum-Team beizubringen, wie man iterativ ein MVP (Minimum Viable Product) entwickelt und es dem Markt bzw. den Usern aussetzt – bis ein Produkt gefunden wird, das es sich in allen Details fertig zu bauen lohnt.
In diesem Prozess stellt man wiederum fest, wo es im Team an Skills mangelt, und in der Regel tut es das. Die nächste Aufgabe wäre also, diese Skills zu entwickeln. In der Softwareentwicklung hat sich für den Aufbau und den Austausch von Wissen das Mob bzw. Pair Programming etabliert, das Prinzip lässt sich aber auf andere Arbeitsbereiche anwenden. Fehlen bestimmte Skills zur Gänze, muss man sich diese zusätzliche Kompetenz ins Team holen.
Auf der Ebene der Infrastruktur stößt man schnell an Grenzen, die aufgelöst werden wollen: Hat das Team überhaupt geeignete Räume, in denen die Zusammenarbeit möglich ist? Sind Kommunikationsmittel im Einsatz, mit denen die Teamarbeit strukturell überhaupt abgebildet werden kann („Pull“-basierte Tools wie Slack oder Microsoft Teams können das), oder läuft die schriftliche Kommunikation des Teams hauptsächlich über E-Mail? Gibt es Arbeitsmaterialien wie Flipcharts, Whiteboards etc. erstens in ausreichender Menge und zweitens in guter Qualität?
Bleibt noch die Ebene der Architektur, auf die man einen Blick werfen sollte. Wie ist das Unternehmen organisiert und passt diese Organisationsstruktur überhaupt zu dem Produkt, das sich die Kunden und Anwender wünschen? Eng verbunden damit ist die Frage der Führungskultur in der Organisation: Sind Selbstorganisation, Freiwilligkeit und Commitment erlaubt und werden sie belohnt?
Was bedeutet das für die Arbeit als ScrumMaster oder Agile Coach? Ich muss einerseits die genannten Ebenen im Blick behalten und gleichzeitig meine Rolle mit Konsequenz leben. Das bedeutet, die agilen Werte und Prinzipien mit Bestimmtheit zu vertreten. Das bedeutet zum Beispiel, den nötigen langen Atem mitzubringen und dem Management so lange auf den Nerv zu gehen, bis die Lizenz für das geeignete Kommunikationstool gekauft wurde. Müsste ich das Handeln des ScrumMasters auf einen Aspekt reduzieren: immer wieder transparent machen, wo es hängt – auf allen Ebenen. Nur so komme ich überhaupt an die entscheidenden Punkte heran, die eine Organisation in ihrer Produktivität behindern.

ScrumMaster in Aktion: Das Feiern von Erfolgen

Es ist 9.00 Uhr. Wir haben uns vor dem Taskboard versammelt. Es ist alles noch ganz frisch, wir lernen noch, ein Hauch Unsicherheit liegt in der Luft. Der erste Kollege beginnt und hängt seine Tasks um. Die Kollegin folgt. Der erste Task wird auf „Done“ gesetzt. Die erste Aufgabe ist geschafft. Ich lade zum Feiern ein, strahle die Kollegin an. Ich empfinde die erste erledigte Aufgabe als große Genugtuung. Grund genug, um kurz innezuhalten und den Moment wirken zu lassen. Einziger Haken daran: um mich herum nur verdutzte Gesichter, die Kollegin ist verunsichert. Lob für eine solche „Kleinigkeit“ ist sie nicht gewohnt. Sie mache doch nur ihren Job. Auch der Product Owner ist verwirrt: Sollte das hier nicht selbstverständlich sein? Warum also ist der ScrumMaster so begeistert?
Ich merke schnell: Das Problem liegt tiefer. Lob und positive Rückmeldungen gehen hier allen schwer von den Lippen. Aus der Psychologie ist bekannt, dass Belohnung der positiven Verstärkung dient. Damit soll die Wahrscheinlichkeit erhöht werden, dass sich ein gewünschtes Verhalten wiederholt. Situationsgebundene Belohnung kann also durch Loben erfolgen. Dies sollte allerdings nicht zu freigiebig eingesetzt werden, da es sonst unverdient erscheint. Bewiesenermaßen wird das Belohnungssystem jedoch gezielt durch die Wertschätzung unserer Mitmenschen angesprochen – das steigert die Ausschüttung des Glückshormons Dopamin.

Den kleinen Dingen Aufmerksamkeit schenken

Meistens sind es ja die kleinen Dinge, die als selbstverständlich hingenommen werden, und es erscheint uns deshalb nicht nötig, diese wertzuschätzen. Es liegt uns fern, die kleinen Dinge zu sehen, die in Summe zum Gesamterfolg beitragen. Gerade im Prozess der Veränderung ist es jedoch sehr wichtig, diese kleinen positiven Fortschritte zu erkennen und hervorzuheben. Dopamin ist dafür verantwortlich, dass wir Erfahrungen als wohltuend empfinden, in Zukunft werden wir uns an dieses Gefühl erinnern können. So werden diese aktiv unterstützt und in Zukunft höchstwahrscheinlich wiederholt werden. Noch wichtiger als das Lob durch den ScrumMaster und den Product Owner ist das Lob untereinander. Kollegen, die sich gegenseitig zu ihren einzelnen Leistungen wertschätzend äußern, steigern die produktive Zusammenarbeit und den Zusammenhalt im Team.

Das Team mit Freiheiten belohnen

Das Team kann neben diesen kleinen Wertschätzungen auch durch Freiheiten belohnt werden. Vertrauen, das dem Team beispielsweise vom Product Owner entgegengebracht wird, ist eine wertschätzende Handlung, die dazu führen kann, dass das Team bemüht ist, beim nächsten Mal die Erwartungen des Product Owners zu übertreffen. Es wird dadurch selbstbewusster und beginnt, sich selbst mehr zuzutrauen. Damit ist die Grundlage für innovativere und kreativere Lösungen gelegt und das Team wächst noch mehr zusammen. Zugestandene Freiheit wirkt durch ihren wertschätzenden Charakter also ebenfalls als positive Verstärkung und steigert die Produktivität im Scrum-Team.

Gold Cards

Die gleiche Wirkung haben sogenannte Gold Cards, die der Product Owner an die Teammitglieder vergibt. Mit diesen Cards können Mitarbeiter innerhalb eines gewissen Zeitraums einen Teil ihrer Arbeitszeit in etwas investieren, das sie interessiert. Dies kann eine Fortbildung, persönliche Weiterbildung oder Zeit sein, um an eigenen Ideen zu arbeiten. Der Vorteil an dieser Variante ist, dass dem einzelnen Mitarbeiter gegenüber Interesse ausgedrückt wird, nicht nur an der Leistung des Teams.

Eine Release-Party schmeißen

Im skalierten Umfeld gibt es eine weitere mächtige Möglichkeit, das gesamte Team oder sogar mehrere Teams für ihre erbrachten Leistungen zu belohnen. Wie wäre es beispielsweise mit einer Release-Party? Die Teams haben durchgehalten, gekämpft und geliefert. Warum also nicht den Release gebührend mit allen Beteiligten feiern? So kann sogar das Angenehme mit dem Nützlichen verbunden werden: Die Teams können ihre Leistungen bei einer Präsentation von den Stakeholdern und dem gesamten Umfeld anerkennen lassen und anschließend kann sich das Team gebührend selbst feiern.
Zurück zum Geschehen: Ich wiederhole meine Aufforderung, den ersten Task auf „Done“ zu feiern. Peinlich berührt versucht sich die Kollegin aus dem Mittelpunkt zu stehlen. Wir haben noch einen langen Weg vor uns, aber ich werde nicht aufgeben, denn: Gerade am Anfang sind es die kleinen Erfolge, die aus einer Gruppe von Menschen ein Team machen.

Foto: CC0 Creative Commons – pixabay, pexels

Story Mapping – die Geschichte aus Sicht des Kunden

Es ist doch so: Eine Produktvision oder Produktidee zu konkretisieren und daraus User Storys zu entwickeln, ist nicht immer einfach. Ganz im Gegenteil: Es ist meistens sehr kompliziert. Allein schon die Frage nach dem Anfang und dem Ende ist schwierig. Man fängt an, seine eigenen Ideen und die des Teams zu sammeln und zu dokumentieren. Am Ende steht man mit einer langen Liste an Ideen da und schnell stellen sich ein paar Fragen:

Wenn man in dieser Situation steckt, hilft es, sich mit einer Story Map in den Kunden hineinzuversetzen und dessen Geschichte zu erzählen. Wie macht man das? Nun, wie bei jeder guten Story braucht es eine gewisse Struktur, die sich in Aktivitäten, Steps und Details unterteilen lässt. Ach ja, eine große leere Wand, Post-its und Stifte sind auch von Vorteil.
Zunächst werden die Aktivitäten auf einzelnen Post-its festgehalten. Aktivitäten sind große, meist in sich abgeschlossene Schritte, die der Kunde macht. Zum Beispiel: Informationen über ein Produkt einholen, Produkt auswählen, Warenkorb einsehen, Zahlungsoptionen auswählen oder Lieferoptionen auswählen.
Eine Stufe tiefer kommen die Steps. Diese helfen, die großen, groben Aktivitäten spezifischer zu machen. Hier wird aufgezählt, was der Kunde innerhalb einer Aktivität alles macht, um sie letztlich abzuschließen. Beispiele für die Steps innerhalb der Aktivität „Produkt auswählen“ können sein: einzelne Produkte ansehen, favorisiertes Produkt auswählen, Produktdetails ansehen, Produktdetails anpassen, Produkt in Warenkorb legen.
Die Details füllen die Steps mit Leben und werden am Schluss aufgeschrieben. Hier werden alle wilden, coolen aber auch essentiellen Ideen, die die Steps zu einem Erlebnis machen sollen, an die Wand geheftet. Diese Details können sowohl ganz spezifisch als auch grob und allgemein formuliert sein. Zum Beispiel: Warenkorb-Button, die Farbe anhand eines Tuschkastens auswählen, Anwendungsgebiete des Produkts anzeigen oder ein Produktteaser.

 

Story map

Beispielaufbau einer Story Map
angelehnt an: Patton, Jeff und Economy, Peter (2015, 1. Aufl.): User Story Mapping – Die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung)

 

Innerhalb der Schritte kann man ganz schnell feststellen, ob etwas vergessen wurde oder nicht. Wenn ja, dann werden die Post-its einfach umsortiert und neu angeordnet. Das Schöne ist: Es wird dabei jede Menge miteinander gesprochen und jeder erzählt seine Vorstellung der Kunden-Story. Ganz nebenbei wird so ein einheitliches Verständnis geschaffen. Das Tolle an Story Mapping ist, dass es entweder als einzelne Methodik innerhalb eines Prozesses zum Aufbau eines initialen Produkt Backlogs verwendet werden kann oder nachgelagert, als Resultat eines Design Thinking Workshops. In Kombination mit Design Thinking entsteht so gleichzeitig die Story inklusive Feedback des Kunden. Einen guten Einblick, wie ein Design-Thinking-Prozess aussieht gibt es hier.
Doch wie komme ich nun von der Story Map zu einem initialen Produkt Backlog mit Epics und User Storys? Das erzähle ich beim nächsten Mal.

Visualisierung: Behübschung oder Mehrwert für den Scrum Flow?

Überall dort, wo Menschen aufeinandertreffen, um miteinander Dinge zu erarbeiten, zu besprechen und zu planen, ist Visualisierung sinnvoll – zum Beispiel bei Meetings, Tagungen, Konferenzen, Seminaren, Trainings und Workshops. Obwohl es unzählige Möglichkeiten gibt, verstehen viele unter „Visualisierung“ noch immer nur PowerPoint-Präsentationen und vergeben sich damit die Chance auf einen nachhaltigen Eindruck. Was bleibt nach der x-ten PowerPoint-Präsentation in Erinnerung? Endlose Folienschlangen, dicht bepackt mit Zahlen, Daten und Fakten – kaum etwas davon bleibt erwiesenermaßen im Gedächtnis der Zuhörerschaft hängen.
Auch die Wissenschaft zeigt: Visuals schaffen es deutlich besser, die Zuhörer und Zuschauer zu binden. Laut einer Studie der Universität von Minnesota gemeinsam mit der 3M Corporation, die den Einfluss visueller Hilfen im Präsentationssetting untersuchte, kann das menschliche Gehirn Visualisierungen bis zu 60.000 mal schneller verarbeiten als reine Textinhalte. Da 90 Prozent der vom Gehirn absorbierten Informationen visueller Natur sind, können im Anschluss visualisierte Inhalte wesentlich besser abrufen werden.

Visualisierung

Beispiel einer unterstützenden Visualisierung zum Thema “Methodenevolution” während einer interaktiven Meetingform

Das ist ideal für den agilen Kontext, der von der Interaktion, der Freiwilligkeit und Bereitschaft im Team lebt, gemeinsam an Produktlieferungen zu arbeiten. Visualisierungstechniken schaffen es, die Menschen in Arbeitssitzungen und Lernumgebung stärker zu aktivieren. Als Visual Facilitator kann ich hier komplexe Inhalte und unterschiedliche Perspektiven sichtbar machen, dem Team Impulse für den Dialog geben, Gedanken strukturieren und schließlich wichtige Ergebnisse sichern. Neben den zahlreichen Vorzügen zeigen sich in der Unternehmenspraxis allerdings auch einige Herausforderungen, die man beachten sollte, wenn man die Vorzüge der Visualisierung im agilen Kontext nutzen will:

  1. Halten Sie eine lebendige Präsentation. Gehen Sie nicht mit vorgefertigten Flipcharts in eine Präsentation. Als Live-Zeichner sollten Sie die Darstellung im Laufe der Präsentation entwickeln, um die Zuhörer abzuholen, den Erinnerungswert zu steigern und Publikumsfeedback direkt einfließen lassen zu können. Der Zuhörer und Betrachter wird dadurch zweifach kognitiv stimuliert – der Erinnerungswert steigt.
  2. Vermeiden Sie die Ornamentierung von Scrum. Auch wenn Prozess, Inhalte und Ergebnisse in visueller Sprache, d.h. in Kombinationen von Text, Bild und Containern gut sichtbar gemacht werden können, schlägt im Zweifel der Inhalt die Form. Konzentrieren Sie sich auf die Präsentation und nutzen Sie Visualisierungshilfen nur zur Unterstützung Ihrer Kernaussagen.
  3. Lassen Sie sich als ScrumMaster nicht auf die Rolle des Facilitators reduzieren – ein mit bunten Visuals geschmückter Scrum-Meeting-Raum ist keine Garantie für einen funktionierenden Change Prozess. Dem Team und den Stakeholdern hilft die Transparenz, die durch Visualisierungen in Meetings, von Artefakten und auf Boards entsteht. Übernehmen Sie aber nicht alle zeichnerischen Leistungen, sonst werden Sie schnell auf die Rolle des Visual Facilitators reduziert – als ScrumMaster haben Sie noch wesentlich wichtigere Aufgaben!

Nicht nur, aber besonders im agilen Umfeld bieten ausdrucksstarke Visualisierungen die Möglichkeit, den Wert und die Wichtigkeit von Aussagen zu unterstreichen und klarer zu machen. Vom Teammeeting bis zur Großgruppenveranstaltung mit mehreren Hundert Teilnehmern haben Sie ein kraftvolles Tool in der Hand, wenn Sie die damit verbundenen Herausforderungen ernst nehmen.

Foto: CC0 Creative Commons – pixabay, AlexanderStein

Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw

Social Impact Lab 2.0 – Lean im Startup

Das Social Impact Lab in Stuttgart ermöglicht sozialen Startups im Gründungsprozess, über mehrere Monate hinweg aus ihren Ideen ein tragfähiges Geschäftsmodell zu entwickeln. Ganz unter dem Motto “have a social impact” konnten wir – Michael Friedmann und Marcel Rößner – den Gründerinnen und Gründern im Rahmen eines Workshops einen Einblick in agile Arbeitstechniken geben. Im Speziellen zum Thema “Lean Startup”.
Die teilnehmenden Startups des Social Impact Labs durchlaufen das achtmonatige Stipendium #Wirkungsschaffer, das Workshops und Coachings in den verschiedensten Bereichen beinhaltet. Als Berater für agile Produktentwicklung hatten wir daher die Zielsetzung, den Teilnehmerinnen und Teilnehmern in einem eintägigen Workshop einen guten Überblick über agile Methoden zu geben und ihnen möglichst leicht anwendbare Konzepte mitzugeben, die sie einfach umsetzen können. Denn auch soziale Startups brauchen ein hieb- und stichfestes Geschäftsmodell, um langfristig nicht von Spenden und Fördergeldern abhängig zu sein. Da sich die Startups im Social Impact Lab teilweise in einer frühen Gründungsphase befinden, konnten wir ihnen vor allem mit dem Thema Lean Startup einen neuen Denkrahmen mit auf den Weg geben.

Was ist (ein) Lean Startup?

Lean Startup ist eine Methode, bei der schnell und mit möglichst wenig Aufwand geprüft wird, ob für eine Idee ein Markt existiert oder nicht. Um eine Idee testen zu können, muss erst ein Produkt gebaut werden, das diese Idee verkörpert. Mit herkömmlichen Methoden und Vorgehensweisen kann dieser Prozess auch ein paar Jahre dauern. Der Trick bei Lean Startup: Es kommt nicht darauf an, dass das Produkt in allen Einzelheiten funktionsfähig auf dem Markt erscheint. Wichtig ist zunächst die Funktionalität, von der vermutet wird, dass sie dem Kunden Nutzen bringen wird und damit sein Problem löst. Dabei sprechen wir vom Minimum Viable Product (MVP). Es ist das Mindeste, was benötigt wird, um prüfen zu können, ob das Produkt gekauft wird oder nicht. Welche verschiedenen Strategien und Typen eines MVPs existieren, könnt ihr in diesem Blogbeitrag nachlesen:

Am Anfang steht die Hypothese

Ein Startup beginnt immer mit einer Hypothese, die es zu überprüfen gilt. Der Zyklus, in dem eine solche Hypothese überprüft wird, nennt sich „Build-Measure-Learn-Zyklus“. Zunächst wird auf Basis der Hypothese ein MVP gebaut, mit dem die aufgestellte Hypothese überprüft und gemessen werden kann. Basierend auf diesem Feedback und den gemessenen Daten gilt es nun zu lernen: Das Produkt bzw. die Idee wird anhand der Ergebnisse gepasst und eine neue Iteration des Prozesses wird durchlaufen. Die reale Hypothese eines früheren Startups lautete beispielsweise:

Menschen kaufen Schuhe online = Profit

Mit dieser Hypothese ist der heutige Schuhgigant Zappos, damals noch als kleines Startup, 1999 in den Onlinehandel eingestiegen. Was Zappos anfangs benötigte, war keine ausgefeilte Online-Plattform, sondern eine rudimentäre Website mit Bildern von Schuhen und einer einfachen Kauffunktion. Über diese Website konnten Schuhe ausgewählt und schließlich gekauft werden. Die Fotos der Schuhe hatten die Gründer einfach in einem nahegelegenen Schuhladen aufgenommen. Wurde nun ein Schuh online von einem Kunden bestellt, mussten die Zappos-Gründer wieder in das Schuhgeschäft laufen, die Schuhe dort kaufen, anschließend händisch verpacken und an den Käufer versenden. Ziemlich umständlich, oder? Als langfristiges Geschäftsmodell wäre das sicher nicht tragbar. Aber was Zappos mit dem MVP bewiesen hatte, war, dass Menschen – genauer gesagt potentielle Schuhkäufer*innen – tatsächlich bereit waren, online Schuhe zu kaufen. 
Da die anfängliche Hypothese damit bestätigt worden war, war es erst jetzt sinnvoll, eine echte Onlinehandelsplattform mit einfacheren, digitalen Prozessen nach und nach zu entwickeln.
Mit simplen Mitteln wie Google Adwords konnte zusätzlich gemessen werden, wer die wirkliche Käufergruppe war, um das Sortiment von Zappos stetig darauf auszurichten und das richtige Kundensegment anzusprechen. Wurde ein Schuh nie angeklickt, konnte er schnell wieder aus dem Sortiment genommen werden. Produkte, die bei den Kunden Anklang fanden, konnten identifiziert und das Sortiment in diesem Bereich ausgebaut werden.

Und wenn sich die Hypothese nicht bestätigt?

Doch was wäre gewesen, wenn sich die Hypothese nicht bestätigt hätte? Auch für diesen Fall liefert das Lean-Startup-Konzept eine Antwort: den sogenannten Pivot, zu deutsch Richtungswechsel. Wird eine fundamentale Hypothese der Idee oder des Geschäftsmodells widerlegt, so MUSS ein Richtungswechsel erfolgen, da das Startup sonst am Nutzer vorbeientwickelt und keinen Wert liefert. Das Startup ist somit nicht gescheitert, sondern führt rechtzeitig einen Richtungswechsel hin zu einer neuen Hypothese durch.
Im Social Impact Lab konnten wir mit den Teilnehmern im Rahmen unseres Workshops einen fundamentalen ersten Schritt im Sinne des Lean Startups gehen. Nachdem wird das theoretische Konzept vorgestellt hatten, baten wir die Teilnehmer, die Hypothese ihrer Geschäftsidee zu formulieren, um sie im Nachhinein im Plenum zu diskutieren.
Nach der Vorstellung konnten wir genauer auf die Besonderheiten der Hypothesen eingehen und prüfen, was getan werden könnte, um diese möglichst schnell auf dem Markt zu validieren. Das konstruktive Feedback und gemeinsame Hinterfragen unter den Teilnehmern brachte weitere Ideen hervor.
Übrigens: Der Lean-Startup-Ansatz ist nicht nur für Startups geeignet, sondern grundsätzlich für jede Produktentwicklung. Auch in bereits etablierten Unternehmen sollten Ideen bzw. Hypothesen möglichst schnell geprüft werden, um radikal nutzerzentriert zu entwickeln und Wert zu generieren. Probieren wir es doch gemeinsam aus!

Foto: Copyright Marcel Rößner

3 Argumente gegen User Stories und wie ihr ihnen begegnen könnt

In unseren Trainings oder in der Arbeit mit Teams begegnen wir einer Vielfalt von Gründen, warum eine bestimmte agile Praktik in diesem Team nicht angewendet werden kann. Dabei sind die Begründungen nur auf den ersten Blick spezifisch für das jeweilige Team und vor allem sind es in den seltensten Fällen tatsächlich sachliche Gründe, warum etwas nicht geht. Menschen stehen Veränderungen prinzipiell erst einmal kritisch gegenüber. Deshalb werden neue agile Praktiken nicht einfach ausprobiert, sondern meist erst einmal gründlich geprüft.
Daran ist prinzipiell nichts Falsches – unser Gehirn spart viel Energie, wenn es gelernte Praktiken abspielt und nicht immer Neues ausprobiert. Gleichzeitig kann es ganz schön frustrierend sein, wenn man einem Team etwas zeigen möchte und nur Widerstand erntet. Manchmal verbirgt sich hinter der vorgeschobenen rationalen Begründung auch ein Gefühl der Unsicherheit. Ehrlich wäre es, einfach zu sagen: „Ich will es nicht machen! Den alten Prozess kenne ich, der neue macht mir Angst, weil ich noch nicht weiß, was genau passiert.“ Im beruflichen Kontext sind aber wenige so reflektiert und ehrlich und deshalb lohnt es sich, sich als Scrum Master oder Agile Coach schon einmal auf die typischen Widerstände einzustellen, die einem bei der Einführung eines neuen Meetings, Artefakts oder einfach nur einer kleinen Prozessänderung begegnen werden.
In den nächsten Wochen wollen wir euch einige jener Argumente nennen, die uns immer wieder begegnen, damit ihr dagegen gewappnet seid und euren Teams helfen könnt, sich auf das Abenteuer des Ausprobierens einzulassen. Im ersten Teil widmen wir uns dem Thema User Stories.

„So ein simpler Satz ist mir viel zu wenig!“

Ganz klar, die User Story in ihrer klassischen Syntax ist einfach – und das soll sie auch sein! Eine gute User Story ist nämlich nichts anderes als eine „Einladung zur nachgelagerten Konversation“. Das bedeutet: In ihrer offenen Formulierung ist sie dazu gedacht, dass der Product Owner mit dem Team über die User Story spricht, sie auf den Prüfstand stellt und dadurch die Details immer klarer werden – bis die Story „ready for sprint“ ist.

„Aber eine User Story kann doch nicht mindestens zwei Mal im Refinement gewesen sein!“

Gerade weil User Stories anhand der INVEST-Kriterien formuliert werden, sollen sie unter anderem verhandelbar und klein sein. Das bedeutet, dass es viele Gespräche und einige Durchläufe braucht, um mehr Klarheit über die Anforderung zu bekommen, die sich in der User Story versteckt. Je vager die Formulierung und je näher die User Story noch an ihrer Ideenphase ist, desto klarer wird, dass es mehr Details braucht, bis alle Teammitglieder das gleiche Verständnis über den Inhalt der User Story haben. Das Backlog Refinement ist dafür der geeignete Termin. Sprecht als Team über den Inhalt, verschafft euch Klarheit und ergänzt, was das Zeug hält: Akzeptanzkriterien, Testfälle, Abhängigkeiten, Risiken und alle Details, die euch einfallen. User Stories werden dann auch oft kleiner geschnitten, wenn sie sich für einen Sprint als zu groß herausstellen.

„User Stories, okay, aber Personas? Brauch ich wirklich nicht!“

Simon Sinek sagt immer wieder, dass das „Why“, also das Warum, das einen antreibt, klar sein muss. Daher sollte die dahinterliegende Antwort etwas elaborierter sein als ein lapidares „Isso“. Auch wenn dem Team der Mehrwert klar ist, ist es unglaublich hilfreich, sich die Anforderungen mit der Brille bestimmter Zielgruppen anzusehen: Warum tickt meine Zielgruppe so wie sie tickt? Und was bedeutet das für mein Produkt? Gibt es widersprüchliche Anforderungen meiner User-Gruppen? Worauf will ich als Product Owner mein Augenmerk legen und für wen priorisiere ich? Personas helfen dabei, sich als Team in die jeweilige Zielgruppe hineinzuversetzen. Je mehr Daten und Fakten in die Persona fließen, desto besser – und dennoch: Entwerft eure Personas so, als wären sie reale Wesen mit Charakter, Lebenslauf, Vorlieben und gebt eurem Produkt damit so viel Kontext, dass ihr euch der Frage nach dem „Why“ leichter nähern könnt.
Sind euch in eurer Arbeit noch andere Argumente gegen User Stories begegnet? Lasst uns wissen, wie ihr darauf reagiert.

Dieser Beitrag ist im Pair Writing mit Sandra Wittmann entstanden.
Foto: CC0 Creative Commons, pixabay – aitoff

Scrum Meetings – Retrospective

The final meeting within the Scrum framework is called the Retrospective. The key is to review the last iteration and determine how we can improve during the next one as a team.  
Are you curious to find out how to do a Retrospective efficiently? Watch my how-to video to find out! 

7 Erfolgsfaktoren der Digitalisierung- Rahmenbedingungen

Ob eine Digitalisierungsinitiative erfolgreich verläuft oder nicht, hängt zunächst von den Rahmenbedingungen ab: von den organisatorischen und und von jenen der Infrastruktur. Dabei geht es gar nicht darum, am Arbeitsplatz eine Fun-Park-Atmosphäre zu schaffen. In erster Linie ist es wichtig, dass sich Mitarbeiter auf ihre Arbeit fokussieren können und alle Mittel zur für die Zusammenarbeit zur Verfügung haben. Mehr dazu in diesem Video.

Stage Gate und Scrum?

Im Innovationsmanagement ist der Stage-Gate-Prozess einer der wichtigsten Bausteine. Neuere Variationen regen explizit an, bei den Meilensteinen den Kunden mit ins Boot zu holen. Das lässt sich mit Scrum oder agilen Methoden generell gut kombinieren. Was oft noch fehlt, ist ein Umdenken in der Budgetierung. In diesem Video zeige ich, wie sich Stage-Gate-Prozesse, Scrum und der Venture-Capitalist-Ansatz kombinieren lassen, um das finanzielle Risiko im Auge zu behalten.

Scrum4Schools: Lernen für die Zukunft

Seit einigen Monaten berichten wir auf unserem Blog immer wieder über das Projekt Scrum4Schools. Wieso ich mich gerne so intensiv mit dem Thema beschäftige? Der nächsten Generation, den von Natur aus neugierigen und wissbegierigen Schülerinnen und Schülern, soll es schon in ihrer Ausbildung möglich sein, sich selbstbestimmt und intrinsisch motiviert Wissen anzueignen. Der angenehme Nebeneffekt: Sie lernen damit bereits in ihrer Ausbildung, wie man in Teams selbstorganisiert arbeitet und eignen sich agiles und wirtschaftliches Denken an. Schüler und Studenten sind aus heutiger Sicht zu wenig vorbereitet für die Arbeitswelt und werden ins kalte Wasser gestoßen, solange sich das Bildungssystem nicht anpasst. Reines Auswendiglernen bereitet nicht mehr auf das vor, was in der Arbeitswelt von heute gefragt ist. Die wichtigsten Kompetenzen sind Eigeninitiative, Selbstverantwortung und Selbstorganisation sowie die Fähigkeit, Dinge zu hinterfragen.
Dem Magazin „junior//consultant“ habe ich im April 2018 zu meinem persönlichen Werdegang und zu unserer Initiative ein Interview gegeben. Mir war es wichtig, mein Herzensprojekt vorzustellen, vor allem die Chancen und Ziele, die Scrum4Schools mit sich bringt: Sollten Schüler und Studenten wirklich ihre Arbeitsweise ändern und was haben sie im Endeffekt davon? Mehr Aufwand? Sind die Lernergebnisse um so vieles besser, dass es sich lohnt, das gesamte Bildungssystem auf Dauer zu revolutionieren? Wenn ihr neugierig auf Antworten seid, dann empfehle ich euch mein Interview auf der Medienplattform für junge Consultants – hier könnt ihr es nachlesen. 
Passend zum Projekt haben wir eine Checkliste konzipiert, mit deren Hilfe sich Scrum4Schools-Projekte in Eigenregie umsetzen lassen. Den Download findet ihr auf unserer Scrum4Schools-Website. 

Foto: CC0 Creative Commons – pixabay, Pixapopz

"Ja, genau. Was für eine Chance!" oder wie Sprache Wirklichkeit schafft

In unserer täglichen Arbeit in Unternehmen verschiedener Größe und Art begegnen uns immer wieder Sätze wie folgende:

Kennen Sie diese Sätze aus Ihrem eigenen Arbeitsalltag, nutzen Sie diese vielleicht manchmal selbst ganz automatisch oder sogar gern? Da sind Sie nicht allein. Wir hören sie sehr oft und immer wieder, sie nisten sich in unserem Sprachschatz ein. Lesen Sie diese Sätze noch einmal und hören Sie in sich rein. Neben dem wiedererkennenden Augenrollen merken Sie vielleicht, was diese Sätze noch auslösen: Grenzen. Enge. Unverbindlichkeit. Resignation. Hilflosigkeit. Unbeweglichkeit und Fremdbestimmtsein. Wie stehen wohl die Chancen, in einem solchen Umfeld neue Dinge zu probieren? Sich weiter zu entwickeln? Lust zu bekommen, die Verantwortung für sein eigenes Handeln wieder zu übernehmen?
Sprache schafft Welten. Ich bin als Kind mit Bastian und Fuchur durch Phantasiewelten geflogen, habe mich mit Momo vor den grauen Herren versteckt oder mit Michel aus Lönneberga im Schuppen geschnitzt. Vielleicht haben Sie ähnliche Erinnerungen und lächeln gerade, weil Sie daran denken? Dann geht es Ihnen wie mir. Und das alles durch Sprache. Sie als Führungskraft sollen eine Wirklichkeit schaffen. Sie haben eine Vorbildfunktion, spannen und geben einen Rahmen, haben eine Vision und motivieren Ihre Mitarbeiter. Sprache und Kommunikation können Ihnen dabei einen nicht unerheblichen Dienst erweisen. Es liegt in Ihrer Hand, Ihre Umgebung mitzugestalten und das nicht nur, aber definitiv auch über die Kommunikation. Was bedeutet das für Ihre tägliche Arbeit? Achten Sie ausreichend auf Ihre Kommunikation? Wie können Sie Sprache einsetzen, um eine produktivere Arbeitsumgebung zu schaffen?

Welche Wirklichkeit wollen Sie für sich und Ihre Mitarbeiter schaffen?

Wenn Sie frei wählen wollen, welche Kommunikation aus Ihnen heraus passiert, wenn Sie adressatengerecht und gezielt kommunizieren und Ihr Team auch über Kommunikation führen möchten, habe ich hier ein paar Tipps für Sie. Doch tragischerweise gilt wie bei so vielen Dingen: Beginnen Sie bei sich selbst. Gleichermaßen sind diese Hinweise auch auf Ihr Team anwendbar.

1. Sprache ins Bewusstsein holen durch Zuhören

Gönnen Sie sich den Spaß und beobachten Sie Ihre Kommunikation einen Tag lang. Wie oft sagen Sie wundervolle kleine Worte wie „man“, „eigentlich“, „ja, aber…“ oder verwenden den unverbindlichen Konjunktiv? Hören Sie also zu. Sich selbst und anderen. Denn das Tückische ist: Wir HÖREN diese Worte nicht mehr bewusst, und doch landen sie in unserem Bewusstsein und tun dort ihre Arbeit im Verborgenen. Zerren Sie sie wieder ans Licht, indem Sie darauf achten. Bitten Sie Ihre Mitmenschen, Sie auf die Nutzung dieser Worte anzusprechen, am besten direkt in der Situation, in denen es ihnen auffällt. Erst, wenn Sie sich Ihre Sprache ins Bewusstsein holen, können Sie an ihr etwas verändern. Wenn es Ihnen auffällt, halten Sie inne und korrigieren Sie sich selbst laut. So lernt Ihre Umwelt direkt etwas mit. Vielleicht machen Sie im Team direkt eine Tagesaufgabe daraus, um alle einzubeziehen? Zusammen mit anderen lernt es sich ja doch leichter und lustiger.

2. Bedürfnisse kennen – Was will Ihnen Ihre Kommunikation sagen?

Jeder Mensch handelt in jeder Situation für sich selbst sinnvoll. Und jede menschliche Handlung ist darauf ausgerichtet, ein Bedürfnis zu befriedigen, das in ihrem System eine Rolle spielt. An diesen Aussagen kommen Sie nicht vorbei, wenn Sie sich selbst reflektieren – was wiederum unvermeidlich ist, wenn Sie Ihre Kommunikation ins Bewusstsein holen und verändern möchten. Fragen Sie sich so oft wie möglich: „Welches Bedürfnis bediene ich gerade mit dieser Wortwahl? Welche Aussage steckt wirklich dahinter?“ Lassen Sie sich davon überraschen, was Sie dabei über sich selbst lernen werden. Können Sie eine bestimmte Sache nicht, oder wollen Sie das vielleicht gar nicht? Und wenn dem so ist, was heißt das für Sie, welche Konsequenzen hat das? „Das müsste man eigentlich mal machen …“ Nutzen Sie den Konjunktiv, weil Sie nicht alle Informationen haben, um sich zu committen? Nutzen Sie das „man“, um zu signalisieren, dass Sie es – aus welchen Gründen auch immer – auf keinen Fall machen wollen?

3. Fragen stellen

Eine Hauptaufgabe meines Berufs schätze ich sehr: Fragen stellen – ob nun mir selbst oder meinem Gegenüber in Coaching- oder Beratungssituationen. Manchmal reicht nur die eine richtige Frage zum richtigen Moment, ein „ja, aber“ löst sich in Luft auf und eine neue, nie dagewesene Betrachtungsweise liegt auf einmal auf dem Tisch. Eine der wirksamsten Fragen in meinem beruflichen Alltag ist für mich: „Was bräuchte es denn, um …“ Viele Menschen sind so schnell in einem negativen Kreisel von „Das geht nicht, weil“, dass selbst mir schwindlig wird. Ein „Was bräuchte es denn, um …“ bremst den Kreisel ab und man kann die Umgebung wieder wahrnehmen und neue Wege sehen. Diese Frage ist nicht nur für das Gegenüber toll, sondern auch für Sie selbst. Was bräuchte ich denn, um … zu wollen, zu können, den Mut zu haben,…? Was fehlt noch, um …? Wen bräuchte es, damit wir…? Was ist uns nach der Veränderung möglich? Ich könnte stundenlang weitermachen, wie Sie merken …

4. Üben, üben, üben

Versuchen Sie es mal, sagen Sie: „Ich kann das nicht.“ Halten Sie inne und sagen Sie dann: „Ich kann das noch nicht. Was bräuchte ich, um es zu lernen?“ Merken Sie den Unterschied? Alle Sätze, die Ihnen begegnen, können Sie umformulieren. Wichtig ist dabei meiner Ansicht nach, dass die neue Formulierung einen Raum für Möglichkeiten öffnet, Handlungsfähigkeit zurückgibt und beweglich macht. Frei nach dem Motto: Handle so, dass sich die Anzahl deiner Möglichkeiten vermehrt.
Worauf ich meine Aufmerksamkeit richte, davon bekomme ich mehr – so heißt es. Richten Sie also Ihre Aufmerksamkeit auf eine öffnende, positive, wertschätzende, Möglichkeiten aufzeigende Kommunikation und Sie werden mehr davon bekommen. Werden die Menschen um Sie herum zunächst vielleicht irritiert sein? Klar, das kann sehr gut sein. Und gleichzeitig geschieht dies dadurch, dass Sie das Kommunikationssystem Ihrer Mitmenschen irritieren und es darauf reagiert. Irritieren, Muster hinterfragen und verändern, Denk- und Lernprozesse in anderen Menschen anstoßen und mitgestalten … das ist alles möglich mit der entsprechenden Kommunikation. Und vor allem ist es notwendig für Veränderungen jeglicher Art.
Wollen Sie also in Ihrem Umfeld etwas verändern, schauen Sie sich Ihre eigene Kommunikation und die Ihrer Umgebung an. Und dann… fangen Sie an, entdecken Sie Ihre Sprache neu, nehmen Sie bewusst wahr und lernen Sie, sie einzusetzen.
Ich wünsche Ihnen viel Erfolg und auch Freude dabei. Wenn Sie Unterstützung benötigen, sagen Sie Bescheid, wir stellen dann gerne ein paar relevante Fragen.

Transition Teams – ein Praxisbericht

“Wir müssen agil werden” ist schnell gefordert – doch wie schafft man das? Das Agile Transition Team beschäftigt sich mit dieser Frage und entwickelt die passende Strategie. Wichtig dabei ist, dass auch das Transition Team nach agilen Prinzipien, zum Beispiel nach jenen von Scrum, arbeitet.
Christoph Schmiedinger erklärt in diesem Video, wie das in unserer Praxis abläuft.

Commitment

Join me for my how-to video, in which I explain the basics of commitment. Why is it essential to define a goal, which we want to achieve as a team? And how will a voluntary mutual agreement affect the team dynamic? 
Find out by watching my video! 

Die Tücken des Freizeit-Scrum

Mit der Einführung von Scrum sind verschiedene Hoffnungen verbunden. Genauso häufig werden jedoch fatale Fehler begangen, die Projekte scheitern lassen. Eine typische Problematik ist Teilzeit-Scrum: Teams arbeiten mit minimalem Fokus am Projekt, oft gerade mal an einem Arbeitstag pro Woche.

Schmalspur-Kapazitäten vs. High-Performance-Erwartungen

Trotzdem wird erwartet, dass alle Vorteile des Frameworks zum Tragen kommen – das geht in einer solchen Konstellation leider nur begrenzt. Teams stöhnen über die Last der Mehrarbeit, es gibt De-Commitments, und im Gesamten haben alle weniger Lust zum Arbeiten als vorher. Der Grund liegt in den Transitionskosten des Multiprojektmanagements.
Versuchen Sie einmal ein kleines Experiment: Das Ziel ist es, in möglichst kurzer Zeit 3 x 10 Zeichen (I-X, A-J, 1-10) auf ein Blatt Papier zu schreiben. Sie nehmen dafür 3 unterschiedliche Stifte und 3 Blatt DIN-A4-Papier zur Hand (diese liegen untereinander)
Variante I: Sie nehmen den ersten Stift, schreiben den Buchstaben „A“, legen den Stift weg, schieben das Blatt unter den Stapel, nehmen den zweiten Stift, schreiben „I“ auf das zweite Blatt, legen den Stift weg, schieben das Blatt unter den Stapel usw. – so lange bis Sie die drei Zeichenfolgen notiert haben.
Variante II: Sie nehmen das erste Blatt, notieren die Buchstaben A-J, nehmen das zweite Blatt, notieren die Zahlen I-X usw.
Bei welcher Variante haben Sie weniger Zeit benötigt?
Der ständige Wechsel zwischen verschiedenen Kontexten benötigt Zeit und schmälert die Leistungsfähigkeit enorm. Die Aufmerksamkeitskurve beim Taskswitching gleicht einer Sinuskurve – immer wieder braucht es Energie, sich in einen neuen Kontext einzufinden. Diese Beobachtung haben Sie vielleicht auch schon bei der kleinen Simulation gemacht.
Und so ist das auch bei Teilzeit-Scrum: Das Aufteilen von Teammitgliedern auf mehrere Projekte zerstört das enorm fokussierte Umfeld, das Scrum mit seinen Events schafft.

Tun Sie als Manager das, was keiner erwartet: Stellen Sie Ihre Teams vollständig frei

Wie entkommt man dem Dilemma? Die einfachste und zugleich herausfordernde Antwort lautet: Stellen Sie die Teams von anderen Projekten frei. 100 Prozent Kapazität für ein Projekt.
Das mag absurd klingen, doch so schöpfen Sie wirklich alle Vorteile der Agilität aus. Viele Manager – ob Weltkonzern oder KMU – haben eine sehr ähnliche Erfahrung gemacht. Freigespielte Mitarbeiter liefern praktisch dreifach Mehrwert:

Dieser Ansatz verlangt Mut, aber es lohnt sich. Sollten Sie nicht die Möglichkeit haben, solche Maßnahmen zu setzen, hilft häufig ein anderer Blickwinkel.
Folgende Gedankenlinie kann Ihnen dabei helfen, Ihre persönlichen Schritte zur Veränderung zu identifizieren:

Sollten Sie beim Nachdenken über diese Fragen ins Grübeln kommen: Viele haben es schon vor Ihnen getan. Unsere Beobachtung ist dabei, dass die Lösung sehr häufig individuell gefunden werden muss. Die Chancen, dass Kollegen über die gleichen Baustellen stolpern wie Sie, nehmen jedoch zu. Teilen Sie gerne Ihre Erfahrungen und Sichtweisen. Vielleicht hat jemand bereits ein funktionierendes Rezept dafür entwickelt.

Foto: CC0 Creative Commons – pixabay, geralt

Agile Banking – Impediments

Wo muss beim Agile bzw. Digital Banking eigentlich die IT aufgehängt sein? Auf keinen Fall ist es ein nebensächlicher Kostenblock, der einfach in irgendeinen beliebigen Bereich geschoben werden kann, denn: Banken werden in Zukunft Tech-Companies sein. Das Bewusstsein dafür muss ganz oben vorhanden sein, beim Topmanagement. Über diese Frage spreche ich mit Christoph Schmiedinger in diesem Video.

Agile Senioren? Auf jeden Fall!

Normalerweise sind unsere Kunden große Banken, Automobilhersteller oder andere Wirtschaftsunternehmen. Seit 2017 sind wir aber auch in einem ganz anderen Bereich unterwegs: in einem Seniorenwohnstift, genauer gesagt dem Georg-Brauchle-Haus in München. Das klingt ungewöhnlich? Auf jeden Fall! Es zeigt aber auch: Das Prinzip Agilität kann beinahe in jedem Bereich angewandt werden – mit hohem Nutzen und Erfolg für die Beteiligten.
Wie viele Pflegeeinrichtungen stand das Georg-Brauchle-Haus vor großen Herausforderungen: Neben Fachkräftemangel kämpfte das Wohnstift auch mit hohem Kosten- und Zeitdruck. 2014 entschloss sich die Direktorin Verena Wolf-Dietrich daher, die Projektmanagement- und Kommunikationsprozesse umzustrukturieren. Wir halfen ihr dabei, passende Elemente agiler Arbeitsmethoden und eine neue Feedbackkultur zu implementieren.

Von „jeder für sich“…

Im KWA Georg-Brauchle-Haus in München leben rund 230 Bewohner; davon werden im Schnitt 120 Bewohner durch den hauseigenen ambulanten Dienst versorgt. Über 120 Mitarbeiter in den Abteilungen ambulante Pflege, Betreuung, Küche, Hauswirtschaft, Rezeption, Kundenbetreuung und Verwaltung müssen im Schichtbetrieb koordiniert zusammenarbeiten, um die Versorgung der Senioren zu gewährleisten. Als Verena Wolf-Dietrich im Oktober 2014 die Hausleitung übernahm, identifizierte sie Defizite in der internen Kommunikation. Ein Beispiel: Gibt es einen neuen Bewohner, müssen alle beteiligten Abteilungen effizient kommunizieren. Die Haustechnik wird über speziell benötigte Einrichtungen informiert, die Küche bekommt Informationen zu Unverträglichkeiten, die Hauswirtschaft klärt, welche Leistungen übernommen werden und die Pflegekräfte erfahren alles über die medizinische Historie des Bewohners. Fehlen diese Informationen oder kommen sie zu spät, erlebt der Bewohner einen holprigen Einzug. Wolf-Dietrichs Schlussfolgerung: Ein optimales Versorgungsniveau erreicht das Georg-Brauchle-Haus nur mit einer effizienteren Kommunikationsstruktur.

… hin zu „alle an einem Strang“

Neben der besseren Versorgung der Bewohner war es das Ziel der Maßnahmen, die Bewertungen durch den MDK (Medizinischer Dienst des Spitzenverbandes Bund der Krankenkassen) und die Heimaufsicht weiter zu verbessern. Nicht zu unterschätzen ist zudem das Empfehlungsmarketing: je zufriedener die Bewohner, desto häufiger würden sie sie Einrichtung weiterempfehlen.

Mit Scrum die Potentiale entdecken

Gemeinsam mit borisgloger consulting entschied sich Verena Wolf-Dietrich, Elemente aus Scrum als Framework für die Neustrukturierung zu nutzen. Denn mittlerweile hat sich die Managementmethode längst über die Grenzen der Softwareentwicklung hinaus etabliert. Dank klarer Rollen, regelmäßigem Feedback und schlanker Prozesse hilft sie auch im Seniorenwohnstift bei einer besseren und effizienteren Zusammenarbeit und besserer Selbstorganisation der Teammitglieder. Denn die Mitarbeiter werden dabei nicht nur als bloße Ressource angesehen, sondern fördern das Potential jedes einzelnen.

So funktioniert’s

Das Führungsteam, bestehend aus einem Vertreter der Abteilungen Pflege, Hauswirtschaft, Kundenbetreuung, Verwaltung und Haustechnik sowie der Stiftsdirektorin Verena Wolf-Dietrich, führte einige der wichtigsten Scrum-Prinzipien ein: Anstatt langwieriger, ineffizienter Besprechungen, die bis dahin jede Woche abgehalten wurden, planten sie nun „Dailys“ und „Quarterlys“ ein. Bei den viertelstündigen, täglichen Meetings, die im Stehen abgehalten werden, reden alle Beteiligten über akute Themen im Betrieb – besonders im Schichtdienst eine gute Möglichkeit, immer auf dem neuesten Stand zu bleiben. Beispielsweise ist der Leerstand von Wohnräumen für den Wohnstift eine sehr teure Situation. Durch die Dailys kann der Neubezug der Wohnungen viel schneller und besser organisiert und durchgeführt werden. Bei den alle drei Monate durchgeführten „Quarterlys“ werden dagegen größere Projekte und Probleme diskutiert und Feedback gesammelt.
Auch die Dokumentation und Visualisierung der Besprechungsergebnisse wurde grundlegend und auf Scrum basierend verändert: Anstatt lange Protokolle zu schreiben, wird im Besprechungsraum ein Taskboard aufgestellt. Darauf hält das Team den aktuellen Stand aller Projekte für alle sichtbar fest. Die Spalten des Taskboards werden in „Was?“, „Wie?“ und „Wer?“ eingeteilt, die einzelnen Aufgaben auf Zettel geschrieben und entsprechend am Board befestigt. Ein Foto des Boards nach jeder Sitzung ersetzt das Protokoll. Diese einfache, aber sehr praktische Methode motiviert die Mitarbeiter zudem dazu, mehr eigene Ideen einzubringen und umzusetzen.

Win-Win-Win-Situation für Management, Angestellte und Heimbewohner

Die Einführung der Scrum-Methoden hat zu einer reibungsloseren und effizienteren Organisation des Wohnstifts geführt – eine Win-Win-Situation für alle Beteiligten! Bei einer Einrichtung, in der so unterschiedliche Abteilungen von Pflege über Küche bis hin zur Verwaltung unter einen Hut gebracht werden müssen, ist das eine beträchtliche Leistung. Auch die Stimmung unter den Mitarbeitern und Bewohnern konnte entscheidend verbessert werden, viele Bewohner empfehlen die Einrichtung weiter. Großer Anlass zur Freude waren zudem die Verbesserungen der MDK-Bewertungen und Heimaufsichtsnoten, die die Ergebnisse der Umstrukturierung schwarz auf weiß verdeutlichten. Doch auch wirtschaftlich kann der Erfolg belegt werden: Seit der Einführung der agilen Maßnahmen im Jahr 2014 verzeichnet das Georg-Brauchle-Haus in München eine jährliche Umsatzsteigerung von zehn Prozent – eine Win-Win-Win-Situation für Management, Angestellte und Heimbewohner!

Foto: CC0 Creative Commons – pixabay, sabinevanerp

Video: Digital Avengers – So stellen Sie Ihr schlagkräftiges Superhelden-Team zusammen

Im Call for Papers der „Agile Digital Transformation“ inspirierte mich die Frage nach dem geeigneten Team, mit dem man die Herausforderungen der Digitalisierung meistern kann. Ich machte mich auf die Suche nach einem passenden Hollywood-Teams als Metapher und stieß schließlich auf die Superhelden-Truppe der Avengers. Nicht nur konnte ich sofort einige Parallelen zu performenden Teams entdecken, die Verknüpfung passte auch zum Start des neuen Avengers-Streifen im Kino. Also, Welt aus, Film an und beide Teile der Avengers-Streifen geguckt, um nach den Parallelen und Mustern zwischen den Superhelden und Hochleistungsteams zu suchen. Herausgekommen ist ein unterhaltsamer Vortrag, der sich einerseits damit beschäftigt,

Die Slides zu diesem Vortrag findet ihr unter diesem Link
Viel Spaß beim Nachschauen!

Video: 6 Erfolgsfaktoren der Digitalisierung

Während der Begleitung diverser agiler und digitaler Transformationen habe ich mich immer wieder gefragt, was denn die zentralen Erfolgsfaktoren in einem solchen Wandel sind? Beim Vergleich verschiedener Unternehmen ist mir dabei aufgefallen, dass einzelne Faktoren in bestimmten Unternehmen absolut vorbildlich umgesetzt und andere wiederum komplett außer Acht gelassen wurden.
So hat beispielsweise Unternehmen A bei den Rahmenbedingungen alles richtig gemacht – neue Organisationsstruktur, neue Räumlichkeiten und eine Verschlankung der Hierarchie und Bürokratie. Parallel dazu wurden dringend benötigte Experten mit Wissen zu Data Analytics eingestellt. Doch leider krankt es am modernen Führungsverständnis: Die Führungskräfte sehen sich weiter als Verwalter der jeweiligen (wenn auch neu geschnittenen) Einheiten. Unternehmen B hingegen hat es mit einem ambitionierten Kulturwandel geschafft, neue Führungskräfte zu bestellen, deren Augen bei der Vorstellung ihres jeweiligen Vorhabens zu leuchten beginnen. Gepaart mit einer intensiven Auseinandersetzung mit den Bedürfnissen des Kunden, scheint der Weg zur digitalen Transformation vorbereitet zu sein. Doch leider krankt es an einer zu strikten Governance, die viel zu früh viel zu viele Information zu den diversen Vorhaben fordert und somit große Steine in den Weg legt.
Ich habe mich immer wieder gefragt, was passiert, wenn alle diese zentralen Erfolgsfaktoren in einem Unternehmen berücksichtigt werden würden. Ist der Weg des Wandels damit geebnet? Ist es, wie im Englischen so schön bezeichnet, ein einfacher „cakewalk“? Auch wenn ich diese Frage noch nicht final beantworten konnte, so habe ich trotzdem die wichtigsten Erfolgsfaktoren zur Digitalisierung in einen Vortrag gepackt und hoffe, damit einen Überblick über die Themenbereiche gegeben zu haben, an denen während des Wandels gearbeitet werden muss.

Skalierte agile Organisation: Das übergreifende Arbeitsmodell als Führungsinstrument

Im klassischen Führungsparadigma soll eine Führungskraft vermitteln, was wie zu tun ist, um ein definiertes Ziel zu erreichen. Damit verbunden ist die Kontrolle: Erledigen meine Mitarbeiter die vorgegebenen Aufgaben? Demgegenüber liegt dem agilen Führungsverständnis die Annahme zugrunde, dass sich die Organisation automatisch in die „richtige“ Richtung bewegen wird, wenn das Management durch den Sinn – die Vision, das „Warum“ – eine grobe Richtung vermittelt und die Rahmenbedingungen (die Constraints) vorgibt.
Obwohl die Forderung nach einer Vision banal klingt, haben Unternehmenslenker große Mühe, sich auf dieses neue Führungsverständnis einzulassen. Bereits die Definition einer Vision ist eine Herausforderung. Die Frage, weshalb das „Warum“ so wichtig ist (allen voran Simon Sinek) und wie eine Vision entsteht („Geheimnisse einer wirklich guten Vision“) wurde in den entsprechenden Diskussionen hinlänglich bearbeitet. Anders sieht es beim Setzen der Rahmenbedingungen aus: Wie gelingt es dem Management, einen Rahmen vorzugeben, innerhalb dessen die Organisation die Lieferfähigkeit erhöhen und gleichzeitig ein hohes Maß an Transparenz schaffen kann?
Die erste Hürde ist, sich von einem nach wie vor weit verbreiteten Irrglauben zu verabschieden: Agilität bedeutet nicht, Teams ohne Kontrolle und Vorgaben einfach machen zu lassen, in der Hoffnung, es werde schon etwas Gutes dabei herauskommen (Video: Agilität – das Managen von Unsicherheiten). Sicherlich gibt es hoch performante agile Teams, bei denen es genügt, eine Vision zu kommunizieren. Gerade beim Change in einer klassischen Organisation ist es jedoch umso wichtiger, neben einer griffigen Vision auch klare Rahmenbedingungen zu definieren. Demnach bedeutet Agilität nicht, die Freiheit zu haben alles zu tun, sondern vielmehr, die Freiheit zu haben, sich innerhalb der gesetzten Rahmenbedingungen in Bezug auf die Vision selbst zu organisieren.
Der Entwurf eines Arbeitsmodells ist ein bewährtes Mittel, um Teams in die Selbstorganisation zu führen.

Was ist ein Arbeitsmodell?

Ein Arbeitsmodell an sich ist nicht mehr als die Beschreibung der in einem Unternehmen gelebten Scrum-Rollen, -Meetings und -Artefakte. Scrum selbst gibt diese zwar vor, jedes Unternehmen lebt die Rollen, deren Skalierung, die Meetings und Artefakte allerdings anders. Meetings finden in unterschiedlichen Taktungen mit unterschiedlichen Teilnehmerkreisen und Formaten statt. Während in dem einen Unternehmen als Artefakt lediglich ein Taskboard existiert, schwören andere Unternehmen auf einen Releaseplan und ein übergreifendes Unternehmensbacklog, während andere pflichtbewusst alle Artefakte anwenden, die Scrum definiert.
Ein übergreifendes Arbeitsmodell ist die Sammlung und Konsolidierung der bestehenden Rollen, Meetings und Artefakte, um daraus Best Practices abzuleiten. Das Arbeitsmodell ist ein lebendes und somit lernendes Artefakt, das veränder- und anpassbar ist und auf neue Erkenntnisse im Sinne einer verbesserten Zusammenarbeit reagiert und diese abbildet.
Unsere Erfahrung ist, dass idealerweise ein Scrum-of-ScrumMaster die Verantwortung für die Erstellung des Arbeitsmodells übernimmt. Er erhält durch die Arbeitsmodelle der einzelnen Teams, die von seinen ScrumMastern erstellt werden, einen Einblick in die Arbeitsweise der Teams und ist somit in der Lage, daraus ein übergeordnetes Arbeitsmodell zu erstellen.

Wozu dient das Arbeitsmodell?

Das Arbeitsmodell unterstützt dabei, Transparenz, Einheitlichkeit und eine Meetingkultur zu schaffen sowie den Prozessframework kontinuierlich zu optimieren.

Gleichzeitig ist das Arbeitsmodell ein lebendes Dokument, das auf Veränderungen und neue Erkenntnisse in der Arbeitsorganisation reagieren kann und diese abbildet. Es dient den ScrumMastern zur Reflexion und ist somit selbst Gegenstand der kontinuierlichen Verbesserung.
Das Arbeitsmodell kann also zu einem wichtigen Instrument des Change werden, indem es Orientierung gibt und die übergreifende Zusammenarbeit der ScrumMaster fördert. Es bietet eine Alternative zu Hierarchien, da es dem Unternehmen eine Arbeitsorganisation auf Teamebene anbietet, die nicht auf der Ableitung von Führungsebenen beruht.
Im Idealfall erzeugt ein Arbeitsmodell einen Rhythmus, der das iterative Arbeiten unterstützt und eine Art Taktung für das Unternehmen erzeugt.

Foto: CC0 Creative Commons – pixabay, Michael Gaida

Scrum and multi-disciplinary teams

In this edition of my video series, I explain the need to use multidisciplinary teams in Scrum, rather than cross-functional. Teams should consist of members from all business areas to develop a fully functional solution.  
Join me in my video to find out why using multi-disciplinary teams is critical. 

Was agiles Testen nicht ist und was es ist

In meinen Projekten höre ich oft Sätze wie „Unser Testing-Team macht auch Scrum, also machen wir agiles Testen“ oder „Wir testen in den Sprints, also machen wir agiles Testen. Und vor dem Release gibt es noch einen Testing-Sprint für die Integrationstests“ oder „Wir testen sprintversetzt – was in einem Sprint entwickelt wurde, testen wir im nächsten“ usw.
Solche und noch viel mehr ähnliche Sätze zeigen mir, wie sehr „agiles Testen“ missverstanden wird. Alle erwähnten Aussagen zeigen mir nur: Es wird weiterhin nach dem Wasserfall entwickelt – nur in kürzeren Iterationen, mehr nicht. Kein agiles Entwickeln und schon gar nicht agiles Testen. Denn was ist „agil“ per Definition?

„Lieferung funktionierender Software in kurzen Iterationen und in Inkrementen.“

Wie aber soll man sicherstellen, dass die Software funktioniert, wenn sie nicht innerhalb einer Iteration getestet wird? Und zwar komplett. Nicht nur ein bisschen, ohne Integrationstests am Ende des Releases, ohne sprintversetzte Tests, sondern alles findet im Sprint statt, sodass am Ende des Sprints ein Stück Software potenziell an den Kunden geliefert werden kann.

Was unterscheidet agiles Testen noch vom klassischen Testen?

Wir wissen, dass das ganze Entwicklungsteam für die Qualität des Produkts verantwortlich ist. Wenn nur die Tester testen, kann von gemeinsamer Verantwortung nicht die Rede sein. Natürlich braucht es weiterhin die Tester im Team. Sie bringen wertvolles Know-how mit, auf das nicht verzichtet werden kann. Dennoch können und sollten alle Teammitglieder ihren Beitrag zur Qualität des Produkts leisten, zum Beispiel so:

Mit anderen Worten: Agiles Testen ist die Gesamtsumme aller Tätigkeiten, die dafür sorgen, dass am Ende jedes Sprints die gelieferten Funktionalitäten funktionieren und vom Kunden potenziell sofort genutzt werden können.

Foto: CC0 Creative Commons, testbytes – pixabay

What is Scrum?

In this episode of “The Agile How-To”, we explore the basics of Scrum and where it originated around 20 years ago. To the contrary of what most people believe, Scrum is not a project management methodology! Scrum is more like a mindset. It is a framework which embraces the ideas behind being agile –to deliver fast results that meet the user’s needs.   
 Join me in my video journey, where I explain the basics of Scrum.

Die drei Säulen des Digital Bankings

Wir bauen ein schönes, modernes Frontend und dann können wir es schon aufnehmen mit den Fintechs? Zum Banking der Zukunft gehört dann doch etwas mehr als nur eine hübsche Oberfläche und ein wenig Scrum. Digital Banking braucht moderne Architekturen wie Microservices und eine flexible Infrastruktur.
Christoph Schmiedinger erzählt mehr über das Gesamtpaket, das Banking wirklich “digital” macht.

Video: Banken werden zu Tech Companies

Die Zielgruppen von Banken werden jünger – und anspruchsvoller. Die nachrückenden Kundengenerationen sind mit den neuen Technologien aufgewachsen und verlangen mehr von Online-Services als nur die klassische Überweisung, das reicht von der Vermögensverwaltung bis zum Kreditabschluss. Fintechs haben das erkannt und liefern Lösungen, die Bankgeschäfte einfacher und angenehmer machen. Und: Sie sind jünger und haben daher nicht mit den Schwierigkeiten von Legacy Systemen zu kämpfen.
Um aufzuholen brauchen Banken also nicht nur agile Arbeitsweisen, sondern auch neue Technologien, Architekturen und Geschäftsmodelle. Mehr dazu von unserem Banking-Spezialisten Christoph Schmiedinger.

Das Impediment Board aus Sicht des Managers

Habt ihr euch als Manager schon mal gefragt, was der Nutzen eines Impediment Boards ist? Ein Impediment Board visualisiert Hindernisse, die euch oder eure Teams daran hindern, zu liefern. Das Board sollte möglichst öffentlich und für alle einfach einsehbar sein. Ideal ist daher ein haptisches Board, also eines zum Angreifen. Das stellt sicher, dass Probleme sichtbar bleiben, bis sie gelöst sind. Aber wie kann man sich so ein Impediment Board vorstellen? Die einfachste Variante sieht aus wie ein Taskboard. Es besteht von links nach rechts betrachtet aus drei Spalten: „Zu erledigen“, „In Bearbeitung“ und „Fertig“. Bei Bedarf kann ganz links noch eine Spalte mit „identifizierten Problemen“ hinzugefügt werden. Dort werden Hindernisse gesammelt, die entdeckt wurden und deren Beseitigung noch nicht vereinbart ist. Auch hier ist es sinnvoll, zu priorisieren.

Ziel ist, zu jedem Zeitpunkt einen Überblick darüber zu haben, wie weit die Beseitigung aktueller Probleme fortgeschritten ist. Das schafft

Das negative Gegenbeispiel wäre eine „Vorschlags-/Verbesserungsbox“, die sich „jemand“ von Zeit zu Zeit ansieht, und bei der unklar bleibt, ob und wann ein Problem angegangen wird. Das kann zu komplettem Frust und völliger Verweigerung führen („Hier ändert sich eh nie etwas“ oder „Mir hört ja eh keiner zu“).
Die Visualisierung kann euch helfen, Stück für Stück bessere Rahmenbedingungen zu schaffen – ganz genau das ist die Aufgabe des Managers. Der Aufwand, um das Board aufzubauen, ist sehr überschaubar; die einzige Voraussetzung ist, dass ihr wirklich an den hochkochenden Problemen arbeiten und sie lösen wollt. Das ist nicht immer selbstverständlich.
Man kann das Board dann noch beliebig ausbauen: Zum Beispiel mit einer Definition von „Problem gelöst“, mit einfachsten Kennzahlen, mit einer Einladung zur Beteiligung von Mitarbeitern/Kollegen, unterschiedlichen (Auswirkungs-)Klassen etc. Empfehlenswert ist jedoch, einfach anzufangen und bei Bedarf und stückweise Veränderungen am Board vorzunehmen.
Ihr seht, das Impediment Board ist ein ganz simples Hilfsmittel für die konsequente Beseitigung von Hindernissen. Probiert es aus! Wir freuen uns, wenn ihr eure Erfahrungen mit uns teilt.

Dieser Beitrag ist im Pair Writing mit Faruk Ince entstanden.

Scrum: Einfach nur die nächste Sau?

„Scrum ist doch bloß wieder die nächste Sau, die durchs Dorf getrieben wird.“ Das war in etwa der Wortlaut eines Teilnehmers meines Scrum-Workshops. Stimmt das am Ende? Ist Scrum nur ein Hype? Oder sind die zugrundeliegenden Konzepte vielleicht seit Jahrzehnten erprobt?
Die Basis von Scrum ist das iterative Liefern von Produkt-Inkrementen. Ein Blick in die Geschichte zeigt: Das Konzept von Versuch und Irrtum ist alles andere als neu. Bereits in den 1930er-Jahren entwickelt der Physiker und Ingenieur Walter Shewhart in den Bell Labs, aus denen später AT&T hervorgeht, eine Methode für die iterative Produktentwicklung. Er nennt diese Methode „Plan Do Study Act“. Sein Kollege William Edwards Deming entwickelt die Methode weiter. Populär wird dieses iterative Vorgehen in der weiteren Folge unter dem Begriff „Deming-Cycle“. 1993 übernimmt Jeff Sutherland die Entwicklungsleitung bei Easel Corp. Die Herausforderung besteht darin, ein neues Produkt innerhalb von sechs Monaten auf den Markt zu bringen. Sutherland sucht nach Lösungsansätzen, die ihm bei diesem Unterfangen helfen können. Das Ergebnis: Einige wenige Meetings, die den Deming-Cycle in wiederkehrenden Iterationen abdecken und der Ansatz, Feedback zum Produkt auf Basis fertiger und nutzbarer Teillieferungen einzuholen.
2018 wird das Konzept hinter Scrum bereits 25 Jahre alt. In unzähligen Projekten und ganzen Unternehmen ist es zum Standard-Vorgehen in der Produktentwicklung geworden. Kein Wunder. Die Markteintrittsfenster für neue Produkte werden zunehmend kleiner und der Innovationsdruck auf die Unternehmen steigt und steigt. Scrum und andere agile Methoden versprechen die Lösung – nicht immer mit Erfolg. Denn häufig wird nur die Meeting-Mechanik umgesetzt, ohne jedoch die zugrundeliegenden Konzepte zu beherzigen.
Ist Scrum nun also die nächste Sau, die durchs Unternehmensdorf gejagt wird? Was denkt ihr? Ich bin gespannt auf eure Antworten.

Veränderungen – eine Frage von dürfen, wollen und können

Als ich in den letzten Wochen in Gesprächen von meinem Job erzählte, drehten sich irgendwann alle um das Thema Veränderungen im Allgemeinen und Übernahme von Verantwortung im Speziellen. Es fielen die typischen Sätze wie „Das geht bei uns aber nicht“, „Meine Leute kriegen das nicht hin“, „Das ist echt so anstrengend“ oder auch „Ist es das denn wert? Geht doch auch so“.
Tut es das? Aus dem systemischen Coaching mag ich folgende Frage sehr: „Was passiert, wenn nichts passiert?“ Wenn wir aufhören, uns zu verändern. Geht das überhaupt? Und wie geht das eigentlich genau mit der Veränderung – kann man das lernen? Meine bisherigen Erfahrungen zeigen, dass es dabei nicht um die Methode – zum Beispiel um Scrum oder Kanban – geht. Die Prozesse sind klar, sind erprobt und funktionieren. Ist es also der menschliche Faktor, der Veränderungen ermöglichen oder verhindern kann?
Im agilen Kontext werden drei Faktoren beschrieben, die in meinen Augen nicht nur auf Mitarbeiter, sondern auch wunderbar auf „den Menschen in Gänze“ anwendbar sind: Dürfen. Wollen. Können.

Diese drei Faktoren bedingen sich gegenseitig. Wenn der Mensch nicht will, bringt es nichts, wenn er könnte oder sogar darf. Wenn er nicht darf, bringt es nur Frust, wenn er wollte und könnte. By the way: Natürlich muss man längst nicht alles wollen, was man kann.
In lang gelebten und erlernten Strukturen ist womöglich jedoch die Erlaubnis „von oben“, aus der Chefetage heraus, eine der Voraussetzungen für die Umsetzung von Veränderungen beim einzelnen Mitarbeiter. Denn: das Wollen kann über das Dürfen gefördert werden, davon bin ich überzeugt. Erst langsam und zaghaft, ähnlich einem scheuen Wesen, das noch nicht weiß, welche Gefahren vielleicht in dem Raum lauern, der sich da plötzlich auftut. Ich durfte mehrfach erleben, wie sehr Mitarbeiter aufblühen, wenn sie sich ausprobieren und Verantwortung übernehmen dürfen, ohne Angst vor etwaigen Folgen haben zu müssen, wenn etwas schiefgeht. Das ist für eine Führungskraft ein tolles Erlebnis.
Was bräuchte es dafür also konkret?

Dürfen

Es braucht Führungskräfte, die sich selbst hinterfragen und hinterfragen lassen. Die ihre Mitarbeiter nicht als Erfüllungsgehilfen für den nächsten Bonus sehen, sondern als Mitstreiter an ihrer Seite auf dem Weg zum zufriedenen Kunden, einem erfolgreichen Projekt oder Produkt. Ein Mensch, der anderen Menschen etwas zutraut und ihnen erlaubt, selbst zu denken und zu handeln.
Jemand, der Vertrauen in sich selbst und seine Mitstreiter hat und loslassen kann. Eine Chefetage, die Fehler erlaubt und sie sogar begrüßt, denn durch Fehler generiert man im Mindesten neues Wissen, wenn nicht sogar neue Ideen und Produkte. Eine Führungskraft, die ihre Mitarbeiter und deren Erfolge feiert und wahrnimmt. Die ein positives Menschenbild hat und bereit ist, Wissen zu teilen, Fehler zu verzeihen, Mut zu fördern und Rahmenbedingungen zu schaffen, in denen all dies möglich sein kann.
Aber: Führungskräfte sind tatsächlich auch nur Menschen, die den gleichen inneren und äußeren Herausforderungen gegenüberstehen wie jeder andere auch. Das vergessen wir nur manchmal gern und erwarten, dass sie alles sofort richtig machen. Auch für sie sollte also gelten: Fehlermachen ist erlaubt und gewünscht.

Wollen

Wenn die Führungsebene die ehrlich gemeinte Einladung zur Veränderung ausspricht, dann braucht es den Willen der Mitarbeiter, diese Einladung auch anzunehmen. Auch hier sind Selbstreflexion, Veränderungsbereitschaft und Mut nötig. Es hilft immens, wenn die Mitarbeiter sich selbst, ihre Kompetenzen und Fähigkeiten kennen oder kennenlernen wollen. Sich selbst Fehler zu erlauben, ist manchmal gar nicht so einfach. Aber mit der Zeit kann man das lernen. Mitarbeiter sollten neugierig sein und Lust haben, Dinge auszuprobieren. Auch sie sollten bereit sein, ihr Menschenbild zu überprüfen und den Führungskräften die Chance und Zeit zur Veränderung geben. Das bedeutet also nicht nur Nachsicht mit sich selbst bei Rückschlägen, sondern auch mit den Kolleginnen und Kollegen aus anderen Abteilungen und/oder Hierarchien.

Können

Der Faktor des Könnens ist wohl derjenige, der am ehesten über Trainings, Weiterbildungen und Kompetenzentwicklung veränderbar ist. Hier kann und darf die HR-Abteilung zeigen, was sie draufhat und die Mitarbeiter in ein neues miteinander Arbeiten begleiten. Fachliches Know-how über Veränderungsprozesse und verschiedene Methoden, Coachings durch die Führungskraft oder einen „agile Coach“, das Schaffen von Räumen und Rahmenbedingungen, um die neuen Erkenntnisse zu testen, sind hier nur einige Dinge, die es braucht, um die Kunst der Veränderung zu lernen. Neben der Unterstützung durch HR und andere Formate müssen Mitarbeiter und Führungskräfte sich jedoch auch selbst um ihre Weiterbildung kümmern wollen.
„Eine schlechte Angewohnheit kann man nicht einfach aus dem Fenster schmeißen. Man muss sie Stufe für Stufe aus dem Haus begleiten“, habe ich irgendwo gelesen. Und ich kann aus eigener Erfahrung sagen: Die wehren sich. Die einen mehr, die anderen weniger. Aber alle tun es. Es dauert, macht definitiv nicht nur Spaß, kann und darf zwischendurch wehtun. Vielleicht wie bei einem Training für einen Marathon? Aber: Es darf Spaß machen und manche Angewohnheiten hüpfen die Treppen freiwillig runter, sobald Sie sich die Erlaubnis gegeben haben, die Tür aufzumachen. Und gegen den Schmerz helfen die kleinen Erfolge, die sich recht schnell einstellen.
Klar ist: Es erfordert großen Mut von allen Beteiligten, sich auf dieses Wagnis der Veränderung einzulassen. Einen Vorschuss an Vertrauen und das Verlernen der gemeinsamen Vorgeschichte sowie der Denkweisen, an die man sich so schön gewöhnt hat. Das Unbekannte und Neue macht erstmal Unsicherheit und Angst. Und das geht allen so, egal, ob Sie Chef sind oder nicht.
Ich wünsche Ihnen viel Erfolg, Durchhaltevermögen und auch Spaß daran und ziehe meinen Hut vor allen, die allein schon darüber nachdenken, sich auf diesen Weg zu machen.

Strategie und Wettervorhersage: der Wunsch nach der Einschränkung von Möglichkeiten

Erst neulich saß ich abends mit dem Manager eines Kunden zusammen, um ein Managementmeeting vorzubereiten. Er ist wohl einer der innovativsten Köpfe seines Unternehmens, agil im Handeln und Mindset. Klar in der Kommunikation, gewitzt im Manövrieren durch die im Umbruch befindlichen Hierarchien und Schwärme seines Konzerns. Als wir über Strategie sprechen, erzählt er mir begeistert von seinem Chef. Der würde mit einer klaren Strategie und überzeugenden Ansagen genau zeigen, wo es langgehe. Für mich hörte sich das im ersten Schritt wie ein Widerhall aus der Vergangenheit an.
Die Strategie im Sinne einer strategischen Planung ist hier am Werk. Strategie, Handlungsfelder, Aktionen, geplante Ergebnisse, Ziele, Zeitleisten und Fortschrittsmonitoring. Kurz denke ich mir: „Huch, was ist denn hier los? Wie passen Mindset und Handeln meines Gegenübers mit seiner Affinität zu dieser Form und Denke von Strategie zusammen?“ Nun, ich musste nicht lange warten. Die Antwort kam postwendend: „Da gibt es Klarheit und Richtung. Mag ich das, wie das daherkommt? Nicht immer. Aber das, was es tut schon. Wir haben Richtung und die Dinge entwickeln sich. Trotz der unsicheren und sehr veränderlichen Umwelt.“  Und das sei, so meinte mein Gegenüber, auch notwendig. Es sei besser als so manch andere, vage und nur „highlevel“ dargestellten Strategieansätze, die er jüngst in anderen Kontexten kennengelernt habe. Dann wendete er sich an mich: „Du hast mir die Frage nach der Strategie gestellt. Ganz ehrlich. Eigentlich müsstest Du uns sagen, wie es geht. Was eine Strategie braucht.“

Strategiearbeit: Die Suche nach Sicherheit

Dieses Gespräch geht mir nach. Erst jüngst hatte ich einen Strategieprozess entlang des Golden Circle von Simon Sinek geführt, einen reflexiven Diskurs über die Gesamtorganisation meines Kunden. Ein Strategieteam aus Freiwilligen hatte die Vorarbeiten gemacht und war mit Denkanstößen und Fragestellungen in die Organisation gegangen. Zuerst hatten wir uns die umgebende Rahmenstrategie auf Unternehmens- bzw. Divisionsebene angesehen. Dann haben wir unser „WHY“ erarbeitet, das „HOW“ beleuchtet und zum Schluss im „WHAT“ die Handlungsfelder herausgearbeitet, die nun mit Zielen und Roadmaps in drei Fristigkeiten beantwortet wurden. Das Ganze in wiederholten Reflexionsschleifen mit Kollegen, Managementlevels und Peers. In einer Townhall.
Was verbindet die Schilderungen meines Gesprächspartners mit den Erfahrungen aus dem oben geschilderten Prozess? Auch in der Reflexionsarbeit kam wiederholt das Anliegen zum Vorschein, alle Aspekte möglichst zu reduzieren, zu vereinfachen – so dass sie für alle Mitarbeiter klar und umsetzbar wären. Es gab also den Wunsch nach einem Plan, den man befolgen und damit die Stärke der Ausführung ausspielen könnte.
Dieses Begehren an die Strategie ist wie jenes an die Wettervorhersage: Wie sicher können wir uns sein, dass das angenommene Szenario auch wirklich eintritt? Zu wie viel Prozent wird es Sonne geben oder der Schnee genau da fallen, wo wir ihn für die Winterferien brauchen? Wie können wir die Anzahl der möglichen Zukünfte einschränken, oder zumindest jener, die in ihren Attributen allzu unterschiedlich sind? Wie können wir Anzahl und Komplexität der möglichen Zukünfte reduzieren, um wirtschaftlich vertretbare Vorbereitungen – also strategisches Handeln – zielführend und erfolgssicher auszurichten?
Es geht immer um Sicherheit, die wir ausbauen wollen, für uns selbst und damit auch für unsere Unternehmen. Vielleicht halten Sie diesen Ansatz für unzulänglich. Dennoch möchte ich Sie einladen, mir in den nachfolgenden Vergleich zwischen Produktentwicklung und strategischer Führung zu folgen. Nach den folgenden Absätzen können Sie dann ja entscheiden, ob Sie diesem Gedanken eine Chance auf ein Experiment geben möchten.

Projektion der Vergangenheit oder Entwicklung mit den Gegebenheiten?

In der Produktentwicklung haben wir über viele Jahrzehnte immer ausgeklügeltere Verfahren entwickelt: Über Vorprojekte, Research und Analysen werden die Anforderungen an ein künftiges Produkt gesammelt, verschriftlicht, organisiert und gemanagt. Umfangreiche Sondierungs- und Erforschungsprozesse, die in voluminösen, präzisen und detaillierten Beschreibungen endeten – den Product Requirements. Auf dieser Basis wurde dann die Produktentwicklung geplant und ausgeführt. Die Planabweichungen und Learnings aus der Realisierung haben dann Eingang in das so genannte Change Management gefunden. In Kürze: Lang laufende Konversationen und Erkenntnisprozesse, die in einem Dokument resultierten.
Anders in der agilen Produktentwicklung. Ausgangspunkt ist die Produktvision – der Leitstern für eine Produktidee. Bereits die Idee wird mit Anwendern und Kunden verprobt. Über Prototypen und Minimum Viable Products werden die Akzeptanz und Tauglichkeit erster Produktansätze untersucht und das Produkt dann über eine Liste an Features (User Stories im Backlog) grob skizziert. Jede Beschreibung passt auf eine Karte im Format A5 und umfasst gerade mal einen Satz: „Als Nutzer möchte ich folgende Funktionalität, um daraus folgenden Nutzen zu erhalten.“ Dazu noch ein paar Constraints – das war es. Unmöglich für ein Team, damit schon loszulegen. Aber genug, um zu verstehen, worum es bei einem Produkt geht.
Sukzessive nehmen Teams und Product Owner die User Stories unter die Lupe und besprechen sie, entwickeln dabei das Kontextverständnis weiter und auch die User Story selbst – je nachdem, wie sie diese verstehen und den Möglichkeitsraum in jeder einzelnen erkunden. Dann wird gebaut – in kurzen Zyklen und mit viel Reflexion. Entlang des Erkenntnisgewinns aus der Realisierung werden die weiteren User Stories konkretisiert und weiterentwickelt. Stück für Stück. Zur User Story heißt es: „Jede User Story ist ein Versprechen auf eine nachfolgende Konversation.“ Nicht das Artefakt „User Story“, sondern die dazugehörige Konversation ist der Schlüssel zur erfolgreichen Produktentwicklung. Den restlichen (Scrum)Prozess spare ich mir hier, er ist hinlänglich bekannt und beschrieben.

Die Entwicklung ist gleichzeitig der Rollout

So steht die klassische strategische Planung der agilen Strategieentwicklung gegenüber. Beide benötigen Artefakte und Prozesse. Für die agile Hemisphäre nehme ich in Anspruch, dass der Entwicklungsprozess gleichzeitig der Rollout-Prozess ist. Strategie als emergentes Kommunikationsgeflecht, das seine Wirkung im Hier und Jetzt entfaltet und die Komplexität möglicher Zukünfte über den Umgang damit im Heute managt. Emergent und reflexiv. Sicher keine Anleitung zum Weiterreichen, die einfach umgesetzt werden muss. Eine solchermaßen entwickelte und umgesetzte Strategie befähigt jedenfalls alle Organisationsteilnehmerinnen, den eigenen Beitrag entsprechend auszurichten.
Diese Sichtweise und Herangehensweise  mag nicht für alle Unternehmensformen und -kulturen gleichermaßen möglich sein. Für agile, selbstorganisierte Netzwerkplayer und Plattformbusinesses ist sie aber eine unverzichtbare Grundlage strategischer Arbeit.
Für diese Art der Herangehensweise benötigt es allerdings auch einige Zutaten:

Und natürlich die Inspiration, die wie in der biologischen Veredelung den inneren Reflexionsprozess positiv irritiert und die häufig um sich selbst kreisenden Reflexionsschleifen leicht aus der Bahn wirft, damit Neues entsteht und Emergenz ermöglicht wird. Diese Aufgabe – den Keim der Veränderung –finden wir im Kunden und Anwender. Also benetzen Sie Ihre Organisation immer wieder mit Kundenperspektiven, O-Tönen und echten Begegnungen.
Unsere möglichen Zukünfte sind wie das Wetter der Zukunft. Es wird regnen, die Sonne wird scheinen, Nebel wird unsere Sicht eintrüben. Eis und Glätte werden Wärme und Hitze weichen. Das alles in überschaubarer, mit Wahrscheinlichkeiten zu versehender Gewissheit. Eines aber ist sicher: Wir werden glückliche Momente erleben. Wir werden erfolgreich sein. Wir werden bestehen.

Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Video: Agile Projekte im feindlichen Umfeld – Was das Management dazu wissen muss

Ihr sollt ein agiles Projekt durchführen, doch rundherum bleibt in der Organisation alles beim Alten? Ich nenne das etwas überspitzt “Agile Projekte im feindlichen Umfeld”. Nun, es gibt mehrere Möglichkeiten, damit umzugehen, und jede dieser Möglichkeiten hat ihre Vor- und Nachteile. Gelingen, oder zumindest etwas reibungsloser ablaufen, können solche Projektkonstellationen aber vor allem dann, wenn für alle Beteiligten transparent gemacht wird, wann woran gearbeitet wird. Mehr dazu in diesem Video.
 

Video: Story Maps für Dummys – äh…Manager

Story Maps haben für Manager einen wesentlichen Vorteil: Sie sehen auf einen Blick, was ein Team in den kommenden Iterationen vorhat, wie das Projekt verläuft und ob es Hindernisse gibt, bei deren Auflösung man als Manager ggf. helfen kann. Die Idee der Story Map an sich ist sehr einfach: Es ist ein um 90 Grad gekipptes Backlog mit Zeitachse. Mehr dazu in diesem Video.
 

Video: Agilität und Software Engineering – oder Conways Law und DevOps

Einige Zuseher haben sich die Frage gestellt, warum Microservices und DevOps so wichtig sind und was das alles eigentlich mit Agilität, inkrementellem Liefern und iterativer Entwicklung zu tun hat. Wahrscheinlich kennt ihr Conway’s Law: Im Produkt einer Organisation spiegeln sich auch immer ihre Kommunikationsstrukturen wider. Meistens bremsen zu starke und zu viele gegenseitige Abhängigkeiten zwischen Teams sowohl die Qualität als auch die Schnelligkeit der Entwicklung aus. In der Softwareentwicklung hat man sich daher die Frage gestellt, wie man bei einer Teamstruktur diese Abhängigkeiten reduzieren kann – also brauche ich auch eine entsprechende Produktarchitektur und eine Infrastruktur für das kontinuierliche Liefern. Mehr dazu in diesem Video.
 

Video: Sprintlängen werden immer kürzer, warum eigentlich?

Wie lange sollte eigentlich ein Sprint sein? Vor mittlerweile mehr als 15 Jahren habe ich die Idee eingebracht, dass Sprints in der Webentwicklung nicht länger als zwei Wochen dauern sollten – seitdem hat sich die Ansicht „ein Sprint dauert zwei Wochen“ in der agilen Community verfestigt. Doch heute stehen wir vor völlig neuen Herausforderungen und inzwischen gibt es Unternehmen, die in der Softwareentwicklung täglich, manchmal sogar stündlich releasen. Was ist denn jetzt überhaupt eine Iteration? Wie man sich einem passenden Zyklus annähern kann, erkläre ich in diesem Video.

 

Video: Führen mit Appreciative Inquiry

„Worauf ich meine Aufmerksamkeit richte, davon bekomme ich mehr.“ Diesen Führungsgrundsatz haben wir bereits kennengelernt. Es gibt ein tolles Instrument, mit dem man diesen Grundsatz einfach in den Alltag als Führungskraft einflechten kann und ich selbst möchte dieses Instrument nicht mehr missen: Appreciative Inquiry oder „wertschätzendes Fragen“. Wenn eine Organisation ein System aus Konversationen ist, genügt es oft schon, Diskussionen in Gang zu bringen, um eine Veränderung anzustoßen. Wie das mit Appreciative Inquiry funktionieren kann, erkläre ich in diesem Video.

 

Fragen und Antworten zum Innovation Lab

Wie könnte die Vision für ein InnoLab lauten?

Eines unserer aktuellen InnoLabs an einem großen Produktionsstandort hat sich die Vision auf die Fahne geschrieben, innovativen Ideen aus dem Kreis der Belegschaft einen Raum zu geben und sie mit agiler Unterstützung schnell in die Umsetzung zu bekommen. Jede Idee ist willkommen, solange es etwas mit dem Arbeiten im Werk zu tun hat. Die Leute kommen beispielsweise in dieses InnoLab, weil sie die Produktion am Band verbessern oder etwas für die Zufriedenheit der Mitarbeiter und Mitarbeiterinnen tun wollen. Dabei begleiten wir die Produktentwicklungen nach Möglichkeit von der ersten Formulierung der Idee bis zum produktiven Status.
Das InnoLab ist also ein interner Inkubator für direkt nutzbare Verbesserungen. Wir entwickeln mit dem Nutzer an der Einsatzstelle und lassen mit den Mitarbeitern damit nicht nur ein völlig neues, anspornendes Selbstbild entstehen, sondern schaffen auch Produkte, die tatsächlich gebraucht werden.

Was genau passiert in einem InnoLab?

In unserem aktuellen InnoLab durchläuft eine Idee die folgenden Schritte:

  1. Formuliere eine Idee und stelle diese im Rahmen einer Pitchveranstaltung vor.
  2. Freiwillige Mitarbeiter des Werkes dürfen zwischen unterschiedlichen Ideen entscheiden. Der Gewinner wird nach dem Mehrheitsprinzip ermittelt.
  3. Werde als Ideengeber oder als ein von der Idee begeisterter Mensch der Product Owner.
  4. Stelle ein interdisziplinäres Team aus internen Experten (aus den Fachabteilungen, aus der IT oder aus den Produktionshallen) zusammen.
  5. Hole dir die Unterstützung durch einen ScrumMaster.
  6. Jetzt hast du mit deinem Scrum-Team sechs Wochen Zeit für die initiale Umsetzung der Vision und für die Erstellung eines Prototyps.
  7. Suche dir interne oder externe IT-Dienstleister für die Umsetzung, wenn du eine digitale Lösung umsetzen möchtest. Suche dir die jeweiligen Experten, wenn deine Lösung außerhalb der IT liegt.
  8. Nutze dein Startkapital von 20.000 Euro (für die IT-Unterstützung und etwaige andere Kostenpunkte bspw. Hardware).
  9. Pitche deinen fertigen Prototypen wie in der „Höhle des Löwen“ (bestehend aus bspw. 4 Führungskräften aus unterschiedlichen Fachrichtungen wie Controlling, Strategie, Produktion, Human Resources etc.).
  10. Überzeuge die Löwen und erhalte ein Go für die von dir beantragten Gelder und die Möglichkeit, weitere drei Monate im InnoLab zu arbeiten.
  11. Die „Höhle der Löwen“ öffnet sich jedoch maximal zwei weitere Male. Somit muss dein Produkt nach rund 1 Jahr das InnoLab verlassen und allein in der Linie laufen können.

Was kann man in einem InnoLab lernen?

Die Produktentwicklungen im InnoLab passieren im Vergleich zum herkömmlichen Konzern-Kontext unvergleichlich schnell, denn die direkte Entwicklung mit dem Anwender ist heutzutage leider immer noch eher selten.
Um beides erfolgreich umzusetzen, haben sich im InnoLab mehrere (agile) Prämissen als hilfreich erwiesen:

Welche Herausforderungen gibt es in einem InnoLab?

Trotz vieler Erfolge und positiver Stimmen stehen wir vor einigen Herausforderungen. Am Ende des einjährigen Entwicklungszyklus sind die Produkte häufig bereits auf die Produktion ausgerollt und werden an verschiedenen Standorten, in verschiedenen Abteilungen und Produktionshallen genutzt. An dieser Stelle müssten die Produkte in die Linie überführt werden, weitergeführt und gewartet werden.
Dabei stoßen wir noch immer häufig an die starren Strukturen, die uns Geschwindigkeit nehmen und den Rollout erschweren. Und noch ein Punkt: Nicht alle Produkte werden wirklich breit produktiv ausgerollt. Viele Unterstützer, die den Weg begleitet haben, erfahren das als Enttäuschung. Wovon wir jedoch überzeugt sind, ist: Wir haben tolle Ideen verfolgt, wir haben Anwender*innen eingebunden, wir haben Produkte verprobt und rechtzeitig festgestellt, dass es (vielleicht noch) nicht an der Zeit ist für diese Produkte. Was jedoch bleibt und über den Product Life Cycle hinaus wirkt: Die Leute gehen in ihre Teams in der Linie zurück, nehmen Impulse zum neuen Arbeiten mit und verändern weitere Bereiche des Unternehmens von dort aus.
Unser Tipp: Bevor ein Innovation Lab so richtig fliegen kann, sollten im Zuge einer Organisationsentwicklung einige Impediments beseitigt werden:

Video: Führen mit Verstärkung

“Worauf ich meine Aufmerksamkeit richte, davon bekomme ich mehr” – dieses Führungsprinzip kennen wir ja schon. Also sollten Manager ihre Kolleginnen und Kollegen einfach noch mehr loben, oder? Nun, das kann nach hinten los gehen, denn Lob ist meistens eine Beurteilung der Persönlichkeit eines Menschen. Wir wollen aber mehr von bestimmten Handlungen und Ergebnissen. Das ist ein Fall für die positive Verstärkung.
Was der Unterschied zwischen Lob und positiver Verstärkung ist und wie ihr die positive Verstärkung richtig einsetzt, erfahrt ihr in diesem Video.
Viel Spaß beim Anschauen
Boris
 

Scrum4Schools an der Hochschule München: Die Agilität erwacht

„Die Woche war viel zu schnell um“, „Das hatte ich anders verstanden“ oder „Wir sind fast fertig“. Das hört man von Scrum-Teams schon mal am Tag vor dem Review und somit am Ende eines Entwicklungssprints. Aber nicht nur dort, sondern auch in einer Wirtschaftsvorlesung von Prof. Holger Günzel an der Hochschule München. Er möchte nämlich mit seinen Studentinnen und Studenten in den nächsten sechs Wochen Scrum4Schools als Rahmenwerk für die Ausarbeitung von Studienarbeiten einsetzen.

Woche 2 – Definition of Done und die erste Lieferung

Der Ablauf

Zu Beginn des Sprint Plannings hatten die Studentengruppen eine Definition of Done erarbeitet. Dieser zufolge sollten sie die ersten relevanten Lieferungen, wie eine Agenda oder eine Literaturrecherche von drei relevanten Texten, bereits nach der ersten Woche abgeben. Prof. Günzel hat an alle Studierenden Bewertungsbögen ausgeteilt. Darauf finden sich zum einen die festgelegten Akzeptanzkriterien sowie die allgemeinen Constraints des Produktes Hausarbeit. Ziel ist es, dass jeder Studierende zu jeder Zeit die Bewertungskriterien für die Abschlussnote kennt und diese im Review für das Feedback zu den anderen Lieferungen nutzen kann.

Das erste Review

Jede Gruppe bekommt eine Timebox von 10 Minuten. Die erste Gruppe präsentiert. Die Zuhörer können auf ihrem Bewertungsbogen nur wenige Punkte abhaken und geben kräftig Feedback, was sie sich für die nächste Iteration vorstellen könnten. Prof. Günzel hält sich im Hintergrund. Die zweite Gruppe präsentiert. Anstatt inhaltliche Lieferungen zu präsentieren, hat diese Gruppe die Aufgabenstellung für sich neu geschrieben und vorher abgestimmte Rahmenbedingungen außer Kraft gesetzt. Sie haben ihre Arbeit nicht nach der Herangehensweise von Scrum strukturiert, sie haben auch kein Taskboard und damit einhergehend keine bewertbare Lieferung. Die Zuhörer sind irritiert und finden keine passenden Checkpunkte auf ihrem Feedbackbogen. Prof. Günzel muss eingreifen und erläutert erneut den Kontext sowie die Aufgabenstellung. Erst jetzt versteht die Gruppe, was das eigentliche Ziel ihrer Aufgabenstellung ist. Alle atmen auf, es sind ja noch fünf Wochen Zeit. Gut, dass es das Review gibt und sie somit schnell Feedback erhalten haben.

Die erste Retrospektive

Die Gruppen sitzen wieder beisammen und versuchen, auf ihre gemeinsame erste Woche zurückzublicken. Was ist uns bereits sehr gut gelungen? Wo können wir vielleicht noch etwas besser werden, damit wir nächste Woche wieder so gutes Feedback bekommen? In jeder Gruppe werden relevante Veränderungen identifiziert und in kleine Maßnahmen heruntergebrochen. Prof. Günzel beobachtet, dass sich jeder ein bis zwei Verbesserungen am Taskboard notiert.
Hier zeigt sich wieder einmal sehr schön: Man kann noch so viel vorab über die gemeinsame Zielstellung sprechen – erst beim Umsetzen kommen die Fragen und man erkennt, ob man den Kunden wirklich verstanden hat.

Video: Führungsgrundsatz # 1 – Stärken stärken

 

Unsere Gesellschaft ist darauf getrimmt, immer auf das zu schauen, was nicht funktioniert. Auch viele Manager lassen sich ständig von dem ablenken, was (noch) nicht rund läuft und stecken zu viel Energie in die Ausmerzung vermeintlicher Fehler und Schwächen. Dabei gibt es im Leben wie im Management ein einfaches, aber extrem wirksames Prinzip: Worauf ich meine Aufmerksamkeit richte, davon bekomme ich mehr. Schaue ich ständig auf die Fehler, bekomme ich mehr Fehler. Schaue ich hingegen auf die Stärken und kommuniziere ich meine Beobachtungen an die Kollegen, werden sie diese Richtung beibehalten.

Mehr dazu in diesem Video.

Video: Agilität – das Managen von Unsicherheiten

 

„Vertrauen ist gut, Kontrolle ist besser!“ – Hat dieses Sprichwort überhaupt Platz im agilen Management?

Ja, allerdings nicht in diesem wörtlichen Sinne. „Ask the team“ ist eine Maxime agilen Arbeitens, „Deliver“ genauso. Als Manager vertraue ich auf die Loyalität des Teams, aber ich vertraue nicht blind darauf, dass ein Team schon alles schaffen wird. Es geht hier also um das „Zutrauen“. Um zu überprüfen, ob ich einem Team bestimmte Aufgaben zutrauen kann, etabliere ich als Manager einen reflexiven Prozess. Anhand von Daten und Fakten sehen sich Team und Manager gemeinsam an, was bereits klappt, wo noch nachjustiert werden muss und wo Unterstützung gebraucht wird.

Mehr dazu in diesem Video.

Video: Management oder Entrepreneurship

Von den Herausforderungen der VUCA-Welt haben wir bereits gehört (siehe dieses Video). Ist das traditionelle Management-Paradigma aus Zielvorgaben, Gewinnorientierung, genauer Planung und Wettbewerbsdenken für diese neue Welt überhaupt geeignet?
Hier lohnt sich ein Blick in die Entrepreneurship-Forschung: Unternehmer agieren immer unter unsicheren Bedingungen und entwickeln dadurch meist ganz andere Herangehensweisen, damit ihr Unternehmen bestehen kann. Diese Art des Denkens wird auch als “Effectuation” bezeichnet.
In diesem Video erkläre ich kurz dieses neue/alte Paradigma. Vielleicht hilft es euch dabei, euren eigenen Managementansatz auf die anstehenden Herausforderungen auszurichten.
Viel Spaß beim Anschauen
Boris
 

Video: Management in der VUCA Welt

VUCA – das neue Modewort ist in aller Munde. Es steht für

Was bedeutet das eigentlich und was heißt das für mich als Manager? Wie gehe ich mit diesen Herausforderungen um?
Im Video erkläre ich die Begriffe und zeige euch kurz, wie ihr dieses Thema mit Hilfe von Management-Frameworks in den Griff bekommt.
Viel Spaß beim Anschauen
Boris
 

Video: Der Manager als Facilitator – Leadership Design

Für ein erfolgreiches Meeting muss man drei Ebenen in den Griff bekommen: zunächst die Beziehungs-, dann die Prozess- und schließlich die Inhaltsebene. Diese drei Ebenen sind keine Sequenzen, sondern die drei Schichten einer Grundlage, auf der ein Meeting verläuft. Der Job des Managers als Facilitator innerhalb eines Meetings ist es, kontinuierlich an der Beziehungs- und Prozessebene zu arbeiten, aus den Inhalten hält er sich raus. 
Abseits dieser punktuellen Aufgabe in einem Meeting muss ein Manager aber reflexive Prozesse etablieren, um langfristig Vertrauen aufzubauen. Es geht also um die Frage: Wie will ich mit meinen Kollegen auf Dauer zusammenarbeiten? In diesem Video zeige ich kurz und knapp, wie ihr das als Führungskräfte mit Hilfe von Leadership Design machen könnt. 
Viel Spaß beim Anschauen!
Boris 
 
 

Video: Der Manager als Facilitator – Die Kreisarbeit

Für unser Unternehmen hat es sich bewährt, so gut wie alle Meetings nach der Methode “Kreisarbeit” (Circle Way) durchzuführen. Bei unseren Company Days sitzen mehrere Dutzend Leute in diesem Kreis und führen produktive Dialoge. Wir nutzen diese Art des Miteinandersprechens auch bei unseren Kunden und sogar bei Videokonferenzen. Für uns funktioniert es extrem gut. In diesem Video erkläre ich euch die Grundlagen. Wer mehr darüber nachlesen möchte, findet hier weitere Informationen. 
 

 
 

Zu Gast beim 3. Handelsblatt Industriegipfel: Was macht eine gute Führungskraft aus?

Heute eine kleine Ankündigung im eigenen Sinne. Am 10. November werde ich auf dem 3. Handelsblatt Industrie-Gipfel sprechen. Mein Thema: „Keine Digitalisierung ohne Freiwilligkeit – Wie Sie die Generation Y führen“. Auf der Veranstaltungswebsite habe ich bereits einen kleinen Vorgeschmack darauf veröffentlicht. Lest hier, was eine gute Führungskraft in Zeiten von Digitalisierung und Generation Y ausmacht.
 

Video: Der Manager als Facilitator – Grundlagen

Meetings sind meist gähnend langweilig. Doch gleichzeitig sind Meetings eines der wichtigsten Elemente im Rennen um den produktivsten Executive. Deshalb ist es wahrscheinlich sinnlos, die immer wieder geforderte Idee “No Meetings” ernst zu nehmen. Viel wichtiger ist es, Meetings so produktiv wie möglich zu gestalten.
In diesem Video erkläre ich die Grundlagen erfolgreicher Meetings. Wer diese Grundlagen beherzigt, wird es schaffen, dass die Kolleginnen und Kollegen gerne zu den Meetings kommen – weil sie einfach Spaß machen.
Viel Spaß beim Anschauen
Boris
 

Video: Agilität und Digitalisierung gehören zusammen

Agile Organisationen in ihren heutigen Dimensionen sind nur möglich geworden, weil es das Internet gibt. Dadurch wurden die Kosten der Peer-to-Peer-Kommunikation innerhalb von Unternehmen so weit reduziert, dass nun die Transaktionskosten in einer dem Marktplatz ähnlichen Organisationsstruktur geringer sind als in einer traditionellen Organisationsaufstellung. Vorausgesetzt, dass Unternehmen ihren Mitarbeiterinnen und Mitarbeitern die passenden Tools und Techniken anbieten, werden sie auf diese Weise ganz von selbst zu agilen Organisationen.
In diesem Video erkläre ich den Gedankengang ausführlich – ich bin sehr auf eure Kommentare gespannt!
Viel Spaß beim Anschauen
Boris
 

Video: Der Marktplatz – Wie ordnet sich eine Organisation?

In der Digitalisierung wird der Marktplatz zur vorherrschenden Organisationsform. Doch weshalb funktioniert der Marktplatz? Was ist der Marktplatz in der Organisation? Wie organisiere ich den Marktplatz in einer Organisation? Wie erreiche ich, dass Menschen bei den Projekten am Marktplatz mitmachen?  
Anhand unserer eigenen Firma zeige ich, wie sich dieses Vorgehen tatsächlich leben lässt und wie sich die Projekte immer wieder an dem ausrichten, was die Menschen im Unternehmen machen wollen. 
Viel Spaß beim Anschauen
Boris 
 

Video: Der Open Space – eine Grundlage

Die Digitalisierung erzwingt die Umstrukturierung vieler Unternehmen. Viele Manager suchen Anhaltspunkte dafür, wie sie das Unternehmen für diese Herausforderung aufstellen müssen. Schnell reagiert die agile Community und baut Blaupausen: Nexus, LeSS, SAFe® und wie sie alle heißen. Ich finde, das sind hilflose Versuche, Selbstorganisation zu verordnen. Dabei werden die Prinzipien der Selbstorganisation sträflich verletzt und wir fallen wieder in Command and Control zurück. Doch es gibt vielleicht eine Blaupause dazu, wie sich eine Organisation „agil und mithilfe von Freiwilligkeit“ organisieren kann. Buurtzorg hat es vorgemacht.
In diesem Video erkläre ich, wie die Open Space Technologie funktioniert. Wir müssen uns mit dieser Organisationsform auseinandersetzen, um zu verstehen, wie sich Organisationen aufstellen müssen.
Viel Spaß beim Anschauen
Boris
 
 

Video: Einladen zum Mitmachen

In einem der letzten Videos habe ich darüber gesprochen, dass Führen mit Freiwilligkeit die notwendige Voraussetzung ist, um agil zu führen. Wir haben auch gesehen, dass es eine Ambivalenz zwischen Autonomie und Kooperation gibt. Wie gelingt es, diese Ambivalenz zu nutzen, statt sie zu ignorieren?
Die Antwort: Man lädt zum Mitmachen ein.
Dieses kurze Video zeigt, wie eine Einladung funktioniert und weshalb Menschen Einladungen auch manchmal nicht annehmen – sie haben einfach nichts davon.
Mehr dazu im Video.
Viel Spaß beim Anschauen!
Boris
 

Video: Autonomie oder Führen mit Freiwilligkeit

Als Führungskraft im agilen Unternehmen ist es wichtig, sich mit der Natur des Menschen auseinanderzusetzen. Nach Gerald Hüther werden Menschen vom Streben nach Verbundenheit getrieben. Sie möchten wissen, wie eine Kultur bzw. ein System funktioniert, wenn sie dort hineinkommen. Das Verrückte: Gleichzeitig strebt der Arbeitnehmer aber nach Autonomie und Selbstständigkeit. Ihre Aufgabe ist es also, diesen Balanceakt in ein dynamisches Gleichgewicht zu bekommen. Das hört sich zunächst paradox an, ist aber unausweichlich für die Zufriedenheit der Mitarbeiter und somit auch den Erfolg des Unternehmens.

 

Scrum oder die Kraft des Scheiterns

 

Chaotisch, revolutionär, unberechenbar – das wird oft mit Scrum verbunden.

 
In gewisser Weise mag das stimmen: Gerade wenn man frei und unkonventionell arbeiten kann, besteht die Chance, Probleme mit Herangehensweisen wie Design Thinking oder Prototyping betrachten zu können und so zu völlig neuen Erkenntnissen zu gelangen. Diese Arbeitsweise garantiert allerdings nicht, dass der Prototyp am Ende auch funktioniert.
 
Doch was ist gut am Gedanken des “fail fast”? Die Anforderungen ändern sich heute zu schnell, ein perfekt ausgearbeiteter Plan sichert daher nicht den Projekterfolg. Wer zu lange plant, wird schnell vom Wettbewerb überholt. Also ist es mehr als sinnvoll, keine weitere Energie in eine Idee zu stecken, die nicht funktioniert. Wenn man sich von einer Lösung trennt, schafft man Raum für neue Möglichkeiten. Scrum fordert permanentes Feedback vom Anwender und das Denken in fertigen Produkteinheiten. Dadurch lässt sich schnell identifizieren, ob ein Projekt noch relevant ist. Sollte das nicht der Fall sein, lässt es sich einfach beenden und damit viel Geld einsparen.
 

Auch Scrum-Projekte können scheitern

Häufig wird mit Scrum in Unternehmen die Hoffnung verbunden, dass Projekte jetzt nicht mehr scheitern, doch genau diese Hoffnung wird viel schneller enttäuscht. Vielmehr muss man den Begriff des Erfolgs in Scrum ganz anders definieren: Wer schneller scheitert, kann schneller wieder aufstehen und neu anfangen. Genau darin liegt die eigentliche Kraft von Scrum.
 
“Fail fast and often“- bemerke, dass es nicht funktioniert und das schnell. Die Angst vor dem Scheitern begleitet jedes Projekt, auch solche, in denen Scrum gelebt wird. Der entscheidende Unterschied zu klassischen Projekten ist aber: Man geht anders damit um, wenn das Produkt nicht funktioniert. Klar, es wurde entwickelt, um zu funktionieren, um eine Lösung zu sein. Viel Energie ist in das Produkt geflossen, es hat Schweiß und Tränen gefordert. Doch wer Scrum lebt, der weiß: Im Scheitern liegt eine ungeheure Kraft. Wer scheitert, macht mit neuen Erfahrungen und Wissen weiter, das durch die Retrospektiven gleich wieder in den Prozess einfließt.
 
Man startet jeden Tag mit dem Anspruch, sein Bestes zu geben, und gleichzeitig weiß man: Das Feedback des Nutzers kann alles in ein völlig neues Licht rücken. Damit in Projekten umgehen zu können, ist eine große Kunst. Offenheit ist nicht zuletzt deshalb einer der Werte von Scrum: Offen gegenüber neuen Ideen und Feedback.
 
Die Ansprüche von Scrum sind schnell und klar formuliert, aber es ist hart, sie umzusetzen. Viele Unternehmen schrecken heute noch davor zurück, Scrum in aller Konsequenz zu leben, denn eines ist sicher: Scrum legt Defizite schonungslos offen. Alles, was nicht zum Ziel führt, aber seit Jahren mitgeschleppt wird, kann plötzlich infrage gestellt werden. Nicht zuletzt fordert Scrum auch menschlich heraus. Es ist ein ständiges Reflektieren darüber, ob man die Werte lebt.
 

Bin ich offen für Neues?

Bin ich respektvoll gegenüber anderen?

Bin ich mutig?

Bin ich verbindlich?

Bin ich fokussiert?

 
Was ist der Lohn für die harte Arbeit? Stetiges Wachstum, das man an sich selbst, aber auch an anderen sieht. Sich entwickeln zu können und völlig neue Erkenntnisse gewinnen zu dürfen.
 
Das ist mitunter hart und schmerzvoll. Aber es lohnt sich.

Spirit of Agility

 
Donnerstagvormittag, irgendwo in Deutschland in einem schicken Scrum Intro-Training, erster Tag. Es geht um die Werte und Geschichte von Scrum. Die Teilnehmer hören ruhig zu. Irgendwann kommt sie, die Frage. Man kann darauf Wetten abschließen, man kann sie hassen oder einfach nur als Geschenk annehmen:
„Wie soll das bei uns funktionieren, diese Freiwilligkeit, ohne Gantt-Chart und detaillierte Planungsphase?“
„Dann müssten wir ja den Einkauf zu den Entwicklern setzen, das geht hier nicht!“
„Wie soll das bei unseren vielen Parallelprojekten gehen?“

Die Liste an Fragen und Bedenken ist lang und vielfältig.

Diesen Fragen ist gemein, dass sie am Ende eine Ungläubigkeit ausdrücken, die die Teilnehmer noch für sich behalten. Da steht etwas völlig Neues auf dem Plan, das nun droht, das gute alte Projektmanagement zu zerstören. Mit eigenartigen Prinzipien. Wenn man in manchen Unternehmen die Türen aufmacht, hat man den Eindruck, in einem falschen Zeitalter zu stehen. Doch was hält die Teilnehmer am Ende wirklich davon ab, sich dem Neuen hinzugeben? Es ist eine riesige Kulturfrage, eine Frage der Offenheit für Neues.
Scrum fordert genau das: Offen sein, nicht fertig sein, nicht denken „Meine Retro ist die beste, das wird sich nie ändern.“ Das Denken in alten Mustern sitzt tief. „Da muss man drüber nachdenken“, ist einer der typischen Sätze, die Eigenverantwortung ausschließen, niemand fühlt sich adressiert.
Scrum fordert das Gegenteil von dem, was in vielen Organisationen heute noch Standard ist: keine Hierarchien, schnelle Entscheidungen, doing less delivers more, Entwickler und Anforderer sitzen zusammen an einem Tisch, nur Fertiges ist fertig … Kein Wunder also, dass die Schmerzen groß sind, wenn man sich einer neuen Herangehensweise an die Produktentwicklung widmen soll.

It’s the spirit, stupid!

Wie kann so etwas gelingen? Nicht umsonst verfolgen wir in unserem Unternehmen die Philosophie: „Doing as a way of thinking!“ Einfach mal machen, nicht reden, einfach ausprobieren. Das heißt: die Leute ins Machen bringen. Und häufig gibt es dann Erkenntnisse, die beeindrucken.
Beim Ball Point Game werden die Teilnehmer immer ruhiger, und erkennen, wie sie mit ihren Stärken und Handicaps am besten umgehen, Sie erkennen, wie ein Team und Selbstorganisation in einem gegebenen Rahmen funktionieren kann. Sodass am Ende des Tages häufig doch ein Hauch von Agilität durch den Raum zieht und nach zwei Tagen „neue Menschen“ das Training verlassen.
 

Video: Der agile Festpreis

 
Buch Der agile FestpreisOb nicht agil oder agil: Noch immer sind für die Zusammenarbeit Verträge notwendig. Andreas Opelt beschäftigt sich intensiv mit den passenden Vertragsformen für das agile Arbeiten, vor allem mit dem Agilen Festpreis. In diesem Video erkläre ich seine Ideen dazu. Nicht im selben Umfang wie er das im Buch “Der Agile Festpreis” tut, aber vielleicht macht euch das Video ja Lust aufs Lesen 😃
 
Viel Spaß beim Anschauen — Boris
 

Video: Schätzmethoden – Was ist Magic Estimation?

 
User Stories sind klein. Doch wie finde ich heraus, ob eine User Story klein ist?
In diesem kleinen Vortrag über Magic Estimation zeige ich euch, wie einfach es ist, User Stories der Größe nach zu schätzen. Dabei will man nicht absolut wissen, wie groß eine User Story ist, sondern man will sie relativ zu den anderen User Stories eingruppieren. Ich erkläre auch, was passiert, nachdem die Eingruppierung stattgefunden hat und nach welcher Vorschrift die User Stories zum nächsten Sprint zugelassen werden.
Dank “Magic Estimation” lassen sich übrigens sehr viele User Stories in nur wenigen Minuten schätzen.
 
Viel Spaß beim Anschauen — Boris
 

 

Video: Was ist eine User Story?

 
Mit den nächsten drei Videos bespreche ich einige Themen rund um das Schätzen von User Stories. Den Anfang mache ich gleich mit den User Stories selbst.
User Stories sind eigentlich recht einfach zu verstehen, wenn man sich darauf beschränkt, bei dem zu bleiben, was eine User Story ist: ein Versprechen auf eine nachfolgende Konversation. User Stories beantworten drei Fragen: WER braucht WAS WOZU? Es ist völlig unnötig, User Stories noch viel besser aufschreiben zu wollen oder sie vielleicht sogar so formulieren zu wollen, dass sie von jedem in jeder Situation verstanden werden.
Bis jetzt bin ich mit meiner Auffassung von User Stories in allen Projekten immer gut gefahren.
 
Viel Spaß beim Anschauen — Boris
 

 

Agile Banking – die Zukunft?

Das Zinsumfeld ist herausfordernd, die Regulierungszyklen werden immer kürzer und junge Fintechs knabbern an den wenigen verbliebenen Profit-Bringern der Bankhäuser. Die Antwort der etablierten Bankenwelt: Start-up-Mentalität und Agilität – eine Art Verjüngungskur für die Veteranen. Doch warum sind es genau diese zwei Zutaten, die in Zukunft den großen Erfolg bringen sollen? Für die Vorbereitung eines Vortrags habe ich mir diese zwei Fragen mit Jakob Etzel gestellt, der mit Partnern sein eigenes Fintech “predictr” gegründet hat. Aber der Reihe nach.
Start-Ups sind Vorbild für alle großen Konzerne, wie unlängst einmal mehr die Tageszeitung “Die Welt” feststellte (“Silicon Valley ist der Ballermann der Tech-Szene”). Was ist das Magische an diesen Organisationen? Viele der ehemaligen Start-ups sind bei weitem nicht mehr so klein, dass behauptet werden kann, es liege an der geringeren Größe und den damit einhergehenden Vorteilen. Klar, die schlankeren Strukturen schaffen einen Vorteil, aber viel wesentlicher ist, dass Start-ups die Agilität in ihrer DNA haben. Sie müssen in der Regel immer schnell Lösungen entwickeln, um erstens zu überleben und zweitens die nächste Finanzierungsrunde zu überstehen. Wichtig ist, als Start-up nicht der Verführung eines Shareholder-Ansatzes in neuen Kleidern zu erliegen und somit den Kunden bzw. die Lösung komplett außer Acht zu lassen. Das zeigt ein prominentes Beispiel der letzten Zeit: Theranos, ein Unternehmen, das seine bisherige Finanzierung auf einem großteils auf zweifelhaften Methoden basierenden Geschäftsmodell aufbaute und versuchte, die Investoren mit dem Wecken großer Erwartungen ohne wirkliche Substanz zufrieden zu stellen. Wir sollten jedoch nicht von einzelnen Beispielen auf die Gesamtheit schließen. In der Regel orientiert sich ein Großteil der Start-ups stringent an den Kunden, um ein möglichst ertragreiches Geschäftsmodell zu entwickeln. Das bedeutet auch, dass im Falle eines nicht maximal erfolgreichen Modells einfach flexibel weiter evaluiert wird, ob eine andere Variante des Modells oder ein gänzlich anderes nicht noch sinnvoller sein kann.

Methoden und Prinzipien sind überall einsetzbar

Dank des Sparrings und der Diskussion mit Jakob bin ich mir heute noch viel sicherer als zuvor: Viele der Ideen, die Start-ups verwenden, um flexibler zu sein, können tatsächlich auch problemlos in großen Unternehmen angewendet werden – wir schreiben immerhin das Jahr 2016. Methoden wie Design Thinking und Rapid Prototyping sind heute weit verbreitet und sollten zum Repertoire jeder Produktentwicklungsabteilung gehören. Das funktioniert in vielen Branchen: Werden im Mobile-Bereich Papier-Prototypen erstellt, so bedient man sich in der Hardware moderner 3D-Drucker oder eines speziellen Prototyping-Equipments. Was, wenn gar kein Produkt erstellt wird? Auch das ist kein Problem, der Kreativität sind keine Grenzen gesetzt. Die Bankfiliale der Zukunft? Mit Hilfe von Lego ist schnell ein Modell gebaut, das mit Hilfe von Passanten vor der Filiale getestet werden kann.
Agilität ist das zweite Mittel zum Erfolg. Auch hier zeigen diverse Transformationsvorhaben in Großbanken, dass diese Ambitionen durchaus ernst genommen werden. Die niederländische ING Bank hat es vorgemacht: Nach einem jahrelangem Veränderungsprozess hat sie nun eine Organisationsstruktur, in der einzelne Teams tatsächlich end-2-end verantwortlich sind – und das auch außerhalb der IT (siehe dazu das Video “Agile way of working at ING Netherlands”).

Die Bremsklötze

Doch was sind die großen Herausforderungen speziell im Bankenbereich? Ein wesentlicher Aspekt neben dem regulierten Umfeld sind sicher die Kernbankensysteme, die in der Regel bereits seit Jahrzehnten im Einsatz sind und alles andere als optimale Voraussetzungen für eine agile Entwicklung bieten. Diese Tatsache bremst die Innovation. Die IT hindert das Business, neue und bessere Produkte auf den Markt zu bringen, und das nur, um die Altsysteme nicht weiter zu belasten. Die gute Nachricht ist: Es gibt Auswege und Strategien, um diese Monolithen mit Hilfe moderner Softwarearchitekturen wie Microservices schrittweise und in vielen kleinen Iterationen abzulösen und so einer flexibleren Zukunft entgegen zu gehen.
Eine weitere Herausforderung ist die Verbindung der analogen und digitalen Kanäle: offline in der Filiale und am Schalter und online in den unzähligen Finanzportalen und Apps. Hier sind nicht nur neue Systeme nötig, sondern auch grundlegende Veränderungen in den Strategien, um diese zwei Welten in Einklang zu bringen. Das e-Commerce-Business hat es erfolgreich vorgemacht; es gibt zahlreiche gute und vor allem funktionierende Multi-Channel-Konzepte.
Ich denke, dass sich der Weg der Reise hin zu einer agileren Bank lohnt. Mit Hilfe der agilen Werte und Methoden wie Scrum und Kanban können bei richtigem Einsatz viele der erhofften Vorteile – insbesondere die Nähe zum Kunden, die kürzere Time-to-Market und eine flexiblere Releaseplanung – erzielt werden. Tatsache ist, dass die Reise anstrengend wird und viele alte Denkmuster durchbrochen werden müssen. Auch müssen wir uns von den Rucksäcken der Vergangenheit befreien und wenn notwendig, alte Relikte entsorgen, um Neues entstehen lassen zu können – auch wenn das vielleicht das Ende des Kernbankensystems in seiner bisherigen Form bedeuten mag.

Stop using user stories like that!

„We are using user stories instead of requirements.“ Probably everybody working in a Scrum environment already heard this sentence – to some it sounds smart, to others it simply sounds dangerous. Wow, no requirements! It is one of my favourite false statements concerning Scrum, right after: „We do agile, we do not plan anymore“ and „Self-organization does not need leadership“.

Understand the user story

User stories are part of the family of functional requirements, containing many kinds of requirements. But I do not mind the wording aspect, because we need to change and differenciate words to embrace a new culture. I prefer to take a look at the context behind such sentences which is: In Scrum we try to express user-centric requirements in a story-like syntax.
But in many cases user stories are actually used to describe

And Scrum Masters keep asking: „Who’s the user?”
And developers respond: „Well, my manager is the user!” or „My colleague might be the user” or „I see it clearly now: I am the user!”
And every Scrum Master needs to say: „Well, that is correct”, because in literally 90% of these situations that is the case.
And that is how we miss the unique magic of a user story.

Following the reward

Most of us were trained to serve the company, serve the boss and serve ourselves. Far too often, this is what we are rewarded for. Here are some examples I experienced myself within the course of only one week:

For good and biological reasons, we tend to focus on something we get rewards from.

User stories keep the focus

Back to the business context: In a complex product development process, we can easily lose sight of who is finally rewarding us for our good work. Sometimes we even just don’t know who actually pays our salary. In any case it is the user who buys our cars, our 3D printers or uses our new fancy banking app.  The main problem is that developers often don’t focus on the actual user. At this point, the magic of an user story helps a lot: It focuses on the user. Not on the manager, not on the colleague and not on ourselves. The user story is supposed to be decoupled from reward systems usually in place. It solely focuses on the user.
By attaching value to the outcome for the user, a user story shows every day how much benefit a team is delivering to the guy it is paid by. And this is the reason why we use this kind of requirement in Scrum. Scrum is user-centric, it is about getting feedback about what a user might need or love and why!
 
With this in mind, yours
Marcus

Video: Das Transition Team I

Wie verändert man eine ganze Organisation mit Scrum? Wir haben dazu bereits vor Jahren ein Modell entwickelt, das sich in vielen Unternehmen und Konzernen bewährt hat. Es ist nicht immer komplikationslos, mit diesem Modell zu arbeiten, doch es zeigt gerade den ganz großen Unternehmen, wie der Weg zu einer agilen Vorgehensweise oder sogar der Weg zu einer echten agilen Organisation gemanagt werden kann.
Kern dieses Modells ist das, wie wir es nennen, “Transition Team”. In diesem Video erkläre ich euch den Grundgedanken und die grundsätzliche Funktionsweise dieses Teams.
 
Viel Spaß beim Anschauen – Boris
 

Making of "Scrum – Think b!g" – Teil 3

Buchcover Scrum-Think bigHeute zeige ich euch, wie man über skaliertes Scrum (Scaled Agile) in kurzer Zeit sehr viel schreiben kann. Der Trick besteht darin, Scrum für den Schreibprozess anzuwenden. Wie im ersten Teil des Making of “Scrum – Think b!g” geschildert, habe ich eine Vision und eine grobe Struktur, sozusagen die Epics. Doch dann geht es ans Entwickeln. Das geht bei mir leider nicht in Sprints, weil Schreiben mein Hobby ist – es hat also nicht den gleichen Stellenwert wie Sport, meine Familie (meine Frau und meine Tochter, Haushalt, einkaufen, Instandhaltung, die Pferde meiner Frau), mein Unternehmen (Finanzen, Infrastruktur, Führung), meine Teams (Ausbildung), meine Kollegen (Anleitung und Führung) und meine Kunden (Beraten) oder mein Studium (in dieser Reihenfolge). Erst dann kommt das Schreiben. Es muss also in den Zwischenraum, wo noch ein wenig Platz ist. So wie jetzt gerade 😃 … Meine Frau ist bei den Pferden und reitet mit einer Freundin aus, meine Tochter hängt satt, aber ein wenig quengelig im Tragetuch vor meinem Bauch, ich sitze an unserem Esstisch und schreibe ein paar Zeilen. In diesen Situationen habe ich keine Zeit, lange darüber nachzudenken, was ich schreibe. Produzieren ist beim Schreiben das A und O. Nur was geschrieben ist, lässt sich betrachten, überdenken und überarbeiten.
Und da wir als Scrum-Evangelisten wissen, wie das geht, fängt der Sprint an. Die Timebox dauert so lange, wie meine Tochter friedlich im Tuch sitzt, also etwas über eine Stunde. Dann geht es los. Ich schreibe drauflos. Es fließt von selbst, etwas schreibt in mir. Bevor ich den Satz in den Rechner tippe, weiß ich nicht, was ich schreibe. Genauso war es beim Schreiben des neuen Buchs zur Skalierung. Einfach drauflos. Immer dann, wenn mir ein wenig Zeit blieb, sonntags oder im Zug, im Bus, im Flieger, im Hotel im Frühstücksraum oder im McCafé (das geht echt gut da 😃), habe ich in die Tasten gehauen.
Wie bei allen meinen anderen Büchern lag auch beim Buch zur Skalierung die Kunst darin, ständig zu schreiben, denn sonst musste ich immer wieder nachschauen, wie weit ich gekommen war. Ein Tag Pause war kein Problem. Wenn ich allerdings ein oder zwei Wochen, manchmal ganze vier Wochen nicht am Buch arbeitete, brauchte ich ein bis zwei Tage, um wieder ins Thema hineinzukommen.
Das Schreiben selbst ist nicht das Problem, das Überarbeiten schon. Der Ablauf sieht immer gleich aus: Ich schreibe am ersten Tag drauflos, bis zur Hälfte der Zeit, die ich zur Verfügung habe. Dann sehe ich mir das Geschriebene an und schreibe es oft noch einmal leicht um. Dann schreibe ich weiter. Am nächsten Tag lese ich alles, was ich am Vortag geschrieben habe und schreibe alles wieder um, was mir nicht gefällt. Innerhalb weniger Stunden ist damit schon die dritte Version des Textes entstanden. Nun schreibe ich einfach mit neuen Ideen die nächsten Abschnitte weiter. Ab und zu lese ich noch einmal alles vom Anfang des Kapitels an und schreibe um, was mir nicht mehr gefällt oder wo ich unklar bin.
So geht es in einer Tour, Kapitel für Kapitel weiter. Wenn ein Kapitel fertig ist, gebe ich es Dolores und sie fängt dann an, die vielen Schreibfehler auszubessern und verdrehten Satzwendungen zu entwirren oder ganze Passagen neu zu strukturieren. Sie liest das Manuskript aus der Sicht der Leser und, oh, sie nervt dabei. Immer fragt sie genau an den Stellen nach, die mir selbst noch unklar sind oder sie will Quellenangaben. Das Ärgerliche daran: Es hält auf und bringt mich aus dem Konzept, doch gleichzeitig erhöht das massiv die Qualität des Buchs. So hat sie zum Beispiel eingefordert, dass ich das Kapitel über die Regularien in der Medizintechnik noch einmal genauer ansehe. Oder sie wollte ganz genau wissen, warum ich von einer fraktal skalierten Organisation spreche – mir war es zwar klar, aber ich hatte es für die Leser nicht nachvollziehbar genug herausgearbeitet. Wenn ich das Manuskript inhaltlich abgeschlossen habe, ist aber noch lange nicht Schluss. Dolores bearbeitet das gesamte Manuskript einmal durch, lässt es ein paar Tage liegen, liest es nochmal durch und macht Feinkorrekturen, gibt es dann ins Korrektorat des Verlages und sieht sich anschließend die Korrekturen an, übergibt danach das fertige Manuskript dem Verlag, prüft nach ein paar Wochen das erste Layout, meldet Änderungen an den Verlag, sieht das zweite Layout durch und gibt es frei. Und dann, endlich, geht mein Buch in den Druck.
Würde mich freuen, wenn ich Euch auf mein neues Buch Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen neugierig gemacht habe. Es kommt am 13. Februar 2017 in die Buchhandlungen.
 

Video: Das Scrum Bild

Ken Schwaber und Jeff Sutherland haben uns mit ihrer Darstellung von Scrum sehr dabei geholfen, Projekte in der Hälfte der Zeit mit dem doppelten Resultat zu liefern. Doch dieses Bild unterstützt uns nicht dabei, Projekte mit Scrum zu skalieren oder zu verstehen, wie die User Stories ins Backlog kommen. In diesem Video zeige ich euch, dass dieses Bild von Scrum einem Paradigma angehört, das Entwickler noch immer als Abarbeiter darstellt und den Blick darauf verstellt, dass sie im Unternehmen die kreative Leistung liefern. Das traditionelle Bild passt zu sehr ins Denkschema des V-Modells.
Dreht man das Bild allerdings, zeichnet man es neu, wird sehr schnell die Eleganz der Einfachheit von Scrum erneut sichtbar.
Viel Spaß beim Anschauen — Boris
 

The malicious behavior of non-constraints

Modern managers understand and execute the Theory of Constraints (TOC) to an extent where they can structure and balance their agile company portfolio against the capacity of the company’s constraint (bottleneck). This leads to slack time and lower resource allocation on non-constraints and to some strange feelings and behaviors of people working in non-constraint areas. In this article, I want to take a closer look on the feelings and behaviors of those people. Why? Because I truly believe that management needs to take these feelings and behaviors into consideration in addition to managing the constraint. Because if they don’t, people are going to abuse the TOC management framework until the organization is neither efficient nor effective any more.

Management’s top priority: Manage the constraint

The basic idea on which this article is based is the Theory of Constraints (TOC) which has been described in depth by Wolfgang Mewes in the 1960s and Eliyahu M. Goldratt in the 1980s. The TOC in short describes a management framework that helps to effectively and efficiently manage organizations. The core assumption behind the TOC is that the throughput of every process and every flow of work in every organization is limited by at least one step in the flow of work. If management wants to increase the overall throughput of this flow of work, it should identify the constraint and increase the throughput of this constraint.
This sounds trivial, right? It is. It is quite easy to understand and very hard to master. This article shows you just one – from my perspective insufficiently covered – reason why in practical application this is so hard to master.
I won’t dive deep into the theoretical foundation of the Theory of Constraints. I only want to describe the five basic steps of the management framework TOC by Eliyahu M. Goldratt:

  1. Identify the system’s constraints
  2. Decide how to exploit the system’s constraints
  3. Subordinate everything else to the above decision
  4. Elevate the system’s constraints
  5. If in the previous step a constraint is broken, go back to step 1, but do not allow inertia to cause a system constraint

Consequences of this management priority

As an ultimate consequence of the TOC, management has to deal with the constraint and with nothing else. By doing so, overall (economic) performance of the organization will be improved constantly. On the other hand, this means that non-constraints in an organization don’t receive management’s attention. Non-constraints also receive very limited funds – only as much as needed to not become a bottleneck itself. The underlying assumption is that these funds very likely will be wasted since they don’t increase the overall system’s throughput. It also means that non-constraints always have some capacity left since the overall throughput of the flow of work is only limited by the constraint. You can call this idle time if you want.
By following the TOC management principles, you cannot and you do not want to avoid this idle time. In contrast, you need idle time. Think it in terms of protective capacity: Whoever has some capacity left can adapt quickly to fluctuating demand. You can use idle time to work e.g. on small initiatives that don’t require the constraint’s capacity.

birdys/photocase.de

The feelings and behaviors of people at a non-constraint workplace

I have, as far as I know, never worked in a constraint workplace. Some years ago, I worked as head of a service department for information logistic services. The core task of this department was to ship invoices to clients of all European subsidiaries of this company. It also included scanning incoming documents for the same subsidiaries. The department was crucial for the company since almost all invoices were sent out by this department. The liquidity of the company depended on our work. Nevertheless, it was a non-constraint workplace. Back then I wasn’t aware of the TOC. I wasn’t able to accept that our department was by far not the most important part of the system. I was just a young and highly ambitious department head who wanted to prove his worth.
The top executives didn’t allocate the budget I wanted for all my fancy improvement projects and that upset me. They didn’t tell me why I could not get all the resources I requested. Above all, IT resources were reduced to a minimum. Without knowing it precisely I am almost sure that the IT’s capability to deliver software for supporting the organization’s delivery processes had been the constraint back then.
Since I didn’t understand why this made perfect sense from an overall organization’s perspective, I was quite dissatisfied and to some extent bored with my routine work, that lacked fancy projects and offered no possibility for bringing shiny new service ideas to life. So, I started to actively hack the system. I activated my network across the company, especially in the IT department, and started submarine projects to improve processes within my department. Without knowing it, I caused my peers in all the different departments to start multitasking. I consumed valuable resources that were needed elsewhere. My hacks were damaging the company without me realizing it.
I was bold enough to ask for performance bonuses when I had finished the submarine project against all odds and with almost no official funding by top executives – and I received them. I felt like I was achieving something. The department added services and increased capacity due to improvements. Instead of bringing the whole organization more money, it only increased the overall idle time of this department. But by starting more submarine projects, I unwittingly disguised the fact that my department, my team and I had been idle a good amount of time because my team was heavily involved in those submarine projects.
Now I know that this was local optimization. I understand that this was problematic. But it felt so right.
Interestingly, I worked overtime almost every day. I was pushing my team and other colleagues hard to achieve arbitrary deadlines because I desperately wanted to achieve something. Having slack time felt wrong. Or to rephrase it: It didn’t come to my mind that slack time would have been better for me and the company than being busy all the time.
While we were doing the ship building flow simulation in a recent training workshop, one participant stated: „I just cannot sit around doing nothing. This cannot be right. I need to do something. This is not efficient at all.“ And the participant was right. Having parts of your system being idle is not perfectly efficient. And it doesn’t need to be. When systems (and organizations are systems) are built to achieve throughput, then getting things done is more important than efficiently using all the resources in the system. Getting things done means being effective, not being efficient. I don’t need every step in the flow of work to be fully utilized to increase overall throughput. On the contrary: (Over-)Utilization is harming the organization’s overall performance, creates waste and exhausts employees. True, “the winner is always the most efficient at being effective” (Thanks, Steve Tendon for that quote). This doesn’t mean that everybody must run at full speed all the time.

Why this seriously matters

Since working as a consultant, I’ve seen my own old behavior repeatedly in my clients’ organizations. I’ve seen multitasking as a result and the negative effect it has on people and organizations. I’ve seen managers who were hacking the system themselves to achieve some kind of local optimization. This is always bad! Seriously, this behavior must be avoided. The optimization of the system’s parts don’t result in an optimized system. The flow through the parts of the system needs to be optimized which often means that the interactions between the system’s parts need to be optimized.
Employees search for mastery, autonomy and purpose as Daniel Pink expresses it. They spend lots of their lifetime in their jobs. So, it is understandable that they seek for these three drivers in their jobs. Moreover, employees want attention and acknowledgement by peers and managers. If managers only manage constraints, this might lead to artificial constraints all over the company just to receive some management attention. If managers acknowledge people only when they are being busy, all the employees in an organization will ultimately become busy. You will always get what you measure. This busy business creates waste, decreases overall throughput, and burns out employees.

Management’s accountability

It’s the management at ‚the top‘ of the organization that is responsible for setting the organization’s agenda. First, this means to find and manage the organization’s constraint. It’s easier said than done since everybody in the company is most likely busy all the time and thus working at full capacity. If everybody is busy all the time you can hardly see the systems bottleneck. So, management needs to reduce the overall work in progress (WIP) to a point where multitasking is (almost) avoided. This can be achieved by making the current work in progress visible (e.g. with task boards). Soon they are going to find the constraint of the organization. Most likely this will be the one part of the system that remains fully utilized even if the workload of the whole system is reduced dramatically. Of course, management then should follow steps two to five of the list above.
But that is not enough, unfortunately.
The whole organization needs to know where the constraint is. To be clear: Being the constraint is nothing bad because there will always be one. It is nobody’s fault to be the constraint. So, don’t blame anybody. It’s the process, the policies or the system design that creates the constraint. When the whole organization understands where the constraint is and how this constraint can be elevated, then it is the management’s obligation to avoid useless utilization for non-constraints.
This sounds obvious; however, I’ve seen it the other way round all too often to not mention it. Slack time has to be clearly allowed in the organization. Even jocular sentences like: „Oh, you are leaving already? Do you only work part time?“ create an environment in which employees might feel pushed to work harmfully and completely useless overtime. Management should lead by example and should acknowledge employees who use their slack time self-confidently.
Management then has to create a project (or initiative) portfolio for the overall organization in order to constantly balance the demand for change against the organization’s throughput and to avoid the reoccurrence of multitasking. This portfolio must be reworked constantly and needs to be communicated clearly within the whole organization. The underlying principles of portfolio decisions should be communicated as well. The organization’s health will increase significantly as soon as employees understand that this portfolio aims at increasing the value for the organization and at avoiding multitasking. 100% utilization is nothing to aim for.

The power of budget allocation

Management needs to allocate funds strictly and stick to its decision as long as it is needed. Funding is not meant to please people. It is all about effective resource allocation and the avoidance of multitasking. Whoever has no funds may not be allowed to use a team’s capacity. There is a role in Scrum that has the accountability to fend off those requests: the ScrumMaster. Consistent (management) behavior, that is visible in day-to-day decisions, will change the organization’s culture for the better over time.

Summary

From my personal experience, I can tell that working at a non-constraint workplace doesn’t feel right with a utilization mindset. This is especially true if the organizational culture seems to regard busyness as an indicator for performance. Employees seeking mastery, autonomy and purpose might hack your system in order to achieve their own (local) optimizations. This is natural and harmful at the same time. It’s the management’s challenge to behave in a way that allows a culture of adequate utilization to emerge. This prevents multitasking, frees employees’ schedules and increases the overall system’s throughput.

Agile methods in safety-critical projects

Before I joined borisgloger consulting, I worked for a software vendor that delivers solutions for safety-critical environments. While we initially tried to manage the development with traditional project management methods, we switched to more agile methods over time. During this time I also was constantly in contact with the Vienna Institute of Systems and Safety Engineering, in particular with Hans Tschürtz. Together we developed a procedure model that allows the usage of agile methods while ensuring compliance to safety standards.
Agile in safety-critical projects has become a more important topic today than five years ago, when we started developing our ideas. Agile is everywhere, especially in the automotive industry. Customers and users value innovative solutions while taking safety for granted. They even punish companies if there are only minor indications that safety is not assured – refer for example to the discussion about the driving assistance system of Tesla. Thus we need a development approach, that allows being innovative and flexible while ensuring upmost safety for potential users. In the following paragraphs I will discuss the key success factors of such an approach.

The Team

Cross-functional teams are most important in agile development. We need to have all the skills that are necessary for developing the product represented in the team. In safety-critical projects this requirement calls for the integration of a safety engineer in the development team. Further we should treat safety like quality – a value everyone in the team has to care about.

The Start

When starting a safety-critical project, we recommend an initial workshop phase, in which the whole development team plus experts analyzes the requirements, elaborates a first rough technical concept and performs a first safety analysis. Depending on the context and size of the project, this workshop may last from 2 to 10 days. We don’t believe that it is necessary to do months of analyzing and designing. To keep the workshop attendees focused we recommend to carry out the following workshop off-site.
The workshop itself is split in four parts:

After elaborating those parts, the results lay the foundation for the development project, that can now start with its iterations.

Impact Assessment

During the iterations, every new user story has to be assessed if the new functionality has an impact on the current safety concept. Are the new hazards introduced? Do we need new safety measures? A first analysis can be already done during the backlog refinement meeting. The more cross-functional a team is, the easier the identification should be. If the user story has an impact, the team knows that at least some parts of the safety concept have to be updated in the iteration.

Definition of Done

To maintain an overview of what is necessary if the user story has an impact, you can make use of your Definition of Done. Just add all required tasks, for example an update of the Functional Failure Analysis or an update of the safety case. Of course, this checklist can be quite long for safety-critical projects, but that’s the constraint that such projects have to face.
I hope you got a little insight in how safety-critical projects can be tackled with agile methods. If you have any further questions, don’t hesitate to contact me.

ScrumMaster: Wie setze ich ein gutes Scrum-Team auf?


Derzeit arbeite ich als Agile Coach und unterstütze meinen Kunden in der täglichen Arbeit mit Scrum, d.h.: Rollencoaching der ScrumMaster und Product Owner, Ausbildung der internen agile Coaches und Durchführung eines Intensivcoachingprogramms für neu startende Scrum-Teams. Ähnlich wie in dem Comic oben kommen bei meinen neuen ScrumMastern zwei Fragen auf:

  1. Was mache ich jetzt als ScrumMaster?
  2. Wie setze ich mein Team auf?

Auf die erste Frage möchte ich nur kurz eingehen, denn was ein ScrumMaster machen sollte, ist euch wahrscheinlich hinlänglich bekannt und wird in anderen Quellen ausgiebig behandelt: Der ScrumMaster ist verantwortlich für den reibungslosen organisatorischen Ablauf inner- und außerhalb seines Scrum-Teams. Er löst Impediments und agiert als Coach für seinen Product Owner und sein Development-Team. Zu guter Letzt arbeitet er als Change Agent mit anderen ScrumMastern in seiner Organisation daran, diese bei der Transformation zu einer agilen Organisation zu unterstützen.
Mehr Informationen zu den Aufgaben eines ScrumMasters findest du in diesem Blogbeitrag und Video von Boris Gloger oder in der 5. Auflage von Scrum – Produkte zuverlässig und schnell entwickeln.
Hier und heute ist mir die Antwort auf die zweite Frage besonders wichtig.

Das Team aufsetzen

Idealerweise ist das Scrum-Team crossfunktional aufgesetzt und besteht aus T-Shaped Professionals. Dabei bedeutet Crossfunktionalität, dass ein Team alle Skills besitzt, die es zur Produktentwicklung und –umsetzung benötigt. Ein crossfunktionales Team kann beispielsweise aus zwei bis drei Entwicklern, einem Tester und einem Testautomatisierer, einem Architekten und einem UX-Designer bestehen. Somit sind die Voraussetzungen für eine End-to-End-Entwicklung des Produkts im Team geschaffen.
T-Shaped Professionals besitzen tiefergehende Fähigkeiten in einer Disziplin und sind gleichzeitig in der Lage, sich aus angrenzenden Tätigkeitsbereichen Wissen anzueignen und innerhalb des Teams anzuwenden. Beispielsweise kann ein Tester nicht nur Testfälle schreiben und testen, er versteht auch einfache Codestellen der Entwickler und kann so simple Codefragmente selbst schreiben. Ebenso verhält es sich mit dem Architekten. Die Vision jedes Scrum-Teams sollte es sein, so viel Wissen wie möglich auf die einzelnen Köpfe zu verteilen. In absehbarer Zeit kann beispielsweise die Entwicklung der Architektur vom Dev-Team übernommen und  vorangetrieben werden.
Ein Team sollte nicht mehr als 7 bis 9 Mitglieder haben. Ist das Team größer, sollte man das Team wenn möglich (sinnvoll) teilen.

Und in der Unternehmenspraxis?

In den meisten Unternehmen, die mit Scrum starten, ist es nicht möglich, die ersten Scrum-Teams von Anfang an crossfunktional und t-shaped aufzusetzen. Das liegt meistens daran, dass einerseits die Mitarbeiter in mehreren Projekten gleichzeitig eingesetzt sind und ihnen die Zeit fehlt, sich bewusst und engagiert im Team einzubringen. Andererseits wird erst mit der Einführung von Scrum aufgedeckt, welche Skillprofile das Unternehmen wirklich braucht. Meistens müssen die passenden Mitarbeiter erst am Markt gefunden werden. Scrum startet allerdings nur selten auf der grünen Wiese. Daher sollte man zunächst einmal mit den vorhandenen Ressourcen und gegebenen Constraints arbeiten. Das Management sollte von Anfang an einbezogen werden, etwa in kurzen Meetings, in denen der ScrumMaster immer wieder die beschriebenen Impediments transparent aufzeigt. Mit der notwendigen Portion Geduld wird sich stückweise etwas ändern und das Team wird sich zu einem High-Performance-Team entwickeln. Immer wieder werden faule Kompromisse eingegangen, zum Beispiel wird ein Tester für drei Scrum-Teams eingesetzt. Für die fokussierte Arbeit in einem Team ist das nicht förderlich, trotzdem ist es gängige Praxis. Auch hier gilt wieder: Das Management einbinden und gemeinsam nach Lösungen suchen.
Hat eine Organisation einen höheren agilen Reifegrad erreicht, startet ein erfahrener ScrumMaster erst dann mit seinem Team, wenn ein Großteil der Mitglieder mindestens zu 60-70 % für das Scrum-Team verfügbar ist. Außerdem wird er darauf achten, so bald wie möglich einen Tester zu 100 % im Team zu integrieren. Innerhalb des Scrum-Teams fördert er den Wissenstransfer, damit auf eine End-to-End-Entwicklung hingearbeitet wird. Entweder braucht das Scrum-Team im Idealfall keinen eigenen Architekten mehr oder das Dev-Team ist in der Lage, mit dem Architekten gemeinsam die Softwarearchitektur weiterzuentwickeln.
Ein weiteres gängiges Modell aus der Praxis sind verteilte Teams. Die Teammitglieder befinden sich nicht an einem, sondern an mehreren Standorten. Manche Unternehmen sind in dieser Situation besonders kreativ, wie ein Beispiel aus meiner eigenen Erfahrung zeigt:

Es ist möglich, auch als verteiltes Team gute Ergebnisse zu erzielen. Dazu braucht es einen ScrumMaster, der vor allem in der Anfangsphase darauf achtet, dass das Team mindestens 3 Tage pro Woche gemeinsam vor Ort verbringt und entwickelt. Nur so können sich die Teammitglieder gegenseitig kennenlernen und ein Wir-Gefühl entwickeln. Die Sprintwechsel werden selbstverständlich auch gemeinsam durchgeführt. Hierbei empfehle ich, den Sprintwechsel auf zwei Tage zu legen. Am ersten Tag Anreise, Review und Retro, abends kann das Sprintende mit allen gefeiert werden. Am nächsten Tag finden im Laufe des Vormittages Sprint Planning I & II statt. Anschließend kann das Team gemeinsam starten, bevor sich alle wieder auf den Weg nach Hause machen. Bei einem Kunden beispielsweise legten die auf vier Standorte verteilten Teammitglieder in Summe 600 km pro Woche zurück, um die Meetings und den Sprintwechsel gemeinsam an einem Ort durchzuführen.

 
Wende dich als ScrumMaster beim Aufsetzen deines Teams beispielsweise an den unternehmenseigenen Agile Coach oder an andere ScrumMaster und bitte das Management sowie HR um Unterstützung. Oder wende dich an uns 🙂
 

And so this is Christmas?

I do like Christmas. I like the decoration, the presents, the tree, the Christmas markets in all the different cities, meeting and feasting with family and friends, snow and people going nuts to find the right presents for their loved ones. But there is one thing I cannot stand. Honestly, I do not like to sing Christmas carols. I loathe it. I am not good at it and believe me – you wouldn’t want to hear me sing.
One could say that this is all Christmas is about: Thinking of the birth of Jesus, singing some carols, celebrating with friends. Is it less of Christmas, because I do not go to church? Would it stop being the „Fest der Liebe“ if we did not have a Christmas tree? What about the people who stopped exchanging gifts for Christmas? And is it less of a reason to celebrate because I do not sing? When does it stop to be Christmas? What is absolutely necessary in order to be allowed to call it so and what is optional? Who decides? And what happens if we ignore the decision and still have the opinion, that it feels like Christmas?

I recently had a discussion on how to help one of our customers. Everyone who regularly deals with Scrum knows that it is most powerful when the roles, meetings and artifacts are used together. The overall framework is thought-out, proven and tested. Planning without reviewing doesn’t make much sense. We know that people should have a kind of understanding for the big picture and for the work items which are coming up next, because that gives a better understanding and more confidence, even if plans are a-changin’. It makes sense to meet in short intervals to check whether the initial plans still are valid. And it is sensible to reflect from time to time to see whether there is something that can be improved.
However, I see that companies often cannot digest so big a change at once. In these situations I would rather take baby steps in the direction of a complete Scrum implementation. I propose to look out for the most pressing issue at the moment and see which meeting, role or artifact might be most useful. „But that ain’t Scrum if we only have Dailys and Planning meetings“ one may say. Really? Is it only Scrum if we have all the roles, meetings and artifacts in place and working? Or is it ‘almost, but not quite, entirely unlike Scrum’? Isn’t it more about the general spirit and mindset, which really counts? Who decides? Scrum.org? Jeff Sutherland? Boris Gloger?
In fact I don’t really care. I don’t see myself as being ordered to introduce Scrum but to help companies – to help people – find a solution for their business problems. The essence of a transformation is never the introduction of a new method but working on the beliefs and inner attitudes of the employees – which, by the way, includes managers. If meeting with the team on a daily basis helps, let’s go for it. If dancing with a hula skirt in front of the team and stakeholders every other day is useful, I’ll do it (you got to pay me some extra plus pay for the hula skirt, though). This is the equivalent to buying a Christmas tree if it helps getting in the right mood. Two weeks later people might lust for some cookies.
Nevertheless, I have a clear picture in mind on what a fully fledged Scrum implementation looks like so that I can always decide which is the next sensible step when being confronted with a new problem. I have a vision of where I want my customers to be some time in the future. Is one of the current meetings not as good as it could be? Is there room for improvement for some of the roles? Do we need something completely new? Or – even better – is there something which can be taken away to improve things?
In other words, I have a opinion and some experience of what Christmas should be. Therefore I can decide whether it makes sense to go for some decoration or head for eggnog. You might disagree with my idea of Christmas. You might prefer Santa Claus over the Christkind but that is something I can cope with and we can discuss. However, this doesn’t change my view on my perfect Christmas party.
The most pressing issue of our customer at that time was that the project team had too much to do at once. They were missing focus. New problems, tasks, orders kept dripping in and no one took the time to check whether the team was working on the most important issues. So what we proposed as next sensible step was to start prioritize rigorously in regular short-cycled planning meetings with a reasonable planning horizon to cope with the missing focus and the ever changing tasks to be done.
Is it Scrum? Or just „a“ way of being more agile? I don’t care, it helped. And although I won’t be singing in front of our decorated tree I am sure that I will have a wonderful Christmas holiday.

Magic portfolio prioritization – the Magic Matrix Technique

Whenever I work together with clients in a scaled agile organization, prioritization across the borders of a team or even across large business units is perceived as most challenging by the participating Product Owners, Managers or Shareholders. One of the reasons for this perception is the fact that a common method for prioritization is often missing and thus urgently needed.
In this blog post I want to introduce to you the Magic Matrix Technique that my colleague Karl Bredemeyer and I designed for a large workshop a long time ago. With the Magic Matrix Technique you can prioritize cross-organizational projects and create a unique company backlog that lists all projects of a company in a discrete order. We have used this technique very often since then and it always proofed its value.
The technique is called Magic Matrix just because the client for whom we designed the workshop called it that way after the workshop was over.
It is basically a good combination of the Magic Estimation game invented by Boris Gloger, the Prioritization Matrix invented by Donald Reinertsen, and some facilitation. This technique is very generic and can be used for almost every prioritization approach. That’s why some Product Owners I worked with use it to prioritize their user stories in their product backlog as well.

Initial situation

Let me introduce you to the challenge this client faced that day. Based on a management consulting intervention that we had done before a group of shareholders, c-level executives and top managers from ‘business‘ (e.g. marketing, customer care), ‘technology‘ (e.g. directors of tech, lead architects) and ‘legal‘ for the first time in the history of that company aimed to establish a common company backlog to avoid prioritization conflicts in the development teams. These prioritization conflicts had led to avoidable context switches, multitasking within product development, and thus to poor output of their delivery flow.
All the people named above attended an offsite workshop to bring all the important projects into a discrete order and to consequently allow the different development teams to pull work from that list. As in every business context the total budget for the whole product development was limited – and so was the available time to realize certain projects and initiatives.
The atmosphere in this offsite workshop had been tense since minute one. We did a check-in and asked each participant about his or her intention for attending the meeting. Very often they answered: “I am here to fight for my projects.” After some time of community building and introduction to the topic, the participants wanted to start with prioritization. But how to do this in such a tense atmosphere and with so many strong managers in the room?
Let’s have a detailed look on how to perform the Magic Matrix Technique in order to achieve a (company-wide) portfolio prioritization.

Attendees

Keep the number of attendees reasonably small. I know that everybody has an opinion on project priorities but only few have budgets to run projects. Try to have less than 20 participants.
The selection of attendees to this workshop depends on the specific situation you are facing. If you try to create a company backlog, make sure that each business unit that is requesting resources needed to develop a product has a representative in this workshop. When I say ‚resources needed to develop a product‘ I am not only talking about development resources. Think also of all the ‚shared resources‘ that are necessary to bring a product to life (e.g. purchasing, release management, lawyers and so on).

Overall time frame

Depending on the number of attendees and their experience in collaborating across the company, the time needed for this technique will range from two hours to a bit more than half a day.

Setting

The setting of a workshop always determines the behavior of the attendees. Karl and I chose to create a special setting: we printed out all project requests on A3-sheets and pinned them to the wall. We aimed at creating a feeling of being in a museum or a gallery. Very often those galleries trigger a certain sense of urgency because the attendees are overwhelmed by the sheer amount of projects they want to deliver. Sometimes they immediately understand that they need to say NO to certain projects for now.

On the floor, we had prepared a large square, simply made of white painter’s tape, and two long tape lines next to it. The square contained nine smaller squares. The y-axis was labeled ‘cost of delay‘ and was divided into three sections: low, medium, high. The x-axis was labeled duration of delivery and was divided into short, medium, long. This creates a 3 by 3 matrix that distinguishes 9-fields.

Right, this is the Matrix created by Donald Reinertsen which he derived from prioritization mathematics also known as weighted shortest job first (WSJF / 2).
The two long tape lines repeat the labels of the Magic Matrix (below I’ll explain why). The first taped line was divided into three sections labeled high, medium, low. The second line was also broken down into three sections labeled long, medium, short.

Operation

1. Gallery walk

Let the attendees walk along the gallery that shows every project (or user story) printout taped to the wall and let each project be introduced briefly by the attendee who raised the project.

2. Allow Questions

Allow short questions to improve understanding. This is not about arguing, just about a common knowledge base of each project.

3. Distribute the printouts

Now take the printouts off the wall. In order to run the next part of the session smoothly, only pick around 30 to 40 printouts. In case you have printed out far more projects or initiatives, ask the attendees to pick the one project that is most important to them. Do the same with the second most important project and so on until you have picked around 30 to 40 printouts. In the workshop described above more than 160 printouts were sticking to the walls.
Deciding what NOT to take off the wall was a first emotional moment for the participants.
Let every participant hold one or more printouts in his or her hands. It is not necessary that every participant holds a printout of a project that he or she raised initially.

4. Introduce the cost of delay scale

Introduce the first line of tape on the floor to the participants. This is the line symbolizing the cost of delay (2). The cost of delay is always defined with a specific point of time in mind. Make this point of time explicit to the participants.


In the situation described above, it was a date some months ahead. A highly important media event was going to take place and would have high economical relevance to the whole company. The question at this first line of tape is then: How high will the cost of delay be if we do not finish the selected project completely until that special date in the future? Consider the cost of delay in direct relation to the other projects. Make sure that everybody understands the meaning of the word ‘relation’. It means that you don’t try to calculate precise costs but rather estimate it in close relation to the other projects you are discussing. Don’t try to assume the cost of delay for one project in isolation.

Consider different categories for the cost of delay. The cost of delay is the area below the line.

5. Play the first round of Magic Estimation

With this question in mind let all the participants play one round of Magic Estimation. Magic Estimation is an Estimation game that was invented by Boris Gloger many years ago and has proven its value in countless user story prioritization sessions. I will not describe the game in detail. If you are not familiar with the game, feel free to follow the link.
Instead of using the modified Fibonacci scale as you might know it from the original Magic Estimation game (you can buy a Magic Estimation poster to facilitate estimation meetings on our website) or from planning poker, we only use these three sections of the scale: low, medium, high. It is essential that all the participants remain silent during the whole round. Talking will disrupt the flow and impact the outcome of the estimation negatively.
The facilitator, who might be you, looks for projects that jump from one section of the scale to another. Those printouts are marked with a dot in a specific color by the facilitator. This dot indicates that the participants disagree on the relative cost of delay of this project.
If you perceive that almost all projects tend to move towards the ‚high‘ section of the scale, interrupt the game for a moment. Remind the participants that they have limited resources as well as limited time. Point out that not all projects can be equally critical in terms of cost of delay regarding the specific date defined at the beginning of the session.

6. Agree on the cost of delay category for each project

After the first round Magic Estimation is over and all projects have been put to the floor, grab the first project from the ‚high‘ section that has been marked with a dot by the facilitator. Ask who disagrees with the cost of delay for this project being high.
The project should not be discussed separately but in relation to other projects, so chose some from the high and medium section that did not receive a dot mark. Keep the discussion short and always keep it in relation to other projects without a dot mark and in relation to the specific date in the future you agreed on before. Formulate something like this: “You silently agreed on a medium cost of delay for project A and on a high cost of delay for project B. Is the cost of delay of project C closer to project A or to project B?”
Agree on the relative cost of delay for the project at hand and write it on the printout in the same color as the dot mark.

7. Repeat brief discussions

Repeat these brief discussions for all projects with a dot mark. Keep the discussions short and decision-oriented.

8. Have a coffee break

When you’ve agreed on the relative cost of delay for all projects, have a coffee break and let lots of fresh air into the room. While the participants enjoy their coffee, write the relative cost of delay on the remaining project printouts according to the sections they were put into. It is important that every project printout has its own cost of delay note because you will need this later for sorting the projects.

9. Second round of Magic Estimation

Repeat the Magic Estimation game at the second taped line. Again, every participant receives some project printouts before the game starts.
The question for this round is: “In relation to the other projects: How long would it probably take to finish this project if we only did this single project at a time?” In order to avoid confusion, use a different color now for making the dot marks than you used in the cost of delay round.

10. Agree on the duration of delivery

Agree on the relative duration of delivery for those projects that received a color mark. This again needs some facilitation to avoid long discussions. Remind the participants that this is just a wild guess in relation to the other projects left and right along the taped scale. It is not necessary to be precise.
Write down the assumed duration on the project printout.

11. Sort the projects into the matrix

After this is done, ask all the participants to grab the project printouts on the floor and sort them into the taped matrix on the floor. This is straight forward. Every of the nine squares is described by a specific cost of delay and duration of delivery.

12. Do the elevator

We are almost done. You probably experience that some squares contain more than one project. This is not a problem at all. Do the ‘easy elevator’ next. Start with square 1 (cost of delay high and duration of delivery short) – grab two of the projects in that square and ask for the relative cost of delay again considering the special date in the future. Let the participants explain their opinion and come to a decision.
Now grab one more project out of the same square of the matrix. Ask: “Is the cost of delay of this project higher than of the project currently lowest or is it lower?” Quickly sort the projects until you have a discrete order in this particular square.

13. Create the sequenced company backlog

Take the ordered projects and lay them out in the room in this discrete order. Since you have started with the most critical square 1, you will now experience that discussing the other squares will go more smoothly.
Repeat the ‘elevator‘ and complete the discrete order of the projects until you’ve laid out all projects that you have chosen after the gallery walk.

If there are still projects on the wall

It might happen that there are still some projects left on the wall. Honestly, this is not surprising at all. This actually happened in the workshop described above as well. Reflect on this situation together with the participants: Are these projects really worth being discussed in this workshop? The participants already have a quite big backlog. Long backlogs harm delivery performance and should be avoided.
Make clear that the participants now have a technique at hand with which they can add backlog items smoothly whenever the backlog is almost delivered.

Why it works like magic

1. Overview

Usually cross-company projects or initiatives are discussed, handled and processed each at a time. One prepares a business case and tries to overcome some gates in an approval process.
Opposite to that the Magic Matrix prioritization technique makes all projects visible at once that are important to the company – so one can overview their overall importance and their general contribution to the company goals.

2. Communication

It is not uncommon at all that different businesses or requesting units don’t have to talk to each other when initiating a project. This inevitably leads to the perception that one’s own project belongs to the most important ones or is even the most important project in the company. This often causes conflicts between business units since multiple resource allocations are revealed far too late – that is, when conflicting projects have already started.
When using the Magic Matrix Technique, a lot of valuable discussions arise among the participants. If you repeat this format – let’s say quarterly – the participants get used to collaboration and aim for a shared goal together.

3. Movement instead of mathematics

I assume that Don Reinertsen, who I once met for some days in Essen, would consider this format to be a bit playful and not mathematical enough. And although I highly value Don and his contributions to the art of product development, I have experienced that only few understand his insights and recommendations to such an extent that they can use it practically.
If you don’t have enough time to introduce the principles and ideas behind Don’s ‚Second Generation Lean Product Development‘, this specific matrix suffices to benefit from its strong mathematical basis.
Instead of calculating the cost of delay, you relatively determine it using group knowledge. In his book mentioned above, Don states that humans are not very successful in estimating the cost of delay (COD) of a single item based on intuition. If different experts are questioned separately, the resulting COD values spread tremendously. Relative estimation in the Magic Estimation game and the communication here comes into play: Obviously, values like ‘high‘, ‘medium‘ or ‘low‘ are not precise. But that is not the intended result of this technique.
The goal of this technique is to be fairly accurate and to support decision making in a very short time. Just recap: You initially prioritize a whole company backlog in less than a day!
And because all the projects on the wall are important to the company, it doesn’t even matter if the cost of delay is precise as long as the priorities of the company backlog items are mostly right.
Prioritization means to sort and sequence. It is important to consider that – with all due respect to mathematics – this is a decision. I often experience ‘decisions by Excel‘ which means the decision to prioritize some project or feature is somehow ‘outsourced‘ to a spreadsheet to avoid clear decision making.
Don’t forget that there is a ‘No’ in every decision: prioritization also means not to do something else that has less or no priority. Saying ‘NO‘ is the ultimate tool to avoid system overload thus resulting in low performance.

5. Agreement

Generally you ‘just‘ need to agree on resource allocation and on the method you use in order to achieve this allocation. Both will be reached with the Magic Matrix Technique – it is fast and, maybe surprisingly, it is also fun. Not to forget that the initiated discussions about business goals among all participants are as valuable as the prioritized company backlog itself.

6. Speed

Since this technique can be executed fast and with little effort, it can be repeated several times a year. This helps to constantly refine the company backlog which allows strategic adjustments more often without harming the currently running product development process.
In the end this makes the company more adaptive. It even allows to decrease the size of projects to a bare minimum because you can reduce the forecasting cycles. As soon as your management team is capable of constantly and effortlessly adjusting the company backlog, you can run prioritization sessions more frequently. This reduces the investment risk and allows quicker market feedback, which ultimately results in better products and more revenue.

What happened then

The client which first participated in the Magic Matrix workshop still uses this technique to prioritize the company backlog. Over time it evolved into a strategic product portfolio. The Magic Matrix is not only used for the company portfolio. It is also used to prioritize team backlogs which have a higher granularity.
Today, for this client prioritization conflicts belong to the past. The product development teams are more focused and are thus able to deliver faster and in higher quality.
In this workshop we created a shared view of the company’s priorities across the business domains. Over time a cross-domain top management Scrum team emerged which adjusts its shared strategic product roadmap once a month in an office workshop.

Additional information: Constraints to this technique

As far as ‘mathematical logic‘ behind the presented technique is concerned, we are talking about the division of cost of delay and the duration of development. This calculation is also called CD3 calculation. It fits with Scrum very well since it focuses on time dependencies and thus fosters delivery focus.
Nevertheless, there are some limitations to this technique. Using the Magic Matrix Technique will be beneficial if the compared backlog elements show distinguishable costs of delay. Sometimes backlog elements are so closely related to each other that you can hardly distinguish the delivery of one item from the other. In this case, it helps to find an overarching backlog item that integrates the smaller items.
Using the overall delivery duration as criteria for prioritization is only truly beneficial if the participants of this workshop don’t know the ‘organizational constraint‘ of their delivery flow. If the participants know the constraint, it is not recommended to consider the whole delivery duration. Use the processing duration of the delivery step that constraints the overall delivery flow instead. This calculation technique is called throughput octane (or product octane).
However, management teams performing the prioritization of a ‘company backlog‘ for the first time are hardly ever familiar with the ideas of the theory of constraints. Therefore, it is very unlikely that they are able to precisely name their constraints, which makes it impossible to calculate or estimate the throughput octane. Which leads back to the Magic Matrix Technique as being ‘good enough‘ for the described purpose of prioritization.

Why Scrum does not work

Many organizations I have worked with in implementing Scrum were disappointed with their inability to deliver. Well, they do not put it that way, they tell me: „Scrum does not work“, „It produces too much overhead“, „The team is not as productive as promised by Scrum“ or „Customers do not want to do Agile anymore because they do not see any value in it“.
In the past, I always had the feeling that this was an invitation to the boxing ring. I felt like I had to defend myself and the values I offered as an Agile Coach. By now I have come to the conclusion: I do not have to defend anything. I believe in Scrum and I know that it works if implemented and applied correctly, adapted to organizational needs. That leads me to my second enlightenment: If the principles are respected and the rules offered by the framework are respected, Scrum not only works but also reduces overhead, makes teams more productive and delivers value to the customer.
So instead of stepping into a fight over Agile and Scrum, I ask the following questions:

If you can answer all these questions with an honest „yes“, I am happy to dive deeper with you inside your organization to understand, why the results do still not meet the expectations. If you cannot answer all the questions with a bright „yes“, I am also happy. Because now we can start doing Scrum.

Österreichische Scrummies aufgepasst: Umfrage zu Scrum-Zertifizierungen

Wie wichtig sind Scrum-Zertifizierungen in Österreich? Wie verbreitet sind die Zertifizierungen inzwischen und welchen Nutzen haben sie? Diese Fragen stellt sich Andreas Lakmann im Rahmen seiner Bachelorarbeit “Der Stellenwert von Scrum-Zertifizierungen in Österreich -Empirische Untersuchung zur Bedeutung von Scrum-Zertifizierungen aus Sicht der Belegschaft und Unternehmen”. Dazu hat er einen Fragebogen entwickelt und sucht nun möglichst viele Personen, die den Fragebogen ausfüllen. Die Fragen richten sich einerseits an Mitarbeiter, die bereits eine Scrum-Zertifizierung haben) und andererseits an die Weiterbildungsspezialisten aus HR-Abteilungen sowie an Abteilungsleiterinnen und -leiter.
Auch mich selbst interessiert diese Frage sehr, deshalb helfen wir Herrn Lakmann, das richtige Publikum anzusprechen. Ich fände es toll, wenn ihr bei dieser Umfrage mitmachen würdet! Es geht auch wirklich schnell, länger als 5 Minuten solltet ihr nicht brauchen. Natürlich werden alle Angaben vertraulich behandelt.
Hier ist der Link zum Fragebogen für Mitarbeiter (vorranging Personen, die bereits eine Scrum-Zertifizierung haben): https://www.netigate.se/a/s.aspx?s=340211X71675706X57806
Link zum Fragebogen für HR-Abteilungen und Abteilungsleitungen:
https://www.netigate.se/a/s.aspx?s=340762X71324788X64264
Vielen Dank für eure Unterstützung!
Boris

Hélènes column: Product Owner wanted!

The other day, another kick-off workshop with a pilot team in hardware. Regarding NDAs, I cannot get into details about the product – nevertheless I want to share with you some impressions. Most people were highly motivated by the product vision. Me too, after a team member had explained it to me but not anymore after I had spoken with the current Product Owner! The team member I had asked about the vision told me the following: “It will be the fastest device ever developed for this production process and we do it for company XXXX, the market leader! The challenges are to realize these production steps but also to make it faster than ever before. And I am quite excited that – by the way – we also try a new way of working.”

I asked the Product Owner the same question, and he answered: We want to develop a device which will contain modules X, Y and Z and use the following technology and the customer wants it mid 2017.“ I gave him a second chance: „What is YOUR vision for the product?“ He answered: „My vision for the project is of course to deliver the product. And it will be great if we can implement 60% of Scrum in this project. I will be happy with that.”

This story points out an issue that – unfortunately – occurs very often:

You can work with or in the most amazing companies, offering the most exciting products (cars, planes, rockets, or what have you) and you will still have difficulties finding real Product Owners, people blazing for the product, able to articulate and communicate a vision and inspire others.

Managers today are mostly focused on managing resource allocation, projects and work packages! Well, I know that most of the companies are project based organizations, switching resources from here to there according to deadlines or resources utilization rate. Switching to a team and product based organisation is one of the biggest challenges. I once again have to refer to Elon Musk as an inspiration for Product Owners because when we listen to SpaceX employees it sounds like this: „There was always this feeling that we were facing a sort of insurmountable challenge and that we had to band together to fight the good fight.”

Musk’s mission statement is impressive: „The only thing that makes sense to do is strive for greater collective enlightenment.”

Video: Die Rollen in Scrum

In den letzten Jahren sind mir in zahlreichen Gesprächen immer wieder die vielen Ideen dazu aufgefallen, welche Rollen es in Scrum gibt. Von einigen habe ich gehört, es gäbe den ScrumMaster, den Product Owner und das Team – möglicherweise noch ein paar Stakeholder.
In diesem Video erkläre ich euch meine Sichtweise auf das Thema Rollen. Aus meiner Sicht gibt es mindestens 6 Rollen und wenn man will, kann man die Rolle der Stakeholder als 7. Rolle einführen. Doch das nur am Rande – die Erklärung dazu wird es in einem anderem Video geben. Nur soviel: Wer verstehen will, wie man Scrum am besten skaliert, kommt um die Idee der Small World Networks nicht herum. Dazu braucht man wiederum ein klares Bild der Rollen in Scrum und davon, wie sie zusammenspielen. Dieses kurze Video soll uns dabei unterstützen, ein gleiches Bild der Rollen in Scrum zu entwickeln.
Viel Spaß beim Anschauen! — Boris

Video: Werte und Scrum!

Wer Scrum verstehen will, muss sich neben dem Prozessmodell von Scrum auch mit Scrum als Haltung auseinandersetzen. Scrum-Praktiker richten sich u.a. an den diesen essenziellen Werten von Scrum aus: Mut, Offenheit, Respekt, Commitment und Fokus.
 
Scrum-Werte_borisgloger
 
Obwohl ich mich nun bald zwei Jahrzehnte mit Scrum beschäftige, ist es auch heute immer wieder nützlich, mir die Werte von Scrum vor Augen zu führen. Dann wird mir klar, dass ich zum Beispiel gerade den Fokus nicht halte oder noch keinen Weg gefunden habe, die freiwillige Teilnahme (= Commitment) in einem Unternehmen zu etablieren. Die Werte von Scrum sind es, mit denen man auch über Scrum als Framework für die Skalierung nachdenken kann.
Viel Spaß beim Anschauen! — Boris
 

How to get customers on board

Just the other day I was meeting the representatives of a potential new client. As we were discussing their expectations regarding Scrum they brought up a topic that has made me curious for some time now: „Our clients do not understand what we are doing. We need to explain them how to write good requirements according to Scrum and train them on the method.“ First of all, I do not want to talk about expectation management in agile product development and I also do not want to talk about a “you-change-and-I-don’t“-culture. What I would like to talk about is how to get an internal or external client, the management or even regional Key Users aboard this Scrum flight.
I can offer an easy answer: „Do it!“ That is all! Involve your users in the process, deliver continuously, reflect and adapt and use the framework to let them find their role and contribution.
Now here’s the not-so-easy answer: „Do it!“ Of course, customers will not understand why they have to be with the team for a Review meeting every second week when everything is going well anyway. They will not understand why they should take part in a Backlog Refinement session every week, and if the team is really ambitious they also have to attend the Sprint Planning every second week. They will probably not understand why they have to prioritize requirements together with the Product Owner and why they have to let go of some ideas, because in the past they only had to point out the requirements they wanted. And most probably at the beginning, customers both internal and external will not see the benefit of telling the Development Team what they do in their departments every day, how they work and answering questions they do not have the feeling a developer should care about.

Make them an essential part of your daily routine

Here’s the cure: Keep them in the loop. Let them become an essential part of your daily routine. Talk to them. Make them feel valuable for the development process. Listen to them. Understand them. Make them feel what it means to be part of Scrum. And again, that is all! All the concepts you write for communication channels, all the explanations you give on your work and all the trainings that you consider helpful to make them understand are only as good as your daily practices and communication routine with them.
However, you need to explain your why. Why do you do the things you do and why do you mean to change current ways of working relations? If that is clear to you, you can make it clear to them. And then, after some nice talks, maybe two or three joint retrospectives and finally, after the first delivery that meets the expectations in solving their daily problems and in which they can see their ideas growing, they will value the close working relationship and the quick feedback that this framework offers. And soon, they will not leave the plane before take-off anymore.

Agilität für Gesellschafter: 7 Schritte, den Unternehmenswert nachhaltig zu steigern (Teil 1)

Dieser Blogbeitrag begleitet den gleichnamigen Vortrag von Karl Bredemeyer und mir auf der Agile Bodensee 2016.

Vor einiger Zeit arbeiteten wir in einem großen Beratungsmandat, bei dem es darum ging, die Zusammenarbeit in einem Unternehmen über die gesamte Wertschöpfungskette – von der Idee bis zur Auslieferung des Produkts an den Anwender – zu optimieren. Das übergeordnete Ziel des Auftraggebers war es, die Lieferfähigkeit seiner Organisation deutlich zu steigern und die Produktentwicklung stärker auf die Bedürfnisse der Anwender auszurichten. Wir analysierten die Ausgangssituation und stellten fest, dass es eine große Distanz zwischen der Seite der Anforderung und der Seite der Produktentwicklung gab. Vereinfachend ließ sich der Befund wie ein großer, tiefer Graben zwischen Produktmanagement und Anwendungsentwicklung beschreiben.
Innerhalb dieses Beratungsmandats gelang es uns, die Brücke zum Gesellschafterkreis des Unternehmens zu schlagen. Die Gesellschafter unterstützten die Prinzipien agilen Arbeitens mit dem expliziten Ziel, den Wert des Unternehmens zu steigern und verpflichteten das Topmanagement zur gemeinsamen Verbesserung der Lieferfähigkeit in einem unternehmenseigenen „agile way“, der den Anwender in das Zentrum sämtlicher Aktivitäten stellt. Entlang unserer Empfehlungen begann nun die Optimierung der Lieferkette.

Wann agiles Arbeiten funktioniert

Machen wir es kurz: Agiles Arbeiten funktioniert in der Praxis nur dann, wenn es das explizite Ziel ist, mit der Agilität den Unternehmenswert nachhaltig zu steigern. Sie als Gesellschafter sind es, die agiles Arbeiten zum Wohle der Wertsteigerung im Unternehmen und damit zu Ihrem eigenen Wohl vorleben und einfordern sollten. Dadurch wird Agilität zu einem immateriellen Vermögenswert Ihres Unternehmens, zur DNA der Organisation und zu einem Teil der Unternehmenskultur. Dies macht eines deutlich: Es geht bei der Einführung von Rahmenwerken wie Scrum, Kanban etc. im Kern weder darum, Entwicklungsteams produktiver zu machen oder ein Taskboard in ein Großraumbüro zu stellen und bunte Zettel darauf von links nach recht zu schieben, noch geht es darum, die Mitarbeiter zufriedener zu machen, auch wenn das ziemlich oft ein erfreuliches Ergebnis agiler Unternehmensführung ist.
Eine agile Transformation ist eine große Investition und erfordert Geduld – vor allem Ihre Geduld und Ihr unbedingtes Buy-In als Gesellschafter. In dem Augenblick, in dem für Sie der Zusammenhang zwischen agilen Führungs- und Entwicklungsrahmenwerken und der nachhaltigen Steigerung des Unternehmenswertes klar geworden ist, hat Agilität eine echte Chance, zu einem Teil Ihres Unternehmens zu werden und eine positive Wirkung im Sinne der Wertsteigerung zu entfalten. Ohne den Zusammenhang zwischen Agilität und Unternehmenswertsteigerung bleibt agiles Arbeiten nur Kosmetik.

Liebe Gesellschafter, es geht um Sie!

Niemand weiß es besser als Sie: Die heutigen Zeiten sind geprägt von einem komplexen Markt, diffusen Kundenwünschen und erheblichem Wettbewerbsdruck. Es ist in Ihrem Interesse, Agilität mit ihren Facetten zum Betriebssystem Ihres Unternehmens, Ihres Investments zu machen.
Sie als Gesellschafter können den Wert Ihres Unternehmens mit 7 Schritten nachhaltig steigern. Diese 7 Schritte bauen aufeinander auf. Sie sind wie ein Turm: Lassen Sie einzelne Elemente aus, ist der Erfolg nicht mehr sichergestellt. Die 7 Schritte zur Steigerung des Unternehmenswertes umfassen

  1. die Werte,
  2. die Finanzen,
  3. die Organisation,
  4. die Methode und die Skills,
  5. die Produktentwicklung,
  6. die Architektur und
  7. die Infrastruktur.

Betrachten wir in diesem ersten Teil die Schritte 1 bis 4 näher.

photocase7ocpo6gba68m1

picea/photocase.de

1. Die Werte

Die Kenntlichmachung agiler Werte bildet das Fundament für jede agile Transformation. Hierzu gehören nicht allein die fünf Scrum-Werte Fokus (der wichtigste!), Mut, Commitment, Offenheit und Respekt oder die Verortung auf dem agilen Manifest, sondern auch die Integration von Lean-Prinzipien (eliminate waste, Pull etc.). Als Gesellschafter sorgen Sie in letzter Konsequenz für die Ausrichtung Ihres Unternehmens, selbst dann, wenn das operative Management an ein C-Level-Board übertragen wird. Sie als Gesellschafter sollten persönlich und erkennbar vorleben, dass diese Werte eine Bedeutung für Ihr tägliches Handeln besitzen. Es ändert zum Beispiel die Kultur Ihres Unternehmens, wenn Sie immer wieder klarmachen, dass es wertvoller ist, etwas zu Ende zu bringen, statt etwas Neues zu starten. Für die ledigliche Ankündigung einer Lieferung gibt es von Ihnen keine Anerkennung mehr.
Sie haben darüber hinaus die Verantwortung, das Mindset zur kontinuierlichen Verbesserung in kleinen Schritten in das tägliche Handeln der durch Sie beeinflussten Manager zu übertragen. Von dort aus wird sich dieses im Unternehmen verbreiten. Nutzen Sie beispielsweise regelmäßige Retrospektiven auf allen Ebenen der Organisation als Taktgeber für diese Verbesserung.

Zusammenfassung

2. Die Finanzen

Agile Produktentwicklung wird von Wirtschaftsprüfungsgesellschaften wie KPMG inzwischen als Asset gewertet, falls diese in der Unternehmung verankert ist, da sich daraus eine schnelle Reaktionsfähigkeit sowie eine hohe Produktqualität ableiten lassen. Genau diese Reaktionsfähigkeit und Produktqualität leiden jedoch häufig unter der klassischen Kostenrechnung und der damit verbundenen Überbetonung der Kostenkontrolle und lokalen Effizienzgewinne. Der zweite logische, aber mutige Schritt zur Steigerung des Unternehmenswertes bewegt sich weg von der klassischen Kostenrechnung hin zu einer durchsatzorientierten Betrachtung der Wertschöpfungsprozesse (Stichwort Throughput Accounting). Aus diesem Perspektivenwechsel leiten sich für Sie eine Fülle von Möglichkeiten ab, neue qualitative Managemententscheidungen zu treffen.
Bei diesem Schritt können Sie sich von einem Leitgedanken führen lassen: Finanzdaten und die Prozesse zu deren Erhebung dürfen die Mitarbeiter nicht an ihrer eigentlichen Arbeit hindern, nämlich Nutzen für den Anwender zu generieren. Das führt Sie zu neuen Möglichkeiten der Freigabe von Investitionsbudgets. Verlegen Sie in der Bewertung von Investitionsentscheidungen Ihren Schwerpunkt von den (ohnehin kaum sinnvoll prognostizierbaren) Kalkulationen des Returns on Investment hin zu Risikoszenarien. Statt zu fragen: „Wie viel erhalte ich in den nächsten Jahren zurück?“, stellen Sie die Frage: „Wie viel lasse ich das Investitionsexperiment maximal kosten, bis ich meine Mittel stoppe?“ Oder fragen Sie nach der Cost of Delay: „Wie viel Umsatz steht auf dem Spiel, wenn ich dieses Investment nicht oder später tätige?“
Dieser neue Schwerpunkt bei Investitionsentscheidungen wird die Art des Diskurses in Ihrem Management positiv beeinflussen. Wir haben bereits Manager erlebt, die selbst wie Investoren agierten. Mitarbeiter konnten Investitionsvorhaben (Projekte) pitchen und um Mittel werben. Daraus erwächst im Laufe der Zeit eine Unternehmenskultur, die das Probieren und Lernen der Risikoaversion vorzieht.

Zusammenfassung

3. Die Organisation

Eine Organisation ist nur so schnell wie ihre langsamste Liefereinheit – sowohl in einem Transformationsprozess als auch in der Entwicklung und Herstellung von Produkten. Am besten adressieren Sie daher im 3. Schritt die folgenden Themen auf der Ebene der Organisationsentwicklung:
Jeder Manager der Organisation sollte die Theory of Constraints (ToC, auch Engpasstheorie genannt) verstehen und in sein praktisches Handeln überführen können. Verkürzt beschreibt die Theory of Constraints, dass es in jedem Liefer- oder Wertschöpfungsprozess immer einen Engpass gibt, der die Ausbringungsmenge des Prozesses maximal begrenzt. Wenn die Ausbringungsmenge dieses Prozesses gesteigert werden soll, dann ist jedes Investment außerhalb des Engpasses Geldverschwendung, da es nicht dazu dienen kann, den Durchsatz zu steigern. Wenn Sie Ihren Mitteleinsatz entsprechend fokussieren, sind die finanzwirtschaftlichen Folgen erheblich. Allerdings müssen Sie dafür im 2. der 7 Schritte das Verständnis für durchsatzorientierte Finanzrechnung in Ihre Organisation eingebracht haben.
Slack – Menschen ohne Zeitpuffer produzieren Fehler, die das unerfreuliche Potenzial in sich bergen, ein gesamtes System lahmzulegen. Sie haben außerdem im wahrsten Sinne des Wortes keinen Platz für Innovation. Puffer oder auch freie Zeit bei der Arbeit in einem Wertschöpfungsprozess ist nicht nur sinnvoll, es ist die logische Folge der Theory of Constraints: Jeder Mitarbeiter, der nicht am Engpass arbeitet, muss unweigerlich „Freizeit“ (Slack) haben. Sie sollten Organisationen aufbauen lassen, in denen die maximale Auslastung von Mitarbeitern oder Maschinen nicht das Ziel, sondern verboten ist.
Wie die Theory of Constraints sollte Conway’s Law verstanden und bei der Organisationsgestaltung beachtet werden. Conway’s Law beschreibt, dass die Systementwürfe (oder Produkte) einer Organisation immer die Kommunikationsstrukturen dieser Organisation abbilden. Was sich sehr theoretisch anhören mag, hat erhebliche praktische Implikationen. Falls Sie am Nutzer orientierte Produkte entwickeln wollen, werden Sie auch eine Organisation entwickeln müssen, die sich am Nutzer orientiert.
Da agile Organisationsgestaltung nicht allein mit diesen drei Konzepten bewältigt werden kann, sollten Sie und Ihre Topmanager sich auch mit den folgenden Themen vertraut machen:

Es hat sich bewährt, im Management ein fundiertes, gemeinsames Verständnis dieser Themenfelder zu erzeugen. Der Erfolg der tatsächlichen Umsetzung hängt maßgeblich von Ihrem Engagement und Ihrer gezielten Rahmensetzung ab.

Zusammenfassung

4. Die Methode und das Skillset

Den Fokus des Managementhandelns Ihrer Organisation auf das Erlernen von Fähigkeiten und Methoden agilen Arbeitens zu lenken, ist erst dann sinnvoll, wenn ein hinreichend stabiles Fundament durch die ersten drei Schritte gelegt wurde. Wir beobachten oft, dass die agilen Skills auf der Ebene einzelner Teams schnell Erfolg zeigen, an den bestehenden Organisationsstrukturen und an der Unternehmenskultur drohen die Transformationsbemühungen dann aber zu scheitern.
Sie als Gesellschafter prägen durch Ihr beobachtbares Verhalten das Verhalten der Topmanager und damit die Kultur des Unternehmens. Erst wenn sich eine Kultur agilen Arbeitens erkennbar ausbildet, wird die Vermittlung von Methoden und Fähigkeiten ökonomisch wirksam. Falls in Ihrem Unternehmen bereits Bottom-up-Ansätze agilen Arbeitens erkennbar werden, schaffen Sie am besten die Rahmenbedingungen, die dieses Arbeiten unterstützen.
Agile Skills und Methoden wie

entfalten im Sinne der Wertschöpfung eine größere Wirkung, wenn sie auf einen fruchtbaren Boden fallen, der von der Organisation vorbereitet wurde. Es ist in Ihrem Interesse, das Wissen über diese Fähigkeiten und Methoden durch das Topmanagement in einer Organisation verbreiten zu lassen und es ist sinnvoll, dass Sie sich diese Fähigkeiten zunächst selbst aneignen und die Methoden selbst nutzen.

Zusammenfassung

Hier geht es weiter mit den Schritten 5 bis 7!

Video: Was ist Scrum?

Mit Büchern, Checklisten und vielen Stunden Training habe ich in den letzten Jahren Tausende von Menschen für Scrum begeistert. Dabei ging es mir immer darum, Scrum einfach und klar zu vermitteln, damit ihr wirklich versteht, was tatsächlich hinter den Rollen, Meetings und Artefakten steckt. Ich will, dass ihr mit Scrum selbst erfolgreich seid.
Mein Team hat mich davon überzeugt,  dass ihr nicht nur lesen wollt, sondern es auch per Video erklärt bekommen wollt. Also gut, dann lasst es uns probieren. In den folgenden Wochen werdet ihr hier jeweils ein aktuelles Video zu Scrum finden. Ich habe versucht, es wie einen kleinen Onlinekurs aufzubauen, jede Woche gibt es ein weiteres Thema. Die Videos werden jeweils 5 bis 8 Minuten lang sein. Ihr könnt sie gerne in euren Trainings oder in eurer täglichen Arbeit nutzen.
Den Anfang macht eine kurze Erklärung zu Scrum. Viel Spaß beim Anschauen!
Boris
PS: Feedback bitte im Kommentarfeld 🙂

Selbstorganisation braucht Führung: Die glorreichen Sechs – Freiwilligkeit

Drittes Grundelement von agiler Selbstorganisation ist die Freiwilligkeit. Ein hohes Maß an Freiwilligkeit erzeugt intrinsische Motivation und hohes Engagement. Für die Performance eines selbstorganisierten Teams ist es eine, wenn nicht die entscheidende Antriebskraft. Allerdings ist Freiwilligkeit auch eine eigenwillige Erscheinung, die besondere Bedingungen braucht, um zu wirken. In unserem Zusammenhang kann man drei Arten von Freiwilligkeit unterscheiden:
„Erzwungene Freiwilligkeit“, die von den Betroffenen in der Regel als Zwang, Druck, d.h. als Unfreiwilligkeit erlebt wird, ist für das Thema Selbstorganisation nicht nützlich. Sie zeigt sich in der Regel in verschiedenen Formen von mehr oder weniger massiven Widerständen. Diese können aggressiv nach außen gerichtet sein, subversiv im Untergrund rumoren oder passiv im Form von Rückzug und Verweigerung auftreten. Erzwungene Freiwilligkeit kann im agilen Kontext nur als kurze Bedenkzeit akzeptiert werden und muss in der Regel zu einer Entscheidung im Sinne von Ja oder Nein zur selbstorganisierten Teamarbeit führen. Hier muss die Führung für Transparenz sorgen, um eine eindeutige Entscheidung zu ermöglichen und Mut zur Konsequenz aufbringen. Die Zusammenarbeit und Abstimmung von Management und lateralen Rollen ist hier wesentlich.
„Bedingte Freiwilligkeit“ heißt in der Regel, einverstanden zu sein, rationale Einsicht in die Notwendigkeit zu haben, ohne jedoch echtes Herzblut zu investieren. Handelt es sich um Einzelfälle im Team, kann die laterale Führung damit leben. Sie muss es jedoch als ihre Aufgabe sehen, mit dem/den Betroffenen weiter zu kommen, um eine höhere Stufe von Freiwilligkeit zu entwickeln. Auch hier gilt es, Zeit zu lassen, positive Erfahrungssituationen zu kreieren und z. B. in coachingorientierten Einzelgesprächen eine Entwicklung anzustoßen. Ein Team, in dem die bedingte Freiwilligkeit dominiert, kann und wird allerdings mittelfristig in selbstorganisierter Form nicht überleben bzw. nur mittelmäßige Leistungen erbringen können.
„Unbedingte Freiwilligkeit“ als dritte und hocherwünschte Form ist ein Überlebensmotor von Selbstorganisation jeder Couleur. Sie ist intrinsisch, ohne wenn und aber angelegt und erzeugt bei Einzelnen, aber auch beim Team als Ganzes den besonderen Flow zur High Performance. Ist ein hohes Maß an unbedingter Freiwilligkeit erreicht, kann die laterale Führung loslassen und sich im Schwerpunkt als Coach und Begleiter einbringen.
Für die Führung bedeutet das, die Teams Erfolge erleben zu lassen und aus einer gewissen Distanz als Beobachter und Impulsgeber zu fungieren. Unbedingte Freiwilligkeit hat mit Sinn und Verstehen (Rationalität, siehe “Sinn”) zu tun, sie hat jedoch auch eine hohe emotionale Komponente. An erster Stelle steht hier das Bedürfnis nach Anerkennung. Diese ist zweifellos ein Schlüsselelement im Führungshandeln und in verschiedenen Formen einzubringen.
Laterale Führung muss bewusst emotionale Situationen kreieren und/oder verstärken: Erfolge feiern, wahrnehmbare Highlights (mit)gestalten, kreative Visualisierungsmittel einsetzen – das alles fördert Freiwilligkeit nachhaltig. Wie bei allen starken Emotionen kann man durchaus von einem Ansteckungseffekt (leider auch bei negativen Emotionen) reden. Das heißt, gemeinsam erlebte Situationen mit einer starken positiven emotionalen Aufladung fördern die unbedingte Freiwilligkeit. Gezielte Arbeit am Teamgeist durch Teamentwicklung, sei es in Retrospektiven oder durch besondere Maßnahmen, fördert die unbedingte Freiwilligkeit und schafft Begeisterung, die wiederum den Flow für höchste Performance erzeugt.

Glaubwürdig sein

Begeisterung zu wecken, sowohl individuell als auch kollektiv, ist auch eine Führungsaufgabe. Man nehme sich ein Beispiel an erfolgreichen Trainern im Sport, ohne Namen zu nennen. Nur wenn das Feuer in der Führung selbst brennt, kann man es bei anderen entfachen. Wie sieht es also mit dem eigenen Begeisterungslevel aus – das sollten Führungsverantwortliche prüfen und reflektieren. Wenn ich wirklich begeistert bin, muss ich das glaubwürdig kommunizieren (Vorsicht: nicht missionieren!). Spüre man in sich selbst wenig Begeisterung, ist es wichtig, sich ehrlich nach den Hindernissen zu fragen und diese zu bearbeiten.
Im Führungshandeln muss klar erkennbar sein, dass der zentrale agile Wert, den Menschen in den Mittelpunkt zu stellen und sich als System in erster Linie an den Mitarbeitern und nicht am Geld, sprich Gewinn zu orientieren, glaubhaft gelebt wird. Die moderne neurowissenschaftliche Forschung hat umfassend nachgewiesen, dass Freiräume und Gestaltungsmöglichkeiten die unbedingte Freiwilligkeit massiv fördern. Laterale Führung hat hier die Karten in der Hand und muss, wo nötig, die Gestaltungsräume der einzelnen und der Teams verteidigen und schützen.
Häufig behindern Impediments aller Art die unbedingte Freiwilligkeit und Begeisterung. Die Vertreterinnen und Vertreter der lateralen Führungsrollen müssen es daher unbedingt ernst nehmen, diese Impediment zu bearbeiten und aus der Welt zu schaffen. Transparenz durch ein lebendiges Impediment-Backlog und durch permanente Kommunikation mit dem Team über den Umgang mit Impediments sind dabei ein wesentliches Element.
 
Nachlesen?
Selbstorganisation braucht Führung: Die glorreichen Sechs – Sinn
Selbstorganisation braucht Führung: Die glorreichen Sechs – Struktur
 

Selbstorganisation braucht Führung: Die glorreichen Sechs – Struktur

Die zweite Grundkomponente von Selbstorganisation ist die Struktur (Ordnung). Sie gibt einem Team Orientierung und Sicherheit und macht die höhere Komplexität der Zusammenarbeit überschau- und handhabbar. Das heißt, klare Rahmenbedingungen (in der Regel durch die disziplinarische Führung) festzulegen und zu kommunizieren. Rahmenbedingungen – das bedeutet u. a. Grenzen zu definieren, Verantwortungsbereiche festzulegen, Arbeitsstrukturen (z. B. Scrum, andere Projektverfahren) zu vorzugeben, Meetingregeln zu installieren, Rollen und Funktionen auszustatten und zu legitimieren, usw.
Das Spannungsfeld von Grenzen und Freiräumen muss transparent und im Idealfall – dort, wo möglich – durch ein gemeinsames Commitment manifestiert sein. Laterale Führung ist sozusagen im Auftrag des Managements der “Hüter” dieser externen Strukturen und Ordnungsmuster und sollte im Umgang damit konsequent sein. Ein zentrales und genuines Struktur- und Ordnungselement ist dabei die Führung selbst. Das Vorhandensein von Führung gibt sozialen Systemen (Teams) die Sicherheit und Orientierung, dass „nicht entscheidbare“ Entscheidungen getroffen werden können und Konflikte bearbeitet und gelöst werden, die im kollektiven Miteinander nicht lösbar sind.
Das wesentlichste Moment im Führungshandeln ist es also, da zu sein, präsent und spürbar zu agieren, Kontakt zu halten und, wo nötig, merklich Führung zu übernehmen. Selbstorganisierte Teams brauchen jedoch neben den vorgegebenen auch interne, selbstbestimmte Ordnungsnormen und Regeln, sowohl auf der fachlichen als auch auf der sozialen Ebene. Laterale Führung hat hier die Aufgabe, Anregungen für die Entwicklung solcher formalen Strukturen zu geben, sie zu committen, zu beobachten und bei Bedarf zu modifizieren. Müssen Strukturen, warum auch immer, verändert werden, gehört absolute Transparenz zur lateralen Führungsaufgabe. Dabei gilt Transparenz sowohl „top down als auch bottom up“. In Meetings, wie z. B. der Retrospektive, kann laterale Führung das Strukturgefüge mit dem Team reflektieren und ihm helfen, sich mit strukturellen Fragen und Problemstellungen auseinanderzusetzen.
Teams brauchen zwar Ordnung und Struktur, sehen aber eher in ihren fachlichen Aufgaben die eigentliche Profession und weniger in der Gestaltung von Strukturen. Darin kann die Führung eine ihrer zentralen Aufgaben sehen und für ihr Team die Pflege von Strukturen mit übernehmen. Gute Strukturen schaffen Freiräume für selbstorganisierte Planung und Produktion.
 
Trainingstipp: Selbstorganisation braucht Führung
Buchtipp: Selbstorganisation braucht Führung – Die einfachen Geheimnisse agilen Managements

Exploratives Testen: Finden wir raus, was wir nicht wissen!

Menschen, die Software benutzen, machen manchmal Dinge, an die kein Entwickler oder Tester denkt. Mit systematischen Tests und durch Testautomatisierung lässt sich zwar ein hohes Maß an Testabdeckung erreichen, aber es besteht immer das Risiko, Fehler zu übersehen. Sie lassen sich nicht durch Automatisierung aufdecken, sondern nur durch das kreative Gehirn eines guten Testers.
Grundsätzlich gibt es drei Ansätze, wie Software getestet werden kann:

  1. Wir gehen davon aus, dass wir wissen, was uns erwartet. Die Anforderung ist klar formuliert. Wenn ich <Username x> in das <Feld y> eingebe, dann passiert <Aktion z>. Das wollen wir mit einem sogenannten „Gutfall-Test“ überprüfen.
  2. Wir wissen nicht, was passiert, wenn wir eine bestimmte, falsche Eingabe machen, oder das Programm mitten in der Datenverabeitung schließen. Diesen Fall wollen wir mit einem sogenannten „Negativ-Test“ überprüfen.
  3. Es gibt aber Dinge, von denen man gar nicht weiß, dass man sie nicht weiß. Das kann vor allem bei Software passieren, die man seit Jahren testet – hier entsteht leicht eine Betriebsblindheit. Man konzentriert sich, teilweise auch aus Zeitmangel, nur noch auf das Testen von Akzeptanzkriterien. Aber haben die Tester und Entwickler die Anforderungen genau so verstanden, wie der Fachbereich sie gestellt hat? Haben sie etwas übersehen?

Das Programm aus Anwendersicht erkunden

Beim explorativen Testen nimmt der Tester  die Perspektive eines Users ein und begibt sich auf eine Reise durch das Programm. Je nachdem was man entdecken möchte, können das völlig unterschiedliche Reisen sein. Zum Beispiel kann man die Rolle eines Hackers einnehmen, der Spaß daran hat, im Programm Sicherheitslücken zu finden, die er ausnutzen könnte. In dieser Rolle versucht man möglichst ungültige oder ungewöhnliche Eingaben und Aktionen zu machen, um herauszufinden, wie stabil das Programm bleibt. Oder man nimmt die Rolle eines Users ein, der im Umgang mit einem Computer ungeübt ist. Auf dieser Reise möchte man herausfinden, ob das Programm leicht und selbsterklärend zu bedienen ist. Viele andere Rollen und die zugehörigen Reisen werden im Buch „Exploratory Software Testing“ von James A. Whittaker anschaulich beschrieben. Der Autor geht auch darauf ein, warum manche Programmfehler unentdeckt bleiben und wie uns die Technik des explorativen Testens dabei helfen kann, diese doch noch zu finden.
In einem Projekt, in dem ich als Softwaretesterin gearbeitet habe, hat sich das gesamte Scrum-Team jeden Morgen nach dem Daily-Scrum zusammengefunden und festgelegt, wer welche Reise macht.
Jedes Mitglied des Entwicklungsteams (Tester, Softwareentwickler, Analysten) nahm dabei eine User-Rolle ein und startete eine Reise durch das gesamte System. Die ersten 15 Minuten des Tages waren immer dem exoplorativen Testen gewidmet. Wir konnten so aus „wir wissen nicht, was wir nicht wissen“ oft ein „wir wissen, dass….“ machen.
Natürlich gehört eine Dokumentation der Ergebnisse dazu. Diese sollte jedoch so knapp wie möglich und so umfangreich wie nötig sein, denn 15 Minuten pro Tag sind kurz – da will man die Zeit nicht mit überdetaillierter Testdokumentation verstreichen lassen. Es genügt zum Beispiel eine Checkliste oder eine Mindmap: Die bereitet man vor, um sich auf das zu fokussieren, was man in dieser Testsession herausfinden will. Die Punkte auf der Liste, die beim explorativen Testen rot geworden sind (also fehlgeschlagen sind), kann man danach in weiterführende Testfälle umwandeln.
Exploratives Testen holt jedes Teammitglied für kurze Zeit aus der Tagesroutine raus, macht Spaß und hilft dabei, das Programm kennenzulernen und so neue, kreative Ideen zu entwickeln. Egal ob man Tester, Entwickler oder Analyst ist: Kreativität ist bei jeder Produktentwicklung gefragt.

Ein Product Owner für zwei Teams, oder?

Mein Kunde hatte sich innerhalb eines großen Entwicklungsprojekts vorgenommen, nicht nur die verschiedensten Applikationen den neuen Anforderungen des Marktes anzupassen, sondern gleichzeitig die Software-Architektur zu modernisieren, um Continuous Delivery zu ermöglichen. Gestartet wurde mit mehreren parallel laufenden Scrum-Teams an vier verschiedenen Standorten. Wir hatten einen Kollegen aus dem Fachbereich, der neben der Rolle des Kunden auch zwei Scrum-Teams als Product Owner betreuen sollte. Auf welche Herausforderungen stößt dieser nun in der Rolle als Product Owner mit seinen beiden Scrum-Teams?

Was der Product Owner eigentlich tun sollte

Im Allgemeinen ist der Product Owner für das entstehende Produkt und den dazugehörigen Business Value verantwortlich, den das Produkt für das Unternehmen erzeugen soll. Gemeinsam mit dem Team arbeitet er an der Vision, pflegt das Backlog (Schreiben von User Storys und deren Priorisierung im Backlog) und er ist im ständigen Kontakt mit den Stakeholdern.
In meinen Augen ist der Product Owner ein betriebswirtschaftlicher Allrounder mit Liebe zur eingesetzten Technologie, der verschiedene Funktionen in einer Person vereint und dafür sorgt, dass das Richtige entwickelt wird. Zusätzlich bringt er die unterschiedlichen Positionen von Team und Stakeholdern zum größtmöglichen wirtschaftlichen Nutzen für das Unternehmen auf einen Nenner. In diesem Fall sah es aber anders aus.
Bild_ella_1

Der Product Owner hat keine Zeit

Bereits in den ersten Sprints stellten beide Scrum-Teams unabhängig voneinander fest, dass ihr Product Owner für sie kaum zeitlich verfügbar war. Das Backlog war weder vorbereitet noch priorisiert und daher liefen die Meetings sehr unstrukturiert und nicht konstruktiv ab. Nur sehr schwer konnten die Teams in Erfahrung bringen, welche User Storys im kommenden Sprint bearbeitet werden sollten. Für Fragen während des Sprints stand der Product Owner nur sehr eingeschränkt zur Verfügung, da er in seiner Rolle als Hauptansprechpartner im Fachbereich viele Aufgaben wahrnehmen musste und häufig unterwegs war. Letztendlich war auch der Product Owner mit der Situation unzufrieden, weil er den Anforderungen der beiden Teams nicht gerecht wurde und zunehmend überfordert war.

Der dreigeteilte Product Owner

Während einer Coachingsitzung mit diesem Product Owner entstand folgendes Bild:
Bild_ella_2
Es zeigt, dass schlichtweg die Fokussierung fehlte. Der Verantwortliche konnte sich weder seiner bisherigen Tätigkeit als Kunde noch seinen beiden Scrum-Teams widmen.
Mit dem Fokus auf nur ein Team könnte er sich besser in die Rolle des Product Owners einfinden. So sollte ein Product Owner Vertrauen in die Fähigkeiten seines Teams haben und es selbstständig entscheiden lassen, wie es seine Anforderungen umsetzen will. Dieses Vertrauen kann er jedoch nur erlangen, wenn er sich auf eine Sache, hier ein Scrum-Team, konzentrieren und sich mit dem Team und dessen Fähigkeiten auseinandersetzen kann. Zusätzlich ermöglicht die Fokussierung, auch ausreichend Zeit in die eigene Vorbereitung zu investieren. Mit einem vorbereiteten Product Owner laufen die Meetings strukturiert und effizient ab, sodass alle motiviert in den neuen Sprint starten können.
Ein Product Owner ist zudem Teil des Scrum-Teams. Er teilt sich im Idealfall mit dem Dev-Team und dem ScrumMaster einen eigenen Teamraum, verwaltet dort seine Artefakte (Story Map, Product Backlog etc.) und ist als Ansprechpartner verfügbar: für das Team und für die Stakeholder. So kann er sich voll und ganz auf das Team und deren Anfragen konzentrieren und wird nicht ständig unterbrochen. Auf allen Seiten ist dadurch ein Produktivitätsschub zu erwarten.

Ein Product Owner für zwei Teams, oder?

Im Laufe der ersten Sprints erkannten wir, dass die Konstellation nicht zielführend war. Selbst nachdem der Product Owner ein Scrum-Team abgegeben hatte, spürten wir keine wesentliche Verbesserung. Und so wurde schlussendlich entschieden, dass sich der Vertreter des Fachbereichs nun auf diese Rolle konzentrieren sollte – sie beanspruchte seine volle Aufmerksamkeit.
Ich bin der Meinung: Grundsätzlich ist es nicht sinnvoll, einen Product Owner für zwei Scrum-Teams einzusetzen, geschweige denn einen Kollegen, der mit zusätzlichen Aufgaben betraut wird. Die beschriebene Situation zeigt gut, auf welche Schwierigkeiten alle Beteiligten stoßen und dass diese sich nicht immer beseitigen lassen. Die Kunde-Product Owner-Konstellation führte außerdem dazu, dass zwei Teams nicht ausreichend gut und schnell entwickeln konnten und das wiederum verlangsamte das Projekt. Um einer solchen Situation künftig vorzubeugen, sollten alle Projektinvolvierten vor dem Start in den Aufgaben und Rollen innerhalb von Scrum trainiert werden. Zusätzlich sollten die Ausgestaltung der Scrum-Rollen und die Erwartungshaltung innerhalb der Organisation besprochen werden. So können bereits im Vorfeld mögliche Bottlenecks identifiziert und gelöst werden, bevor sie innerhalb des Projekts zu realen Schwierigkeiten führen. Und schließlich bin ich davon überzeugt, dass ein Product Owner seine Rolle nur so effektiv wie möglich ausführen und alles Nötige für sein Team geben kann, wenn er fokussiert arbeitet und sich nicht um mehrere Teams oder Projekte innerhalb der Organisation kümmern muss.
Übrigens ist es durchaus möglich, in Scrum einen Product Owner für zwei Teams einzusetzen. Allerdings setzt das unbedingt voraus, dass die Teams bereits seit mehreren Jahren mit Scrum gearbeitet haben und dass es die Produkt-Business-Beziehung vollständig durchdrungen hat. Der Grad der Selbstorganisation innerhalb der Teams ist dann bereits so hoch, dass es ausreicht, die große Vision des Product Owners zu kennen, um das Richtige zu liefern.
Bild_ella_3
 
Weitere Informationen zu Scrum 3.0 finden Sie hier: “Von Scrum 1.0 zu Scrum 3.0” oder “Boris Gloger and Scrum 3.0: Is the Future of Scrum Really No Backlogs or Standups??”

A model for management helps to understand ScrumMaster duties

The Scrum world mostly focuses on leading agile teams. In this community we constantly discuss how to treat team members and whether the Product Owner is a part of the team or not. We question the role of management and are still not sure if the ScrumMaster is a leader. Several times the agile world tried to dismiss managers as not being useful anymore. In his famous article “First, let’s fire all the managers” Gary Hamel even treated the manager’s position as a tax rather than a value creating function (Hamel 2011). Most people on the operational level (primarily those who produce something) consider managers as not creating value. Management is something bad whereas no management is something good. Sometimes, agilists believe that only leadership is necessary and people are able to manage themselves.
I have never been sure whether this simplistic approach to distinction between management and leadership is really useful. And I am still struggling with the idea that large corporations like Daimler, General Motors, Apple or Google shall exist without having a “management”. Of course I know that Buurtzorg for example doesn’t have a distinctive management level, neither has Spotify. Being aware of that, I wanted to know more and went back to university. I enrolled in a Global Executive Master of Business Administration Program at St. Gallen University (HSG). Within the first week of the program I was shown that the professors thought like the protagonists of the agile world but they don’t try to simplify things in the same way as we sometimes tend to do within the agile community.
It might be useful for the agile community to understand the deep implications of seeing management as a “reflexive design praxis” as the St. Gallen Management Model (SGMM) suggests (I will talk about the SGMM in another article). One “translation” of the SGMM into practical terms is described by a model, that I do not claim having understood correctly in detail yet but I would like to share a piece with you which helped me understand the difference between the logical levels of vision and strategy. Looks pretty obvious when you see this model, but not having clear this distinction before had confused my thinking. We got this depiction from HSG Professor Dr. Wolfgang Jenewein who specializes in High Performance Teams (he has also written a book about it, see Jenewein and Heidbrink 2008). He coaches large organizations as well as football teams – and it seems to me that he is very successful in doing so.
jenewein2
You can see the model he introduced and which is used at HSG by many professors in the picture. Please note that this is not the St. Gallen Management Model itself (Rüegg-Stürm and Grand, 2015) which I will try to describe in another article. The model explained by Jenewein operates on three levels – normative, strategic and operational – and five different aspects of management (give a vision, create a strategy, build an organization, form a culture and lead your people) which comprise “Leadership” as one necessary function of management. Let’s have a look at the three levels:

  1. The normative level represents the settings put in place by managers or e.g. the board of directors. One function of the normative level is to determine the vision of the company or the team. A vision offers the “Why?” (see Sinek 2011). The normative level is located above the strategic level, so the strategy of a company or team is not part of the vision but it can influence the vision of course.
  2. Most of the time, the strategic level consists of a set of processes to determine and guide the actions of a company or team. On this level we need to answer all the questions which help guiding the company. We need to deliver:
    a. Focus
    b. The positioning of the company/team = the differentiation to other teams or companies
    c. Customer segments and the respective customer needs
    d. We need to consider potentials and risks of our strategy
    e. And it is all about the FUTURE!
  3. The operational level is the most important according to the agile community as the “real” work is done on this level:
    a. Set up of processes to organize the organization. That means also to set targets and goals for the organization.
    b. Working on and building the culture
    c. “Leadership” is a day to day activity which is shaped by the context you are working in. If you are the head of department, you will need to set up visions that are different from those visions you would set up if you were the ScrumMaster of a cross-functional development team.

I believe this model helps us to understand which aspects of management need to be taken care of in order to structure an organization, a department, a project and even a team. As the ScrumMaster is the one who works on raising the productivity of the organization, he is also in charge (on his level) of making this happen.
The ScrumMaster has to make sure that there is a vision, a strategy, a clear set of rules that guides the organization and he needs to build the culture. He or she does this by applying modern leadership tools as I described in “Selforganization needs Leadership”(available online here)
If you understand leadership as an activity then you can also learn it. You can learn how to help your team by working on all three levels using the appropriate “transfers”, f.e. the company vision becomes the product vision, the strategy might become your product roadmap and so on. Using an approach that lets team members grow in their personality, work attitude and ability of self organization.
 
Hamel, G. (2011). First, let’s fire all the managers. Harvard Business Review, 89(12), 48-60.
Jenewein, W., Heidbrink, M. (2008). High-Performance-Teams: Die fünf Erfolgsprinzipien für Führung und Zusammenarbeit. Stuttgart: Schäffer-Poeschel.
Rüegg-Stürm, J., Grand, S. (2015). The St. Gallen Management Model. English translation of the fourth generation of the German text. Bern: Haupt Verlag.

Scrum in der Hardware: Wie starte ich?

Nach vielen agilen Projekten in der Hardwareentwicklung will ich hier mit dem Vorurteil „agile Entwicklung in der Hardwareentwicklung funktioniert nicht” aufräumen. Aber bevor ich das mache, möchte ich noch einmal einen Blick darauf werfen, was agile Entwicklung oder Scrum für die Menschen, die es anwenden, und für die Prozesse bedeutet.
Agile Entwicklung ist ein teambasiertes Vorgehen, das Entwickler befähigt, selbstbestimmt zu entscheiden, WIE sie ein Produkt entwickeln. WAS zu entwickeln ist, wird über die Vision, die Anforderungen und vor allem die Constraints festgelegt. Ziel ist es, in kurzen Iterationen fertig entwickelte Funktionen zu liefern, um dadurch schnelles Feedback zu bekommen. Dabei spielen die Produktarchitektur und Produktmodularität eine wichtige Rolle, um die einzelnen Funktionen unabhängig als Komponenten entwickeln zu können. Die Scrum-Meetings und Artefakte ermöglichen eine optimale und reibungslose Kommunikation sowie einen geregelten Informationsfluss durch Taktung und Synchronisierung zwischen allen Experten, die an der Entwicklung beteiligt sind. Zusammengefasst bedeutet Scrum in der Hardware, schnell Funktionen zu prototypisieren und dem Kunden oder Nutzer zum Feedback vorzulegen. Hier ist ein Umdenken in der gesamten Entwicklung und in der Gestaltung der Prozesse notwendig, etwa im Beschaffungsprozess, in der Zusammenarbeit mit Zulieferern und der Teamzusammensetzung.
Die meisten Unternehmen, die Scrum einführen wollen, haben immer wieder dieselben Fragen:
Zum Prozess: Wie passen die kurzen Iterationen zu den heute oft nur in Monaten gemessenen Entwicklungszyklen? Wie sollen wir ein komplexes Produkt im Zwei-Wochen-Rhythmus integrieren und testen bzw. prototypisieren? Wie passt unser PEP (Produktentwicklungsprozess) nach dem Wasserfallprinzip zur agilen Vorgehensweise?
Zur Struktur: Wie soll die Arbeit in einem interdisziplinären funktionalen Team aussehen? Wie müssen wir unsere Projektstruktur und Ressourcenplanung überdenken? Wie bekommt man Mitarbeiter dazu, mitzumachen?
Zu den Zulieferern: Wie soll eine agile und interaktive Entwicklung die hohen Abhängigkeiten meistern?

Kleine Schritte und Pilotieren

Wenn Sie mit agiler Entwicklung beginnen wollen, fangen Sie am besten klein an. Überfordern Sie sich und die Organisation nicht. Sorgen Sie dafür, dass die Menschen in den Teams fokussiert arbeiten können. Hier ist schon die erste Hürde zu nehmen: Fokussiert bedeutet, zu 100 Prozent für dieses Projekt eingeplant zu sein und nicht “Er ist zu 0,2 FTE in diesem Projekt eingeplant“. Das Freistellen von Ressourcen ist oft die erste schmerzhafte Erfahrung mit Scrum, denn das bedeutet unter Umständen, dass andere Dinge erst mal nicht erledigt werden. Das ist aber nur die halbe Wahrheit, denn durch die Fokussierung schafft man letztendlich mehr Arbeit als zuvor. Die Organisation steht vor einer Veränderung. Dazu ist es nötig, Raum zu schaffen und sich Zeit zu nehmen. Starten Sie mit nur einem Projekt und fangen Sie in kleinen Schritten an zu lernen.

Crossfunktionale und autonome Teams

Versuchen Sie, Teams so autark wie möglich zusammenzustellen. Das bedeutet: Jedes Team sollte alle Fähigkeiten besitzen, um das Produkt entwickeln, beschaffen, produzieren und vertreiben zu können. Stellen Sie  ein crossfunktionales bzw. ein interdisziplinäres Team zusammen, denn es muss selbstständig und schnell auf Änderungen reagieren können, um Geschwindigkeit aufzunehmen. Hier liegt schon der erste Mehrwert: Das Team muss sich schon vor dem eigentlichen Entwickeln im Klaren sein, welche Funktionen welche Schnittstellen benötigen. Welche Fähigkeiten braucht das Team, um bestimmte Funktionen entwickeln zu können? Hier fängt Agilität an: Das Produkt muss so konzipiert werden, dass Funktionen entfernt, ersetzt oder weggelassen werden können und trotzdem eine Funktionalität in sich gegeben ist. Nicht nur im aktuellen Produkt, sondern auch im zukünftigen (siehe dazu “Product teams for hardware products”).
Erfahrungsbeispiel 1:
Ein Team (Automobilbranche) forderte in einer Entwicklungsphase, dass ein Mitarbeiter aus dem Einkauf zu 100 Prozent seiner Zeit für das Projekt zur Verfügung gestellt werde. Nach kürzester Zeit wurde seine Mitarbeit als äußerst hilfreich empfunden, er selbst gab das Feedback, dass er selten zuvor so schnell auf Wünsche reagieren konnte und frühzeitig erfahren hatte, wann Bestellungen ausgeführt werden mussten. Das brachte dem Team gerade bei der Bestellung von Prototypen und Musterteilen extreme Geschwindigkeitsvorteile – bedingt durch die crossfunktionale Zusammensetzung des Teams.

Raum und Zeit für Zusammenarbeit

Sorgen Sie dafür, dass ihre crossfunktionalen Teammitglieder gemeinsam in einem Raum arbeiten, damit sie sich schnell absprechen und Feedback geben können. Zudem brauchen sie in diesem Raum viel Platz, um zum einen ihre Ergebnisse sowie Aufgaben transparent zu machen und zum anderen ihre Arbeitsergebnisse zu visualisieren und auszustellen. Zudem sollten die Teams zeitgleich und gebündelt an Themen arbeiten, damit auch hier der Fokus auf eine Aufgabe entstehen kann.
Erfahrungsbeispiel 2:
Ein Team war für den Bau einer komplett neuen Produktionshalle plus Produktionsanlage verantwortlich. Das Unternehmen hatte erstmalig veranlasst, dass alle externen Zulieferer als interdisziplinäres Team alle zwei Wochen für je zwei Tage an einem gemeinsamen Ort zusammenarbeiteten. Das Team bestand aus 15 Personen und setzte sich sowohl aus externen Zulieferern als auch internen Mitarbeitern zusammen. Ein so großes Team bedeutet zusätzliche Komplexität, viel Kommunikationsaufwand und große Artefakte, wie zum Beispiel ein riesiges Taskboard. Doch für den Anfang war der Vorteil eines zusammenarbeitenden Teams viel wichtiger als die Schwierigkeiten, die durch die Teamgröße entstehen können. Das war ein Kompromiss, der sich bezahlt gemacht hat. Durch die Nähe und Zusammenarbeit wurden die 3D-Baupläne ständig synchronisiert und abgeglichen. Dadurch war schnelles Feedback gegeben und Kollisionen in den Zeichnungen konnten sofort beseitigt werden, nicht erst Wochen später. Die Planungs- und Review-Meetings bestätigten dem Team alle zwei Wochen, auf dem richtigen Weg zu sein. Das positive Feedback eines Projektteilnehmers am Ende des Projekts hat mich besonders motiviert und darin bestätigt, das Richtige zu tun. Dieser sagte, dass er seit 25 Jahren in diesem Unternehmen arbeitete und noch nie ein Projekt miterlebt habe, das so reibungsfrei und strukturiert im Zeitplan abgearbeitet worden war.

Mindset

Das agile Mindset beruht darauf, dass Mitarbeiter ihre Arbeit gerne machen. Daher ist die Projekt-/Produktvision in einem agilen Umfeld so wichtig: Mitarbeiter sollen nicht nur ihren Job gerne machen, sondern auch bei einem agilen Projekt freiwillig mitmachen. Wenn sich Mitarbeiter freiwillig für ein Projekt melden, verpflichten sie sich selbst, das Projekt zum Erfolg werden zu lassen. Es bedeutet zudem, selbstbestimmt zu sein, Verantwortung zu bekommen und diese auch anzunehmen.
Nach meinem Verständnis fördert Scrum durch Selbstorganisation und Eigenverantwortung die Motivation und das Engagements von Menschen. Das geschieht unter vorgegebenen Rahmenbedingungen, auch Constraints genannt. Das heißt, dass Teams selbstbestimmt und autark in ihrer Umgebung sind. Ein anschauliches Beispiel dafür ist der Flugzeugbau: Bei der Entwicklung eines Flugzeugs sind für die Zulassung zum Luftverkehr gewisse Vorschriften einzuhalten. Innerhalb dieser Vorschriften gibt es aber große Handlungsspielräume, in denen man entwickeln kann, was man möchte und wie man das möchte. Diese Rahmenbedingungen können von den Behörden vorgegeben oder durch die Definition of Done in einem Projekt festgesetzt werden. So können die Qualitätsbedingungen, die Testverfahren oder die Dokumentation zu Constraints in einem Projekt werden. Agile Teams können innerhalb der Constraints autark bestimmen, was und wie sie entwickeln. Ziel ist es, dass sich die Rahmenbedingungen für die Teams auf das Nötigste beschränken. Die Erfahrung in Teams zeigt: Um so mehr die Führungspersonen vorgeben, desto weniger entstehen bei den Mitarbeitern Selbstorganisation, Motivation und Eigenverantwortung. Die positive Variante: Je mehr Vertrauen einem Team entgegengebracht wird, desto mehr Verantwortung wird vom Team übernommen und desto selbstbestimmter arbeitet das Team. Das Ergebnis sind Mitarbeiter, die Herausforderungen lösen, mit dem Fokus auf das Produkt Entscheidungen treffen und dafür auch Verantwortung übernehmen – Mitverantwortung heißt auch mitdenken.

Prozesse, Prototypen und Zulieferer

Was wird aus dem Produktentstehungsprozess (PEP), der aufgesetzt wurde? Diese Frage beschäftigt Manager in Maschinenbauunternehmen am meisten. Meine Erfahrung zeigt, dass der Produktentstehungsprozess im ersten Schritt eine gute Unterstützung ist, um Scrum einzuführen. Es ist dabei kein Widerspruch, einen PEP nach Stage Gate zu haben und gleichzeitig  agil zu entwickeln. Das heißt, dass zwischen den Milestones inkrementell in kurzen Iterationen Produktfunktionalitäten geliefert werden. An den Milestones werden Lieferforderung und Lieferung abgeglichen. Das Management hat somit weiterhin Informationen zu jedem Projekt an den einzelnen Milestones. Oft ergibt sich aus diesem Vorgehen eine Art hybrider Scrum-Stage-Gate-Prozess.
Erfahrungsbeispiel 3:
Bei einem anderen Team aus der Automobilzuliefererbranche ging es darum, ein Konzept für eine neue Scheinwerfertechnologie zu entwickeln. Durch die agile Entwicklung kam das Team von den vielen Plänen, Konstruktionen und Berechnungen ab und entwickelte stattdessen einen Prototyp, um Feedback des Kunden einzuholen. Nach einigen Sprints war der Kunde bereits so begeistert, dass er meinte, die Funktionalität des Prototyp reiche für seinen Zweck vollkommen aus. Das Entscheidende an diesem Erfolg waren zwei Dinge: Zum einen hatte sich der Kunde die Zeit genommen, um vor Ort zu sein, den Prototyp zu prüfen und schnell Feedback zu geben. Zum anderen erkannte der Kunde auf diese Weise frühzeitig, dass das Team sein Ziel schon erreicht hatte. Ich frage mich, wie oft Dinge weiterentwickelt werden, obwohl sie das gewünschte Ziel schon lange erreicht haben – nur weil niemand das Entwicklungsprojekt stoppt. Ein Plan muss nicht immer bis zum Ende verfolgt werden, wenn die Realität den Plan überholt.
 
Fazit: Scrum hilft vor allem in einem komplexen Umfeld, in dem die Koordination und Zusammenarbeit unterschiedlicher Experten notwendig ist. Gerade dann, wenn nicht alle Entscheidungen up-front möglich sind und noch Ungewissheit über das herrscht, was der Kunde oder Nutzer tatsächlich braucht, ist Scrum die ideale Lösung.

Scrum bei alpha-board (Teil 3): Produkte entwickeln, an die vorher niemand gedacht hat

Was wir nun wissen ist, wie man möglichst endanwenderorientiert Anforderungen aufsetzt (Scrum bei alpha-board – Teil 1) und warum wir diese stets kurzfristig spezifizieren (Scrum bei alpha-board – Teil 2). Was wir noch nicht geklärt haben: Wer schreibt die Anforderungen? Im klassischen Projektmanagement macht das oft ein Business Analyst oder ein Anforderungsingenieur intern im Fachbereich oder extern beim Kunden. Die Detailspezifikation von Anforderungen ist in diesen Fällen also sowohl personell als auch zeitlich von der Umsetzung getrennt.
Das Ideal “Entwickeln, statt nur umsetzen“ hatte sich bei der alpha-board GmbH, einem Dienstleister für agile Hardware-Entwicklung, schon vor meiner Ankunft (vielleicht unbewusst) durchgesetzt. Die personelle Trennung zwischen Spezifikation und Umsetzung, wie im ersten Absatz beschrieben, war teilweise schon gar nicht mehr vorhanden. Unvorstellbar? Keineswegs, während meines Aufenthalts haben wir diese Mauer zwischen Spezifikation und Umsetzung kontinuierlich eingerissen. Im Folgenden sehen Sie einen Überblick über den Anforderungsprozess, mit dem wir als Team arbeiten. Als ideale Grundlage dient der Design-Thinking-Prozess, ausführlich auch beschrieben von Boris (Gloger 2014). Design Thinking lässt sich grundlegend in fünf Phasen unterteilen:

Discovery – Lass uns entdecken!

In der ersten Phase wird das Problem des Kunden von allen Beteiligten entdeckt. Es war der erste Workshop mit meinem neuen Scrum-Team und der Geschäftsleitung. Auch Vertreter aus dem Vertrieb wurden in dieses „Erkundungsteam” einbezogen. Während der Gespräche sorgten diese Kollegen immer wieder für einen neuen Blickwinkel auf Problematiken, das Gespräch war konstruktiv und vielseitig. Die initiale Idee für das Produkt hatte das Team bereits vorher kennengelernt. Für mich war essenziell, dass das Team diese Idee verstand, um die Herausforderungen der potenziellen Endanwender besser kennenzulernen. Das klassische Design Thinking geht hier weiter und versucht, wenn möglich, den Anwender selbst beim Auftreten des Problems zu beobachten oder über den Problemkontext zu interviewen (vgl. Gloger 2014, S.59ff). Auch der „Lean Start-up“-Gedanke greift dieses Vorgehen unter dem Begriff “Customer Discovery” auf.

Interpretation – ist alles.

Nachdem das Team die Problematik verstanden hatte, ging es nun darum, sie zu interpretieren. Boris schreibt dazu: Das Team soll nun die „Bedeutung“ und “den tieferen Sinn“ (suchen) und damit “Einsichten finden“ (vgl. Gloger 2014, S.73). In unserem Fall wich die nun generierte Vision im Ergebnis von der vorherigen initialen Produktidee ab. Durch die neue Vision wurde uns klar, dass speziell für eine Komponente die technischen Anforderungen höher waren als für marktübliche Vergleichsprodukte. Damit stieg das technische Risiko des Gesamtprodukts. Abschließend wurden die ersten Personas entwickelt (siehe Scrum bei alpha-board – Teil 1). Damit war der erste Tag vorüber. Es war anstrengend, aber im Großen und Ganzen waren alle zufrieden, denn der Grundstein für das neue Produkt war gelegt.

Ideation – Zuerst ist alles erlaubt.

Am nächsten Tag trafen wir uns wieder. Die dritte Phase des Design Thinkings ist die Ideengenerierung. Die Vision und die Endanwender gaben die Richtung vor. Die Ideation kann man mit der initialen Anforderungerhebung des Projektstarts vergleichen. Um den Endanwenderfokus nicht zu verlieren, benutzen wir dazu User Stories. Nach einem kleinen Crash-Kurs folgte schon die Übung: Wir schrieben die ersten Epics und User Stories zum aktuellen Produkt. Wichtig ist: Am Anfang ist grundsätzlich alles an Vorschlägen erlaubt, ganz nach der Brainstorming-Regel „Ideen sind immer wertvoll“. Im zweiten Schritt dachten wir über weitere Rahmenbedingungen für das Produkt nach. Zum Beispiel sollte unser Produkt  zu Normteilen auf dem Markt kompatibel sein. Erst im letzten Schritt ging es an das Aussieben der Ideen. Outcome dieses Schrittes war ein konkretes funktionales Konzept für einen ersten Prototyp. Es hatte sich schlussendlich eine abgewandelte Variante der ursprünglichen Produktidee entwickelt.

Experimentation – Das ist unser Quality Gate.

Aus Scrum-Sicht befanden wir uns erst jetzt im Sprint. Schon beim Bauen des ersten Prototyps erhielt das Scrum-Team erstes Feedback: Was funktionierte und was nicht? Am interessantesten war für uns das Feedback eines außenstehenden Nutzers: Bei unserem Produkt bot es sich an, ein paar unbeteiligte Kollegen testen zu lassen. Wir waren überrascht, wie viel Feedback in kurzer Zeit von Anwendern generiert wird. Aus diesem Feedback entstanden neue Anforderungen oder alte wurden geändert. Qualität wird also darüber definiert, was funktioniert und was gut ankommt. Gesprochenes ist einfach erfassbar, Verhalten im Kontext zum Produkt zu interpretieren dagegen erfordert meist Übung und Kompetenz. Doch schon der bloße Fokus auf diese impliziten Informationen hilft dem Entwicklungsteam, sich in den Endanwender zu versetzen und so Potenziale zu heben.

Evolution – Der nächste, bessere Prototyp

Hatten wir zuerst gehofft, auf eine Regelungseinheit verzichten zu können, wurden wir in der Experimentation-Phase eines besseren belehrt. Zwar war die Funktion grundsätzlich erfüllt, aber unsere Anwender gaben uns das deutliche Feedback, dass der erhoffte Nutzen noch nicht eingetreten war. Die Evolution ist nichts anderes als die nächste Iteration: Unsere Hypothese wurde verfeinert und neue wurden formuliert. Und somit ging’s in die nächste Runde auf dem agilen Weg der Produktentwicklung und wir bekamen die Chance, ein noch besseres Produkt zu bauen.

Hypothese und Learnings

Wenn wir einen Produktentwicklungprozess effektiv datengetrieben gestalten können, benötigt es

Gerade der letzte Punkt wird im Design Thinking nochmal hervorgehoben, da schlussendlich alles in einem Team erledigt wird. Schon deshalb hat es mir geholfen, diesen Prozess tiefer zu untersuchen. Sich in dieser Offenheit des Produktentwicklungsprozesses ständig an den Endnutzer zu adaptieren, ist der große Vorteil agilen Arbeitens.
In diesem Sinne, euer Marcus
Quelle:
Gloger, B. (2014). Wie schätzt man in agilen Projekten. München: Carl Hanser Verlag.

Warum sitzt David Alaba auf der Bank?

Als Österreicher freue ich mich auf diesen Sommer besonders. Seit Langem hat es unsere Fußball-Nationalmannschaft wieder einmal geschafft, sich für ein Großereignis zu qualifizieren. Wir fahren nach Frankreich und ein ganzes Land ist im Fußballfieber: Fanartikel verkaufen sich wie warme Semmeln, Spiel-Städte wie Bordeaux entdecken den österreichischen Fußballfan als gänzlich neue Touristengruppe und Testspiele gegen Fußballzwerge werden mit Interesse verfolgt. Und so lese ich eines Abends nach dem Testspiel gegen Malta den Spielbericht und wundere mich, dass unser Superstar, David Alaba, bereits zum zweiten Mal das halbe Spiel über auf der Bank sitzt. Müssen wir uns Sorgen machen?
Nein. Ganz im Gegenteil. Teamchef Marcel Koller sieht sich Alternativen an. Richtig gehört. Der Fußball-Zwerg Österreich sucht Alternativen für den besten Linksverteidiger der Welt. Zu Recht. Schließlich kann es sein, dass David Alaba ausfällt, geschont werden muss oder – vielseitig wie er ist – an einer anderen Stelle eingesetzt wird. Um das Team darauf vorzubereiten, lässt er gegen Malta einen anderen Spieler links außen auflaufen. Der Trainer investiert also Testspielzeit.

Fußball ist wie Softwareentwicklung – ein Teamsport

Genauso wie beim Toreschießen (Siehe: Mats Hummels darf keine Tore schießen) zeigt sich in diesem Fall eine Parallele zwischen Fußball und der Softwareentwicklung. Sehen wir uns den Zusammenhang anhand eines – nicht ganz – fiktiven Beispiels an:
Stellen wir uns vor, wir haben einen Spezialisten in unserer Mannschaft, der in seinem Bereich (sei das nun die linke Außenbahn oder die Datenbankverwaltung) eine Koryphäe ist. Aus welchem Grund auch immer ist er zur Zeit jedoch nicht verfügbar. Als Teamsportler wissen wir, dass Ausfälle im Laufe der Saison vorkommen und entsprechende Alternativen aufgebaut werden müssen. Ähnlich sollten auch Entwicklungsteams aufgestellt sein:
Selbstverständlich hat jedes Teammitglied individuelle, unterschiedlich ausgeprägte Stärken. Dennoch müssen wir auf einer Position agieren können, falls es hier zu einem Ausfall kommt. Trainer investieren an dieser Stelle Testspielzeit. Manager können diesem Vorbild folgen und in Wissenstransfer investieren. Dabei verlangt natürlich niemand, dass die Alternative so gut ist wie der Stammspieler, das Team darf nur zu keinem Zeitpunkt auf einer Flanke komplett offen sein.
Im Fußball wie auch in der Softwareentwicklung gibt es die Möglichkeit, Schwächen in der Mannschaft kurzfristig zu kompensieren. Während Fußball-Vereine Spieler ausleihen, können Unternehmen externe Berater oder Entwickler zukaufen. In beiden Fällen gelten dabei zwei Grundsätze:

Doppelspitzen lohnen sich

Im Fußball wie auch in der Softwareentwicklung lohnt es sich, Teams so aufzusetzen, dass jede Position bzw. Funktion mit mehr als einer Person besetzt ist. Während es im Fußball darum geht, gegenüber einem Gegner keine Schwachstelle zu offenbaren, hilft uns die Absicherung innerhalb der Teams dabei, Engpässe in der laufenden Entwicklung zu verhindern. Treten Probleme auf, kann durch die Mehrfachbesetzung außerdem gewährleistet werden, dass jemand da ist, der sich des Problems annehmen kann. Im Sport wie auch in der Softwareentwicklung können Sie sich kurzfristig behelfen, achten Sie dabei allerdings darauf, sich nicht in Abhängigkeiten zu begeben, die Sie nicht steuern können.

Mats Hummels darf keine Tore schießen

Auf dem Fußballplatz hat jeder Spieler eine wesentliche Verantwortung. Die Stürmer sollen Tore schießen, die Mittelfeldspieler die Bälle nach vorne bringen, die Verteidiger sollen verhindern, dass die gegnerische Mannschaft trifft und der Torwart versucht, Schüsse aufs Tor abzuwehren und Elfmeter zu halten. Das bedeutet aber nicht, dass die Spieler nur genau und ausschließlich das machen. Wenn sich die Chance ergibt, darf auch mal ein Abwehrspieler ein Tor schießen oder ein Stürmer in der Abwehr aushelfen. Stellen Sie sich vor, Tore, die nicht von einem Stürmer geschossen werden, zählten nicht. Hummels trifft? Das entspricht nicht seiner Verantwortung als Verteidiger. Marko Arnautovic verhindert auf der Linie ein Tor des Gegners? Die Abwehr des Stürmers gilt nicht, die gegnerische Mannschaft bekommt ein Tor zuerkannt.

Und in der Entwicklung?

Was am Fußballplatz absolut undenkbar ist, scheint in der Entwicklung von neuen Produkten gang und gäbe. Dort gibt es oft einen Hardwareentwickler, der ausschließlich Hardware entwickelt, eine Konstrukteurin, die ausschließlich konstruiert, einen Technischen Zeichner, der ausschließlich Zeichnungen erstellt, eine Einkäuferin, die ausschließlich Teile einkauft, einen Softwareentwickler, der nichts anderes macht, als Software zu schreiben. Jeder hat seinen Bereich, für den er verantwortlich ist. Nur er kann die dort anfallenden Aufgaben übernehmen und nur in seinem Verantwortungsbereich kann er arbeiten.
Wenn wir in Unternehmen neue agile Teams aufsetzen, lautet einer der ersten Einwände, die wir hören oft: „Ich bin Konstrukteur, ich darf nur konstruieren.“ oder „Ich teste nicht, dafür haben wir Versuchsmitarbeiter.“ Die Möglichkeit, außerhalb des eigenen Bereichs zu arbeiten oder zu helfen wird gar nicht in Betracht gezogen. Fehlt es zum Beispiel akut an freien Zeichnern oder ist der Teamkollege überlastet, kommt es selten bis gar nicht vor, dass der andere Kollege, der vielleicht die nötigen Fähigkeiten hätte, dem ersten hilft und somit das Projekt nach vorne bringt.
Was ist der Grund dafür? Hier sind einige Hypothesen:

Würden die Teammitglieder ein bisschen nach links und rechts neben ihrem eigenen Verantwortungsbereich schauen (dürfen), würden sie merken, dass sie sehr wohl helfen können.

T-shaped Professionals in der Produktentwicklung

Auch wenn der Verteidiger seine große Stärke in der Abwehr ausspielen kann, sind seine Fähigkeiten als Stürmer trotzdem gut genug, um auch mal ein Tor zu machen. Der Verteidiger reagiert situativ und flexibel auf die aktuellen Anforderungen, anstatt sich zurückzuziehen und darauf zu warten, dass der Gegner den nächsten Angriff startet. Auch wenn der Stürmer im Mittelfeld aushilft, ist er nach wie vor Experte im Schießen von Toren. Oftmals braucht es nicht DEN Topspieler mit den besten Fähigkeiten, sondern nur jemanden, der zur richtigen Zeit am richtigen Ort das Richtige tut, um den Teamerfolg zu gewährleisten. Genau so verhält es sich auch in der Entwicklung. Der Konstrukteur konstruiert, doch wenn er Zeit hat, darf er ruhig auch mal testen oder in der Fertigungs- oder Prozessplanung unterstützen. Das macht ihn nicht weniger zu einem Experten. In der agilen Community nennt man Mitarbeiter, die fachliche Expertise in ein paar speziellen Bereichen haben und darüber hinaus über Basiswissen in angrenzenden Bereichen verfügen „T-shaped Professionals“. Sie werden erstaunt sein, in wie vielen Bereichen außerhalb der eigenen Verantwortung man durchaus sinnvoll helfen kann.
Ein sehr positives Beispiel für diese Hilfsbereitschaft liefert eine niederländische Firma für Belüftungssysteme, in der ich einige Projekte begleiten durfte. Dort hat in einem Projektteam ein Mitarbeiter aus der Fertigungsprozessplanung in einer Phase, in der er eigentlich noch nicht so viel zu tun hatte, gerne und wie selbstverständlich den restlichen Teammitgliedern seine Hilfe angeboten. Die Designer im Team, die sonst regelmäßig mit neuen Aufgaben zugemüllt wurden, konnte er unterstützen und entlasten, obwohl er nicht in seinem Fachgebiet gearbeitet hat. Das hat dem Projekt und allen Mitgliedern gut getan und Ruhe ins Team gebracht. Das war die Theory of Constraints in Reinkultur: Der größte Engpass wurde aufgelöst, der Durchfluss an der richtigen Stelle erhöht.

Designated Teams fördern nachhaltige Zusammenarbeit

Die Voraussetzung dafür: Offenheit und eine nachhaltige Teamzusammensetzung. Nur wenn die Teammitglieder das Gefühl haben, sagen zu dürfen, dass sie Zeit frei haben, ohne vom eigenen Chef und Abteilungskollegen dafür mit einem Maulkorb bestraft zu werden, werden sie das auch tun. Da Fairness nach dem SCARF-Modell von David Rock ein menschliches Grundbedürfnis ist, muss außerdem absehbar sein, dass der Gefallen, der da geleistet wird, später auch wieder zurückgezahlt werden kann. Werden die Designer später aus dem Team genommen, ohne dass sie sich revanchieren konnten, wird der Prozessplaner einmal und nie wieder geholfen haben. Aus diesem Grund ist die Konsistenz im Team so wichtig. Das Stichwort hier lautet „designated teams“.
Fußball ist eine Teamangelegenheit, genau wie die Entwicklung neuer Systeme oder Software und nur wenn alle zusammenarbeiten, wird man das Spiel am Ende auch gewinnen. Da zählen Tore vom Verteidiger genauso viel, wie Tore der Stürmer. Lassen Sie Ihr Team also auch wirklich als Team arbeiten. Und trauen Sie sich, auch mal über Ihren Schatten zu springen. Sie und Ihr Team werden daran wachsen und davon profitieren.

Eine Geschichte von Freiheit, Zufriedenheit und gelebter Agilität

Was macht für einen Endzwanziger einen tollen Arbeitgeber aus? Für ein Kind der Neunziger, das alle Möglichkeiten hat und alles machen kann, das es sich vorstellen kann. Noch nie waren die Möglichkeiten und Freiheiten so vielfältig und noch nie waren die Angst und Unsicherheit so ausgeprägt wie heute. Was wünscht man sich als Vertreter der Generation Y, der schon seit mehreren Jahren als Agiler Coach arbeitet, von einem Arbeitgeber?

All I Wanna Do

Wenn ich den Gedanken verfolge, kommen zahlreiche Begriffe hoch: