Manifest für Führungskräfte – Eine Diskussion

Heiko hat ein Manifest für Führungskräfte veröffentlicht:

Die Meinung unserer Mitarbeiter ist uns wichtiger als unsere Eigene

Anderen zuzuhören ist uns wichtiger als uns selbst reden zu hören

Die Menschen sind uns wichtiger als Prozesse und Strukturen

Die Entwicklung unserer Mitarbeiter ist uns wichtiger als unsere Eigene

Zusammenarbeit ist uns wichtiger als organisatorische Grenzen

via Scrum@Work.

Für mich greift dieses Manifest zu kurz, auch wenn Heiko einige wichtige Punkte heraus gearbeitetet hat.

Als Führungskraft ist man immer wieder in Situationen, in denen schnell wichtige Entscheidungen getroffen werden müssen. Kurz, hier heißt es, sich selbst zu vertrauen und für die eigene Entscheidung die volle Verantwortung zu übernehmen. Es hilft auch nicht, Verantwortung an eine Gruppe zu deligieren oder gar ein neues Grüpplein für die Entscheidungsfindung zu bilden. Zudem muss eine Führungskraft auch führen können, d.h. der Gruppe der Mitarbeiter vermitteln können, was das Ziel des gemeinsamen Tuns ist und letztendich muss die Führungskraft den Mitarbeitern ermöglichen das Ziel zu erreichen. Den Weg freiräumen und den Mitarbeitern die Freiräume verschaffen, damit diese erfolgreich arbeiten können. Hierfür muss meistens “nach oben” kommuniziert werden und auch “nach oben” gekämpft werden. Freiräume bekommt man nicht, diese muss man sich erarbeiten.

Die Meinung unserer Mitarbeiter ist uns wichtiger als unsere Eigene

Die Meinung von Mitarbeiter muss Führungskräften wichtig sein, d.h. nicht, dass die Führungskraft und Mitarbeiter immer gleicher Meinung sein müssen. Es ist beispielsweise stets kritisch zu hinterfragen, weshalb Mitarbeiter eine bestimmte Meinung haben. Welchen Wissensstand, welche Ausbildung und welche Erfahrungen haben die Mitarbeiter. Warum bin ich als Führungskraft anderer Meinung? Es gibt viele Situationen, in denen Führungskräfte unpopuläre Entscheidungen treffen müssen, d.h. die Meinungen von Führungskraft und Mitarbeitern sind dann unterschiedlich. Wenn die Meinung von Chef und Mitarbeitern jedoch grundsätzlich gegensätzlich sind, dann stimmt etwas nicht und das Verhältnis Mitarbeiter <-> Führungskraft wird nicht gut funktionieren.

Anderen zuzuhören ist uns wichtiger als uns selbst reden zu hören

Richtig. Als Vorgesetzter muss die Führungskraft jedoch auch in der Lage sein, in schwierigen Zeiten die Führung zu übernehmen. Das Management darf dann nicht stumm bleiben, sondern muss eine aktive Rolle einnehmen und Ziele sowie Rahmenbedingungen kommunizieren.  Grundsätzlich ist allerdings das aktive Zuhören eine sehr wichtige Fähigkeit von Führungskräften. Merke: Mitarbeiter können wichtige Berater ihrer Führungskräfte sein – falls der Vorgesetzte daran Interesse hat (er sollte). Wie bei allen Beratern, können diese jedoch nicht die Entscheidung für den Beratenden übernehmen.

Die Menschen sind uns wichtiger als Prozesse und Strukturen

Menschen sind immer das Wichtigste. Andererseits benötigt eine Organisation, d.h. eine Gruppe von Menschen, eben auch Prozesse und Strukturen. Wenn diese schlecht für die Menschen ist, dann ist es an der Führungskraft zu handeln. Das ist eine weitere  zentrale Aufgabe der Führungskraft.

Die Entwicklung unserer Mitarbeiter ist uns wichtiger als unsere Eigene

Vielleicht besser: Unsere eigene Entwicklung darf nicht auf Kosten unserer Mitarbeiter geschehen. Die Entwicklung der Organisation ist wichtiger als die Entwicklung einzelner Individuen. Weiterentwicklung muss für alle möglich sein. Kurz: Entwickle Deine Mitarbeiter weiter! Deine Mitarbeiter dürfen Dich auch überholen!

Zusammenarbeit ist uns wichtiger als organisatorische Grenzen

Richtig. Zusammenarbeit muss aber auch von allen Parteien gewollt sein, lokale Optimierung muss überwunden werden. Blockadehaltung muss sanktioniert werden. Die Organisation muss sich weiterentwickeln.

Done Done – Ohne Ausreden

Falls ich ein Unternehmen gründen sollte, dann werde ich alles tun, um die Softwareentwicklung auf maximale Produktivität auszurichten. Keine Ausreden, keine faulen Kompromisse. No Muda, kein Wischi-Waschi. Es muss mit jeder Aktivität Werte für das Unternehmen erzeugt werden. Ganz klar: Fokussierung aller Kräfte auf die wichtigen Themen, Reduktion von Komplexität durch einfache Grundregeln und Automatisierung – und vor allem Investitionen in das Team als zentrales Organ der Werterstellung. Alles in Einklang mit den agilen Werte / Scrum Werte (Offenheit, Mut, Respekt und Fokussierung, ..).

Simon hat weitere wichtige Punkte recht gut in seinem Posting “‘No excuses’ done done” beschrieben. Nicht bei jedem Punkt bin ich 100% bei ihm, allerdings sehe ich bei jedem Punkt die positiven Aspekte.

Ein sehr kontroverse Punkt dürfte beispielsweise sein, dass das Team für alle Umgebungen verantwortlich ist:

Continuous ‘environmenting’ – Team administers and supports all its environments

  • Stops team shipping crap to production
  • Team develops expertise in how product runs
  • Freedom to innovate in the ‘system space’ to meet business needs
  • Monitoring and alerting with Nagios and Munin

vgl. Präsentation mit weiteren Details – lesenswert

Sehr wichtig ist folgender Hinweis:

This stuff is as hard or as easy as you want to make it. It’s not enough to be doing the technical practices and it’s not enough to be living the values and principles. You gotta do it all and more, at the same time, learning all the while. It takes courage, willpower and zeal. And, dare I say, you gotta know what you’re doing. There really are no excuses. Ultimately, for me, it comes down to having the right people, creating the right environment and working with the right clients.

Das ist verdammt richtig.

SLM: Ein paar Gedanken zu Scrum

In der typischen Interpretation der Scrum-Methodik ist die Rolle eines Projektmanagers nicht mehr vorgesehen. Die fachliche Projektleitung obliegt dem Product Owner, die technischen Entscheidungen werden durch das Team getroffen. Der Scrum Master sorgt für Einhaltung der Regeln, coacht das Team (und den Product Owner) und kümmert sich um Blocker/Hindernisse.

Für mich stellen sich hierbei zwei Fragestellungen bei der organisatorischen Restrukturierung:

  • Wie können mehrere Projekte in einem Team bearbeitet werden?
  • Was geschieht mit der Linienorganisation?
  • Scrum und Architektur?

Mehrere Projekte pro Team
Im „ein-Projekte-Scrum“ gibt es typischerweise den klassischen Projektmanager nicht mehr. Wenn jedoch mehrere Projekte in einem Team bearbeitet werden sollen, so hat ein PM wieder eine gewisse Berechtigung. Er stimmt sich mit dem PO des Team ab, damit der PO die Prioritäten richtig setzen kann. Er muss auch bei Rückfragen des Teams verfügbar sein. Die Hauptaufgabe des PM ist in dieser Konstellation jedoch die Kommunikation mit dem Kunden und die Einlastung von Aufgaben (Stories) in verschiedene Scrum-Teams. Die Zusammenarbeit mit verschiedenen Scrum-Teams wird gerade in komplexen Projekten nötig, in denen viele unterschiedliche Aufgaben anfallen und unterschiedlichste Experten (gibt es ja laut reinem Scrum in dieser Form auch nicht) benötigt werden.

Kunde > PM > PO > Team

Zu kritisieren sind hier die vielen Zwischenstation vom Kunden zum Team. Im Rahmen von Rückfragen muss es daher immer gestattet sein, dass das Team direkt mit dem Kunden redet, um Unklarheiten zu beseitigen. Wenn möglich sollte hierbei PM und PO involviert sein.

Linienorganisation und Vorgesetzte
Ich beobachte, wie die Linienvorgesetzten zunehmen als Scrum Master agieren. Je nach Firmenkultur und Persönlichkeit des SM kann dies jedoch problematisch werden – genau dann, wenn der SM nicht mehr coacht sondern Anweisungen erteilt. Grundsätzlich sollte über eine Vereinfachung der Linienorganisation nachgedacht werden, d.h. kleinere Abteilungen könnten zusammen gelegt werden, da viele Aufgaben des klassischen Vorgesetzten zurück an das Team delegiert werden und weil Hindernisse durch Scrum Master beseitigt werden sollten. Was bleibt ist die reine Personal- und Budgetverwaltung.

Scrum und Architektur
Laut Scrum soll das Team alle Entscheidungen hinsichtlich Umsetzung treffen. Es kommt jedoch relativ häufig vor, dass das Team nicht zu allen Themen die benötigte Expertise besitzt. In diesem Fall muss darauf geachtet werden, dass das Team mit Experten zusammen arbeitet und somit ganz bewusst externe Hilfe in Anspruch nimmt. Dies muss das Team auch rechtzeitig kommunizieren. In anderen Fällen, dominiert ein einzelnes Team-Mitglied das Team in wichtigen Fragestellungen. Da das ganze Team jedoch für den Erfolg einer Aufgabe verantwortlich ist, muss sichergestellt werden, dass alle Team-Mitglieder ausreichende Kenntnisse haben um eine Alternative richtig bewerten zu können. Sollte ein Mitglieds des Teams zu dominant werden, dann muss der Scrum Master eingreifen.

Noch eine Einführung in Scrum
So, und jetzt mal wieder ein Video zur Einführung in Scrum (für alle die immer noch nicht genug haben):