Kontiniuerliche Wertschöpfung

Ein Grundgedanke in agilen Prozessen wie Scrum ist es, in Intervallen potentiell auslieferbare Produkt- oder Projektstände zu erzeugen. Jetzt kann man sich fragen, warum dies ein Vorteil zu anderen Produktionsphilosophien ist?

An jedem Intervallende habe ich die Möglichkeit, mein Produkt meinem Kunden oder Anwender zur Verfügung zu stellen. Damit ist die Zeitspanne, bis ich mit neuen Funktionen am Markt oder beim Kunden bin sehr kurz. Diese Taktung können oft nur wenige Mitbewerber erreichen. Sobald die Anwendung so ausgeliefert ein Mindestmaß an Nutzwert für die Zielgruppe darstellt, kann abgerechnet oder anderweitig monetarisiert werden.

Was bei Großprojekten oft Monate und Jahre dauert, beginnt hier von Anfang an. Darüber hinaus habe ich frühes Feedback meiner Anwender, welches maßgeblich in meine Produktgestaltung einfließen kann und so eine gute langfristig erfolgreiche Positionierung am Markt sichern kann.

Spinnt man den Gedanken der häufigen Auslierferung weiter, kommt man schnell zu der Erkenntnis, dass solche Lieferintervalle bestimmte technische Voraussetzungen haben: Kontinuierliche Integration, automatische Tests und schnell durchführbare Deploymentprozesse. Hat man diesen Reifegrad erreicht, entsteht quasi mit jedem Feature, dass ein Team in einer Iteration abschließt, Wertschöpfung für das Unternehmen. Welche Projekte können das schon behaupten?

In der Realität ist dies für viele Unternehmen ein Weg, der Mut, Ausdauer und Kraft kostet. Und vielleicht liegt gerade hier das Potential, sich vom Mitbewerber abzuheben oder auch als interner Dienstleister überzeugen zu können. Noch sind es wenige Firmen, die so weit gegangen sind und ich bin mir sicher: es werden jedes Jahr mehr werden.

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

Selbstorganisation passiert (nicht) von alleine

Wer mit agilen Teams oder Methoden in Kontakt kommt, hört manchmal die Aussage, dass Manager nicht mehr benötigt werden, da sich die Teams selbst organisieren sollen. Das ist ein völlig falsches Verständnis von Selbstorganisation.

Der ScrumMaster hat im Scrum Prozess eine laterale Führungsrolle. Das bedeutet, dass er keine disziplinarische Macht hat, jedoch ganz klar eine Führungsaufgabe hat, was auch durch den Begriff des „Servant Leaders“ deutlich wird.

Wieso braucht man diese Rolle? Sind ein Team von Experten nicht von alleine in der Lage durch Selbstorganisation möglichst efffizient Software zu produzieren? Der Haken an selbstorganisierten Systemen ist, dass ohne vorgegebene Rahmenbedingungen absolut beliebige Systemzustände entstehen. Das bedeutet nicht zwangsläufig Chaos, aber auch nicht, dass ein System alleine zu positiver Entwicklung neigt.

Ein System könnte zum Beispiel zu einer lokalen Optimierung neigen. Sagen wir mal, ein Team ist damit beauftragt, intensive Lasttests auf eine im Internet platzierte Serverfarm durchzuführen. Dieses Team wird sich bemühen, die Arbeitsumstände so optimal wie möglich für ihr Vorhaben zu gestalten und im schlechtesten Fall die Netzwerkbandbreite der gesamten Firma konsumieren.

Und auch Manager setzen Rahmenbedingungen für Teams: Sie müssen Menschen zum Beispiel vor Mobbing schützen, gemeinsame Ressourcen wie Platz im Büro, Netzwerkbandbreite, usw. vor zu hoher Inanpruchnahme durch einzelne Teams und Individuen.

Ein „Rahmengeber“ ist also ein elementarer und wichtiger Bestandteil eines selbstorganisierten Teams. Innerhalb dieser Grenzen kann eine positive und sinnvolle Entwicklung eines Teams stattfinden. Hier ist neben dem ScrumMaster auch das Linienmanagement gefragt, diesen Rahmen zu definieren.

Story Points verständlich erklärt

Bei meiner Recherche im Internet und der gängigen Literatur habe ich gute Beispiele zur Vermittlung des Konzepts von Story Points gesucht.

Bis auf Mike Cohns Erläuterung in seinem Buch „Agile Estimation & Planning“ habe ich wenig leicht verständliches gefunden. Auf die Gefahr hin, dass ich vielleicht einfach eine gute Quelle verpasst habe und das Rad nun neu erfinde, möchte ich meinen Beitrag zu dem Thema zu leisten, um Story Points nochmal auf den Punkt zu bringen:

Storypoints sind eine Einheit, die die Größe einer User Story beschreiben.

Wie ist nun diese Größe definiert? Diese Frage ist nicht pauschal zu beantworten. Es fließen viele Faktoren ein, die von den Individuen abhängen, die diese „Größe“ definieren.

Ein Team könnte eine Größe zum Beispiel so definieren:

* Die Größe einer Story ergibt sich aus ihrer Komplexität. Die Komplexität hängt davon ab, ob und wieoft welche Schichten unseres Architekturmodells durchstoßen werden…

Ein anderes Team vielleicht so:

* Wie komplex sind die Interaktionen zur Umsetzung? Um diese Story umzusetzen müssen wir mehrere Abstimmungs- und Anpassungsrunden zwischen Designer, Interaction Designer und Frontend-Entwickler durchführen…

Wie auch immer ein Team diese Größe definiert, eines ist wichtig dabei: Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der „Struktur“ der User Story. Oder gleich um ein ganzes Bündel von diesen Eigenschaften.

Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.

Ein erfahrenes Team schafft einfach mehr bzw. größere Stories in der selben Zeit als ein unerfahrenes Team, das beeinflusst die Größe nicht.

Was bedeutet das nun für Schätzungen:

Die Diskussionen darüber, wer eine Story umsetzt, sind nichtig. Ob erfahrener oder unerfahrener Entwickler: Es spielt keine Rolle für die Schätzung einer Story. Das unterstützt cross-funktionale Teams in ihrer Arbeit und macht Schätzungen leichter und schneller. Es müssen nur die Eigenschaften identifiziert werden und ein Vergleich mit schon bearbeiteten oder ähnlichen Stories angestrebt werden, dann hat man die Größe.

Wie kann man nun mit Story Points einen Releaseplan erstellen?

Der Zeitfaktor kommt in Scrum dann durch die Teamgeschwindigkeit in das System. Diese so genannte Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration, also:

V = ø (SUM(Story Points der erfolgreich abgeschlossenen Stories im Sprint))

Wenn ich jetzt für alle Product Backlog Items Story Point Werte schätze, sie in der Reihenfolge durch eine Form von Priorisierung sortiere und weiß, wieviele Storypoints mein Team je Iteration umsetzt (Velocity), kann ich die Aussage treffen, in welcher Iteration ich ein Feature liefern kann.

Während der Arbeit entstehen also gemessene Zeitwerte, die ich dann auf die Größe appliziere. Zeiten schätzen wird daher mit Story Points niemand mehr. Das ist eine gute Konsequenz, wenn man überlegt, wie schwer es ist, so etwas komplexes wie die Entwicklung von Softwarebausteinen durch Zerlegung zeitlich abzuschätzen. Es gibt ziemlich dicke Bücher über nur dieses Thema und eher weniger als mehr Projekte, die gute Schätzungen vorweisen können.

Kleinteilige Diskussionen vermeiden

Ein anderer Aspekt ist der, dass durch die Betrachtung der Charakteristika einer Story vermieden wird, zu tief in die für die Umsetzung notwendigen kleinteiligen Elemente hineinzugehen. Die Merkmale einer Story können auch ohne eine detaillierte Tätigkeitenanalyse identifiziert werden. Das ist bei Aufwandsschätzungen in Tagen häufig anders. Hier werden alle notwendigen Tätigkeiten identifiziert und deren Aufwände aufsummiert.

Einfacher in der Praxis

In der Praxis ist das Thema „Story Points“ interessanterweise einfacher, als es tatsächlich zu erklären ist.

Nimmt man eine Referenzstory und einigt sich darauf, dass diese eine mittlere Größe hat, gibt das Team der Story zum Beispiel die Größe „5“. Andere Stories werden dann mit dieser verglichen und als gleich groß, kleiner oder größer eingestuft. Die Agilisten nehmen dann gerne die nach Mike Cohn angepasste Fibonacci-Reihe und verteilen die Elemente darauf: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Die seltsame Skala dient unter anderem dazu, auszudrücken, dass um so komplexer die Story ist (also umso größer), die Genauigkeit der Schätzung in die Binsen geht.

De facto sollte man mit sehr großen Stories vorsichtig in der Releaseplanung sein, denn es herrscht hier eine hohe Unsicherheit in Bezug auf das korrekte Verständnis des Teams für dieses Story – aber das ist ein anderes Thema.

Update vom 14.09.2018: Mit meinen Kollegen von DasScrumTeam habe ich ein kostenfreies Online-Video-Coaching produziert, das User Stories sehr anschaulich vermittelt.

Technische User Stories gehören nicht ins Product Backlog

Die agile Gemeinde hat dieses Thema schon öfter diskutiert – mit sehr unterschiedlichen Ansichten. Daher möchte ich diesen Beitrag nutzen, um meine Meinung darzustellen und sie zu begründen. Meine Erfahrung aus der Rolle des Entwicklers fließen in mein Verständnis ebenso ein, wie die wirtschaftliche Betrachtung der Softwareentwicklung.

Das Product Backlog ist ein Ort, an dem der Product Owner eine Bestellung an sein Team aufgeben kann. Häufig finden hier User Stories Verwendung.

Nach Mike Cohn haben User Stories die 3 C’s als Kriterien:

  • Card: Eine Story sollte auf eine Karteikarte passen.
  • Conversation: Eine Story ist keine vollständige Anforderung oder dergleichen. Es ist ein Versprechen über eine Konversation, die während der Planungssitzung und beim Estimation Meeting noch geführt werden soll.
  • Confirmation: Die Definition, wann eine Story erfüllt ist, sollte auf der Rückseite stehen in Form eines User-Acceptance-Tests, damit das Team weiß, welcher Maßstab im Review Meeting angelegt wird.

Würde ein Product Owner bei seinem Team bestellen, dass eine Komponente von Version 1.2 auf Version 1.3 aktualisiert werden soll? Möchte er diese Konversation mit seinem Team führen? Die Frage ist, ob dadurch ein Mehrwert für ihn aus Geschäftssicht entsteht: Braucht er ein Feature der Komponente, dass nur im neuen Release enthalten ist? Sind Fehler behoben, die den Anwender betreffen?

Jetzt wird der erfahrene Entwickler vermutlich auf die technische Schuld hinweisen. Vollkommen zurecht: Wer in größeren Projekten arbeitet, der kennt die Themen der Komponentenaktualisierung, umfangreicher Refactorings und Austausch ganzer Bausteine.

An dieser Stelle gibt es zwei Optionen:

a) Der Product Owner bestellt ein Feature, dass die Aktualisierung bzw. Bearbeitung der technischen Schuld tatsächlich auch beinhaltet. In diesem Fall werden entsprechende Tasks zu der User Story erstellt und wie gewöhnlich bearbeitet.

b) Der Product Owner interessiert sich eigentlich nicht für die notwendigen Tätigkeiten aber jeder gute Entwickler weiß, dass diese Veränderungen gebraucht werden, um das Fortbestehen und die Wartbarkeit der Anwendung zu sichern.

Das Team sollte im Sprint Planning dann entscheiden, wieviel Aufwand es erwartet in Bezug auf die technischen Veränderungen und dementsprechend das Commitment anpassen, dass es dem Product Owner gibt. In den Velocity / Burndown Graphen ist eine Anmerkung des Product Owners sinnvoll, warum eine vermutlich eingeschränkte Velocity nach der Iteration erreicht wird.

Dies ist eine kritische Stelle der Interaktion zwischen dem Team und dem Product Owner, denn dieser muß dem Team vertrauen, dass das Team wirklich nur die notwendigen Arbeiten in einem Rahmen durchführt, der es nachwievor ermöglicht, echten Geschäftswert zu schaffen. Nutzt das Team diese Entscheidungsgewalt als „technischen Freibrief“ aus, sollte der ScrumMaster diesen Konflikt thematisieren und lösen.

Nur ein verantwortlicher Umgang mit Ressourcen und ein Zusammenspiel aus Technik und Business sichern langfristig den Erfolg.

Machtkämpfe zwischen Produktverantwortlichen und Entwicklern oder Architekten haben hier keinen Platz.

Die Abarbeitung der technischen Tasks wird wie gewohnt im Sprint Burndown dargestellt. Hier herrscht also Transparenz für den Product Owner. Die kritische Frage, warum gewisse Tätigkeiten umbedingt erfolgen müssen, darf gestellt werden und sollte vom Team beantwortet werden ohne dabei eine Rechenschaft abzulegen. Das Team entscheidet selber, wie es produziert.

Hier kann es hilfreich sein, wenn der ScrumMaster beiden Seiten hilft, die Belange des jeweils anderen zu verstehen, für Transparenz zu sorgen und einen tragfähigen Kompromiss zu entwickeln. Ein farbliches Hervorheben von Tasks der „technical debt“ könnte eine Option sein, das Verhältnis für alle Transparent zu halten. Kippt das Verhältnis in die falsche Richtung, sollte es thematisiert werden.

Technische Stories gehören also nicht ins Product Backlog. Technische Tasks gehören hingegen zur Arbeit des Teams. Die Balance zu halten, liegt in der Verantwortung aller Beteiligter.

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?

Wie Scrum die Softwarequalität erhöht und warum der ScrumMaster selten Quellcode liest

Wenn man Scrum erklärt, biegt bei vielen Beschreibungen irgendwann das magische Projektmanagementviereck um die Ecke. Während bei Projekten generell die vier Eckpfeiler Kosten, Funktionsumfang, Zeit und Qualität zur Disposition stehen, sagt Scrum von sich selbst, das Qualität keine verhandelbare Option ist. Unter Projektdruck ist es nicht ungewöhnlich, dass Refactorings unter den Tisch fallen, Dokumentationen weggelassen und Umbauten vermieden werden. Hier sagt diese agile Methode, dass dies nicht passieren darf, um auch langfristig Wert zu schaffen.

Wer korrekt nach Scrum produziert, baut also keine schlechte Software mehr? So einfach ist es natürlich nicht. Hier lohnt es sich, einmal genauer hinzusehen: Wie kann ein solches Framework technische Qualität sicherstellen? Ist ein ScrumMaster ein getarnter Tester, der heimlich beim Abnahmemeeting für den fachlich Verantwortlichen in den Quelltext schaut, ein Code Review macht und mit einem dezenten Lächeln oder mürrigem Dreinblicken dem Product Owner heimlich mitteilt, wie das Team gearbeitet hat?

Guckt man in die Literatur, so hat der ScrumMaster erstmal die Verantwortung für die Prozessqualität. Von technischen Fähigkeiten oder gar Quellcodelesen steht da nichts. Wie kann also durch eine hohe Prozessqualität eine hohe Softwarequalität erreicht werden? Klare Sache: Die Antwort muss in den Prozessbestandteilen zu finden sein.

Bestandteil 1: Potentiell auslieferbare Produkt- / Projektinkremente
Nach dem Ende einer Iteration (also in der Regel nach zwei oder vier Wochen) hat ein Scrum Team eine potenziell auslieferbare Software produziert. Was bedeutet das? Der Anspruch ist hier: Auf CD brennbar, ausrollbar, verkaufbar… Alles, was die Software betrifft, muss erledigt sein. Der ScrumMaster bestärkt den Product Owner darin, Unfertiges abzulehnen und zur Nacharbeit zu geben.

Die „offensichtliche Ware“ ist also sauber. Wie sieht es nun mit dem Innenleben aus?
Hier hängt es maßgeblich vom Team und seiner Erfahrung ab, inwieweit Refactorings durchgeführt wurden, Quellcode bereinigt ist, Module getestet sind. Um so weniger technisches Qualitätsbewußtsein im Team vorherrscht, umso weniger Qualität wird ein Team liefern.

Ist es Aufgabe vom ScrumMaster, sein Team zu mehr technischer Qualität zu bewegen? Jein.  „Technische Schulden“, versäumte Refactorings, schlechte Architekturen  – sie werden durch Scrum sichtbar. Die Geschwindigkeit des Teams wird zum Beispiel geringer, einfache Features liefern riesige Schätzwerte, der Burndowngraph stagniert, am Iterationsende wird nicht geliefert.

Die Aufgabe des ScrumMasters ist es dann, dem Team zum Erkenntnisgewinn zu verhelfen und es darin zu unterstützen, besser zu werden. Findet das Team dann eine gute technische Lösung und die richtigen Maßnahmen? Wir vertrauen ihm und bitten es um Ideen, verfolgen die Umsetzung.

Bestandteil 2: Regelmäßige Auslieferung
Wer verteilte Systeme, interagierende Komponenten, unterschiedliche Bestandteile konstruiert, muss diese irgendwann integrieren und testen.  Hier können viele Probleme im Detail liegen. Um so häufiger hier eine Integration durchgeführt wird, um so sicherer kann das Team sein: Das läuft in der Praxis.

Bestandteil 3: Kanalisierte Kommunikation
Scrum definiert Kommunikationswege und Besprechungen, bringt Ideen für Artefakte mit, die helfen sollen, Anforderungen zu transportieren. Wenn Entwickler keinen Zugang zu weiteren Informationen einer Problemstellung haben, bleibt ihnen häufig nichts anderes übrig, als Annahmen zu treffen.

Scrum minimiert die Anzahl getroffener Annahmen auf ein Minimum, indem es die Kommunikation zwischen Product Owner und Team forciert. Geht man davon aus, dass intensivere Kommunikation eher zu dem gewünschten Produkt führt als ratende Entwickler, erhöht Scrum auch hier die Qualität.

Unbestandteil:  Automatisiertes Testen, kontinuierliche Integration
Scrum schreibt keine technischen Praktiken vor. Das viele der agilen Praktiken aus Extreme Programming eine sinnvolle Ergänzung sind, ist mittlerweile klar. Aber wer bringt nun dem Team TDD, kontinuierliche Integration, Collective Code Ownership und Buildmanagement bei?

Der ScrumMaster ist hiermit zu Recht in der Regel überfordert. Kann er das wissen vermitteln: Prima. Ansonsten kann zum Beispiel auch ein externer Coach mit einem starken Entwicklungshintergrund dazugezogen werden.

Fazit: Scrum sichert Softwarequalität durch seine Prozesselemente. Wie es dem Innenleben einer Software geht, wird nicht durchleuchtet. Die entstehenden Graphen zum Projektfortschritt spiegeln jedoch diese Qualität wieder. Der Rest ist Vertrauen in die Mannschaft. Wünscht das Team bei gewählten Maßnahmen Unterstützung, gibt es viele Lernarten, wie zum Beispiel die Study Group oder ein externer Coach.

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: