Seminar buchen

Monat: April 2011

Veröffentlicht am

Was ist eigentlich ein Agile Coach?

Die Informatik ist ja doch noch eine recht neue Branche, verglichen mit anderen Naturwissenschaften und Ingenieursdisziplinen. Ich habe lange Zeit gedacht, dass mit der weiteren Entwicklung der Branche die Softwareerstellung immer einfacher werden müsste. Es entstehen leistungsfähigere Frameworks, Entwicklungsumgebungen und Tools sowie professionellere Schulungsanbieter und hochwertige Fachzeitschriften.

Mittlerweile hat sich mein Bild gedreht. Die Erwartungshaltung von Anwendern ist mittlerweile durch den Fortschritt so hoch, dass die Komplexität der Entwicklung, Tools und Frameworks auch immer weiter steigt. Nur ein Beispiel: Eine Webanwendung die vor 5 Jahren noch Preise gewann, will heute fast keiner mehr benutzen.

Trotz dieser großen Komplexität gibt es Budget- und Zeitvorgaben, Qualitätsansprüche und Anforderungskataloge, die beachtet werden wollen im Projektverlauf. Seit 20 Jahren arbeiten viele Menschen auf der Erde zusammen, um sich diesem Thema anhand der Lösung „Agilität“ zu nähern. Viele Erfolge großer und kleiner Projekte führten zu der Entstehung neuer Rollen in diesem Kontext. Eine davon ist der Agile / Scrum Coach.

Scrum ist dabei übrigens ein spezielles Vorgehensmodell, während „Agile“ als Überbegriff viele Methoden meint, die sich auf das agile Manifest stützen, wie zum Beispiel Kanban, Extreme Programming oder Crystal.

Was ist nun so ein Scrum bzw. Agile Coach?

 

Lyssa Adkins hat in Ihrem Buch „Coaching Agile Teams“ eine treffende Beschreibung, die ich hier gerne mal sinngemäß in Deutsch wiedergebe:

Ein Scrum / Agile Coach ist

  • Jemand, der agile Praktiken und Prinzipien samit ihres vollen Umfangs schätzt und Teams helfen kann, diese ebenfalls zu schätzen
  • Jemand, der sich mit organisationsweiten Blockaden und Hindernissen auseinander gesetzt hat und währenddessen ein Coach für Manager und andere vielleicht nur indirekt betroffene Mitarbeiter wurde
  • Jemand, der Führungskräften jeder Unternehmensebene die Vorteile agiler Produktion erklären kann
  • Jemand, der die Ideen von professioneller Moderation, Coaching, Konfliktmanagement, Mediation und mehr einsetzt, um Teams zu Hochleistungsteams zu machen

Ergänzen möchte ich an dieser Stelle noch den fast trivialen Punkt, dass der Coach natürlich auch eine umfangreiche Kenntnis in den angewandten Methoden haben sollte.


Mehr dazu in dieser Podcast-Folge:

Veröffentlicht am

Testballons und die Beliebigkeit der Welt

Seit einiger Zeit setze ich mich mit Formen des Konstruktivismus auseinander. Dahinter liegt das Bild, dass jeder Mensch geprägt durch seine eigenen Erfahrungen und Rahmenbedingungen eine eigene Weltsicht hat. Häufig spricht man hier von einer inneren Landkarte, die eben nicht dem Gebiet selbst entspricht (nach Gregory Bateson).

Die Tatsache, dass es keine objektive Wahrheit gibt, hat mich erstmal ziemlich verwirrt. Wie kann ich entscheiden, was ich tue, wenn ich für einen Kunden oder ein Team das Richtige tun möchte?

Dazu kam dann Jurgen Appelos Sicht auf Teams als komplexe adaptive Systeme. Diese Systeme sind selbstorganisierend und folgen keinem kausalen Zusammenhang. Das bedeutet, dass ich nicht Maßnahme A einsetzen kann, um gewünschten Effekt B zu erzielen. Und auch hier stellte sich mir die selbe Frage: Wie kann ich überhaupt noch handeln, wenn ich im vorhinein nicht weiß, ob das gewünschte Ergebnis entsteht.

Die Lösung auf beide Fragen ist eigentlich simpel. Simpel wie die meisten guten Lösungen.

Es ist unmöglich, vorher zu wissen, was die richtige Handlung ist. Welche Handlung ich anstoße, kann nur meine Intuition beantworten. Danach folgt das Vorgehen der „Inspect and Adapt“ Methodik. Entweder die Maßnahme hat seinen Zweck erfüllt oder eine andere  muss her.

Und wenn ein Fehler bei aller Sorgfalt und gutem Willen passiert? Gibt es überhaupt Fehler, wenn die Absicht gut ist und man nicht im Vorhinein weiß, ob der gewünschte Effekt eintritt? Oder ist es nicht vielmehr Feedback, dass wir zum Lernen nutzen können? In lernenden Systemen muss scheitern erlaubt sein und sollten Versuche belohnt werden.

Die Konsequenz
Wenn Menschen mich fragen, in welche Richtung wir uns entwickeln sollten, was als Nächstes getan werden sollte und was bei einem Problem helfen könnte, bin ich handlungsfähig und kann mit festem Willen, Energie und Motivation das vertreten, was meine Intuition mir sagt. Es ist so, als ob  man ständig Testballons startet und schaut, in welche Richtung der Wind sie treibt.

Ja, es könnte die Falsche sein und ja, es könnte die Richtige sein. Wissen werde ich es nur, wenn ich handle und beobachte, was passiert. Und dann diese Erfahrung nutze, um zu lernen und meine Intuition zu stärken.

Veröffentlicht am

Kommunikationsbrücken

Alexander Groß hat in seinem heutigen Vortrag auf der .NET Usergroup Rhein-Neckar Behaviour Driven Design (BDD) vorgestellt. Dieser als „Test Driven Development done right“ propagierte Ansatz beschäftigt sich mit Anforderungsspezifikationen, die eine Maschine automatisiert validieren kann.

BDD funktioniert, indem menschenleserlich formulierte Anforderungen so niedergeschrieben werden, dass diese von einem so genannten Testrunner ausgeführt werden können. So ergibt sich eine Kommunikationsbrücke zwischen Fachanwender und Entwickler. Man spricht eine gemeinsame Sprache.

Hierzu definiert man bestimmte Phrasen, welche dann nach und nach eine Domänensprache bilden, die zum Testen genutzt werden kann.

Der besondere Charm liegt darin, dass so auch technisch versierten Fachanwendern die Möglichkeit gegeben wird, Spezifikationen zu erstellen, die von Entwicklern ausgeführt werden können. Dabei können je nach Ausprägung des BDD Frameworks auch schon Sprachelemente verwendet werden, die noch kein Entwickler programmiert hat – „Spezifikation zuerst“ sozusagen.

Damit ist an einer definierten Stelle das Verhalten des Systems aus der Businesssicht beschrieben – was für eine tolle Dokumentation für neue Entwickler und die Einarbeitung bei Wartungsfällen. Außerdem hängen dann die Testfälle direkt mit den Anforderungen zusammen.

Darüber hinaus lassen sich diese Spezifikationen jede Nacht automatisch ausführen, wenn man einen Buildserver betreibt. So ist also sichergestellt, dass ungewollte Veränderungen am System früh auffallen. So früh, das Entwickler noch den Kontext ihrer Veränderungen kennen und diese korrigieren können oder mit dem Analysten über das neue gewünschte Verhalten sprechen können.

Wenn Sie also Fachanwender und Entwickler enger miteinander kommunizieren lassen möchten, kann diese Kommunikationsbrücke eine gute Idee für Sie sein.

Veröffentlicht am

Reflektion des Study Group Kickoffs

Vor dem 1. Treffen der Study Group habe ich die Dramaturgie der Kickoff Besprechung erarbeitet. Die Besprechung war für eine Stunde angesetzt, sie hat eine Stunde und 10 Minuten letzendlich gedauert. Es haben 8 Mitarbeiter teilgenommen, einige Teilnehmer waren verhindert.

Inhalt Dauer Ziel Methode
Willkommen 2 min Ankommen –
Checkin: Was erwartest Du von dieser Study Group? (1 Satz) 8 min Erwartungen klären Speech Token
Mögliche Themen identifizieren 10 min Themenüberblick VSA
Zusammenführen am Whiteboard 10 min Gefundene Elemente zusammenführen Klumpenbildung
Prioritäten klären 5 min Top 10 zusammenstellen Mehrpunktabfrage Option/2 und max. 2 Punkte je Option
In Liste übertragen 5 min Reihenfolge festhalten Sortierte Liste
Thema wählen 3 min Thema aus der Liste akzeptieren Thumbvoting
Arbeitsmittel und Quellen für Thema 1 12 min Arbeitsmittel und Quellen identifizieren OSA
Rahmenbedingungen 3 min Einigung auf Ort, Intervall und Länge Vorschläge mit Thumbvoting
Checkout 2 min Unterlagen auf Sharepoint kommunizieren –

Der Checkin war thematisch etwas unklar, hier musste ich nachsteuern, um den Fokus auf das Ergebnis auf einer höheren Ebene zu bringen, da es noch nicht um konkrete Inhalte geht. Beim nächsten Mal werde ich etwas weiter ausführen, was ich von der Gruppe möchte und ein Beispiel anbringen.

Ich habe zum ersten mal die Adhäsionsfolien als Whiteboardersatz verwendet, da kein Whiteboard mehr frei war. Die Drag & Drop Funktion ist zum Clustering wirklich praktisch, einzig der Preis der Karten schreckt mich noch ein wenig ab. Außerdem ließ sich eine Folie nicht richtig gut säubern und kein Boardcleaner war in Reichweite. Ansonsten ein wirklich tolles Werkzeug für die Moderation.

Die grundlegende Agenda hat sehr gut funktioniert, jedoch stellte sich beim Brainstorming über den am höchsten priorisierten Punkt ein großer Gesprächsbedarf heraus und die Gruppe war sich nicht einig, ob das Thema einer Study Group gerecht wird und der richtige Teilnehmerkreis anwesend sei.

Hier merkte ich schnell in mir das Spannungsfeld zwischen „der Gruppe Raum zur Diskussion geben“ und einen Zeitplan als Moderator einhalten. Mit verschiedenen Angeboten an die Gruppe konnten wir uns dann einigen, das zweitwichtigste Thema als nächsten Punkt anzugehen, damit wir für das wichtigste Thema etwas mehr Vorlaufzeit haben.

Die nächsten Treffen werden sich also um testgetriebene Entwicklung (TDD) drehen, wobei die Herausforderung sein wird, auch gewinnbringende Informationen für den Office-Entwicklungsbereich zu finden.

Als Verbesserungspotential für meine Moderation habe ich die nachstehenden Punkte heute mitgenommen:

  • Wissen Vertiefen in der Gruppendynamiksteuerung
  • Weitere Methoden zur Konsenzfindung in Gruppen
  • Gruppenergebnisse besser konservieren
  • Checkout bewußter durchführen

Ich werde die Besprechung und deren Ergebnisse, die ich zwischenzeitlich fotografiert habe, im Nachgang noch aufbereiten und der Gruppe zur Verfügung stellen.

Veröffentlicht am

Study Group: Gemeinsam lernen

Mein Kunde Softwarekontor hat mich beauftragt, eine Study Group zu initiieren. Bei diesem Format geht es um gemeinsame Weiterbildung und Austausch zu definierten Themen.

Das ganze funktioniert so:

  • Auswahl eines Lernbereichs
  • Auswahl von passenden Quellen (Webseiten, Bücher, Demos, Quellcode, Webcasts)
  • Definition, wie das Wissen erschlossen werden soll (Lesen in Vorbereitung oder vor Ort, Buchtausch alle 15 Minuten, Durchstöbern…)
  • Ermittlung des passenden Intervalls und der Länge eines Treffens
  • Erstellen einer Roadmap für alle Treffen zu dem Thema (optional)
  • Einigung auf eine Agenda für das nächste Treffen

Einen weiteren Tipp gab mir Deborah hierzu: Hat man mehrere Bücher zu einem Thema bietet sich an, diese erstmal gemeinsam zu sichten:

  • Jeder nimmt sich ein Buch für 15 Minuten, liest darin, was er möchte. Das kann ein Kapitelanfang sein, das Inhaltsverzeichnis, Skimmen einiger Seiten
  • Danach stellt jeder das gelesene den anderen aus seiner Sicht dar
  • Danach tauscht man die Bücher untereinander nochmal aus und wiederholt die obigen Schritte

Als Ergebnis hat jeder einen Überblick über das Lernmaterial, kann es grob beurteilen und per Konsenz kann entschieden werden, welches Material verwendet wird.

Entschließt sich das Unternehmen kostenfrei Getränke und ein paar Snacks oder direkt einige Pizzen zu ordern, wird aus einer Study Group schnell eine tolle Plattform des innerbetrieblichen Austauschs und der Teamentwicklung.