Windows Developer | Software-Entwickler reden zu wenig!

„Die Manager“ machen es „den Software-Entwicklern“ schwer – und umgekehrt. Der Zielkonflikt zwischen Management und der IT zeigt sich in spöttischen, manchmal auch passiv-aggressiv formulierten Feindbildern: „Was hat sich das Management da wieder ausgedacht?“ oder umgekehrt: „Die IT macht wieder ein Problem daraus, die liefern nicht schnell genug.“

Über Software-Entwickler heißt es oft, dass jene nicht über Soft Skills verfügen. Daraus wird die Forderung abgeleitet, dass Software-Entwickler sich durch das Erlernen von Soft Skills professionalisieren sollten. Würden Software-Entwickler über Soft Skills verfügen, würden Projekte nicht scheitern.

Stimmt diese Zuordnung des schwarzen (Kommunikations-) Peters?

Haben sich dabei Software-Entwickler und Manager nicht auf ein gemeinsames „großes“ Ziel (z.B. im Sinne der Unternehmensvision) geeinigt, wird jedwede Einschränkung bzw. Veränderung am System bzw. am Projekt von jeder Seite als qualitätsmindernd aufgefasst.

Während die eine Seite um die Qualität des Systems fürchtet, sieht die andere Projektqualitäten wie das Timing und die Anzahl der Features in Gefahr. Die Messung der Änderungen erfolgt nicht gegen ein gemeinsam vereinbartes Ziel, sondern alleinig gegen die in der jeweiligen Disziplin verankerten Qualitätsmerkmale.

Aus dem Systemkonflikt heraus entsteht ein persönlicher Konflikt zwischen dem Software-Entwickler und dem Manager: die Reputation der beteiligten Personen ist in Gefahr. Diese gilt es zu verteidigen.

Verstehen sich Software-Entwickler und Manager nicht als ein Team, das gemeinsam für ein bestimmtes Produkt (also ein Ziel mit definierten Qualitäten) arbeitet, wird die Reputation der Einzelakteure jeweils wichtiger als die Qualität des vermeintlichen Teamziels. Aus dieser Motivlage heraus werden mögliche Änderungswünsche mit einer Verteidigung der eigenen Herangehensweise beantwortet. Damit verlagert sich eine fachlich-technische Diskussion in das Spielfeld persönlicher Konflikte.

Der Schwerpunkt der IT-Ausbildung liegt im Erwerb von Methodik, Pattern sowie einzelner Software-Sprachen. Die Kommunikation über Projekte und Produkte wird nur selten gelehrt. Schwerpunkt der Manager-Ausbildung liegt in der Bewertung und Beantwortung unterschiedlicher Kennzahlen. Die meisten Schulungen und Ausbildungen für Projektmanager beziehen sich schwerpunktmäßig auf eine bestimmte Projektmethode, selten wird Kommunikation in den Mittelpunkt der Ausbildung gestellt.

Keine der beteiligten Disziplinen wurde in Kommunikation bzw. allgemeiner in Soft Skills speziell ausgebildet. Dennoch werden einseitig den Software-Entwicklern fehlende Soft Skills unterstellt. Sachbücher und Ratgeber ranken sich um die Thematik, in denen Soft Skills „passend für den Software-Entwickler“ aufbereitet und erläutert werden. Gleichzeitig wird das Bild mangelnder Soft Skills auch unter Software-Entwicklern gepflegt. So charakterisiert Robert C. Martin Software-Entwickler mit den Worten: „Most of us got into programming because we prefer to deeply focus on sterile minutia, juggle lots of concepts simultaneously, and in general prove to ourselves that we have brains the size of a planet, all while not having to interact with the messy complexities of other people“[3]

Sachbücher für Manager beschreiben umgekehrt die „schwierigen“ Software-Entwickler und bieten vermeintliche Hilfestellung im Umgang mit besonderen Persönlichkeiten. Würden Software-Entwickler kommunizieren können, würden Projekte nicht unter Druck geraten. Mit dieser impliziten Annahme in den genannten Sachbüchern wird der Mythos genährt, dass Projekte an den mangelnden Soft Skills der beteiligten Software-Entwickler kranken.

Fehlt Kommunikation im Allgemeinen oder sind Zielvorstellungen in Projekten unklar, scheitern diese.[4] Dabei wird in vielen Projekten ausführlich schriftlich kommuniziert. Zur Verständigung über Projekte und Produkte ist eine direkte und persönliche Kommunikation notwendig, die über den Austausch von Dokumenten in Form von Lasten- und Pflichtenheft hinausgeht.

In den zwölf Prinzipien des agilen Manifests heißt es dazu: „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“[5]

Die Autoren des agilen Manifests wertschätzen die Interaktion zwischen den Projektbeteiligten mehr als das Verfolgen starrer Prozesse. Damit ist das agile Manifest die Antwort auf einen Arbeitsalltag, in dem die schriftliche Kommunikation über Projekte häufiger anzutreffen ist als die direkte Kommunikation in diesen.

Die Bedeutung persönlicher Kommunikation wird von vielen Projektbeteiligten unterschätzt. Nur die aktive Auseinandersetzung über die Zusammenarbeit wird diese verbessern. In vielen Projekten heißt es: „Jetzt machen wir das heil. Und ganz am Schluss reden wir nochmals darüber, was schiefgelaufen ist.“ Diese Sitzungen finden nur selten statt. Die Zusammenarbeit verändert sich nicht.

Dechiffriert man agile bzw. Wasserfall-Methoden, so findet man neben schriftlichen Artefakten und Visualisierungen des Projektverlaufs vorwiegend Kommunikationsrituale. Für das Projekt wichtige Fragestellungen wie Teamzusammenarbeit, Arbeitsfortschritt, Risikoanalyse und Zielsetzung für das Gesamtprojekt bzw. für einzelne Iterationen werden in regelmäßig stattfindenden Sitzungen diskutiert und die Ergebnisse anschließend schriftlich fixiert.

In agilen Methoden heißen diese Sitzungen Retrospektiven, während in Wasserfall-Methoden von „lessons learned“ die Rede ist. Während die Retrospektive ein lebendiger Prozess ist, ist die Methodik „lessons learned“ in vielen Wasserfall-Projekten zu einem Berichtspunkt in einem schriftlichen Statusbericht mutiert.

Im Arbeitsalltag vieler Software-Entwickler wird erst zu Krisensitzungen eingeladen, wenn es „brenzlig“ wird. In der jeweiligen Situation wird versucht, möglichst schnell eine Änderung des Projektverlaufs zu erzeugen – ohne eine Basis für eine dauerhafte Optimierung der Zusammenarbeit zu legen. Dies ist wohl der Grund, warum der Mythos, Software-Entwickler könnten nicht gut kommunizieren, so beharrlich gepflegt wird. Dieser schiebt den „Schwarzen Peter“ der fehlenden Kommunikation und mangelnden Optimierung in Richtung IT.

Gleichzeitig nehmen viele Software-Entwickler hin, dass Sitzungen über Zielsetzungen und Verlauf des Projekts nicht regelmäßig stattfinden. Fehlen regelmäßige „Meta“-Sitzungen, sind diese einzufordern. Wer diese nicht einfordert, verhält sich ähnlich unprofessionell wie derjenige, der unter Berufung auf mangelnde Kommunikationsfähigkeiten der Software-Entwickler eine Kommunikation erst gar nicht probiert.

In vielen Lasten- und Pflichtenheften finden sich Erklärungen komplexer Sachverhalte mit vielen Details und in großer Tiefe. Die Ausführungen sind oftmals eine Mischung aus fachlichen Anforderungen und technischen Erläuterungen.

Diese Details geben den Autoren der Lasten- und Pflichtenhefte die vermeintliche Sicherheit, die Anforderungen präzise vermittelt zu haben. Doch in vielen Fällen bleiben Fragen und damit Interpretationsraum offen.

Für die Vermittlung der Anforderungen ist es sehr wichtig, die Zielsetzung der Anforderungen zu formulieren. So können Definitions- und Anforderungslücken im Projektlauf durch die Projektbeteiligten erkannt und „gestopft“ werden. Martin Fowler[6] fordert für UseCases als Erstes die Formulierung des Ziels:

1. Title: „goal the use case is trying to satisfy“

2. Main Success Scenario: numbered list of steps

3. Step: „a simple statement of the interaction between the actor and a system“ [...]

In der Praxis werden UseCases mit Überschriften versehen, welche das jeweilige Feature beschreiben, es aber nicht begründen. Der UseCase heißt zum Beispiel „Newsletteranmeldung“. Der UseCase führt nicht die Steigerung von Leads als Motor für den betreffenden Webshop auf. Eine hohe Steigerung von Leads ist durch eine einfache GUI sicherzustellen. Beschreibt der Autor die Newletteranmeldung in allen Details, wird womöglich ein perfekter Ablauf definiert. Im Resultat wird die Newsletteranmeldung aber kompliziert und für den Konsumenten unhandlich ausgestaltet. Das eigentliche Ziel wird so verfehlt.

Die Zielsetzung einzelner Features fachlich zu begründen, ist notwendig. Dabei ist die Zielsetzung des einzelnen UseCases auch immer in Zusammenhang mit dem Gesamtziel des Projekts zu stellen. Fehlt diese Klarheit, wird das Projektteam ineffizient werden. Entweder es verliert Zeit beim Stopfen der Definitionslücken, oder es erzeugt Implementierungsschleifen, weil zunächst die Anforderung inkorrekt umgesetzt wird.

Daher ist bei Unklarheiten in den schriftlichen Anforderungen zu prüfen, worin diese begründet liegen. Entsprechend ist eine Präzisierung der Formulierungen anzufordern. Um die Formulierung zu erleichtern, ist zu überlegen, ob die Zielsetzung gemeinsam formuliert werden kann oder ob zumindest Hilfestellung aus der IT für diese Arbeit erfolgen kann.

Da Projekte leicht an der Kommunikation scheitern – und selten am Können der beteiligten Software-Entwickler - , ist der Kommunikation in Projekten durch die Software-Entwickler ein größerer Stellenwert einzuräumen.

Der Schwenk in agile Methoden erleichtert dies, da die notwendigen Rituale und Sitzungen entsprechend begründet und beschrieben sind. Ist auf Grund der vorherrschenden Unternehmenskultur ein Wechsel in agile Methoden nicht ohne weiteres möglich, ist für die gelebte Wasserfall-Methode eine Präzisierung der Kommunikationsrituale herbeizuführen.

Neben den Grundfragen an ein Projekt, die Zielsetzung, Leistungsumfang, Zusammenarbeit und strategische Einordnung des Projekts ermöglichen, sind insbesondere für die Formen der rhythmischen Rückschau und die Art der Optimierung der Zusammenarbeit Sitzungsrituale zu definieren. Hierfür können die entsprechenden Methodenbausteine agiler Methoden (z.B. SCRUM Restrospektive) genutzt oder die klassischen Methodenbausteine reaktiviert werden (z.B. PRINCE2 Lessons learned).

Sind die vier Antworten jeweils in einem Satz formuliert, können die Projektbeteiligten damit aktiv arbeiten. Vier Sätze sind „merkbar“. Diese sollten allen wichtigen Dokumenten vorangestellt sein. So werden die vier Fragen ans Projekt ein aktives Werkzeug zur Bewertung von offenen Fragen und zur Einordnung des eigenen Handelns.

In jeder Projektphase werden sowohl im Kleinen als auch im Großen (also im Überblick) die Fragen gestellt:

1. Was und wie haben wir gearbeitet?

2. Was liegt an? Wie meistern wir das?

3. Was und wie wird kommen? Welche (kritischen) Themen sehen wir?

Werden zur Projektinitialisierung die Methodenbausteine vorgestellt bzw. erarbeitet, nach denen das Projektteam zusammenarbeiten wird, ist zu überprüfen ob die Wie- und Was-Fragen in der Rückschau, im Hier-und-Jetzt und in der Vorschau ritualisiert und verbindlich beantwortet werden.

Ist dies noch nicht der Fall, ist eine entsprechender Methodenbaustein zu finden. Der Methodenbaustein „StandUp“ klärt im Kleinen die „Was-Fragen“: In einem täglichen, sehr kurzen Treffen wird das „Was“ in allen Zeitachsen besprochen werden. Das regelmäßige Sprechen im Team legt mögliche Konflikte und Fehlentwicklungen schnell offen.

Diese Fragestellungen sind von allen Projektbeteiligten zu bearbeiten. Durch die Festlegung der Kommunikationsrituale wird eine Basis für eine gute Teamentwicklung gelegt. Zusammen mit expliziten Teamregeln ist dies der Grundstock für eine erfolgreiche Teamarbeit.

Die Prozessführung zur Definition der Kommunikationsrituale sollte maßgeblich vom Management vorangetrieben werden. Ist dies nicht der Fall, ist in einem Feedback-Gespräch genau dies einzufordern.

In Stellenausschreibungen für Software-Entwickler findet man häufig folgende Soft Skills, die von den Stellenkandidaten gefordert werden:

1. Teamfähigkeit

2. Serviceorientierung

3. Eigeninitiative

4. Kundenorientierung

Alle vier genannten Eigenschaften sollten für einen Stellenkandidaten in einer kunden- und serviceorientierten Unternehmung selbstverständlich sein. Diese Auflistung ist als eine Hitliste der Soft Skills zu verstehen, die von den entsprechenden Personalabteilungen beim typischen Bewerber nicht vermutet werden.

Agile Methoden als auch Entwicklungsmethoden, die den einzelnen Software-Entwickler zum Team hin orientieren (z.B. Pairing, TDD), stammen direkt aus der IT. Sie sind in der Praxis entwickelt worden.

Alle aktuell diskutierten Methodenbausteine fokussieren auf Teamarbeit. Gleichzeitig setzen viele agile Methoden auf eine große Eigeninitiative und -verantwortung der beteiligten Software-Entwickler. Der implizite Wertekanon der agilen Methoden beinhaltet eine große Wertschätzung des Wissens und Könnens jedes einzelnen Teammitglieds. Darüber hinaus werden Kunden stark in die Entwicklungsprozesse eingebunden. Gerade vor diesem Hintergrund sind die vermuteten fehlenden Soft Skills nicht nachvollziehbar.

Die Öffnung in Richtung agiler Methoden findet in vielen Unternehmen still statt. Diese aktive Stützung von Teamtechniken und -methodenbausteinen zur Optimierung der Software-Entwicklung wird im Gesamtunternehmen häufig nicht zur Kenntnis genommen.

Vielleicht stimmen doch einige der Vorurteile gegenüber Software-Entwicklern: „Informatiker gelten als technikverliebt, eher introvertiert, nicht besonders sprachgewandt und in ihrem Auftreten wie auch in ihrem Aussehen nicht gerade Führungswillen verbreitend.“[7]?

Es ist wichtig, sich diesen Vorurteilen entgegen zu stellen. Reden über die eigene Arbeit und die eigenen Ansprüche hilft. Die Wahrnehmung der IT als Projektverhinderer basiert darauf, dass Software-Entwickler vor allem mit einem langgezogenen „Ja, aber...“ bei Projektfragen wahrgenommen werden. Es ist an der Zeit, dass die Gegenüber die Begründung für das Handeln der IT mittragen. Hier helfen nicht nur informelle Gespräche beim Mittagessen, sondern auch unternehmensöffentliche Veranstaltungen, in denen die IT die Herausforderungen der täglichen Arbeit darstellt. Diese Form von Meta-Kommunikation hilft die systemorientierte Sicht der IT als begründet wahrzunehmen. Wichtig ist, dass der IT-Standpunkt erklärt wird und in den Unternehmenskanon eingeht. Stabilität, Performanz und (Zukunfts-)Sicherheit sind Zielsetzungen, die ein Großteil des Unternehmens nachvollziehen und mittragen wird.

Die Forderung an verbesserte Soft Skills von Software-Entwicklern verkehrt sich also in die Forderung nach einer veränderten Wahrnehmung der IT. Aus der Sicht vieler Unternehmensteile ist die IT eher Produktion ohne eigene Zielsetzungen. Herrscht in einem Unternehmen diese antiquierte Sicht auf die IT vor, ist dem offensiv entgegenzutreten.

Gelingt es dem gesamten Projektteam eine gemeinsame Zielsetzung festzulegen, ermöglicht die einfache Beantwortung von offenen Fragen im Rahmen der Entwicklung. Mittels Methoden wie ATAM[8] können im Vergleich mit den fachlichen Zielen technische Umsetzungsoptionen gemessen und bewertet werden.

Das Formulieren von fachlichen Zielen, die vom gesamten Projektteam verstanden und getragen werden, ist das oberste Ziel in der Projektkommunikation. Daran schließt sich eine offene Diskussion von Maßnahmen und Features mit Vor- und Nachteilen (sowohl fachlicher als auch technischer Sicht) an. Damit diese von Managern verstanden wird, sind technische Betrachtungen auf konkrete Beispiele herunter zu brechen.

Neben der Bearbeitung des Pflichten- und Lastenhefts ist es die Aufgabe des Software-Entwicklers, die Zielsetzung des Projekts, den gültigen Leistungsumfang, die Formen der Zusammenarbeit und die strategische Einordnung des Projekts zu besprechen und mit zu definieren. Robert C. Martin stellt fest: „The role of the professional developer is a communication role as well as a development role“[9]

Durch eine Darstellung der IT-Ziele und Verankerung dieser in den Unternehmenskanon wird eine Grundlage für eine gleichberechtige und offene Kommunikation über Projekte geschaffen. Durch die Aufnahme zu den „Meta“-Themen der Entwicklung gibt die Software-Entwicklung den schwarzen (Kommunikations-) Peter ab. Durch eine frühzeitige Klärung der vier Grundfragen an ein Projekt sowie der aktiven Bestimmung der Zusammenarbeit im gesamten Projektteam können die jeweiligen Projekte sich auf die wirklichen Baustellen und Herausforderungen konzentrieren.

Denn davon gibt es noch genug!

Dieser Artikel ist zuerst im Windows Developer, Ausgabe 11/2012, Software & Support Verlag erschienen.

• Nächster Artikel: Intuitiv und ohne Vorurteile entscheiden
• Vorheriger Artikel: Weihnachtspause!