Beratungsblog "Methoden (-Bausteine)"

In "Methodenbausteine für Retrospektiven" sammeln Judith Andresen und Julia Schmidt Methodenbausteine, die sich in der täglichen Coachingpraxis als besonders hilfreich erwiesen haben. 

Der folgende Methodenbaustein ist für Teams hilfreich, die Pseudodebatten über das "richtige agil" führen und darüber das Handeln vergessen.

Das Teamphasenmodell von Tuckman (auch bekannt als Teamuhr) beschreibt die Entwicklung eines Teams in insgesamt fünf Phasen. Teams durchlaufen diese Phasen in unterschiedlichen Geschwindigkeiten. Durch Absprachen, Teamregeln sowie neue Teamkonstellationen sind auch Rücksprünge in der Teamuhr möglich.

Das 1965 entwickelte Modell beinhaltete ursprünglich nur vier Phasen. Erst im Laufe der Zeit erweiterte Tuckmann das Modell um die fünfte Phase – Adjourning. Diese Phase gilt jedoch nur für sich auflösende Teams. Hier gilt es bewusst mit dieser Phase umzugehen und sie auch wahrzunehmen. Dieser Umstand macht es möglich, Motivations- beziehungsweise Performance Rückgang erklären zu können.

Karsten Glied sprach auf der BASTA über offene Kommunikation -- der Schlüssel zum Erfolg in Projekten und Teams.

Anfang dieses Monats hatte ich das Glück, die “Agile on the Beach”-Konferenz in Falmouth, Cornwall, besuchen zu können: eine absolute Konferenzempfehlung. Großartiges Line-up in idyllischer Umgebung mit charmanter Durchführung (@Judith: nochmals Danke für den Tipp!). 

Einer der vielen hochwertigen Konferenzvorträge war der von Adrian Howard über Iterative Persona: wie kann man Personae in der agilen Entwicklung verankern und sie dabei agil weiterentwickeln?

Dieser Post basiert auf Adrians Vortrag und den anschließenden Diskussionen.

For many people, the concept of the minimal viable product is quite hard to grasp. It’s even hard to understand the PDCA cycle.” The “d” in PDCA demands: “Just do it!”. Or to paraphrase: “Just do the experiment! Prove your hypothesis!”

And we try - very very hard to do just that. But, let’s be honest, our MVP (emphasis on M for “Minimal”) often is anything but that. It frequently grows to be huge.

What can we do to prevent that? One approach could be to stop aiming for being complete and perfect and rather going for distilling something that is as small as possible while being complete in itself: our MVP, with which we can test our hypothesis.

But how do we find this elusive MVP? How can we talk about it? How can we visualize it?

I hope that you may find the following fable helpful for this process. 

Wie gehen wir schlau mit dem vorhandenen Wissen im Team um?

Stichworte gibt es viele dazu: Crossfunktionalität, Interdisziplinarität, GeneralistInnen, SpezialistInnen oder ein T-Shaped-Skill-Set. Diese Stichworte lassen sich auf eine zentrale Frage zurückführen: Welche Fähigkeiten benötigen wir, und bekommen wir das Wissen sinnvoll verteilt?

Code Reviews gehören zur gängigen Praxis in Entwicklungsteams.  Ziel eines Code Reviews ist es, mögliche Fehler oder Vereinfachungen zu identifizieren, um langfristig die Codequalität zu steigern. 

Die grundsätzliche Code Review Regel ist schnell aufgestellt:

Bevor ein Ticket den Status "Fertig" erlangen darf,
sieht die Definition of Done vor,
dass der Software-Code durch ein anderes Teammitglied geprüft wird.

In vielen Teams und Unternehmen gibt es eine große Sehnsucht, agiler zu werden. Dabei wird in den wenigsten Fällen geklärt, was unter „agilem Arbeiten“ oder einer „agilen Organisation“ verstanden wird. Während die einen unter agil bestimmte Projektmethoden verstehen, träumen andere von einer beweglichen, lernenden Organisation. Andere fordern das „agil Skalieren“. Aber was heißt das genau?

Liebe Leserinnen und Leser,

Gegensätze ziehen sich an. Oft genug so stark, dass es kracht. Das macht unseren Alltag nicht einfacher. In unserem heutigen Newsletter beleuchten wir einige dieser Gegensätze.

Viel Spaß beim Lesen!

Julia Schmidt berichtet über drei Sessions auf der Social Media Week Hamburg, an denen sie teilgenommen hat.

Welche Aufgabe war eigentlich während des letzten Sprints ein echtes Thema? Eine einfaches Mittel zum Finden von Retro-Kandidaten ist die "Shitlist".

Elon Musk wird mit seinen Firmen Tesla und Space X oft als "wahrer Tony Stark" beschrieben. Wie das Alter Ego der Comicfigur Iron Man ist er ein hervorragender Ingenieur. Anders als Iron Man aber offensichtlich kein Einzelkämpfer. Vielmehr treibt er Teams zu außergewöhnlichen Leistungen (wenn auch seine Einstellung zur Work-Life-Balance seiner Mitarbeitern und Mitarbeiterinnen fraglich ist).

Eine Organisation "agiler machen" ist der Auftrag. Das Vorhaben ist komplex. Komplexe Vorgänge werden am Besten iterativ-inkrementell bearbeitet. Der Transitionsauftrag geht daher an ein Transitionsteam, dass sich der Fragestellung in Sprints mit Dailys, Public Reviews und Retros nähert. Aber was genau macht das Transitionsteam eigentlich? 

Diese Frage "Fit für die digitale Transformation" stellte Anja Mentrup auf dem Embedded Software Engineering Kongress in Sindelfingen. Dabei stellte sie eine an SCRUM angelehnte Methode vor, um die notwendigen Veränderungsschritte in der Organisation einzuleiten.

Querschnittsstudien wie das Chaos Study, die sich sowohl mit klassischen als auch agilen Projekten beschäftigen, zeigen, dass die nach wie vor sehr viele IT-Projekte scheitern. Sie werden zu spät, zu teuer oder mit zu wenig Qualität ausgeliefert - wenn überhaupt.

Schaut man sich in diesen Studien die Begründungen an, findet man als Hauptursache nicht mangelndes technisches Wissen, sondern mangelhafte oder fehlerhafte Kommunikation.

Richtig reden sollte einfach gehen. Und werden mit dem sechsten agilen Prinzip eingefordert: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Aber wie gelingt eine offene und direkte Kommunikation? Oder mehr: Wie entsteht ein Klima, in der aufkommende Risiken und Probleme nicht totgeschwiegen, sondern besprochen werden?

Der Vortrag zeigt erste Schritte in offene und faire Projektkommunikation, in der erkannte Risiken und Fehler bearbeitet werden - und nicht das “das habe ich schon immer gewusst” gewinnt.

Dafür stellt die Referentin häufig verbreitete Vorurteile und Handlungsweisen von Team-Mitgliedern vor und zeigt auf, wie offene Kommunikation gelingen kann. Dabei setzt die Referentin auf eine wertschätzende Kommunikation (im Sinne der Non-violent communication) – sowohl in formaler Kommunikation als auch in informellen Gesprächen.

"Wir arbeiten agil -- nur der Auftraggeber / die Auftraggeberin setzt uns unter Druck!" Auf der Web Tech Conference untersuchte Judith Andresen diese häufig gehörte Klage. Sie plädierte für eine ganzheitliche Produktverantwortung.

Die Idee des Minimum Viable Product (MVP) ist für viele schwer zu greifen. An Stelle von „vollständig und perfekt“ gilt es, „klein und in sich vollständig“ zu erfüllen.

A minimum viable product has just those core features that allow the product to be deployed, and no more.

[Wikipedia] Die konkreten Kernfeatures zu bestimmen, fällt vielen Projektteams schwer. Häufig hören wir: "Das geht nicht kleiner!" Die folgende Metapher hilft Euch (vielleicht) das richtige MVP zu finden.

"Wer seinen Arbeitsalltag acht Minuten lang vorbereitet und konsequent plant, kann täglich eine Stunde für das Wesentliche gewinnen."

Anja, Judith und Karsten sprachen in den vergangenen Tagen auf der Code.Talks in Hamburg und der BASTA in Mainz. Agiles Management, Projekte außer Kontrolle, agile Freiheiten und "Frauen in der IT" standen für die drei auf dem Programm.

Planen bis zur Perfektion! Weiter, weiter, weiter! Viele Teams begreifen Minimum Viable Products als unvollkommene Produkte eines nie erreichten Ideals. Das dämpft die Erreichensfreude. 

MVPs und der agile Grundsatz "Good is enough" sind schnell erklärt. Mit ihnen ist ein kompletter Paradigmenwechsel verbunden. Bis der bei allen im Unternehmen angekommen ist, wird es Zeit brauchen. Viel Zeit.

Was heißt eigentlich Lernen in Organisationen? Wie entsteht eine Kultur, in der Lernen möglich ist?

Auf der International PHP Conference in Berlin sprach Judith Andresen über zur Aufgabe und zum Kontext passende Methodenbausteine und Projektmethoden.

Lieber Newsletter-Empfänger,

liebe Newsletter-Empfängerin,

über die "Digitale Transformation" wird aktuell viel geredet und geschrieben. Eher über die Tatsache, dass sie gerade passiert, weniger darüber, wie wir alle damit umgehen sollten. Parallel dazu gibt es eine große Debatte zu agilen Organisationen und Projektmethoden. 

Beide Diskussionen haben viel miteinander zu tun, wie die nachfolgenden Blog-Artikel zeigen.

Lasst Euch inspirieren!

Die Stakeholder einer agilen Transition sind alle Mitarbeiter und Mitarbeiterinnen des Unternehmens. Wie nehmen die Stakeholder agilen Transition am Prozess teil?

Das Anforderungsmanagement wird in vielen Unternehmen über mehrere Ebenen organisiert. Das wird das Anforderungsmanagement prozessural von den Umsetzungsteams abgetrennt. Eine Alternative zu diesem Vorgehen ist der EggPlant-Prozess -- ein interdisziplinärer, getakteter Innovationszyklus.

Viele Unternehmen beschreiben sich als innovativ und lernend. Nur wenige sind hier erfolgreich. Zu tief sind Schuldzuweisungen und Risikoaversionen in der Unternehmenskultur verankert. Dabei ist eine lernende Organisation erlernbar, braucht aber Zeit.

Auf der JAX! sprach Judith Andresen, über viele Wege, agil zu werden. 

Während des BEVH 2015 zeigten Judith Andresen und Dr. Anja Mentrup in einem anderthalbstündigen Vortrag, wie man E-Commerce-Projekte richtig aufsetzt.

Spoiler: die sind meist komplex ;-)

Während des Frühjahrfachgesprächs der German Unix User Group sprach Judith Andresen über eine gute Fehlerkultur -- und speziell über den Methodenbaustein "Retrospektiven". 

Viele Teams möchten neben der Komplexität von Aufgaben auch deren Geschäftswert bestimmen -- beide Werte sind für die agile Planung sehr wichtig. 

Agile Projektmethoden fordern eine interdisziplinäre und iterative Arbeit in kleinen Zyklen. Die Umstellung auf diese Herangehensweise fällt vielen Projektteams sehr schwer – der "Big Design Up Front"-Gedanke sitzt tief in den Projektgenen.

Wie gelingt es aber, kleine, unabhängige Projekte aus einem großen Ansatz heraus zu denken? Wie können sich Teams pragmatisch die Forderung nach Iteration und Lernen erfüllen und sich von impliziten Vorstellungen über gute, vollständige Projekte lösen?

Die aus dem Code Factoring bekannte "Rule of Three" ist nicht nur dort nützlich -- diese Regel ist auch eine gute Faustregel für Prozessveränderungen in Teams und Unternehmen.

Probiert Methodenbausteine, Rituale und Vorgehensweisen im "Management 3.0 #WorkOut" aus! Wir zeigen Euch diese in Ganztagesworkshop am 01. Juni beziehungsweise am 05. November 20151!

Ich höre und vergesse.

Ich sehe und behalte.

Ich handle und verstehe.*

Wie beschreibe ich die Vision meines Products? Neben dem Impact Mapping ist das Lean Canvas eine gute Methode.

Abschätzungen von Zeitbedarf im komplexen oder chaotischen Kontext ist sehr, sehr schwer. Ein probates Mittel zur Bestimmung des Machbaren ist das Aufwandspoker.

Es gelingt uns häufig nicht, korrekt zu delegieren. Unklare Anweisungen oder zu allgemeine Ziele -- die Fehlerquellen für misslungene Delegatioen sind groß. Klarheit über die Delegationsform hilft sowohl den Delegationsgebern als auch den -nehmern.

Die Vorgesetzten, womöglich der Vorstand, fordern ein neues Projekt. Und schnell wird dieses Projekt angefangen. Doch es kommt nie zu Ende. Es ist die laufende Nr. 20 aller Projekte des Unternehmens, und es ist zu ungenau, aber gleichzeitig zu groß spezifiziert. 

Strategische Beratung, Konzept, Design, Produktion: In Agenturprojekten meint jede Disziplin ihren spezifischen Weg zum "perfekten" Ergebnis zu kennen. Oft geht viel Zeit verloren, bis sich alle aufeinander eingegroovt haben – noch schlimmer, wenn sie es nicht tun.

Judith Andresen zeigt, wie man agile Methoden nutzt, um ein Team zusammenzuschweißen und ihm gangbare Wege aufzuzeigen.

Das Team hat sich geeinigt, welche UserStorys im nächsten Projektabschnitt bearbeitet werden. Aber die UserStorys können nicht abgeschlossen werden. Das Projektteam kämpft mit dem Umgang.

An Stelle alles im Detail zu Beginn des Projekts zu planen, werden in agilen Projektmethoden Ziele formuliert, die im Laufe des Projekts eingelöst werden. Um diesen fachlichen Anforderungen zu erfassen, könnt Ihr diese in UserStorys formulieren.

UserStorys funktionieren anders als Lasten- und Pflichtenhefte. Sie sind der Ausgangspunkt einer intensiven Kommunikation über das gewünschte Ziel. 

Update: Der Baukasten ist kein Buch, sondern ein Karteikasten geworden. Die geplanten Inhalte des Buches sind im agilen Karteikasten sminca aufgeführt. Der Karteikasten ist seit 08/2015 bestellbar.