„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.“
Schwarzer Peter liegt vermeintlich in der Software-Entwicklung
Ü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?
Anerkennung als Motivator für alle Projektbeteiligte

Ziel eines Entwicklers ist es, stabile, performante und (zukunfts-)sichere Systeme zu entwickeln, welche leicht zu unterhalten und weiterzuentwickeln sind. Jedwede Anforderung misst sich an den Auswirkungen auf das System. Manager denken in zeitlich begrenzten Projekten. Ihre Arbeit lässt sich mit den Parametern Aufwand, Zeit und Qualität messen, wobei sich die Betrachtung der Qualität häufig an der GUI für den Endanwender misst. Die der Software zu Grunde liegenden Systeme werden aus Sicht der Manager häufig als nicht änderbare Infrastruktur wahrgenommen.
Für alle Projektbeteiligten – Software-Entwickler wie Manager – gilt, dass sie Anerkennung für ihre Leistungen erfahren möchten. Das Erreichen der Ziele bildet die Grundlage für diese Anerkennung. In vielen Projekten wird die Zielsetzung des Projekts nicht deutlich formuliert. Daher formulieren die Projektbeteiligten unterschiedliche Projektziele für ihre eigene Disziplin. Während die Software-Entwickler vorwiegend auf eine stabiles, performantes und (zukunfts-)sicheres System schauen, werten die Manager in den genannten Parametern Aufwand, Umsetzungszeit und Qualität.
Aus diesen Sichtweisen heraus entstehen sehr unterschiedliche Strategien zum Umgang mit Risiken. Während Software-Entwickler versuchen, ihre Systeme dauerhaft stabil zu halten, suchen Manager nach einem effizienten Weg, Projekte erfolgreich durchzuführen. Die Forderung „quick & dirty“ zu handeln ist für den Manager zielführend, da dies Projekterfolge im zeitlich fixierten Rahmen ermöglicht. Die sich aufbauende technische Schuld wird entweder nicht gesehen oder dem nächsten Projekt zugeordnet. Der Software-Entwickler sieht in dieser Forderung, das Timing um jeden Preis zu halten, in den meisten Fällen einen Qualitätsverlust des Systems.
Fehlt ein gemeinsames Ziel, zählen die Einzelziele der beteiligten Disziplinen
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.
Unternehmensvision kennen!
Eine Bewertung und Priorisierung von Projekten ist für den einzelnen Mitarbeiter nur möglich, wenn die Unternehmensziele klar sind. Gerade weil selbst Führungskräfte die für Ihr Unternehmen formulierten Unternehmensziele nicht kennen[1], ist nachfragen unterlässlich. Dies sollte beharrlich erfolgen, bis eine gute Formulierung erfolgt. Nur so lässt sich die Sinnhaftigkeit und Zielsetzung von Projekten nachvollziehen.
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.
Unternehmenskultur: „That’s the Way We Do Things Around Here“[2]
Die Art der Kommunikation in Projekten wird stark durch die Unternehmenskultur geprägt. Die Unternehmenskultur zeigt sich durch die Ergebnisse der Arbeit, formulierte Haltungen,
resultierenden Handlungen sowie den darunter liegenden (häufig nicht artikulierten) Wertvorstellungen.
„Glaubt“ zum Beispiel eine Organisation vorwiegend an eine hierarchisch gegebene Entscheidungsbefugnis, wird dies eine offene Projektkommunikation, die vom gesamten Projektteam getragen wird,
erschweren, im schlimmsten Fall verhindern.
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 Mythos der fehlenden Soft Skills bei Software-Entwicklern
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, gehen Projekte schief
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.
Einfach miteinander reden!
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.
Mit eindeutigen Zielsetzungen und Anforderungen arbeiten
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:
-
Title: „goal the use case is trying to satisfy“
-
Main Success Scenario: numbered list of steps
-
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.
Kommunikation den richtigen Stellenwert einräumen
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).
Vier Fragen ans Projekt
Um ein Projekt in allen Facetten zu verstehen, sind die folgenden vier Fragen präzise zu beantworten:
- Warum?
Aus welcher Motivation heraus wird das Projekt durchgeführt? Welches Ziel soll mit dem Projekt / Produkt erreicht werden? - Was?
Was genau wird in dem Projekt gemacht? Um was geht es? - Wie?
Wie arbeiten wir zusammen? Was ist uns der Zusammenarbeit wichtig? - Wohin noch?
Was ist das große Bild? Wie ordnet sich das aktuelle Projekt in die (Unternehmens-) Vision ein?
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:
-
Was und wie haben wir gearbeitet?
-
Was liegt an? Wie meistern wir das?
-
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.
Kommunikationsaufgaben für Software-Entwickler
Für erfolgreiche Projekte sind für das Projektteam stimmige Projektrituale und -regeln zu leben. Existieren diese nicht, sind diese einzufordern. Zu den Projektritualen und -regeln gehören:
-
Regelmäßig und persönlich über den Projektverlauf (Inhalt und Zusammenarbeit) kommunizieren
-
Zielsetzung für das gesamte Projekt, die Iteration und das Feature kennen und verstehen
-
Vier Fragen ans Projekt beantworten können
-
Projektrituale (für das gesamte Projekt, die Iteration bzw. den Arbeitstag) definieren und leben
Software-Entwickler sind teamfähig!
In Stellenausschreibungen für Software-Entwickler findet man häufig folgende Soft Skills, die von den Stellenkandidaten gefordert werden:
-
Teamfähigkeit
-
Serviceorientierung
-
Eigeninitiative
-
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.
Schwerpunkt auf die gemeinsame Zielsetzung legen
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.
Schwarzen Peter abgeben, Kommunikation aufnehmen
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!
Kommentar schreiben
Rainer Schleevoigt (Dienstag, 01 Januar 2013 17:00)
Judith, Du hast mir aus dem Herzen geschrieben. Leider gibt man (ich) dann irgendwann doch dem Drängen nach und beschleunigt den Fertigstellungsprozess. Dann entsteht so nach und nach der berüchtigte http://de.wikipedia.org/wiki/Big_Ball_of_Mud. Was dagegen tun? Ich habe auch noch kein Patentrezept – hat aber offenbar etwas mit dem eigenen Standing zu tun.
Judith Andresen (Dienstag, 01 Januar 2013 18:35)
Hallo Rainer,
tatsächlich hat es mit Standing zu tun - und mit einem Verständnis dafür, was eine Beschleunigung der Fertigstellung für Konsequenzen im System hat (technical debt, big ball of mud) - und wie sich das zukünftig auswirken wird.
Dieses Wissen ist zunächst einmal "Deines" - während der Diskussion ist das zu übermitteln (dabei ist es einfacher, die Risiken so aufzuzeigen, wie sie auf Marketing- / Managementseite ihre Auswirkungen zeigen werden.) Siehe dazu auch: http://www.judithandresen.com/2012/07/16/alle-risiken-im-griff/