1. Führen von Software-Entwicklungsteams
Der Faktor Mensch
Arno Hütter
2007

2. Führen von SW-Entwicklungsteams / Der Faktor Mensch
“Die Hauptprobleme unseres Fachgebiets
sind nicht so sehr technologischer,
als vielmehr soziologischer Natur.“
(DeMarco, Lister in: „Peopleware“)

3. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Eckpfeiler des Führungsverhaltens (1)
„Leadership, like software, is built upon a foundation. For software, the foundation is the
architecture. For leadership, it‘s your character.“
Verstehen: Kampf um Marktanteile wird durch Führungspersönlichkeiten gewonnen, welche die
Natur und Methoden der Softwareentwicklung kennen. “See the forest and the trees”.
Kommunizieren: “Evangelist” sein, Begeisterung vermitteln, Verstehen weitergeben. GuteKommunizieren: “Evangelist” sein, Begeisterung vermitteln, Verstehen weitergeben. Gute
Kommunikatoren sind auch gute Lehrer. Vorsicht bei unvorbereiteten, beiläufigen Bemerkungen.
Delegieren: Die richtigen Leute für die richtigen Aufgaben auswählen. “You can delegate tasks,
but not speed”. Eine effektive Form der Delegation: Senior/Junior Pair Programming.

4. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Eckpfeiler des Führungsverhaltens (2)
Kontrollieren: Keine “Erwartung ohne Kontrolle”. Daily Builds. Automatisierte Tests. Feedback
von Mitarbeitern einholen. Codeüberprüfung. Wöchentliche Projektstatusmeetings. Vier-Augen
Prinzip. Dokumentation.
Mitwirken: Mitarbeit der Führungskräfte auch bei Programmierung und bei Tests (zeitlich
begrenzt). Die besten Führungskräfte sind nicht nur Trainer an der Seitenlinie, sondern auch von
Mitspieler. Wichtiges Signal für Mitarbeiter.Mitspieler. Wichtiges Signal für Mitarbeiter.

5. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Führungsaktivitäten
Mentoring: Problemlösungskompetenz der Mitarbeiter erhöhen. Zukünftige
Führungspersönlichkeiten heranziehen. Multiplikatorwirkung für die eigenen Bemühungen. Wille
zur Wissensweitergabe ist nötig.
Belohnen: Honorierung außerordentlicher Leistungen. Faire, leistungsgerechte und zeitgemäße
Vergabe. Verschiedenste Formen möglich (finanzieller Bonus, Eintrittskarten, etc).
Korrigieren: Schlampigen Code und inadäquate Lösungen verhindern. Code Reviews. Form der
Behebung vorschlagen, bei der Umsetzung unterstützen, Lerneffekt erzielen. Keine
Schuldzuweisungen, aber problematische Mitarbeiter erkennen und ggfs. ersetzen. Vorbild sein -
eigene Nachlässigkeit beschädigt allgemeines Qualitätsbewusstsein.
Vorhersehen: Über das Tagesgeschäft hinausblicken, ein Bild der Zukunft erschaffen und damit
Mitarbeiter inspirieren und motivieren.
Anpassen: Verhaltensweisen an die jeweiligen Problemstellungen adaptieren,
Herausforderungen annehmen, neue Fähigkeiten aneignen. Probleme sind auch Chancen.

6. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Gefolgsleute gewinnen
Pflichtbewusststein: Loyalität zu Team und Produkt. Läßt sich u.a. durch “Stolz auf das bisher
Erreichte” steigern. Teil einer Sieger-Mannschaft sein.
Bewunderung: Menschen folgen Persönlichkeiten, die sie bewundern. Konsistenz in
Managementstil, Führungseffektivität und im Umgang mit den Mitarbeitern.
Belohnung: Den Mitarbeitern ein Arbeitsumfeld schaffen, welches für sich schon eine BelohnungBelohnung: Den Mitarbeitern ein Arbeitsumfeld schaffen, welches für sich schon eine Belohnung
ist.
Wissen: Wissen ist Macht, speziell in der SW-Entwicklung. Experte sein und bleiben, Wissen
teilen. Mitarbeiter, die davon profitieren, werden somit zu Gefolgsleuten.
Andere Kräfte: Markt- und Konkurrenzsituation, Bezahlung. Normalerweise alleine nicht
ausreichend, aber ein Anfang.

7. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Kategorien von SW-Entwicklern („The Good“)
Der Architekt: Befasst sich mit Gesamtstruktur von Systemen, Problemlösung durch Abstraktion.
Gefahr: Konnex zu den “Umsetzern” und deren Bedürfnissen kann verlorengehen.
Der Konstrukteur: Arbeitet intuitiv, Probleme werden durch Code gelöst. Gefahr: Dokumentation
kann zu kurz kommen.
Der Künstler: Gestalterisches Arbeiten im Vordergrund, aus Anforderungen SW-Konstrukte mitDer Künstler: Gestalterisches Arbeiten im Vordergrund, aus Anforderungen SW-Konstrukte mit
intuitiver Benutzerschnittstelle zu bauen. Gefahr: Ineffizienz und fehlendes Design.
Der Ingenieur: Entschärft Komplexität durch Zielreduktion. Gefahr: Mangelnde Flexibilität bei
geänderten Anforderungen.
Der Wissenschaftler: Problemlösung gem. den Grundprinzipien der theoretischen Informatik,
Puristen. Gefahr: Unpraktikable Lösungen.
Der Geschwindigkeitsdämon: Rasche Umsetzung, Einhaltung des Zeitplans um jeden Preis.
Gefahr: Versteckte Fehler.

8. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Kategorien von SW-Entwicklern („The Bad“)
Der Schlampige: Umsetzung schlampig, fehlerhafter Code, mangelhafte Struktur, Verletzung von
Kodierkonventionen, keine Tests.
Der Eingeschüchterte: Keine Eigeninitiative, weiß nicht wie zu beginnen ist, kann mit
unvollständigen Informationen nicht umgehen.
Der Amateur: Mangelnde Ausbildung und Erfahrung, Überschätzung der eigenen Fähigkeiten.Der Amateur: Mangelnde Ausbildung und Erfahrung, Überschätzung der eigenen Fähigkeiten.
Der Ignorant: Verschlossen gegenüber technologischen Neuerungen, verweigert Fortbildung
oder Änderung der Arbeitsweise.
Der Salatkoch: Schlecht proportionierte Mischung aus Ingenieur, Schlampigem und
untalentiertem Künstler.

9. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Erfolgreiche Entwicklungsteams
Qualität zum Kult machen: Qualitätsbewusstsein ist ein starker Teambildungs-Katalysator, weil
dieses gemeinsame Ziel verbindend wirkt. Funktioniert nur bei unternehmerisch-langfristiger
Denkweise.
Ein Hauch von Elitedenken: Menschen brauchen das Gefühl, in gewisser Weise einzigartig zu
sein. Aufgestülpte unternehmensweite Einheitlichkeit wird auf Managementebene oft als
wünschenswert betrachtet, wirkt aber kontraproduktiv.wünschenswert betrachtet, wirkt aber kontraproduktiv.
Heterogenität zulassen und unterstützen: Signalwirkung: Es ist OK, kein „Corporate Clone“ zu
sein. Wertvolle Ergänzung, z.B. Frauen in ansonsten männer-dominierten Entwicklungsteams.
Erfolgreiche Teams zusammenhalten und beschützen: Nach erfolgreichem Projektabschluss
das Momentum für das nächste Projekt mitnehmen.
Marschrichtung auf strategischer Ebene vorgeben, nicht auf operativer: Schlüssel-
Mitarbeiter identifizieren und mit entsprechenden Freiheiten ausstatten. „Flow of free electrons“.

10. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Entwicklungsteams / Zerstörerische Kräfte
Defensives Management: Entscheidungsfindung ohne Rücksprache mit den Mitarbeitern,
fehlendes Vertrauen.
Bürokratie: Sinnloses Produzieren von Papier, eigentliche Arbeit kommt zu kurz.
Physische Trennung: Verteilung des Projektteams. Telefon statt direkter Interaktion.
Fragmentierung der Arbeitszeit: Zuteilung zu mehreren Projekte.
Qualitätsverzicht: Argument der Kostenreduktion, geringe Identifikation der Mitarbeiter.
Künstliche Endtermine: Werden mit großer Wahrscheinlichkeit ohnehin nicht ernst genommen.
Inspirationsslogans: Triumph der äußeren Form über die innere Substanz.
Ständige Überstunden: Kann nicht von jedem in gleichem Ausmaß mitgetragen werden.

11. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Motivationsfaktoren für SW-Entwickler (1)
Zwei-Faktoren-Theorie (nach Frederick Herzberg):
– Hygienefaktoren: Verhindern Entstehung von Unzufriedenheit, z.B. Einkommen, Sicherheit,
zwischenmenschliche Beziehungen.
– Motivationsfaktoren: Motivation zur Leistung, z.B. Arbeitsinhalt, Anerkennung, Verantwortung.
Motivationsfaktoren sind von besonderer Bedeutung für SW-Entwickler, die sich voll und ganz
mit ihrer Profession identifizieren. Üblicherweise sind das jene Mitarbeiter, die für erfolgreiche
SW-Projekte nötig sind.SW-Projekte nötig sind.
Aufgestellt für den Erfolg: Viele Software-Projekte sind Fehlschläge, gute Entwickler scheitern
nicht gerne und suchen daher nach einem erfolgversprechenden Umfeld. Professionelles
Projektmanagement, kompetente Entwicklungspartner, Qualitätsbewusstsein sind daher
besonders wichtig.
Exzellentes Management: Betrifft sowohl Projektmanagement als auch Personalführung.
Kenntnis der Spezifika von SW-Projekten, rasche Entscheidungsprozesse, Loyalität den
Mitarbeitern gegenüber – und man wird im Gegenzug vollen Arbeitseinsatz erhalten.

12. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Motivationsfaktoren für SW-Entwickler (2)
Abwechslung und ständiges Lernen: Hochqualifizierte SW-Entwickler haben sich Ihre
Profession mit hoher Wahrscheinlichkeit genau aus diesen Gründen ausgesucht.
Herausforderung Problemlösung: Programmierer lieben Herausforderungen. Nächtliche
Kodier-Sitzungen bis ein Problem gelöst ist, sind keine Seltenheit, auch wenn es nicht verlangt
wurde oder extra vergütet wird. Unterforderung hingegen kann sich fatal auswirken.
Gehör finden: Entwickler sitzen - plakativ gesprochen - in den vorderen Schützengräben, und
registrieren sich abzeichnende Probleme mitunter zuerst. Wenn sie sich dazu äußern, v.a. wenn
mehrere Entwickler in ihrer Einschätzung übereinstimmen, sollte man ihnen zuhören.
Anerkennung: Ein erfolgreiches Produkt ist eine Hauptmotivation, die noch gesteigert werden
kann, wenn man dafür auch Anerkennung erntet.

13. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Motivationsfaktoren für SW-Entwickler (3)
An etwas teilhaben, das einen Unterschied macht: Das ist auch bei Software-Produkten
möglich, z.B. Entlastung von manueller Routinearbeit, Effizienzsteigerungen, verbesserte
Kommunikation, breiter Produkteinsatz. Negativ wirken sich hingegen sinnlos erscheinende
Projektarbeiten aus.
Unbürokratische Entscheidungsfindung: Autorität zu eigener Entscheidungsfindung ohne
jedes Mal ein eigenes Komitee einberufen zu müssen.jedes Mal ein eigenes Komitee einberufen zu müssen.
Umgang mit Altlasten: Mit der Wartung von qualitativ problematischen Altprodukten betraut zu
sein, oder gravierende Einschränkung durch die Charakteristika bestehender Legacy-Systeme in
Kauf nehmen zu müssen, wird hochqualifizierte SW-Entwickler auf Dauer nicht zufriedenstellen.

14. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Mitarbeiterauswahl: Variabilität individueller Leistungsfähigkeit
“The most important practical finding involves the striking individual differences in programmer
performance” (Sackmann, H.)
“Within a group of programmers, there may be an order of magnitude difference in capability”
(Schwartz, J.)
“A few good people are better than many less skilled people” (Davis, A.)“A few good people are better than many less skilled people” (Davis, A.)
“The best performers are clustering in some organizations, while the worst are clustering in
others” (DeMarco, Lister)
Aber: Große Schwankungsbreite auch innerhalb einer Ausbildungsgruppe, z.B. unter Absolventen
ein- und desselben Universitätsstudiums. Formale Qualifikationskriterien sind daher nicht
ausreichend.

15. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Mitarbeiterauswahl: „Smart & Gets Things Done“

16. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Mitarbeiterauswahl: Interviewtechniken für SW-Entwickler
Mehrere Interview-Runden, darunter auch ein Test in praktischer Programmierung.
Keine Vorurteile (z.B. aufgrund formaler Ausbildung oder der Meinung anderer).
Einleitung: Vorstellung, Situation entspannen.
Offene Frage nach Projektarbeit des Kandidaten. Kann er komplexere Zusammenhänge
einfach erklären? Ist er begeisterungsfähig? Hat er Schwierigkeiten aus eigener Initiative
überwunden?
Lösung eines einfachen Programmierproblems: Spreu vom Weizen trennen. Wir schnell wurde
das Problem gelöst, wie elegant?
Lösung eines schwierigen Programmierproblems: “Understanding pointers is not a skill, it’s an
aptitude”. Wichtiger als die Lösung ist der Lösungsweg. Diskussion entfachen.
Fragen des Bewerbers

17. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Mitarbeiterauswahl: Und umgekehrt: „The Joel Test“
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

18. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Arbeitsumgebung und Produktivität (1)

19. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Arbeitsumgebung und Produktivität (2)
Getrennte Büros statt „Cubicle Offices“: Zwei bis vier Personen je Büro. Ausreichend Platz.
Bei der Planung sollten Menschen und ihre Bedürfnisse im Vordergrund stehen, nicht
Verkabelungspläne oder dgl. Kosten der Arbeitsplatz-Ausstattung sind gering im Vergleich zu
Personalkosten.
Gestaltungsfreiheit statt Uniformität: Menschen brauchen Individualität, auch am Arbeitsplatz
(zumindest in gewissem Rahmen).(zumindest in gewissem Rahmen).
Ruhe, telefonfreie Zeiten, Unterbrechungen vermeiden: „You never get anything done around
here between 5 and 9“.
Flow: Tief-konzentriertes Arbeiten, höchste Effektivität (Hauch von Euphorie), erst nach einem
gewissen Zeitraum des „Eintauchens“ in die Materie.

20. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Software Craftsmanship (1)
Software-Entwicklung arbeitsintensiver als je zuvor
Menschen als teuerste Ressource
Steigende Nachfrage nach Software-Entwicklern
– Gegenmaßnahme 1: Kurze Einschulungsprogramme: Fehlgeschlagen. Software-Entwicklung verlangt
mehr als die reine Kenntnis der Syntax einer Programmiersprache.mehr als die reine Kenntnis der Syntax einer Programmiersprache.
– Gegenmaßnahme 2: CASE Tools: Fehlgeschlagen. Arbeits-, Modellierungs- und Codierweise wurden
den Entwicklern aufoktruiert. Code für viele Problemstellungen weiterhin das richtige Abstraktionsmodell.
– De-Qualifikation und Industrialisierung sind die falschen Ansätze. Automatisierung ist sinnvoll, hat aber
Grenzen.

21. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Software Craftsmanship (2)
Software-Entwicklung als „Handwerk“.
Gesamtheitliche Beherrschung eines Handwerks nur nach Jahren des Lernens und
Praktizierens erreichbar.
Sobald Handwerk nicht mehr aktiv ausgeübt wird, schwindet das Können.
Lehrzeit: Situatives Lernen. Selbständige Ausführung einfacher Aufgaben, komplexere
Aufgaben unter Aufsicht des Lehrmeisters, Lernen „am Beispiel“.

22. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Quellen (1)
DeMarco, Lister: “Peopleware”
Glass, Robert L.: “Facts and Fallacies of Software Engineering”
McBreen, Pete: “Software Craftsmanship”
Rainwater, J. Hank: “Herding Cats: A Primer for Programmers Who Lead Programmers”
Spolsky, Joel: “Joel on Software”
Spolsky, Joel: “Smart & Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best
Technical Talent”
Walling, Rob: "Nine Things Developers Want More Than Money“,
http://www.softwarebyrob.com/articles/Nine_Things_Developers_Want_More_Than_Money.aspx

23. Führen von SW-Entwicklungsteams / Der Faktor Mensch
Quellen (2)
Weinberg, Gerald M.: “Becoming a Technical Leader – An Organic Problem-Solving Approach”
Weinberg, Gerald M.: “The Psychology of Computer Programming”