Kategorie: Methodisches

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.

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

 

Warum schätzen wir das Schätzen so?

Daemonic Coder

Ich hatte kürzlich die Gelegenheit, mich mit einem Kollegen auszutauschen, der neuerdings erstmalig in einem größeren agilen Projekt arbeitet. Er berichtete mir von einigen Schwierigkeiten im Projekt, ein interessanter „Kristallationspunkt“ dieser Probleme zeigte sich im Thema „Schätzungen“ und wie diese im Team angegangen werden.

Zunächst ein paar Infos zum Hintergrund: Mein Kollege hat viel Erfahrung mit „klassischen“ Projekten, in denen er beteiligt und als (Teil-)Projektleiter eingesetzt war, von den Projekten waren auch viele erfolgreich. Er ist jetzt als technischer Berater in einem groß skalierten Scrum-Projekt, das für seinen Auftraggeber auch eine der ersten Berührungen mit agilem Vorgehen ist. Dementsprechend gibt es in dem Projekt und im Umfeld des Projektes eine bunte Mischung aus dem Wunsch, alles „richtig“ und „by the book“ zu machen und Erwartungen und Gewohnheiten, die sich noch sehr an dem bisherigen Vorgehen aurichten.

Eines der Rituale, das dort eingeführt wurde, ist auch das Planning Poker, mit dem den Sprint-Aufgaben Story Points gegeben werden. Daran störte sich nun mein Kollege sehr – von der Frage, warum man denn nun auf einmal Komplexität statt Aufwand schätzen sollte bis hin zu dem zähen Vorgehen, da man in Unkenntnis des Aufgabeninhaltes Zahlen „raten“ müsse.

Interessant war für uns im Gespräch darüber, dass sich einige Dysfunktionalitäten des Vorgehens genau an diesem Punkt heraus kristalisierten.

Der offensichtlichste Punkt ist der, dass es in dem Team aktuell kaum Teamarbeit gibt – im Endeffekt hat jedes Gruppenmitglied seine oder ihre Aufgaben und arbeitet diese innerhalb des Sprints ab, man kann kaum anderen helfen, da jeder ein Spezialgebiet bearbeitet. Das macht die Schätzrunden schwierig, da jeweils immer nur ein Teammitglied eine Aussage zur Komplexität machen kann, während die anderen versuchen zu „erraten“, was diese Person wohl schätzen wird.

Die eigentlichen Probleme im Team zeigen sich aber, wenn man beginnt zu hinterfragen, warum überhaupt Schätzungen gemacht werden. Wenn ja ohnehin jeder seine Aufgaben hat, wird die Schätzung dann benötigt um zu wissen, ob die Aufgaben in den Sprint passen? Soll mit dem Schätzen sichergestellt werden, dass alle im Team das gleiche Verständnis der Aufgabe haben?

Leider war die Antwort, dass das Schätzen benötigt werde, da das Projektcontrolling damit die Leistungsfähigkeit des Teams messen und überprüfen wolle. Darin sehe ich ein grundsätzliches Problem, das ich hier schonmal angesprochen habe, nämlich, dass ein Indikator zu einem (zumindest indirekten) Ziel erklärt wird. Schließlich soll sich – so die Erwartung des Controllings – der Output des Teams ja verbessern. Wenn das erwartet wird, so sorgt dies bestenfalls zu einem Drift der Schätzungen nach oben. Doch selbst, wenn das nicht der Fall wäre: Die Schätzung der Komplexität (meinetwegen auch des Aufwandes) der Aufgaben ist für diese Fragestellung eine absolut unbrauchbare Schätzgröße! Damit wird bestenfalls der konstante (oder steigende) Mittelabfluss sichergestellt, das sagt absolut nichts darüber aus, wie gut der Output des Teams ist! Dann sollte besser der Product Owner den Business Value der Features schätzen. (Und ja, auch da würde sich sicherlich die Schätzung verändern, wenn ich anfange, das zum Ziel zu erklären.)

Es gibt meiner Meinung nach einige Gründe, warum ein Schätzen durch ein Team sinnvoll sein kann. Beispielsweise, damit das Team weiß, wie viel Komplexität es im Sprint umsetzen kann. Hier kamen wir übrigens auf die Diskussion, warum dann nicht gleich Aufwand geschätzt werden sollte. Meiner Meinung nach deswegen, weil die Komplexität eine Einigung erlaubt, auch wenn die Skills im Team unterschiedlich verteilt sind. Es mag sein, dass ich für die Implementierung eines Features 5 Tage brauche, wenn ich mich in der Technologie nicht auskenne, eine erfahrenere Entwicklerin benötigt eventuell nur 2 Tage. So könnten wir uns nie auf einen Aufwand einigen, wohl aber darauf, dass eine CRUD-Applikation nicht allzu komplex wäre. Zudem kann ich mit der Schätzung von Komplexität auch belegen, dass zumindest ein ähnliches Verständnis für das Feature existiert. Nicht zuletzt habe ich damit einen Indikator, dass ein Team eine bestimmte Velocity hat und diese auch besser werden kann.

Das „Standardziel“ ist es, dass der PO mit den Schätzergebnissen eine Vorstellung davon hat, welche Features in einem längeren Zeitraum schaffen kann, diese Schätzungen helfen bei einer langfristigen Planung. Damit diese Schätzungen allerdings eine Aussagekraft haben, müssen eine ganze Reihe von Voraussetzungen erfüllt sein: Das Team muss relativ stabil sein, um seine Velocity kennen und halten zu können; die Schätzgrundlage muss stabil bleiben können, es darf also nicht durch falsche Zielvorgaben eine Veränderung der Schätzbasis belohnt werden; das Entwicklungsziel muss bekannt genug sein, um zukünftige Features sinnvoll und stabil beschreiben (und in der Komplexität kennen) zu können.

Kurz gesagt, Schätzen ist kein Selbstzweck. Bevor man eine Schätzmethode auswählt oder anwendet, sollte das Ziel der Schätzung klar sein, was in der Realität leider erstaunlich selten der Fall ist.

Feedback und Feedback-Mythen

Daemonic Coder

Feedback sollte kein „Vorwurf“ sein, so liest man oft. Meist wird in diesem Kontext folgendes www-Vorgehen beim Feedback vorgeschlagen:

  1. Wahrnehmung – Was habe ich an Verhalten beobachtet?
  2. Wirkung – Welche Wirkung hat dies auf mich?
  3. Wunsch – Was wünsche ich mir vom Gegenüber.

Damit, so die Idee, sei man mit dem Feedback „bei sich“ und würde nicht sein Gegenüber angreifen.

Ich halte von diesem Vorgehen nichts. Selbst, wenn man es „richtig“ macht, was auch oft genug nicht vorkommt. Ein Beispiel:

„Ich beobachte, dass Du zu unseren Dailies immer 5 Minuten zu spät bist. Das wirkt auf mich, als würdest Du meine Zeit nicht schätzen. Ich wünsche mir, dass Du in Zukunft pünktlich bis.“

Obiges Beispiel entspricht sogar halbwegs dem www-Schema, allerdings gibt es einen großen Fehler: Der Wunsch bezieht sich auf das beobachtete Verhalten, nicht auf die Wirkung. Wenn ich mein Feedback so verpacke, dann hat die „Wirkung“ einzig den Zweck, ein weiterer Vorwurf und eine „Waffe“ zu sein. Davon abgesehen hat das Gegenüber keine „Handlungsoptionen“. Zu guter letzt ist da das kleine Wörtchen „immer“ in der Beobachtung, das immer veralgemeinert und nie richtig ist. 😉 Nächster Versuch:

„Ich beobachte, dass Du zu unseren Dailies bisher 5 Minuten zu spät gekommen bist. Das wirkt auf mich, als würdest Du meine Zeit nicht schätzen. Ich wünsche mir, dass ich das Gefühl habe, dass Du meine Zeit in den Meetings wertschätzt.“

Das ist schon etwas besser. Zumindest hat der Angesprochene nun Optionen. Er könnte vorschlagen, das Meeting später anzusetzen, da er zur bisherigen Zeit gar nicht kann. In der ersten Variante hatte er diese Möglichkeit nicht, da der Wunsch schon fast zu spezifisch war.

Noch besser gefällt es mir aber, wenn man im Gespräch den Wunsch gar nicht formuliert, sondern eine Frage anschließen kann. (Was sicher nicht immer möglich ist, aber ich gehe gerade von einem ansonsten eigentlich funktionierenden Teamgefüge aus.)

„Ich beobachte, dass Du zu unseren Dailies bisher 5 Minuten zu spät gekommen bist. Das wirkt auf mich, als würdest Du meine Zeit nicht schätzen.Wie siehst Du das?“

Manch einer mag nun einwenden, dass man „Feedback doch auch annehmen solle“ und dass so wie in diesem Beispiel eine „Rechtfertigung“ ausgelöst würde. Um ehrlich zu sein, das entspricht gar nicht meinem Menschenbild. Zunächst: Eine Erklärung ist keine Rechtfertigung. Außerdem: Man muss nicht jedes Feedback annehmen.

Die letzte Variante würde es beispielsweise erlauben, dass der Angesprochene eine Erklärung abgeben kann – eventuell kann er zeitlich das Daily gar nicht schaffen. Er kann auch darauf eingehen, dass er die Wirkung gar nicht intendiert habe und so den Feedbackgeber eventuell „entlasten“, da dessen Bedürfnisse ernst genommen werden. Kurz, man gibt so die Möglichkeit, dass gemeinsam an der Wirkung gearbeitet werden kann, anstatt dass ein Symptom, eventuell zu aller Unzufriedenheit, behoben wird.

OKR – Mini How-To

Daemonic Coder

Wie funktionieren OKR? Aus den Google-Handreichungen und anderen Quellen destilliert:

  • „Objectives“ beschreiben das „Was“:
    • Drücken Ziele und Absichten aus
    • Sind aggressiv aber realistisch
    • Sind greifbar objektiv und eindeutig – es sollte durch einen rationalen Beobachter erkennbar sein, ob das „Objective“ erreicht wurde.
    • Es muss einen erkennbaren Wert für die Systel haben.
  • „Key Results“ beschreiben das „Wie“:
    • Drücken messbare Meilensteine aus, ihre Erreichung tragen zum Fortschritt der Bestandteile eines Objectives sinnvoll bei.
    • Beschreiben Ergebnisse, keine Aktivitäten.
    • Enthalten Belege für deren Erreichung
    • Sind die KR alle erreicht, so ist das Objective erreicht
  • Es gibt 2 Arten von OKRs: Verpflichtete (Commited) und Ehrgeizige (Aspirational). Verpflichtete OKRs müssen zu 100% erreicht werden, bei ehrgeizigen ist eine Erfüllung von etwa 70% zu erwarten.
  • Klassische Fallen und Fehler im Schreiben von OKRs:
    • Verpflichtende und ehrgeizige OKRs werden nicht unterschieden
    • Business-as-Usual OKRs
    • Schüchterne ehrgeizige OKRs
    • Sandbagging
    • Who-cares-Objectives / Objectives mit niedrigem Wert
    • Unzureichende Key-Results