Autor: Daemonic Coder

Entwickler sind keine Köche

Daemonic Coder

Außerhalb der Entwickler-Welt gibt es ja immer mal wieder den Einen oder Anderen, der mit „Entwicklersprech“ nichts anfangen kann. Der von Commits und Libraries noch nie gehört hat, der npm-Pakete nicht kennt und dem die Arbeit eines Entwicklers wie eine Mischung aus Magie und Pizzaessen erscheint.

Ich finde es vollkommen in Ordnung, in solchen Fällen den „Unwissenden“ die Arbeit mit Vergleichen näher zu bringen. „Ein Softwarearchitekt macht etwas Ähnliches wie jeder Architekt, er plant etwas, bevor es aufwändig umgesetzt wird. Nur eben eine Software, kein Haus.“

Aber wenn man mit Entwicklern redet, finde ich solche Vergleiche nicht passend. Ich kannte mal einen Manager, der seinem Entwicklungsbereich die Vorteile der Standardisierung näherbringen wollte und dies seinen Mitarbeiterinnen und Mitarbeitern an einem Beispiel aus der Industrie verdeutlichen wollte. Alle, so meinte er, sollten sich auf die Gewindegrößen einigen und so würden Schrauben, Muttern, Bohrer und Dübel immer zusammenpassen.

Bei den Mitarbeitern sorgte dies in erster Linie für Widerspruch: „Die Kundenwünsche lassen sich nicht in ein Dutzend Standardgrößen abbilden“, „Wir wollen nicht 1000x das Gleiche Loch bohren“ und „Muttern sind keine Schnittstellen“ waren die Reaktionen. Und in erster Linie war der Eindruck: Unser Manager hat offensichtlich keine Ahnung, was wir hier arbeiten, sonst müsste er sich nicht eines solchen Beispiels bedienen.

Warum nutze der Manager in diesem Fall kein Beispiel aus der Softwareentwicklung? Er hatte sogar Wissen aus der Softwareentwicklung (C und C++), hätte er erklärt, welchen Nutzen die Standardisierung der Programmiersprache hatte und beispielsweise den Compilerhersteller zu wechseln, dann wäre er von seinen Mitarbeitern meiner Meinung nach viel mehr ernst genommen worden.

Aber irgendwie scheint es sich etabliert zu haben, dass die Arbeit von Entwicklern immer mit der aus anderen Industrien oder Berufen verglichen werden muss. Schon in „Vom Mythos des Mann-Monats“ vergleicht Frederick Brooks die Arbeit eines Entwicklerteams mit einem Ärzteteam. Zugegeben, bei Erscheinen des Buches war die Erfahrung in der Softwareentwicklung auch noch nicht einige Jahrzehnte alt.

Ich persönlich fühle mich als Entwickler von Managern nicht ernst genommen, die ihre Ideen oder Vorstellungen einleiten mit „Nehmen wir mal an, Entwicklung wäre wie…​ Häuser bauen.“

Sicher, man kann daraus lernen, wie andere (Berufe) ihren Job machen, aber — nehmen wir doch mal an, wir würden Software entwickeln. Und darin wollen wir besser werden.

Manager als Schutzschild

Daemonic Coder

Hierarchien sind etwas schlechtes. Böse Manager unterdrücken ihre Mitarbeiter, halten sie vom eigenständigen Denken ab und wollen nur ihre Macht anhäufen.

So scheint es einem oft, wenn in Unternehmen sich die „Agilen Werte“ durchsetzen wollen, Ziel ist immer eine „flache Hierarchie“. Davon abgesehen, dass es das oben beschriebene Verhalten von Managern wohl geben mag, möchte ich an dieser Stelle eine Lanze für Hierarchien in Unternehmen brechen. Wozu sind diese also Nutze?

Hierarchien nehmen Druck

Der CEO einer anderen Firma, für die man tätig ist, ruft erbost den eigenen CEO an, damit „wichtige Features“ doch noch durchgedrückt werden. Der eigene CEO bestellt die Bereichsleiter ein, um ihnen die Wichtigkeit zu verdeutlichen. Die Bereichsleiter wenden sich an die Abteilungsleiter, geben die Info weiter, die Abteilungleiter teilen dem Projektleitern mit, was der Kunde wünscht. Auf der einen Seite könnte das ein „nach oben buckeln, nach unten treten“ werden, aber oft wird durch diese Hierarchie der Druck heraus genommen. Vom erbosten CEO bleibt (zumindest bei einem guten Management) bis zur Projektebene nicht mehr ganz so viel Wut übrig. So können Hierarchien die Mitarbeiter „schützen“ und statt des „Push“ ein „Pull“ in den Projekten ermöglichen.

Wichtige Entscheidungsträger werden geschützt

In jedem Unternehmen ab einer gewissen Größe gibt es Mitarbeiter, die mehr Erfahrung mit bestimmten Technologien oder anderen Themen haben. Diese Mitarbeiter sollten dann typischerweise für wichtige Entscheidungen oder Unterstützung bei hoch priorisierten Projekten zur Verfügung stehen. In klassischen Hierarchien handelt es sich dabei um Chefarchitekten, Chefstrategen oder Senior-Vice-Irgendwas. (Zumidnest unter der eventuell etwas naiven Annahme, dass die Beförderung auf Kompetenz beruht…) Dadurch ist der Zugang zu diesen Mitarbeitern über die Hierarchie „reglementiert“ und sie können in den wichtigen Themen eingesetzt werden.

Und nun, heißt das, ich möchte, dass doch klassische Hierarchien bestehen bleiben? Nicht unbedingt – aber man sollte meiner Meinung nach die Vorteile kennen, da bei einer Transformation hin zu einer flachen Hierarchie diese Effekte auf einmal nicht mehr da sind. Eventuell wird daher der Druck auf Mitarbeiter größer oder Wissensträger sind nicht mehr für die wichtigen Themen verfügbar.

Business-Barnum

Daemonic Coder

„Genau, der kennt unserer Probleme! So läuft das bei uns auch“ manchmal wenn ein Berater oder Referent in eine Firma kommt, dann kommt dieser Eindruck auf und man fühlt sich gleich viel „sicherer“ in seinen (oder ihren, bitte entschudligt an dieser Stelle die rein männliche Form) Händen.

Manchmal muss ich bei so etwas allerdings an klassische Horoskope denken. (Oder an dubiose Persönlichkeitstests wie den MBTI.) Dort gibt es die sogenannten Barnum-Aussagen, die so allgemein oder schwammig gehalten sind, dass sich darin fast jeder wiederfindet. So sind auch manche Berater-Aussagen  so gehalten, dass sie auf praktisch jedes Unternehmen in einer gewissen Größe zutreffen könnten.

Hier mal ein paar Beispiele, die mir über den Weg gelaufen sind, von etwas, was ich gerne „Business-Barnum“ nennen möchte:

  • „Wir kämpfen oft damit, die richtigen Leute in die richtigen Projekte zu bringen, wir müssen die ‚right person for the job‘ finden.“
  • „Digitalisierung ist eine der großen Herausforderungen, der wir uns stellen müssen.“
  • „Wir müssen flexibler werden, dürfen dem aber eine sinnvolle Standardisierung nicht zum Opfer fallen lassen.“
  • „Unsere Prozesse sind zu schwerfällig für den sich schnell verändernden Markt.“
  • „Führung muss anders gedacht werden.“
  • „Die Veränderungen muss in den Köpfen, in den Werten und der Kultur stattfinden, nicht nur in den Prozessen.“

Ergänzungen sind mir sehr willkommen. 😉

Agile Unternehmen

Daemonic Coder

Das „Agile Unternehmen“ ist mittlerweile in mehr und mehr, auch größeren Konzernen, ein Ziel. Eines wird dabei aber oft missverstanden: Ein Agiles Unternehmen bedeutet nicht, dass überall (beispielsweise) Scrum gemacht werden muss. Agilität auf Unternehmensebene heißt, dass sich das Unternehmen den Kundenwünschen anpassen kann, so dass die Mitarbeiter, die mit dem Kunden zu tun haben, wichtige Entscheidungen treffen können.

Eine der Entscheidungen kann auch sein, dass mit dem Kunden ein „klassisches“ Projekt durchgeführt wird, mit Projektleiter, Lasten- und Pflichtenheft und allem, was sonst moch dazu gehören mag. Sicher, eventuell kann man den Kunden dahin beraten, dass ein anderes Vorgehen sinnvoller sein mag, doch wenn man auf den „einzig richtigen Weg“ besteht, so zeigt sich das Unternehmen alles andere als beweglich, also agil.

Dem Widerspricht nicht, dass man auch in klassischen Projekten die Agilen Prinzipien leben kann. Qualität, Kollaboration und Offenheit sind auch im „Wasserfall“ immer angebracht.
Ab einer gewissen Größe scheint es für Unternehmen allerdings immer schwieriger it der Beweglichkeit zu werden. Irgendwann kommt der Punkt, an dem man als Mitarbeiterin oder Mitarbeiter denkt „ich weiß was der Kunde will, aber das können wir nicht machen“. Allerdings nicht, weil das für das Unternehmen zu schwierig sei, sondern weil man weiß, dass es nicht abrechenbar ist, weil das die SAP-Warengruppen nicht vorsehen, weil das im Standardkatalog für Softwarekomponenten nicht vorkommt oder aus welchen Gründen auch sonst.

An dieser Stelle muss ein Unternehmen meiner Meinung nach arbeiten, um „agil“ zu werden. Man muss die Teams, die direkt mit dem Kunden interagieren, in die Lage versetzen, Entscheidungen treffen zu können, die dem Kundennutzen zu Gute kommen – und das ist viel seltener die Auswahl zwischen 3 Standard-Architekturen, als manch ein Enterprise Architect sich erhofft. Ein agiles Unternehmen ist eines, das Entscheidungen möglichst weit dezentralisiert, um gegenüber dem Kunden beweglich auftreten zu können.

Scrum löst keine Probleme

Daemonic Coder

Ich erinnere mich, wie ich einmal bei einer Kundin war, die gerade ein Buch über Scrum gelesen hatte und nun der Meinung war, dass mit diesem neuen Projektvorgehen alle Probleme gelöst seien. „Wir müssen bis Mitte nächsten Jahres das Produkt liefern, daher will ich, dass wir nun Scrum machen!“ rief sie aus. „Ich kann Ihnen versprechen, dass wir mit Scrum bis zu dem Zeitpunkt liefern – ich kann Ihnen nur nicht sagen, was“, war meine, zugegebenermaßen nicht sehr diplomatische, Antwort.

Leider erlebe ich es häufig, dass Kunden, aber auch Manager und Projektleiter der Meinung sind, mit Scrum asl Vorgehen seien alle Projekt-Probleme gelöst. Meiner Meinung nach ist das ziemlich falsch, obwohl ich von Scrum sehr viel halte. Scrum wird die meisten Probleme nicht lösen. Im Gegenteil: Scrum macht viele Projekt-Probleme so schmerzhaft, dass man diese endlich lösen möchte.

Hat der Kunde gar nicht die Zeit, sich dem Projekterfolg zu widmen? Während das bei Dokumenten-Reviews vielleicht kaum auffällt, die der Kunde zusagte, wird es offensichtlich, wenn Reviews immer ohne Stakeholder stattfinden. Gibt es keine wirkliche Sicht darauf, was die zentralen Ziele des Projektes sind? Ein Backlog, der ständig über den Haufen geworfen wird, zeigt dies deutlich. Ist die Technologie, auf der aufgebaut werden soll, risikobehafteter, als man im Elfenbeinturm der Architekturdokumentation noch dachte? Wenn kein Sprint-Ziel gehalten werden kann, dann ist das nicht mehr zu leugnen.

Als diese Probleme werden durch Scrum nicht gelöst. Nur noch unangenehmer als im „klassischem“ Projektvorgehen. Lösen müssen die Beteilgten diese Probleme dann selbst, das kann kein Vorgehensmodell übernehmen.

Goldener Käfig Standardcomputer

Daemonic Coder

Stell Dir vor, es kommt ein Handwerker bei Dir vorbei um beispielsweise das Bad zu renovieren. Am Eingang begrüßt Du ihn freundlich und sagst dann: Wir haben hier überigens Standard-Werkzeug. Sein eigenes Werkzeuig soll er also liegen lassen, statt dessen gibst Du ihm einen anderen Werkzeugkasten. Mit Hammer, Schraubenziehen und allem, was dazu gehört.

Ein guter Handwerker würde wohl auf der Stelle kehrt machen, bei Softwareentwicklern ist das aber aus irgend einem Grund gang und gäbe. Okay, nun verlange ich nicht, dass jede Softwarefirma sagt, dass der Entwickler seinen eigenen Computer verwenden soll; aber das Standard-Werkzeug, dass es oft gibt, ist ebenso oft eine Unverschämtheit gegenüber den Mitarbeitern.

Klar, wenn man in einem Projekt zusammen arbeitet, so sollte man sich auf ein gemeinsames „Toolset“ in dem Sinne verständigen, dass nicht ein paar Entwickler GIT nutzen während andere auf SVN schwören. Aber sollte wirklich die Entscheidung „VI(M) vs Emacs“ auf Unternehmensebene getroffen werden? Daher meine Bitte an alle Unternehmen: Gebt euren Entwicklern das Recht, auf ihren Rechnern Software zu installieren. Egal, was ihr tolles „standardmäßig“ mitgebt. Die Arbeitsumgebung sollte kein goldener Käfig sein!

Ja, es gibt Bedenken, die man ernst nehmen sollte. Vom Installieren von illegaler Software bis hin zu Sicherheitslücken. Aber findet dafür bitte andere Wege. Oder noch besser: Stellt Mitarbeiter ein, denen ihr zumindest im Prinzip zutraut, dass sie ihren Job machen und zumindest nicht böswillig sein werden.

Schwarze Magie bei HR

Daemonic Coder

In zahlreichen Seminaren, sei es zum Verkauf, Beratung, Management – immer wieder werden sie ausgepackt, die Menschenbild-Modelle. Insbesondere in einem „Führungs-Seminar“ bin ich da kürzlich wieder drauf gestoßen.

Sei es DISG, MBTI, was-auch-immer, alle Modelle haben gemeinsam, dass sie versuchen, Menschen in „Farben“, „Typen“, oder, wenn man beim Urvater dieser Modelle bleiben möchte, „Archetypen“ einzuteilen.

Ich erinnere mich an meinen ersten Kontakt mit solchen Modellen: Ich war etwa 16 und machte an der VHS eines kleinen Städtchens einen Rhetorik-Kurs. Der Trainer packte dort den MBTI aus und ließ uns einen Kurztest machen, danach bekamen wir alle, entsprechend unseres Typs, ein Blatt, auf dem Stand,was für ein „Typ“ wir sind. Ich war damals sehr erstaunt, fand ich mich doch in der Beschreibung recht gut wieder. Pronpt kaufte ich mir damals ein Buch zu dem Thema und jeder in meinem Umfeld, der nicht schnell genug davon lief, bekam auch so eine Typisierung und ich las aus dem Buch die entsprechende Seite mit der Persönlichkeitsbeschreibung vor. Immer schien es gut zu passen. Einmal wollte ich einen guten Freund etwas ärgern und las ihm genau „das Gegetnteil“ dessen vor, was sein Typ laut Test hätte sein sollen. Er fand sich darin recht gut wieder. Die nächsten Versuche waren dann, dass ich bei ein paar weiteren Bekannten eine zufällige Auswertung vorlas, die sich auch ganz zufrieden in der Beschreibung wieder fanden.
Sicherlich war das keine wissenschaftlich fundierte Kontrollgruppe, aber das Ergebnis ernüchterte mich damals ziemlich. Leider gab es noch kein Internet, so dass ich damals noch nicht herausfand, was Barnum-Aussagen sind, sonst wäre mir das Phänomen erklärbarer gewesen.

Kurz gesagt, dieser Test ist ziemlicher Humbug. Die anderen, wie bspw. DISG, sind auch nicht viel besser. Alle haben das Problem, dass damit Menschen zu sehr in Schubladen einsotriert werden. Vielleicht mag das Model dem ein oder anderen dabei helfen, zu verstehen, dass nicht alle Menschen gleich ticken – aber um ehrlich zu sein, wer das bei einem Führungsseminar vermittelt bekommen muss, der war vielleicht ohnehin schon der Falsche für eine Führungsrolle!