7 (plus oder minus 2) Arten, wie dein Gehirn dich reinlegt

Keynote von Jasmine Simons-Zahno und Joseph Pelrine, Lean Agile Scotland 2019

„Kognitive Voreingenommenheit“ ist ein bekannter psychologischer Effekt, der oft als Erklärung – oder Entschuldigung – für das Verhalten einer Person herangezogen wird.

Obwohl es eines der bekanntesten psychologischen Konzepte überhaupt ist, ist es definitiv nicht das einzige, das das Denken und Handeln einer Person beeinflusst. Diese Session wird dich durch die unserer Meinung nach relevantesten psychologischen Konzepte bei der Arbeit mit agilen Teams führen und dich und dein Team in die Lage versetzen, die häufigsten Fallstricke zu umgehen, in die wir bisher selbst getappt sind.

Jenseits von Buzzwords – Teamleistung durch die Augen der Psychologen

Keynote von Jasmine Simons-Zahno und Joseph Pelrine, Agile Cambridge 2018

Willst du lernen, wie du dein Team intelligenter machen und besser zusammenarbeiten kannst?

Die Konzepte der intelligenten Teams und der psychologischen Sicherheit sind derzeit heiße Themen in der agilen Welt, mit zahlreichen Blogposts und Konferenzpräsentationen darüber. Wie die meisten psychologischen Themen gehen sie jedoch viel tiefer, als die meisten Blogposts und Konferenzpräsentationen vermuten lassen.

In dieser Session werden wir einen Blick hinter die Kulissen der psychologischen Forschung zu Teamintelligenz und psychologischer Sicherheit werfen und nicht nur erforschen, wie sie getestet werden, sondern auch diskutieren, wie sie trainiert werden können. Du lernst einige einfache und unterhaltsame Techniken, die du nutzen kannst, um dein Team zu verbessern.

Über psychologische Sicherheit, intelligente Teams und andere coole Psychologie-Buzzwords, mit denen Agilisten um sich werfen

Keynote von Joseph Pelrine und Jasmine Simons-Zahno auf der Stretch Conference, 7 – 8. Dezember 2017, Budapest

Bist du daran interessiert zu lernen, wie du dein Team intelligenter werden und besser zusammenarbeiten lässt?

Die Konzepte der intelligenten Teams und der psychologischen Sicherheit sind derzeit heiße Themen in der agilen Welt, mit zahlreichen Blogposts und Konferenzpräsentationen darüber. Wie die meisten psychologischen Themen gehen sie jedoch viel tiefer, als die meisten Blogposts und Konferenzpräsentationen vermuten lassen.

In diesem Vortrag werden wir einen Blick hinter die Kulissen der psychologischen Forschung zu Teamintelligenz und psychologischer Sicherheit werfen und nicht nur erforschen, wie sie getestet werden, sondern auch diskutieren, wie sie trainiert werden können. Du wirst einige einfache und unterhaltsame Techniken lernen, die du nutzen kannst, um dein Team zu verbessern. Auf dem Weg dorthin werden wir auch ein paar Mythen über Dinge wie 7 plus/minus 2 und das Tuckman-Modell ausräumen

Folien-Download hier.

Über psychologische Sicherheit, intelligente Teams…

Vortrag von Jasmine Simons-Zahno und Joseph Pelrine, Agile Tour Vienna 2017

Bist du daran interessiert zu lernen, wie du dein Team intelligenter werden und besser zusammenarbeiten lässt?

Die Konzepte der intelligenten Teams und der psychologischen Sicherheit sind derzeit heiße Themen in der agilen Welt, mit zahlreichen Blogposts und Konferenzpräsentationen darüber. Wie die meisten psychologischen Themen gehen sie jedoch viel tiefer, als die meisten Blogposts und Konferenzpräsentationen vermuten lassen.

In diesem Vortrag werden wir einen Blick hinter die Kulissen der psychologischen Forschung zu Teamintelligenz und psychologischer Sicherheit werfen und nicht nur erforschen, wie sie getestet werden, sondern auch diskutieren, wie sie trainiert werden können. Du wirst einige einfache und unterhaltsame Techniken lernen, die du nutzen kannst, um dein Team zu verbessern. Auf dem Weg dorthin werden wir auch ein paar Mythen über Dinge wie 7 plus/minus 2 und das Tuckman-Modell ausräumen.

Ein tolles Sketchnote-Bild des Vortrags von Katrin

Definition of Done verständlich erklärt

(c) Bernard Goldbach - Creative Commons

Vor Kurzem hielt ich in einem Workshop ein Smartphone in die Luft und fragte einige Menschen, ob das ein gutes Telefon sei. Viele fanden es gut, manche okay und einer mochte es absolut nicht. Bei der Nachfrage nach Gründen stellten wir schnell fest, dass verschiedene Menschen verschiedene Qualitätsmerkmale betrachten und wichtig finden.

Das ist auch in einem Softwareentwicklungsteam nicht anders – bei der Frage, ob ein Stück entwickelte Software fertig ist, gibt es oft Uneinigkeit und Diskussionen. Woher weiß ich, dass ich fertig bin mit der Entwicklung? Was kann ich von meinen Kollegen erwarten, wenn sie ein Feature umsetzen? Was erwartet mein Product Owner?

Um diese Fragen in einem agilen Team zu beantworten und Klarheit zu schaffen, gibt es in der agilen Welt ein Artefakt mit dem Namen „Definition of Done“. Im Prinzip ist es soetwas ähnliches wie eine sehr spezifische Arbeitsvereinbarung oder selbst auferlegte Regeln, wie man Entwicklungsqualität definiert.

Eine Definition of Done (kurz: DOD) ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird.

Man kann sich das als eine Art Kriterienkatalog oder Checkliste vorstellen, die man bei jedem Feature (sprich: User Story) durchgeht und auf Erfüllung überprüft:

  • Habe ich Unit Tests entwickelt?
  • Wurde die Dokumentation erweitert?
  • Sind die Codekonventionen eingehalten?
  • usw.

Definition of Done (DOD)In einem Workshoptermin, den der Agile Coach bzw. ScrumMaster moderiert, wird diese Selbstverpflichtung des Teams als Einigung gemeinsam erarbeitet. In Zukunft ist sie die Basis für Klarheit bei der Frage, ob ein Feature fertig ist und hängt deswegen im Idealfall im Teamraum. Die Verantwortung für die Inhalte und auch die Einhaltung der Vereinbarung liegt ausschließlich beim Team. Ein wachsamer Agile Coach erinnert aber an die festgelegten Elemente zur passenden Gelegenheit.

Übrigens darf man im Laufe des Wachstums eines agilen Teams durchaus erwarten, dass die Definition of Done reift, somit mehr und umfangreichere Qualitätskriterien enthalten sind. Vielleicht ist es damit die erste Checkliste, die organisch wächst.

Management 3.0 – Agile Leadership Practices in Deutschland lernen

Agiles Management ist ein häufig übersehener Teil agilen Vorgehens. Es gibt viele verfügbaren Informationen über agile Softwareentwicklung, agiles Testen und agiles Projektmanagement, aber wenig konkrete Praktiken für Entwicklungs- und Teamleiter. Unabhängig davon müssen auf dem Weg zum agilen Unternehmen aber nicht nur  Entwickler, Tester und Projektmanager neue Praktiken lernen. Auch Entwicklungs- und Teamleiter müssen eine solche neue Herangehensweise zur Führung und Steuerung agiler Organisationen lernen.

Mehrere Studien identifizieren, dass das traditionelle Management das grösste Hindernis bei der Einführung agiler Softwareentwicklung ist. Entwicklungsleiter und Teamleader dürfen also neu erfahren, was ihre Rolle in der agilen Organisation ist.

Jürgen Appelo hat sich seit einigen Jahren mit genau diesem Thema in seinem bekannten Blog auseinandergesetzt, im Buch „Management 3.0“ sowie den gleichlautenden Kursen seine Erkenntnisse aus seiner eigenen Zeit als Manager einer großen agilen Firma in den Niederlanden veröffentlicht.

Zweimal hatte ich im vergangenen Jahr die Gelegenheit, Jurgen in seinen Kursen zu besuchen und bin zu der Überzeugung gekommen, dass die Denkweisen und Werkzeuge, die er entwickelt hat, vielen Führungskräften im 21. Jahrhundert helfen können, professionell und erfolgreich in komplexen Umgebungen zu arbeiten. Daher biete ich in Kooperation mit Jurgen als offizieller Trainer in diesem und den kommenden Jahren offene Management 3.0 Kurse in Deutschland an.

Wenn auch Sie sich diesem Thema intensiver widmen möchten, finden Sie vieles dazu in Jurgen Appelos Buch und in meinen Kursen.

Eine Rückschau: Agile Breakfast Konstanz – Teamcharta

Es war eine außergewöhnliche Einladung – @scrumphony hatte mich im Sommer gefragt, ob ich Lust hätte bei der Scrum User Group Lake Constanz zu sprechen. Die hatte ich.

In der ruhigen und winterlichen Kulisse empfing uns der Bodensee in einer der schönsten Locations, in denen ich bisher gesprochen habe: Ein renovierter Wasserturm, direkt am Ufer des Sees, im obersten Stockwerk mit zwei ausgebauten Räumen versehen, die wir nutzen konnten.

Wie wir zu Beginn meines Vortrags schnell feststellten, war jedoch keiner wegen des Gebäudes hier. Die unterschiedlichen Motivationen der Gäste im vollständig belegten Raum erfassten wir vorneweg (siehe Bild).

Ein Anliegen meines Vortrags sollte es sein, Bewußtheit für die Andersartigkeit von Menschen zu schaffen und den Hintergrund von Konflikten zu thematisieren.

Als Lösungsangebot konnten die Zuhörer die Teamcharta für Scrum Teams und das Harvard Verhandlungsmodell als Inspiration, um strittige Situationen besser behandeln zu können kennenlernen.

 

Eine Teamcharta ist ein gemeinsam erstelltes Dokument, welches diese Teile enthalten kann:

•  Rollen (Wer gehört zum Team, in welcher Funktion?)
•  Verantwortlichkeiten (Wer darf was?)
•  Prozessvereinbarungen (Wie lange ist unsere Iteration?)
•  Regeln des Zusammenlebens (Handys aus im Meeting?)
•  Meetingzeiten (Wann ist das Daily Scrum?)
•  Technische Vereinbarungen (Testgetrieben? Testcoverage?)

Gerne verwende ich ein Mindmap-Diagramm, um alle Aspekte optisch ansprechend abzubilden. Der Ausdruck gehört dann an die Wand des Teamraums.

Die rege Diskussion um den Einsatzbereich des Werkzeugs im Anschluß des Vortrags machte Spaß und mündete darin, dass eine Teamcharta für sehr gute Teams das Zusammenfinden erleichtert, normale Teams am meisten profitieren und schwierige Teams, also solche mit nicht aufgearbeiteten Problemen auf der Beziehungsebene der Mitglieder, mit einer Teamcharta so deutlich auf den Konflikt gestoßen werden, dass man sich den Einsatz vorher gut überlegen darf.

Ansonsten gilt: Alles kann, nichts muss. Gestaltet das Dokument so, wie es für das Team funktioniert und Konsenz und Dissenz werden transparent. Ein weiterer Schritt zu einem Hochleistungsteam ist dann zurückgelegt.

Die NRWConf 2011 in Wuppertal – meine Retrospektive

Dieses Jahr trafen sich in Wuppertal beinahe 200 Menschen, um sich über Softwareentwicklung auszutauschen. In einem Veranstaltungsort, der sonst Konzerten dient und „Die Börse“ heißt, gab es viele Gelegenheiten zum Austausch und um neue Kontakte zu knüpfen. Die informelle Atmosphäre machte dies zu einem richtigen Vergnügen. Das Organisationsteam hat darüber hinaus ganze Arbeit geleistet: Viele Helfer kümmerten sich um die Gäste, unter anderem mit dauerhaften Freigetränken sowie einem schönem Buffet zu einem Eintrittspreis, der mehr einer netten Geste als einem Ticket gleich kam.

Auch aus der Sprecherperspektive war das Bild rund: Ein Speakerdinner zum Wohlfühlen, eine gewissenhafte Programmauswahl und problemlose Technik machten es uns leicht. Das clevere Farbleitsystem verriet, wo welcher Raum ist und die Agenda hatte jeder direkt um seinen Hals am Keylane. An diesen Kleinigkeiten merkt man, dass die drei Köpfe des Just Community e.v. nicht zum ersten Mal eine Veranstaltung dieser Größe organisiert haben – und es war dieses Jahr die NRWConf mit den meisten Teilnehmern überhaupt seit Gründung.

Mit meiner Session names „Teamcharta – Gemeinsam sind wir stark“ hatte ich mir ein Thema vorgenommen, dass auch im agilen Umfeld eher exotisch als typisch ist und ich war sehr neugierig, wie der Anklang bei einer Entwicklerkonferenz wohl sein würde.

Ein voller Saal überraschte mich positiv: Viele Teilnehmer hatten ein großes Interesse, über den technischen Tellerrand hinauszusehen und sich mit der Art und Weise zu beschäftigen, wie Teams Konflikte vorbeugen können.

Und auch von dem Feedback einiger Teilnehmer zu anderen Sessions habe ich den Eindruck gewonnen, das viele inhaltlich spannende Beiträge dabei waren.

Eine rhetorisch gekonnte und inhaltlich ansprechende Keynote von Dr. Ingo Dahm machte aus dieser Veranstaltung nicht zuletzt einen Gewinn. Mein Fazit: Wirklich lohnenswert.

Die volle Blüte Scrums – Entwicklungsphasen eines Teams richtig unterstützen

Teams von Menschen kann man als komplexe adaptive Systeme betrachten, was auch bedeutet, dass solche Gruppen ständiger Veränderung unterliegen.

Jeder Mensch bringt seine Tagesform ein, seine aktuellen Lebensthemen, seine Erfahrung und viele weitere Faktoren, die das Zusammenleben und Arbeiten beeinflussen. Es gibt verschiedene Modelle zur Gruppenentwicklung, welche diese Komplexität auf ein handhabbares Maß reduzieren.

Kommen Scrum-Teams neu zusammen oder werden in ihrer Zusammensetzung stärker verändert, durchlaufen sie verschiedene Entwicklungsstufen. Als erstes dominieren Unsicherheit, Hoffnungen und Befürchtungen aber auch Vorfreude. Die Teammitglieder kennen sich teilweise oder auch vollständig noch nicht.

Hier bieten sich als ScrumMaster vor allem Aktivitäten an, die Vertrauen aufbauen und ein Kennenlernen ermöglichen:

* Kollaborative Gruppenspiele
* Vorstellen bisheriger Projekt- und Erfahrungshistorie
* Partnerinterviews mit anschließender Gruppenpräsentation
* Wertearbeit von Einzelnen und der Gruppe

Besteht eine grundlegende persönliche und berufliche Basis, können Gemeinsamkeiten und Verbindendes herausgearbeitet werden. Formen der Zusammenarbeit können definiert werden, durch:

* Eine gemeinsame Vision/Mission
* Teamnormen bzw. eine Teamcharta
* Konventionen auf technischer Ebene

In der darauffolgenden Differenzierungsphase bildet sich die informelle Hierarchie eines  Teams heraus. Rollen werden detaillierter ausgeprägt, es klärt sich, wer sich für welche Themen verantwortlich macht und fühlt. Um mit auftretenden Spannungen umgehen zu können, kann ein ScrumMaster diese Aktionen planen:

* Einführung des Teams in Gewaltfreie Kommunikation oder andere Kommunikationsmodelle
* Erarbeiten von Regeln für konstruktives Feedback
* Anwenden von Win-Win-Strategien wie dem Harvard-Modell für Verhandlungen

Darauffolgend kann das Team in die hochproduktive Arbeitsphase gelangen – es steht in der vollen Blüte Scrums.

Durch die gemeinsame Basis, vereinende Ziele und einen wertschätzenden, vertrauensvollen Umgang entsteht eine Atmosphäre, die Kreativität und Fehler zulässt. Dies kann noch weiter gestärkt werden durch:

* Lernen von Kreativitätstechniken
* Verbindende Events (Teamabende, Outdoor-Events)

Die meisten genannten Aktivitäten können im Rahmen einer Retrospektive oder gesonderten Teamentwicklungsworkshops eingebracht werden – abhängig vom Grad der Komplexität des Teams, der Herausforderungen und des Unternehmens.

Schaut man sich im Detail diesen aufwändigen Findungsprozess an, wird sich für viele die Frage nach der Häufigkeit von Teamveränderungen beantworten: Teams sollten so selten wie möglich verändert werden – außer sie funktionieren auch nach intensiver Investition nicht.

Und wie sollten nun Scrum Teams generell zusammengestellt werden? Darauf hat Mike Cohn eine Antwort (bzw. einige Fragen).

Shu Ha Ri – Teamentwicklung in Etappen

Jurgen Appelo, den ich dieses Jahr persönlich bei seinem Management 3.0 Seminar in Hamburg kennenlernen durfte, hat eine für mich sehr stimmige Aussage getroffen:

Alle Modelle sind falsch, aber manche sind nützlich.

Ein Modell, dass ich für nützlich halte, ist das Shu Ha Ri – Modell, welches aus dem fernöstlichen Kampfsport stammt und von Lyssa Adkins in ihrem Buch „Coaching Agile Teams“ ausführlich dargestellt wird.

Gerade in einer solch komplexen Domäne, wie der Softwareentwicklung, sind solche Abstraktionen hilfreich, um effektiv mit Gruppen arbeiten zu können und bei Teamentwicklungsprozessen bei der Selbstreflektion zu helfen.

Das Shu Ha Ri – Modell besteht aus drei Stufen:

  • Shu: Jemand, der sich in dieser Ebene bewegt, benötigt klaren Regeln. Ihm fehlt die Erfahrung, Zusammenhänge und Hintergründe bewerten zu können und er folgt den Regeln erstmal in Vertrauen auf seinen Lehrmeister.
  • Ha: Der Lernende beherrscht die grundlegenden Praktiken und Prinzipien. Jetzt entsteht Raum, das Handeln zu reflektieren und ein tieferes Verständnis zu entwickeln, warum das gelernte funktioniert oder was es im Kern ausmacht. Diese Einsichten ermöglichen es, die Regeln zu brechen und neu zu definieren, ohne die dahinterliegenden Wirkprinzipien zu verletzen.
  • Ri: Man selbst ist die Regel. In tiefer Kenntnis der Notwendigkeiten und Mechaniken des Handelns können eigene Regeln erstellt werden, die nichts mehr mit den ursprünglichen Regeln zu tun haben und diese in ihrer Wirksamkeit in Bezug auf die eigene Situation deutlich übertrumpfen.

Man kann dieses Modell auf verschiedene Bereiche eines Teams anwenden, wie auch auf die persönliche Entwicklung in Bezug auf ein Thema.

In welchem Bereich Deines Lebens oder Jobs bist Du Shu, wo Ha und wo Ri?