Fragen von E. Göhring an Judith Andresen, Autorin von “Retrospektiven in agilen Projekten” und “Agiler Baukasten – Methodenbausteine für IT-Projekte"
EG: Warum scheitern immer noch 70% der IT-Projekte an Kommunikation?
JA: Es ist leichter, über eine technische Umsetzung nachzudenken und darüber zu sprechen, als darüber, wie man miteinander umgehen will. Darüber hinaus wirken Gewohnheiten, und diese behindern die aktive Projektgestaltung.
EG: Wo würdest Du ansetzten, wenn Du allmächtig wärst?
JA: Ich würde Menschen den Mut geben, sich zu artikulieren und die Sicherheit, dass ihnen dann nichts Böses passiert. Viele haben Angst um ihren Status, manche sogar um ihren Arbeitsplatz, so dass sie lieber schweigen als Dinge auszusprechen, die ihnen – und meistens auch den anderen – das Leben leichter machen würden.
EG: Während der Vorträge auf der Developer-Conference 2013 in Hamburg stellte ich fest, dass die Sprache der Entwickler seit letztem Jahr noch spezifischer geworden ist. Es gab Vorträge mit einigen deutschen Füllwörtern – der Rest waren zumeist englische Fachbegriffe: developen, deployen, releasen, checken, testing…
Ich beobachte mit anderen Worten eine ausgeprägte Subkultur-Abkapselung. Siehst Du das auch so?
JA: Ja und Nein. Die Alltagssprache der meisten Entwicklerinnen und Entwickler ist Englisch. Viele Teams sind interkulturell aufgestellt und die Regel ist: Sobald einer im Team kein Deutsch kann, spricht man Englisch. Viele Fachbücher, Dokumentationen und Foren werden in Englisch veröffentlicht. Darauf hat man sich geeinigt. Die Entwickler und Entwicklerinnen kapseln sich also nicht bewusst durch den Gebrauch von Englisch ab.
Gleichzeitig mag es sein, dass eine englische Sprachinsel – und damit eine Subkultur – entsteht. Die Frage ist dann: Wie kommunizieren wir mit den Anderen?
Ich bin mir nicht sicher, ob Entwicklerteams sich immer ihrer fachspezifischen Ausdrucksweise bewusst sind. Zwischen unterschiedlichen Fachteams können sprachliche Barrieren entstehen. Hinter den Fachbegriffen steckt ja häufig eine ganze Sichtweise, die sich nicht jedem sofort erschließt. Das ist die eigentliche Barriere.
Ein Designer oder eine Designerin fühlt sich nicht gut in die Teamarbeit integriert, wenn er oder sie nicht versteht, was denn nun am Deployen so problematisch sein soll. Umgekehrt ist vielleicht für einen Entwickler oder eine Entwicklerin derr Zusammenhang zwischen der emotionalen Aufladung der Marke und einem Feature unklar.
Hier hilft nur eine gemeinsame Sprache. Das funktioniert am einfachsten in interdisziplinären Teams. Falls man das nicht bewerkstelligen kann, müssen alle Schnittstellen unter Beachtung der Barrieren sorgsam gestaltet werden.
EG: Teams werden wie bei Soundcloud, Wooga oder Antevorte kleine interdisziplinäre Einheiten mit vollständigen Verantwortlichkeiten organisiert. Auch hier beobachte ich eine starke Abkapselungstendenz. Wie bewertest Du das?
JA: Nein, das sehe ich nicht als Abkapselung! Menschen können nur in Gruppengrößen zwischen fünf und fünfzehn Personen effizient arbeiten. Nur kleine Einheiten schaffen es, Entscheidungswege und Informationen über alle transparent zu verteilen. Kleine Teams liefern besser. Es ist dann von entscheidender Bedeutung, wie sich die Teams untereinander koordinieren.
Ich halte sehr viel von interdisziplinären und auch von geschlechtlich gemischten Teams. Charakterliche Polaritäten müssen einander ausgleichen können.
Aber Achtung: ich halte gar nichts davon, die Teams nach Persönlichkeitstests wie z. B. Myer-Briggs, zu konstruieren. Das ist nicht agil. Besser ist es, die Teams finden sich freiwillig und können die Zusammenarbeit ausprobieren.
EG: Ich habe mal als Webmasterin bei einem Provider gearbeitet. Meine Kollegen freuten sich über die „erste Frau“, die nun bei Ihnen arbeitete. Die Frauen am Empfang und in der Buchhaltung waren also entweder unsichtbar oder keine Frauen oder arbeiteten nicht. Deine Meinung?
JA: Die waren unsichtbar! Viele Projektbeteiligte halten ihren Anteil am Projekterfolg für ganz wichtig – und sehen die anderen Beteiligten einfach nicht. Aber so ein Verhalten entspricht nicht dem Gedanken der Agilität, der alle Individuen über Prozesse stellt. Zu den Leuten, die an einem Projekt beteiligt sind, gehören die, die am Empfang oder in der Buchhaltung arbeiten, auch.
Aber das erklärt das Phänomen noch nicht vollständig. Gerade Technik ist immer noch eine starke Männerdomäne. Das führt dazu, dass der Anteil der Frauen am Projekterfolg schlichterdings übersehen wird.
Das ist aber total sinnlos. Mit Frauen im Team verbessert sich die Kommunikation – und auch die Marge! Insofern: holt die Frauen an Bord!
Wenn wir alle in einem Unternehmen die Arbeit aller anderen Beteiligten sehen und wertschätzen, wird uns der Erfolg sicher sein.
EG: Jeder aus der Entwicklerszene weiß, was eine Retrospektive ist. Es gibt gute Literatur dazu, unter anderem Dein Buch. Warum sollen auch Leute aus anderen Bereichen Dein Buch lesen – und was bringt es ihnen?
JA: Jeder in der Entwicklerszene hat eine Idee davon, was eine Retrospektive ist. Aber die wenigsten wissen, was eine gute ist. Entwickler und Entwicklerinnen müssen ein Gefühl dafür bekommen, falls sie es noch nicht haben, was auf allen Ebenen passiert. Auch auf der Gefühlsebene.
So können Gewohnheiten identifiziert werden, die in Wirklichkeit kaputte Prozesse sind, weil diese gar keinen Sinn mehr machen oder sogar kontraproduktiv wirken.
Retros sind eine Technik, um Stärken zu stärken, Schwächen zu identifizieren und Veränderungen für Menschen und Ergebnisse in Gang zu bringen.
Deshalb sollte man also mein Buch lesen: um Lernen – auch emotionales Lernen — in Unternehmen zu fördern.
Judith Andresen hat als Projektcoach ein untrügliches Gespür dafür, was ein IT-Projekt blockiert. Mit Blick auf die jeweilige Situation zeigt sie Wege zu gemeinsamen Zielen, adäquaten Methoden und sinnvoller Kommunikation. Darüber berichtet sie regelmäßig in ihrem Blog (www.judithandresen.com/blog). Sie hält regelmäßig Vorträge über Fehler- und Unternehmenskulturen sowie Projektmethoden.
