Der Agile Day auf der W-JAX 2014

Agiler durch erfolgreiche Kommunikation

Mirko Schrempp
© shutterstock.com/Rawpixel

Der Agile Day auf der W-JAX zeigt sich über die Jahre als guter Indikator für die Verbreitung und den Einsatz agiler Methoden in der IT. Vor einigen Jahren waren die wenigen Sprecher noch bemüht, einer kleinen Zahl von Zuhörern die Grundzüge agiler Ideen am Beispiel kleiner Projekte zu vermitteln und damit überhaupt erst für die Verbreitung zu sorgen. Der Agile Day zum Auftakt der W-JAX 2014 in München bot ein ganz anderes Bild: Vor über hundert Teilnehmern präsentierten die Sprecher in ihren Sessions Erfahrungswerte und Praxistipps aus großen, in Enterprise-Unternehmen durchgeführten, Projekten. 

Kommunikation steht im Vordergrund

Auch wenn agile Methoden wie Scrum oder Pair Programming für die Entwickler inzwischen zum Alltag gehören, haben „traditionelle“ Manager noch immer Mühe mit diesen Vorstellungen. Johann-Peter Hartmann, CTO von Mayflower, präsentierte in seiner Session einige Positionen, die das Vorstellungsvermögen und die Planungswut des Managements vor Herausforderungen stellen. Wie zum Beispiel macht man jemandem klar, dass zwei Programmierer, die eine Aufgabe zugleich erledigen, effektiver sind als zwei, die zwei Aufgaben parallel machen? Warum sind Planungen, die nicht das gesamte Zeitkontingent im Detail bis auf die letzte Minute ausschöpfen, sinnvoller? Oder warum kann es sinnvoll sein, überhaupt nicht zu planen? Klare Antwort: Jedes Management der Welt überzeugt man nur durch eins – Resultate.

Durch Fehler Komplexität beherrschen 

Das schließt natürlich aus, dass man im Voraus alles festlegt. Denn dann gerät man in die Falle, dass auf dem Weg Probleme entstehen, die nicht vorhergesehen werden konnten und dann natürlich den schönen Plan durcheinander bringen. Die Kunst besteht nun darin zu wissen, was man will und zu wissen, dass man nicht alles planen kann. Der Rest ist dann Handeln. Wenn man erkennt, dass die Aufgabe, die es zu lösen gilt, komplex ist, sodass man ohnehin nicht alle Aspekte erfassen kann, dann ist der beste Weg, zu Ergebnissen zu kommen, anzuerkennen, dass man zum einen nichts weiß und weil man nichts weiß, auch nicht wissen kann was als nächsten zu tun ist. Durch Ausprobieren findet man heraus, was der richtige Weg ist. Dazu gehört auch, dass man Fehler in Kauf nimmt und daraus lernt, um besser zu werden. Denn in komplexen adaptiven Systemen lasse sich eben erst im Nachhinein sagen, was richtig war. Genau dafür sei Scrum entwickelt worden, so Hartmann. Am besten funktioniere das in sich selbst organisierenden Teams, die über emergente Praktiken verfügen – und das Wissen, dass man mit unterschiedlichen Graden von Unwissenheit bzw. Orders of Ignorance mutig an die Aufgabe herangehen sollte. Im Idealfall weit unter dem Radar des Managements, dann steigt die Chance des Erfolgs.

In die gleiche Kerbe schlug auch Gerrit Beine, adesso AG, der die Qualität von so genannten High-Performance-Teams vor allem in der Unabhängigkeit und der Anpassung der Iterationen an die tatsächlich vorliegenden Bedingungen im Team sieht. Gerade solche Teams sind erfahrungsgemäß effektiver, wenn sie auf zeitverschwendendes Stundenschätzen verzichten und stattdessen die Tasks nach ihren Erfahrungen so klein schneiden, dass sie als Team den Sprint erfolgreich abschließen. Das umzusetzen funktioniere am besten, wenn man gegenüber dem Management nicht mit der Motivation des Teams argumentiere, sondern mit dem Business Value, denn das sei die Wohlfühlzone des Managements.

Der Business Value

Diesen Business Value zu vermitteln liegt in der Regel auf der Seite des agilen Teams, denn in den wenigsten Unternehmen sei dem Management klar, wie man das vor allem im Bereich der Entwicklung hinbekomme. Dazu gehört dann auch das Problem, dass der Kunde, sei es das Management, das ein Rewrite eines Altsystems will, oder ein Auftraggeber, sich keine wirklich innovative und Business Value steigernde Lösung vorzustellen vermag. Wie dieses Kommunikationsproblem zu lösen ist, stellte David Tanzer in seiner Session vor, die zeigte, dass im Regelfall der Kunde nicht weiß, dass er das, was er angeblich will, nicht das ist, was er wirklich will. Um wirklich zu dem zu kommen, was der Kunde braucht, muss man die User Stories mit ihm so allgemein und klar wie möglich klären und dann eben dem Team die technische Umsetzung überlassen.

Wenn es an die technische Umsetzung geht, steigt allerdings auch der Erwartungsdruck auf Seiten des Managements, denn dieses will das Ergebnis so schnell wie möglich haben, um damit auch Geld zu verdienen. Damit steigt in der Regel auch der Druck auf das ganze Projekt, und es zeigt sich oft, dass es niemandem schnell genug geht. Hier zeigt die Erfahrung von Carsten Sensler, Art of Arc, und Andre Karalus  aus einem großen Projekt bei der Deutschen Telekom, dass am besten ist, sich steakholderspezifische Kommunikation zu üben, dazu das Vokabular des Gegenübers zu lernen und Messsystem vorher zu klären, damit es hinterher kein Problem gibt. Denn man muss mit der Fachseite, dem Marketing und auch dem Entwicklerteam den Stand des Projekts immer in einer spezifischen Weise erklären, damit auch wirklich verstanden wird, wo man steht, wohin man will und dass man dort auch hin kommt. Dummerweise lernt man so etwas oft erst, wenn das Projekt schon läuft. Dann ist es allerdings angebracht schnell zu handeln, um das schlimme Ende zu verhindern.

Der Architekt gehört ins Team

Aber auch die Teams müssen sich organisieren können, wenn der Plan fehlt und der Erfolg das Ziel ist. Gerade in größeren Projekten entsteht schnell die Gefahr des Wildwuchses. Am besten verhindert man das nach Ansicht von Roland Mast, Sybit, dadurch, dass man den Architekten mit ins Team holt und alles daran setzt, dass Entwickler und Architekt gemeinsam eine Architektur-Vision entwickeln. Damit verhindert man zum einen, dass der Architekt und die Architektur als Fremdköper die Performance des Teams und den Fortschritt des Projekts gefährden, zum andern hat man eine Grundlage, die man wiederum zielgruppenspezifisch an alle Beteiligten vermitteln kann. Wenn das gelingt, könne man die breite, generalistische Expertise des Architekten mit den spezifischen Expertisen der einzelnen Teammitglieder sinnvoll kombinieren und erfahrungsgemäß die Qualität erreichen, die man haben will, weil eben alle die gleiche Vision teilen und verstehen.

Feedback und persönliche Retrospektive

Vor allem in Scrum-Teams ist es selbstverständlich, dass das Team durch Daily Scrums und Retrospektiven den Stand des eigenen Projekts kennt, bewerten und gegebenenfalls verbessern kann. Aber auch für die Einzelnen im Team ist es hilfreich und sinnvoll zu wissen, wo sie stehen und wie sie sich weiterentwickeln können. Anna Löw, Giant Swarm, und Johanes Thönes, ThoughtWorks, haben dazu zwei interessante Ideen vorgestellt.

Anna Löw suchte nach einer Lösung, wie man Mitarbeitern persönliches Feedback geben kann, um die eigene Leistung einschätzen zu können, Möglichkeiten zur Weiterbildung zu finden und mit die Position im Unternehmen zu verbessern. Weil das in den klassischen Personalgesprächen oft auf unvorbereitetes und diplomatisches Phrasendreschen, im besten Fall dann auch noch mit einer Eigenschaftsbewertung auf einer Skala von eins bis fünf hinausläuft und jeder eigentlich nur an die Gehaltserhöhung oder Beförderung denkt, wurde ein Experiment gestartet. Die Idee war, dass sich Kollegen in einem zuvor verabredeten Setting von gewünschten Informationen und Fragen wechselseitig Feedback gaben, das Ganze per Mail. Eine Frage, eine Antwort, jeder hat Zeit zu formulieren und zu lesen, alles in kleinen Häppchen und ohne großen Aufwand. Was sich zunächst sehr merkwürdig anhört, hat im Experiment funktioniert und den Einzelnen sinnvolles Feedback gebracht – und das Ganze wurde auch gleich als Webseite umgesetzt: http://lettingknow.com

Johannes Thönes hingegen hat die Retrospektive aus dem Teamprozess herausgelöst und zu einem Verfahren für den Einzelnen gemacht. Genau wie im Scrum erlaubt es einen Rückblick auf das, was man in einem bestimmten Zeitraum gemacht hat. Alles, was man dazu braucht, ist ein fester Zeitpunkt für das Treffen mit sich selbst, den Kalender, die Photos auf dem Smartphone o. ä., etwas Ruhe und den Mut, ehrlich mit sich selbst zu sein. Im Idealfall wird das zu einem Ritual, das einem dabei hilft, sich über die eigenen Handlungen klar zu werden, privat und beruflich, und sich zu überlegen, was man besser machen möchte und wie man das erreichen kann.

Agil ohne Kommunikation geht nicht, und ohne erfolgreiche Kommunikation zweimal nicht. Der Agile Day zeigte in der Summe, wie man mit sich selbst, den Kollegen, dem Team, allen Projektbeteiligten und sogar dem Management richtig kommunizieren kann, wenn man sich die Mühe macht und allem die Zeit lässt, sich einzuschwingen und das Ganze in einen Flow kommt, der wirklich erfolgreiche Teams spielend zum Ziel führt. 

Aufmacherbild: Global Communications von shutterstock.com / Urheberrecht: Rawpixel

Geschrieben von
Mirko Schrempp
Mirko Schrempp
Mirko Schrempp ist Redakteur für den Windows Developer, das Business Technology Magazin und das SharePoint Kompendium.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: