Autor: Daemonic Coder

Wo sind die ITler hin? Zu ChatGPT??

Daemonic Coder

„Aus Gründen“(tm) beschäftige ich mich gerade mit dem IT Stellenmarkt… War es vor ein paar Jahren noch ziemlich problemlos möglich, im Bereich IT, Transformation und Agilität offene Stellen zu finden, so ist dies derzeit etwas schwieriger. Und immer wieder liest man von Unternehmen, die große Mengen an Stellen abbauen.

Die aktuelle Welle an Stellenstreichungen im IT-Bereich wird oft mit einem einfachen Argument begründet: Künstliche Intelligenz übernimmt Aufgaben, also braucht es weniger IT-Fachkräfte. Klatr, warum irgendwelche Junior-Entwickler, wenn Chat GPT das doch auch gut kann, das Entwickeln. Klingt logisch – ist aber nur die halbe Wahrheit. Denn wer mehr IT in einem Unternehmen will, braucht in der Regel auch mehr IT-Expertise, nicht weniger.Von ChatGPT ausgespuckter Code ist oft nicht fehlerfrei und insbesondere nicht automatisch in der IT-Landschaft deployed.

Gleichzeitig ist es jedoch nicht von der Hand zu weisen, dass viele Unternehmen in den letzten Jahrzehnten massive Overhead-Strukturen aufgebaut haben, die nun auf den Prüfstand kommen.

AI ersetzt IT? Nicht so schnell.

Die Vorstellung, dass AI-gestützte Tools die Entwickler, Systemadministratoren oder Architekten ersetzen, ist verlockend – aber kurzsichtig. Automatisierung kann Prozesse effizienter machen, aber sie schafft auch neue Herausforderungen:

  • Mehr IT bedeutet mehr Komplexität: Systeme müssen integriert, gewartet und angepasst werden. Automatisierung nimmt Routineaufgaben ab, aber jemand muss die Werkzeuge implementieren und weiterentwickeln.
  • AI produziert keinen Wert von selbst: Code, den AI generiert, muss überprüft, getestet und gewartet werden. Und je mehr Unternehmen sich auf generative AI verlassen, desto wichtiger wird die menschliche Expertise, um Fehlentscheidungen oder ineffiziente Lösungen zu vermeiden.
  • Neue Technologien bringen neue Sicherheitsrisiken: Mit der steigenden Automatisierung wächst auch die Angriffsfläche für Cyberangriffe. Unternehmen, die IT automatisieren, müssen gleichzeitig in Sicherheit und Governance investieren. Und wie wohl man sich mit dem Datenschutz fühlt, davon möchte ich gar nicht erst anfangen.

Das eigentliche Problem: Overhead und „Bullshit Jobs“

Trotzdem ist es nicht falsch, dass viele Unternehmen aktuell aufgeblähte Strukturen abbauen. David Graeber beschreibt in seinem Buch Bullshit Jobs, wie viele Organisationen im Laufe der Zeit Stellen schaffen, die wenig bis gar keinen direkten Wert erzeugen – oft im Bereich Management, Controlling oder interner Prozesse.

IT-Teams sind oft von solchen Strukturen betroffen. Je größer ein Unternehmen wird, desto mehr Layer an Projektmanagement, Koordination und Verwaltung entstehen. Plötzlich gibt es mehr Meetings als Codezeilen, und Entwickler verbringen mehr Zeit mit Excel-Reports als mit der eigentlichen Softwareentwicklung. Ich selbst habe in den letzten Jahren sicher mehr Powerpoint-Folien erstellt als „echte“ Architekturen. Dass Unternehmen diese Strukturen nun in Frage stellen, ist nicht falsch, streng genommen sogar zu spät.

Der richtige Fokus: IT als Werttreiber, nicht als Kostenfaktor

Anstatt einfach nur IT-Stellen zu streichen, sollten Unternehmen sich fragen: Wie kann IT zum Wachstum beitragen? Der Fokus sollte nicht auf der Reduktion von IT-Mitarbeitern liegen, sondern auf der Beseitigung von bürokratischen Hürden, die die Arbeit der IT-Teams ineffizient machen.

Effiziente IT bedeutet:

  • Reduktion unnötiger administrativer Aufgaben
  • Klare Fokussierung auf wertstiftende Arbeit
  • Sinnvolle Nutzung von AI als Unterstützung, nicht als Ersatz

IT ist heute das Rückgrat fast aller Geschäftsmodelle. Wer hier vorschnell den Rotstift ansetzt, könnte langfristig eine Schwächung des Unternehmens riskieren – und genau das Gegenteil von dem erreichen, was man eigentlich will: Effizienz.

Scrum ist, wie Entwickler arbeiten – nicht die ganze Welt

Daemonic Coder

Ich mag Scrum. Naja, okay, das ist vielleicht nicht so eine riesige Überraschung, wenn man einen Blog schreibt, der sich mit Agilität beschäftigt. Trotzdem glaube ich, dass ich das betonen sollte, bevor ich mich in diesen Artikel stürze.

Scrum ist gefühlt überall. Wenn irgendwo von Agilität die Rede ist, ist es oft das erste und einzige Framework, das genannt und in Betracht gezogen wird – oft in der unsäglichen Schreibweise SCRUM. Aber es ist ein Framework, das aus der Softwareentwicklung kommt und sich für genau diesen Kontext bewährt hat. Doch anstatt es dort sinnvoll einzusetzen, wird es immer häufiger als generelle Methode für alles Mögliche verwendet – ob es passt oder nicht.

Scrum ist für Software gemacht

Scrum wurde entwickelt, um die Arbeit von Softwareteams zu organisieren. Iterative Entwicklung, inkrementelle Verbesserungen und enge Zusammenarbeit im Team – all das sind Prinzipien, die wunderbar in die Art und Weise passen, wie Software entsteht. In einem Umfeld, in dem Anforderungen sich schnell ändern, technische Herausforderungen komplex sind und ein funktionierendes Produkt nicht einfach im Voraus durchgeplant werden kann, entfaltet Scrum seine Stärken. Die Rollen, Artefakte und Events sind genau darauf abgestimmt.

Aber: Scrum ist keine Universallösung. Es ist kein Allheilmittel für jegliche Art von Arbeit. Trotzdem versuchen viele Unternehmen, es auch in Bereichen einzusetzen, in denen es schlicht nicht funktioniert und die Vorausssetzungen nicht gegeben sind. Dazu gehören:

  • Ein iterativer Arbeitsstil mit regelmäßigen, funktionierenden Zwischenergebnissen – einen Satelliten stückchenweise ins All zu schießen wäre unsinnig.
  • Ein autonomes, interdisziplinäres Team, das eigenverantwortlich Entscheidungen treffen kann – bitte wirklich ein kritischer Blick in die Organisation, ob das nicht nur Wunschdenken wäre.
  • Ein Umfeld, in dem sich Anforderungen häufig ändern und schnelle Anpassungen notwendig sind

Doch wie oft werden diese Bedingungen ignoriert? Ich habe Scrum bereits in Bereichen gesehen, in denen es einfach nicht passt: von Marketing-Teams über HR-Abteilungen bis hin zu strategischen Projekten in Unternehmen. Was passiert dann? Die Meetings werden abgehalten, weil sie im Scrum Guide stehen, Sprints werden erzwungen, obwohl es keine sinnvollen Inkremente gibt, und das Team kämpft gegen ein Framework, das nie für seine Arbeit gedacht war.

Agilität bedeutet Anpassungsfähigkeit. Das sollte auch für die Wahl der Arbeitsweise gelten. Nur weil Scrum ein bekanntes und bewährtes Framework ist, heißt das nicht, dass es für jede Art von Arbeit oder jedes Team geeignet ist. Statt Scrum reflexartig als „den agilen Standard“ zu betrachten, sollten Unternehmen sich die Zeit nehmen, die passende Methode für ihre spezifische Situation zu finden. Denn Agilität bedeutet nicht, einfach nur Scrum zu machen – sondern so zu arbeiten, dass es wirklich funktioniert.

Holokratie – Taylorismus 2.0?

Daemonic Coder

Winslow Taylor gilt als der Erfinder des „Scientific Management“ mit der Idee, die Arbeitsabläufe eines Unternehmens vollständig zu beschreiben und so „perfekte“ Abläufe schaffen zu können. Und er gilt heute beinahe schon als Feindbild der agilen Unternehmen, da seine Ideen als hierarchisch und starr wahrgenommen werden. Und zugegebenermaßen waren seine Ideen Grundlage für eine gewisse Dehumanisierung in der Arbeitswelt. Aber: Das ist meist gar nicht die hauptsächliche Kritik am Taylorismus aus Sicht Agiler Transformationscoaches. Diese merken eher an, dass es in der komplexen Arbeitswelt nicht möglich sei, eine exakte, immer gültige Arbeitsaufteilung vorzugeben. Softwareentwicklung beispielsweise funktioniert nicht „wie am Fließband“.

Dem stimme ich übrigens uneingeschränkt zu.

Um so mehr wundert mich der Zuspruch, den Holokratie oft erfährt. Ich möchte hier nicht Holokratie beschreiben, das ist sicher an anderer Stelle ausführlich genug geschehen, nur meine Kritik oder Verwunderung daran formulieren: Die Idee von Holokratie ist es, dass es ein „Betriebssystem“ ist, das eine Beschreibung „perfekter“ Abläufe hervorbringen kann. Sicher, im Unterschied zum Taylorismus wird diese Beschreibung kollaborativ und nicht vom „allwissenden Management“ erzeugt, aber nichts desto trotz ist das Ziel eine möglichst vollständige (wenn auch veränderliche) Beschreibung der Prozesse.

Für mich klingt daher Holokratie wie ein Taylorismus 2.0.

 

Entschieden entscheiden – egal wer da ist

Daemonic Coder

In „klassischen“ Organisationsstrukturen ist die Frage, wer entscheiden darf, oft recht eindeutig geregelt: Der Chef bestimmt. Und wenn es keine hierarchische Chef-Rolle gibt, dann oft eine fachliche Führung, die entscheidet und die Verantwortung für die Entscheidungen trägt oder zumindest tragen sollte.

Beim Wechsel hin zu einer agileren Organisation beobachte ich oft, dass Teams für sich einen Weg suchen, wie Entscheidungen im Team gemeinschaftlich getroffen werden können. Mehrere Methoden stehen dabei oft zur Diskussion:

  • Mehrheitsentscheid
  • Konsenzverfahren
  • Widerstandsmessung
  • Konsentverfahren

Sicher gibt es nicht die eine Methode, die immer und für alle am besten funktioniert. Aber ich möchte an dieser Stelle aus einem bestimmten Grund die Lanze für das Konsentverfahren brechen:

Gut abgestimmte Teams müssen beim Konsentverfahren keine Beschlussfähigkeit feststellen und sie sind jederzeit flexibel, Entscheidungen zu treffen.

Der erste Reflex vieler Teams für eine Entscheidungsfindung ist oft ein Mehrheitsentscheid. In der Diskussion wird dann aber schnell deutlich, dass zu besprechen ist, wie viele aus dem Team anwesend sein müssen, um eine Entscheidung überhaupt treffen zu können oder ob anstehende Entscheidungen gar im Vorfeld (Agenda) angekündigt werden müssen, um eine Beschlussfähigkeit zu haben. Meiner Meinung nach ist das bei einem Konsentverfahren gar nicht nötig.

Ein Konstentverfahren beschreibe ich so: Steht eine Entscheidung an, so können alle Teammitglieder entweder ihre Zustimmung ausdrücken (Daumen hoch), eine Entscheidung des Teams mittragen (Daumen seitlich) oder gegen die Entscheidung stimmen (Daumen runter). Letzteres ist aber nur mit einem „qualifizierten Einwand“ möglich, also einem Vorschlag, wie der Widerspruch aufgelöst werden kann. Ein solcher Einwand kann auch sein „das können wir nur unter Einbeziehung einer weiteren Person entscheiden“.

Ein Beispiel: Ein Team möchte über eine Änderung der Softwarearchitektur entscheiden, beispielsweise, ob bestimmte Funktionalitäten aus einem Monolithen herausgezogen und in Microservices migriert werden sollen. Bei der Entscheidung darüber kommt es zu einem Widerspruch mit der Begründung „Heute ist Sarah nicht da, die am meisten Erfahrung mit Microservices hat, wir sollten sie auf jeden Fall in die Entscheidung einbeziehen, wenn sie morgen wieder da ist.“

Der Vorteil dessen ist, dass man eine Entscheidung nicht von einem bestimmten Quorum abhängig macht, sondern von der Entscheidungskompetenz der Teammitglieder. Es würde in diesem Beispiel nichts bringen, wenn aus dem Team alle Frontend-Entwickler anwesend wären, die kaum Aussagen zu Microservices machen können.

Voraussetzung, damit dies funktioniert, ist allerdings eine gewisse Teamreife. Nur, wenn man die Fähigkeiten der anderen im Team einschätzen kann, ist ein solcher Widerspruch überhaupt nötig. Aber dann ist das Verfahren meiner Meinung nach besser geeignet, als ein Quorum, das eventuell am Ziel vorbei geht oder eine Verpflichtung zur Vorveröffentlichung, was die Flexibilität sehr einschränken kann.

Kurz gesagt: Nutzt das Konsentverfahren ohne Quorum. Erst, wenn das nicht greift, sollten meiner Meinung nach andere Entscheidungsverfahren genutzt werden.

Was redet der da? Wenn Juristen mit Coaches und Informatikern zusammentreffen

Daemonic Coder

Vor einer ganzen Weile bereits durfte ich (ja, sowas mache ich gerne) eine Abschlussarbeit eines Kollegen und Freundes zur Korrektur lesen. Es handelte sich um eine Arbeit im Fach Wirtschaftsinformatik. Allerdings hatte der Autor vorher einige Semester Jura studiert, was dazu führte, dass ich über einige Formulierungen in der Arbeit sehr stolperte. So wurde im Text ab und an darauf hingewiesen, dass manches „grundsätzlich anders“ gemacht werden solle, als der gewählte Umsetzungsweg, außerdem wurde an der ein oder anderen Stelle eine „billige“ Umsetzung gewählt.

Nach Rücksprache mit meinem Kollegen wurde mir klar, dass er die Begriffe einfach anders verstand, als ich es tat. „Billig“ war für ihn nicht auf die Kosten der Umsetzung bezogen, schon gar nicht war das abwertend „billig“, sondern „angemessen“. Und wenn ein Weg, der „grundsätzlich“ gegangen werden sollte, nicht gegangen wurde, so wich man nur (mit guten Gründen) vom Grundsatz ab. Wir hatten von den verwendeten Begriffen auf Grund unserer unterschiedlichen Ausbildungen ein anderen Verständnis.

Sprachbarrieren existieren nicht nur hin zu Fremdsprachen, sondern auch innerhalb einer Sprache, dort sind sie aber für die Beteiligten oft schwerer zu erkennen.

Wenn sich ein Unternehmen transformiert, so brechen bisherige „Sprachgruppen“ unter Umständen auch auf. Sei es innerhalb eines Teams, weil es sich cross-funktional aufstellt, oder sei es, weil klassische Kommunikationswege durch direktere Kommunikation ersetzt werden. Auf einmal muss der Informatiker mit dem Juristen reden. Erwähnt dann der Informatiker eine Regel als „grundsätzlich“, so ist es etwas, wovon er wohl nicht abweichen will. Alleine die Aufführung des „grundsätzlichen“ erweckt im Juristen die Erwartung, dass im Folgenden auf die Ausnahme eingegangen wird und für einen Coach mögen die „Grundsätze“ die Basis sein, auf der weiter detailliert werden sollte.

Und mein Lieblingsbeispiel der „ausbildungsinduzierten Sprachbarriere“: Wenn ein Psychologe von „5 plus minus 2“ als idealer Teamgröße spricht, so ist nicht der vom Mathematiker verstandene feste Zahlenraum gemeint, sondern „Mittelwert 5, Standardabweichung 2“.

Mein Appell: Werdet euch der verdeckten Sprachbarrieren bewusst, drückt aber niemandem „eure“ Definition auf. Fragt, was das Gegenüber meint und nehmt am besten diese Definition — grundsätzlich. 😉

 

Nachtrag:

Zum Juristendeutsch habe ich noch einen empfehlenswerten Artikel bei leemata gefunden:
https://www.leemeta-uebersetzungen.de/blog/interessantes/deutsch-der-rechtswissenschaft

 

Riesige Risiken und Erwartungen des Managements

Daemonic Coder

Risikomanagement — einer der zentralen Prozesse (nicht nur) im Projektmanagement, eigentlich in jedem (nicht nur) wirtschaftlichen Handeln. Eigentlich sollt man daher meinen, dass Risikomanagement sehr verstanden sein sollte. Leider beobachte ich oft, dass das nur eingeschränkt der Fall ist, spätestens, wenn vom Management die Aufforderung kommt, man solle „Risiken aktiv managen“, so stolpere ich mental oft und frage mich, ob hier alle Beteiligten das gleiche Verständnis haben.

Ich möchte hier nicht zu sehr auf das „normale“ Risikomanagement mit Sammeln, bewerten und Überwachen der Risiken eingehen, denn das kann ganz leicht in geduldigen Excel-Listen oder Tools gemacht werden (und an anderer Stelle nachgelesen werden), ohne dass man sich wirklich über die Implikationen und Erwartungen einig wird. Meine These: Wenn „Manager“ sagen, man solle Risiken aktiv Managen, so scheinen sie oft zu meinen „Sorgt dafür, dass die Risiken gar nicht eintreten.“ Der Unterton: Wir sind uns der Risiken bewusst und akzeptieren diese, liebe Mitarbeiter, aber sorgt dafür, dass nichts schief geht.

Mal einen Schritt zurück, wie kann man mit Risiken umgehen? Spontan fallen mir folgende Möglichkeiten ein:

  1. Risiko akzeptieren
  2. Risiko mitigieren (also abtreten, bspw. durch eine Versicherung)
  3. Eintrittswahrscheinlichkeit senken
  4. Erwarteten Schaden senken

„Risiken aktiv managen“ im Management-Sprech ist also oft Möglichkeit 3, dabei sogar oft ein Extremfall davon, nämlich das Reduzieren der Eintrittswahrscheinlichkeit auf 0. Oft hieße das aber, ein Projekt oder ein Vorhaben gar nicht erst durchzuführen. Andererseits möchte das Management ja, dass die gewinnbringenden Projekte durchgeführt werden, am besten, ohne Zusatzkosten. Das wäre mit Option 1 möglich. Daher der widersprüchliche Wunsch, das Risiko zu akzeptieren und gleichzeitig aktiv managen. In der Realität werden Risiken akzeptiert, wenn der Schaden eintritt will es aber niemand gewesen sein.

Übrigens ist in einem agilen Vorgehen wie Scrum meiner Meinung nach bereits eine ganze Menge Risikomanagement fest eingebaut – vielleicht ist dies sogar der zentrale Vorteil, den Scrum gegenüber einem klassischen Projektvorgehen hat.