Wie viel Solidarität braucht man im Application Lifecycle Management (ALM)?

Diese Frage mutet doch schon sehr philosophisch an. Aber mal im Ernst, könnten wir uns im ALM nicht noch mehr um Werte und Normen bemühen – wie wir das im „richtigen Leben“ doch auch tun? Vielleicht hätten wir mit solch einem (Selbst)Verständnis das eine oder andere Problem weniger?

Ein Szenario

Nehmen wir doch mal folgendes Szenario an: Wir arbeiten in einem mittelständigen Unternehmen, dass hauptsächlich Software für die Finanzbranche erstellt. Das sind alles Auftragsentwicklungen, die über Projekte abgewickelt werden. In einem dieser Projekte muss eine Applikation zur Abwicklung von Transaktionen entwickelt werden. Unser Projektteam arbeitet seit kurzer Zeit agil, wobei die bisherige Organisationstruktur beibehalten wurde. Im Fokus unseres Szenarios steht der Senior Entwickler dieses Projektes. Die Ergebnisse, die von ihm erwartet werden, sind:

1. Ein ausführbares Programm
2. Code im Source Control
3. Beteiligung an Planungsaktivitäten
4. Berichte über den Arbeitsfortschritt
5. Eine Bedienungsanweisung
6. Eine Design Spezifikation
7. Spezifizierte Testfälle

Nehmen wir weiter an, dass unser Senior Entwickler erfolgreich Informatik studierte und das er eine Vorliebe für objektorientierte Softwareentwicklung hat. Er ist ein erfahrener Entwickler, der schon mehrere schwierige Projekte gestemmt hat. Oft waren es seine brillanten Ideen und sein immenser Arbeitseinsatz – gerade vor Projektende – , mit denen er quasi in letzter Sekunde das Projekt „vom Eis“ holte. Mittlerweile gilt er in unserem Unternehmen als Koryphäe, wenn es um Transaktionsverarbeitung geht.

Unser Senior Entwickler, nennen wir ihn Malte, kommt in der Regel zwischen 9:30 und 10:00 Uhr ins Büro. Er liest seine E-Mails und prüft die Ergebnisse des nächtlichen Build-Laufs. Dann ist um 11:00 Uhr das Daily Scrum Meeting – im Allgemeinen kann Malte berichten, dass er seine Aufgaben im Griff hat und keine Probleme zu erwarten sind. Sein Projektleiter, Ludwig, bespricht mit ihm oft im Anschluss seine Aufgaben und priorisiert mit Malte die Themen der nächsten Tage. Auch berichtet Ludwig, welche Punkte von der Test- und Architekturabteilung anliegen und wie das Kunden-Feedback letzte Woche ausgefallen ist.

Ludwig sieht die Stärken von Malte in der Implementierung und beim Schätzen von Realisierungsaufwänden. Schwächen sieht er vor allem in der Motivation für das Erstellen der Dokumentation und in der Kommunikation mit anderen Bereichen unserer Firma. Hier versucht sich Ludwig stark einzubringen und ist überzeugt, dass Malte das zu schätzen weiß. Konflikten versucht Ludwig stets aus dem Weg zu gehen, denn er will Malte nicht mit unangenehmen Themen belasten.

Malte hat viele Freiheiten – er kann seine Gleitzeit relativ uneingeschränkt auslegen, bekommt immer die neueste Software und hat den besten Arbeitsplatz (Fenster mit Blick auf die Berge). Er ist sich durchaus bewusst, dass Ludwig ihm in vielen Dingen freie Hand lässt. Mit Begeisterung entwickelt Malte die Software und versucht ständig den Code zu optimieren. Bei den Planungs- und Berichtaktivitäten bringt er sich in dem Maße ein, wie Ludwig es einfordert. Die Dokumentation versucht Malte gerne an seine jüngeren Kollegen abzugeben oder er lässt es einfach liegen. Meist findet Ludwig dann eine Lösung, ohne dass Malte hier viel von seiner Implementierungszeit opfern muss.

Ein Konflikt

Die Hälfte der Projektzeit ist vorbei. Malte erzeugt täglich ein Build und setz sukzessive die geforderten Funktionalitäten um. Das Frontend hat Ludwig mit dem Kunden abgestimmt. Kleinere Änderungen werden von den Junior Entwicklern umgesetzt. Ansonsten testen diese die Builds von Malte und schreiben die Testfälle.

An einem Dienstagmorgen, gegen 10, beobachtet Ludwig wie Malte heftig mit den Junior Entwicklern streitet. Ludwig kann zwar nicht genau verstehen was gesprochen wird, aber die Aufregung im Raum ist nicht zu übersehen. Beim Daily Scrum eskaliert die Situation, als ein Junior Entwickler über einen Bug im Frontend berichtet, den er gestern gefixt hatte. Malte unterbricht den Kollegen. „An meinen Sourcen habt ihr nichts verloren! Ab jetzt werde ich Euch nur noch lesend freischalten. Wenn ihr was geändert haben wollt, dann nur über meinen Tisch.“ Eine ziemlich lange Diskussion setzt ein, denn die anderen Entwickler sehen das anders als Malte. Schlussendlich muss Ludwig einschreiten und alle zum Schweigen bringen – was ihm nur mit Mühe gelingt. Dann kommt auch noch das Thema Benutzerhandbuch auf, um das sich bisher keiner gekümmert hat. Malte in die Runde: „Bevor ihr meine Builds zum Scheitern bringt, macht euch besser bei der Doku nützlich.“ Und dann ging es hoch her. Auch wenn sich die Gemüter bis zum Mittag beruhigt hatten, die Stimmung im Team war erst einmal dahin – was besonders an der eher verschwiegenen Arbeitsweise zu erkennen war.

Die erste Analyse

Verlassen wir zunächst das Projektteam vom Ludwig und Malte, um die Situation zu analysieren. Sehen wir einmal auf das Szenario. Was konnte man unter anderen beobachten? Da war zunächst ein Projektleiter, der seinen Senior Entwickler Malte ziemlich stark steuert. Und dann Malte selbst, der sich in seinem Refugium „Implementierung“ eingerichtet hat. Malte ist die „graue Eminenz“ im Team und darauf bedacht, dass keiner in seinem Revier wildert – also beispielsweise seinen Code ändert. Es hat eine Art Besitzdenken Einzug gehalten. Malte identifiziert die Ergebnisse, die er erstellt hat, als sein Eigentum, was es zu verteidigen gilt. Andere Ergebnisse der Teamarbeit – wenn man in unserem Szenario überhaupt von Team sprechen kann – werden weniger umkämpft. Ganz im Gegenteil, die von Malte so ungeliebte Dokumentation bleibt eher liegen oder wird anderen Teamkollegen auferlegt.

Unter solchen Bedingungen spricht man wohl eher von sozialer Isolation. Gemeinsame Werte und Normen sind bei den Teammitgliedern nicht stark ausgeprägt. Es gibt eine klare Rangordnung unter den Kollegen und die Voraussetzungen für ein kollegial selbstverwaltetes Team sind kaum vorhanden. Wenn wir uns dann noch die Artefakte ansehen, die vom Team und allen voran den Entwicklern erwartet werden, erscheint die Solidarität doch eher tot als lebendig. Frei nach dem Motto: Jeder macht was er will, keiner was er soll und alle machen mit.

Werte und Normen die wir im ALM brauchen:

1. Das Projekt-Team fühlt sich gemeinschaftlich für die Ergebnisse verantwortlich
2. Die Teammitglieder kennen die Stärken und Schwächen der anderen und achten sich gegenseitig
3. Es wird offen und ehrlich im Projekt-Team kommuniziert
4. Alle Tätigkeiten und Gespräche mit Partnern werden vom Projekt-Team gesteuert und verantwortet
5. Es gibt eine Kultur des Lernens, bei der Fehler ein akzeptierter Weg sind, besser zu werden

Die Liste ist sicher nicht vollständig, aber wir erkennen, dass das Team von Ludwig und Malte noch einen langen Weg vor sich hat.

Wie geht es weiter?

Lesen Sie dazu meinen nächsten Beitrag. Dann werden wir unser Team einer Umorganisation unterziehen, die einige „Besitzstände“ durcheinander bringen wird. Ob das Team wohl zusammen findet? Wird es gelingen, Zusammenhalt in das Projekt-Team zu bringen? Bleiben Sie gespannt und geben Sie gerne hier Ihre Prognosen ab.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.