"Willst du mit jemandem ein Schiff bauen, wecke in ihm die Sehnsucht nach dem Meer."
(Gert Kupfer)

Leitung

Der amerikanische Slogan "My way or the highway!" (dt.: "Auf meine Art oder du bist auf der Straße!") hat heute als Führungsstil nur noch bedingt Gültigkeit. Selbst wenn ein Projekt vor die Wand fährt und ein Experte eingeschaltet wird, um das Projekt zu retten, kann er es nicht allein, sondern nur mit Unterstützung durch das Team schaffen. Und Wasser kocht unter Druck bekanntlich auch nicht schneller, sondern langsamer! Auf der Suche nach der richtigen Art der Motivation kommt vielleicht jeder mal zu dem Punkt, dass er nicht eine Konkurrenz zwischen den Teammitgliedern, sondern eine Konkurrenz jedes Teammitglieds mit sich selbst benötigt.

Wenn man jemanden lobt, weil dieser etwas richtig getan hat, oder zumindest besser als sonst, so wird derjenige seinen persönlichen Fortschritt erkennen und weiter an sich arbeiten. Dies kann sich auf Soft Skills und Hard Facts gleichermaßen beziehen. Auf diese Art wird auch das ganze Team als Ganzes immer besser werden. Es bringt mehr, bei guten Taten zu loben, als bei schlechten zu strafen. Wer mehr über diesen Ansatz erfahren möchte, sollte [B22] lesen, ein kleines Buch mit einem großen Inhalt! Gleiches gilt übrigens für [B31], zu dem es auch ein nettes Video gibt, das den Fischmarkt im vollen Treiben zeigt. In einem Kurspraktikum mit einem echten Projekt kam der ernannte Projektleiter - selbst Kursteilnehmer - auf die geniale Idee, jede Woche den Oscar an denjenigen Mitarbeiter in seinem Team zu verleihen, der etwas ganz Besonderes geleistet hat. Der Oscar stand dann die ganze Woche auf dessen Tisch - für jeden gut sichtbar. Zuerst wurde das albern aufgefasst, aber im Laufe der Zeit wollte natürlich jedes Teammitglied wenigstens einmal diesen Oscar bekommen.

Wer den obigen Ansatz verstanden hat und mit erster positiver Erfahrung anwendet, kann auch die so beliebten "Zielvereinbarungen" einführen. Denn Ziele und die Messungen dessen Erreichungsgrades sollten nicht als Druckmittel oder gar zum Aussortieren von Versagern dienen, sondern zur persönlichen Weiterentwicklung der einzelnen Teammitglieder. "Goals Begin Behaviors - Consequences Maintain Behaviors." (dt.: "Mit Zielen beginnt Verhalten - Konsequenzen pflegen Verhalten.") aus [B11] signalisiert denn auch eine sehr hohe Disziplin und eine ständige Beobachtung sowie Steuerung durch die Teamleitung. Gemäß dem Ansatz aus dem vorherigen Absatz kann ein Teamleiter seine Mitarbeiter zum Ziel steuern, wenn er sie in dem Moment lobt, wenn sie etwas tun, was sie dem Ziel näher bringt. Jeder wird das an sich selbst positiv spüren und motiviert sein, immer häufiger Dinge immer besser zu tun.

Aus dem netten und lustigen Buch [B25] stammt dieser Absatz: "Ich weiß, dass Führen bedeutet, andere zum Handeln zu bewegen. Wie sie handeln, ist ebenso belanglos wie das Ergebnis ihrer Handlungen, denn ich beherrsche den Hiroshito-Transfer immer meisterhafter: Erfolge sind immer auf meine Fähigkeiten zurückzuführen, Misserfolge jedoch immer auf die Unfähigkeit meiner Mitarbeiter. Und wenn einer behaupten sollte er hätte nur nach meinen Anweisungen gehandelt, hat er mich falsch verstanden. Ich bin eine deutsche Führungskraft und setze auf die Initiative und Kreativität, auf die innovative Eigenständigkeit meiner Mitarbeiter. Lediglich wenn mir einer von ihnen gefährlich werden könnte, sorge ich dafür, dass er so schnell wie möglich aus dem mich beschäftigenden Unternehmen verschwindet."

Eine Komponente der Leitung sollte immer auch "Monitoring" sein. Wenn ein Projekt in einer späten Iterationsstufe in Schwierigkeiten durch Erschöpfung, Krankheit, Kündigung oder Mehrarbeit gerät, so ist es in der Regel schwierig, neue Leute ins Team zu integrieren. Ein Projekt wird in dieser Phase durch weitere oder neue Mitarbeiter zunächst nicht beschleunigt, sondern erst mal gebremst. Dies liegt daran, dass neue Mitarbeiter sich erst in die Architektur, die Tools, das Objektmodell und den bestehenden Code einarbeiten müssen und dabei auf die Hilfe der Veteranen des Projekts angewiesen sind (die ohnehin schon genug zu tun haben). In der Regel läuft es auf die Szene im Film "Forrest Gump" hinaus, wo Forrest in Vietnam ankommt und Dan zu ihm sagt: "Bleibt bei mir und lernt was von den Jungs, die schon ne Weile hier sind, dann geht alles glatt." Die neuen Mitarbeiter werden zu Beginn ggf. auch die eine oder andere Änderung vornehmen, die mehr schadet als nutzt. Es ist also wichtig, einen guten Kontakt zu den Teammitgliedern zu haben und Engpässe früh zu erkennen, denn dann lohnt sich die Einarbeitung weiterer Mitarbeiter auf jeden Fall. In diesem Moment zeigt sich dann auch, ob das Team wirklich funktioniert!

Zu einem Team gehören auch Rollen. Dies hat was mit "Effektivität" und "Effizienz" zu tun. "Effektivität" bedeutet: "Die richtigen Dinge tun.", "Effizienz" bedeutet: "Die Dinge richtig tun." Es ist also wichtig, erst einmal zu erkennen, was alles getan werden muss. Dann sollte der Teamleiter mit seinem Team gemeinsam überlegen, wer was am besten tun kann und auch möchte. Und erst dann sollte er verbindlich diese Aufgaben verteilen und sich von jedem Teammitglied einen Plan wünschen, wie dieses die Aufgaben zu tun gedenkt. Bei Bedarf kann die Rollenverteilung ja auch noch mal geändert werden. Falls jemand ein alter Hase in einer Rolle oder einem Thema ist, aber mal was anderes machen möchte und jemand neues erstmalig diese Rolle oder dieses Thema übernehmen möchte, ist es sicherlich sinnvoll, hier eine "Patenschaft" einzurichten. Wenn dann noch Ziele an die Rollen gekoppelt werden, wird auch jedem Teammitglied sein Beitrag zum Projekt und seine Verantwortung im Team sehr schnell klar. Viele Rollen haben Schnittstellen zu anderen Rollen, und diese Schnittstellen müssen sehr wohl ebenfalls erarbeitet und definiert werden. Beispielsweise muss ein Entwickler seine Quellen schon in das Sourcen-Verwaltungssystem einchecken, damit ein Quell-Tester den zugehörigen Prüfstandtest fahren kann.

Wo Licht ist, ist natürlich auch Schatten. Es macht sicherlich auch Sinn, Mitarbeitern mal zu sagen, wo sie etwas schlecht gemacht haben. Schon allein, weil die Leute sonst nach wenigen Monaten nur noch glauben, sie seien die Größten, weil sie ja nur noch gelobt werden und mit minimaler Steuerung ihre Ziele immer besser erreichen. Eine solche Erfahrung steigt Leuten schnell in den Kopf und sie fangen an sich aufzuspielen, weniger zu arbeiten und stattdessen mehr Geld zu verlangen. Zum Loben gehört also natürlich auch Tadeln ("Zuckerbrot und Peitsche"), das spielt auch in [B11] eine wichtige Rolle.

In Notfällen und absolut dringenden Situationen kann es kurzzeitig sogar erforderlich sein, dass einer aus dem Team die absolute Führung übernimmt und bestimmt, wo es lang geht. Auch in den besten Projekten mit den bewährtesten Teams kann dies vorkommen, allein schon durch äußere Zwänge. Ich erinnere mich an ein Projekt einer Embedded Software (ein Betriebssystem eines Consumer-Produktes), bei dem die Produktion der Geräte Anfang der Woche angelaufen war und in der Folgewoche die Chips mit der Software eingesetzt werden sollten. Natürlich wurde Ende der Woche ein schwerwiegender Fehler gefunden ("Wenn etwas schief gehen kann, dann wird es auch schief gehen."). Also setzten wir uns Freitag Nachmittag - gerade Zuhause angekommen - direkt wieder ins Flugzeug, um das ganze Wochenende durchzuarbeiten, damit am Montagmorgen die Chips mit der Software produziert werden konnten. Ansonsten hätten die Bänder im Produktionswerk gestoppt werden müssen! An diesem Wochenende hat aus Effizienzgründen genau einer gesagt, wer was wann wo tut! In solchen Momenten gelten die Regeln der christlichen Seefahrt: Es gibt genau einen Kapitän, und es wird gemacht, was dieser sagt - alles andere ist Meuterei! Und wie die bestraft wird, weiß ja jeder ;-)

In solchen schwierigen Situationen wird typischerweise nicht der Projektleiter das Sagen haben und evtl. nicht einmal der Teamleiter, sondern vielleicht eher eine Rolle, die gerne "DevLead" ("Development Leader", dt.: "Entwicklungsleiter") genannt wird. Dies wird der erfahrenste, respektierteste und fitteste Entwickler des Teams sein. Dennoch sind Projektleiter und Teamleiter natürlich in so einem Moment zugegen, koordinieren unterstützend Aktivitäten und Kommunikation, lösen einzelne Konflikte und holen die Pizza! Manchmal ist es schon eine kleine Stütze, wenn man morgens aus einem Galgenhumor heraus einen Spruch oder Witz des Tages kürt und diesen als Running Gag wirklich durch den ganzen Tag zieht. Dazu gibt es unzählige Sprüchekalender zu kaufen und auch im Internet gigantische Sammlungen - suchen Sie einfach mal nach "Sprüche Witze Zitate".

Gerade in solchen Heldenprojekten hat man oft die Elite der Entwicklung versammelt und sollte sie auch so behandeln. Dazu kann man Familienväter mit einem dauerhaften Kinder-zur-Schule-Bringservice oder junge Haudegen mit 3 Monaten Off für eine Reise durch Südamerika nach Projektende motivieren [B28]. Hier muss man sich einfach vor Augen führen, dass man im Grunde nichts als seine Leute hat. Was bliebe denn schließlich übrig, wenn alle Mitarbeiter eines Softwareunternehmens gleichzeitig kündigen würden? Ein paar Tische mit ein paar PCs darauf! Das Gesamtwissen und die Erfahrung würde sich doch mit den Subjekten einzeln in alle Winde verteilen. Es ist oft nicht einfach, die guten Leute nach einem Heldenprojekt zum Bleiben zu motivieren, aber gerade die Erfahrungen aus einem solchen Projekt sind für ein Unternehmen oft immens wichtig. Wie entsteht denn bei Ihnen in der Küche ein gutes Soufflé? Aus Rohstoffen und einem Rezept! Das Rezept enthält die Erfahrung und liefert damit die Kompetenz; neudeutsch spricht man hier auch von "Humankapital". Dieses Beispiel verwendet der amerikanische Wirtschaftsprofessor Paul Romer [M4] gerne für eine Veranschaulichung seiner Wirtschaftstheorie "New Growth Theory".

Zum Umgang mit Entwicklern in kritischen Projekten lesen Sie auch mal die Reports aus dem Windows 2000 Team von Microsoft, z.B.: "What the Boss Should Know". Die haben ja nun wirklich Erfahrung mit Hammerprojekten, wie auch gut in [B21] nachzulesen ist.

Auch wenn es gerade nicht brennt und demzufolge auch nichts gelöscht werden muss, sollten Sitzungen von Projektlenkungskreisen und Projektsteuerungsgremien stattfinden. Diese Routinen sollten zu Beginn des Projekts durch Vorstellung im Kick-Off-Meeting etabliert und wirklich in einem festen Turnus durchgeführt werden. Alle Leute der Verantwortungsmatrix sollten daran teilnehmen. In diesen Sitzungen wird natürlich ein Sachstandbericht zum Projekt geliefert, die Pläne werden kontrolliert und projektgefährdende Probleme werden signalisiert, damit gemeinsam eine Lösung gefunden werden kann. Typischerweise werden übergreifende, ganzheitliche Probleme diskutiert und gelöst, lokale dagegen nur angeschnitten und delegiert. Wichtig ist, dass die gesamte Verantwortungsmatrix große Probleme frühzeitig signalisiert bekommt (am besten gleich mit mehreren Lösungsansätzen), denn nur so kann das Vertrauen in der gesamten Matrix aufgebaut und erhalten werden. Offenheit und Fairness ist in der Verantwortungsmatrix genauso wichtig wie im Entwicklungsteam oder auch im Fachteam.

Wovon ich persönlich überhaupt nichts halte, sind diese Routinen in Entwicklerteams, die womöglich sogar zweimal wöchentlich mit allen zwanzig Entwicklern stattfinden. Da werden die wesentlichen Probleme eh nicht angesprochen, weil man diese nicht in einer solchen Gruppe diskutieren kann. Demzufolge werden da auch keine wesentlichen Entscheidungen getroffen. Also kann man sich den Quark auch gleich sparen! Man sollte sich einfach mal ausrechnen, wie viel Personenstunden da in schlechter Luft auf heißen Kohlen verbracht werden, dann kommt man schnell zu dem Schluss, dass einen dieser Aktionismus nicht weiter bringt. Operative Hektik ersetzt hier geistige Windstille! Dann doch lieber ein wöchentliches Projektfrühstück, zu dem jeder was Leckeres mitbringt. Dabei werden dann zwischendurch von ganz allein in kleinen Grüppchen auch mal die Probleme besprochen, die auf den Nägeln brennen. Wenn Projektleiter und Teamleiter da nicht auf den Ohren sitzen, erfahren sie die wichtigen Sachen, ohne danach fragen zu müssen - vor allem die Stimmung im Team!

Zur Leitung gehört natürlich auch die Steuerung der Abstimmung des Entwicklerteams mit anderen Teams, beispielsweise den Autoren. Dazu gehört auch die Handbuchabteilung, die parallel zur Implementierung die Bedienungsanleitung schreibt (in Deutschland darf übrigens kein Produkt ohne Bedienungsanleitung verkauft werden). Gerade bei der iterativ inkrementellen Entwicklung kann die Struktur des Handbuchs sehr früh mit der Ausarbeitung der Arbeitspakete für die Iterationsstufen erfolgen und in jeder Iterationsstufe ein Teil des Handbuchs parallel erstellt werden, im Rohbau sogar oft schon anhand der ersten Prototypen.