Montag, 12. November 2018

Management 3.0

FS
Bild: Pixabay / Monfocus - CC0 1.0
Einer der kleineren, trotzdem aber immer erfolgreicher werdenden agilen Ansätze ist das so genannte Management 3.0. Was das ist und wo es herkommt wäre eine Geschichte für sich, an dieser Stelle soll es aber zuerst nur um den Namen gehen. Schon hinter ihm versteckt sich nämlich ein für das Verständnis des Frameworks zentraler Punkt. Er definiert nicht nur was Management 3.0 ist, sondern auch was es nicht ist.

Wie man sich denken kann ist es eine Differenzierung von anderen Management-Praktiken. Dabei setzt es sich zuerst ab von der "herkömmlichen" Art Menschen und Unternehmen zu führen. In diesem Kontext wird diese Management 1.0 genannt und ist geprägt durch Hierarchiedenken, Herrschaftswissen, Command & Control und ähnlichen problematischen Vorgehensweisen.

Warum diese Vorgehensweisen problematisch sind ist aus einer agilen Perspektive klar: Hierarchien verhindern, dass sich die ausführende Ebene verantwortlich fühlt (und benimmt), Herrschaftswissen hält die Mitarbeiter dumm und führt so zu unklugen Entscheidungen, Command und Control verlagert den Ziel des Arbeitens weg von der Sinnerfüllung und hin zur Vorgabenerfüllung. So weit, so bekannt.

Darüber hinaus wird davon ausgegangen, dass es noch eine zweite Art von Management Praktiken gibt, die zwar in ihren Zielen etwas weiter ist, diese aber mit den bisher üblichen Methoden umsetzen will und aus diesen Gründen zwangsläufig daran scheitert. Letztendlich ist er damit nur der bessere unter den schlechten Ansätzen. Für ihn gibt es den Namen Management 2.0.

In der Realität sieht er so aus, dass z.B. Selbstorganisation angestebt wird, die aber dadurch umgesetzt werden soll, dass die dazu (angeblich) nötigen Strukturen den Mitarbeitern ungefragt übergestülpt werden. Klassiker in diesem Bereich sind die von oben angeordneten Einführungen von SAFe oder (Pseudo-)Spotify, was meistens nichts anderes ist als die Ersetzung alter Hierarchien und Kommandostrukturen durch neue.

Auch der Versuch eine neue Unternehmenskultur von oben vorgegeben und zentral gesteuert einzuführen ist eine Ausprägung von Management 2.0. Alleine die Idee, dass man Kultur durch Anordnung verändern könnte ist ein Missverständnis. Wenn dann noch paternalistische Aspekte dazukommen ("die müssen zu ihrem Glück gezwungen werden", "die werden noch verstehen warum das gut ist", etc.) ist kaum noch ein Unterschied zu Management 1.0 erkennbar. (siehe auch: agiler Marxismus und Leninismus)

Management 3.0 ist dagegen der Versuch alle Ebenen in Veränderungen und Entscheidungen einzubeziehen, und zwar nicht nur als Betroffene sondern als Beteiligte. Um das zu erreichen gibt es eine Vielzahl von Praktiken und Techniken die in ihrer Gesamtheit das Management 3.0-Framework ausmachen (z.B. Merit Money und Delegation Poker). Ihnen allen ist gemeinsam, dass sie nicht angeordnet sondern gemeinsam durchgeführt werden sollen.

Mit der Benennung 3.0 erfolgt damit nicht nur eine Differenzierung zum "traditionellen" Management sondern ganz wesentlich auch zu denen, die zwar eigentlich das Richtige wollen, die Transition aber durch Bevormundung der Mitarbeiter und undifferenziertes Copy & Paste anderswo erfolgreicher Methoden umsetzen wollen. Ihnen die Management-Typen 1.0, 2.0 und 3.0 zu erklären kann schmerzhaft aber hilfreich sein und ist daher zu empfehlen.

Freitag, 9. November 2018

Struktur, die aus Post-Its entsteht

FS
Alberto Brandolini hat völlig recht wenn er sagt, dass das Identfizieren und Modellieren von Strukturen und Prozessen am besten mit bunten Zetteln auf einer grossen Wand stattfinden kann. Seine Art das zu tun nennt er Event Storming. Selbst wenn nicht alles davon in jeden Kontext passt, inspirieren lassen kann man sich durch seine Ideen auf jeden Fall.


Dienstag, 6. November 2018

Prozessverbesserung alleine ist keine Lösung

FS
Bild: Wikimedia Commons / Johannes Martin Conrad - CC BY 3.0
Kann sich noch jemand an den Spruch "pünktlich wie die Bundesbahn" erinnern? Lange ist es her, dass das der Normalfall war. Angesichts von Verspätungsquoten von 30 % allein im Fernverkehr versucht die Bahn AG gerade gegenzusteuern. Mit dem so genannten Deutschlandtakt sollen Züge besser aufeinander abgestimmt werden, mit weiteren Massnahmen soll das Ein- und Austeigen schneller und effizienter gemacht werden. Das Ziel: mehr Pünktlichkeit.

Um die Erwartungen von Anfang an zu dämpfen: pünktlich werden die Züge auf diesem Weg nicht werden. Ein bisschen werden die Verspätungen mit Sicherheit zurückgehen, zum grössten Teil aber bestehenbleiben. Denn so gut die Prozessverbesserungen auch sein mögen, dass Hauptproblem werden sie nicht lösen können - die veralteten und immer wieder ausfallenden technischen Systeme.

Man kennt es aus den Durchsagen am Bahnsteig. Weichenstörungen unterbrechen die Fahrt, Signalstörungen verhindern die Einfahrt in die Bahnhöfe, defekte Oberleitungen bringen Züge zum Stillstand, Waggons mit ausgefallenen Klimaanlagen müssen ausgetauscht werden, defekte Schranken dürfen nur im Schrittempo passiert werden - solange das alles nicht in den Griff bekommen wird kann auch der beste Prozess nicht helfen.

Die Parallelen zu IT-Projekten und -Abteilungen sind offensichtlich. Häufig wird die Einführung von Scrum oder Kanban mit grossen Hoffnungen verbunden, die dann an der veralteten Technik und Systemlandschaft scheitern. Computer haben zuwenig Diskspace, Test- und Entwicklungsumgebungen müssen manuell eingerichtet werden, Telefonkabel aus den 70er Jahren verlangsamen die Datenübertragung, etc. etc.

Wie beim Beispiel der Bahn heisst das nicht, dass Prozessverbesserungen nichts bringen. Starre Planungen und Bürokratie zu beseitigen ist immer eine Verbesserung. Ohne die begleitenden Modernisierungen von Software und Hardware wird ihre Wirksamkeit aber deutlich eingeschränkt bleiben. Erst durch eine Kombination dieser Faktoren kann es zum befreienden grossen Sprung nach vorne kommen.

Diese Themen anzusprechen kann in vielen Unternehmen zum Offenbarungseid führen: Agilität sei als Ansatz gewählt worden weil davon ausgegangen wurde, dass die Umstellung von Meetings und Rollen mit geringem Aufwand möglich ist, für darüber hinausgehende Modernisierung wäre aber kein Geld da. Das würde doch auch bestimmt ohne gehen, oder? Derartige Aussagen sind häufiger als man denken sollte.

Die Antwort darauf kann nur eine sein: Das kann man zwar so machen, aber dann sollte man seine Erwartungshaltungen deutlich herunterfahren.

Samstag, 3. November 2018

Wie technikfern darf ein Scrum Master oder Agile Coach sein? (II)

FS
Bild: Pexels / Tim Gouw - CC0 1.0
Die agile Welt ist ein Dorf. Sobald man einige Scrum- oder Kanban-Projekte ausserhalb der IT gemacht hat wird man schnell zum gefragten Ansprechpartner zu diesem Thema. Der Grundtenor klingt dabei immer ähnlich: "Ich interessiere mich ja sehr für Agilität, Scrum Master oder Agile Coach wäre was für mich. IT ist aber nicht so mein Ding. Wie finde denn ich Jobs in anderen Bereichen?" Nun ja.

Es ist nicht so als würde es diese Jobs nicht geben (zwar nicht viele, aber es gibt sie). Ich habe bereits Teams coachen dürfen die mit Scrum oder Kanban im Vertrieb, in der Hardwarefertigung, im Kundenservice und im Change Management gearbeitet haben, dazu kommen immer mehr Beispiele aus anderen Bereichen, zum Beispiel gibt es in meiner Heimatstadt Bonn sogar Scrum im Schulunterricht.

Das letzte dieser Beispiele zeigt aber auch direkt das erste Problem auf: selbst wenn manche Anwendungsgebiete IT-fern sind, einfach zugänglich sind sie aber trotzdem nicht unbedingt. Es darf eben nicht jeder an einer Schule unterrichten, dafür muss man vorher an einer Universität gewesen sein und Lehramt studiert haben. Auch in anderen Fällen stösst man schnell an Grenzen formaler Art, die nicht einfach zu überwinden sind.

Nun engt sich damit die Zahl in Frage kommender Jobs zwar weiter ein, aber es gibt sie, oder? Die Antwort: ja, aber. Sie existieren natürlich, in sehr vielen Fällen allerdings nur temporär. Agilität in Service- oder Hardware-Bereichen findet häufig da statt, wo Innovationsarbeit geleistet wird. Für Experimente, Prototypen und MVPs lohnt sich agiles Arbeiten, sobald die Serienfertigung oder -durchführung beginnt eher nicht mehr.

Scrum Master- oder Agile Coach-Stellen sind in solchen Kontexten nur zeitweise nötig. Derartige nicht-IT-Projekte leihen sich eine solche Person daher in der Regel vorübergehend aus, und zwar von da wo es sie bereits gibt - eben aus der IT. Die Alternative, das Vorhalten eines permanenten Scrum Master- oder Coach-Pools, würde eine Nachfrage voraussetzen die es in den meisten Firmen nicht gibt.

Ist die Suche nach einer Position ausserhalb der IT also völlig hoffnungslos? Das zwar nicht, realistisch betrachtet ist die Wahrscheinlichkeit einen zu finden aber sehr gering, zumindest wenn es eine langfristige Beschäftigung sein soll. Was am ehesten sein kann ist, dass sich eine temporäre Stelle finden lässt, die man mit etwas Glück besetzen kann. Es fragt sich nur - was passiert wenn dieses Projekt vorbei ist?

Die eine Möglichkeit wäre das Entlanghangeln von einer temporären Stelle zur nächsten. Nicht unmöglich aber sehr schwierig - so viele derartige Jobs gibt es auch nicht. Die andere Möglichkeit wäre, eine Beschäftigung im agilen nicht-IT-Bereich als Vorstufe für einen Einstieg in die IT zu benutzen. Aufgrund des Fachkräftemangels ist das nicht einmal unrealistisch, allerdings kommt man dann an der Beschäftigung mit der Technik nicht mehr vorbei. Dieser Umstände sollte man sich bewusst sein.
Powered by Blogger.