Mittwoch, 31. Januar 2018

Kommentierte Links (XXXIII)

FS
  • Thomas Ferris Nicolaisen: How Silos Grow

    Vermutlich muss man das was hier beschrieben wird einmal miterlebt haben um seine Tragweite erfassen zu können. Bei verschiedenen Kunden habe ich Zeuge sein dürfen wie als "Startup im Konzern" gegründete Einheiten vom langen Arm der Bürokratie eingeholt wurden, aber dieser Fall ist noch einmal spezieller: ein Startup bildet aus sich heraus und gewissermassen gegen seinen eigenen Willen jene organisatorischen Silos, die die Gefahr von Bürokratisierung von Verlangsamung mit sich bringen. Verbunden mit Verweisen auf agile Grundlangen, Analysen und Lösungsansätzen ist das einer der besten Artikel zu dem Thema die ich seit einiger Zeit gelesen habe.

  • Farnham Street: Complexity Bias - Why We Prefer Complicated to Simple

  • Warum werden wir agil? Weil alles komplex wird. So weit, so gut. Aber warum wird alles komplex? Die für manche überraschende Antwort: weil wir häufig Komplexität gegenüber Einfachheit bevorzugen. Das es dafür mehrere Gründe gibt ist dann wieder weniger überraschend (wäre es sonst noch komplex?), macht es aber schwieriger zu erklären. Diesen Versuch hier finde ich recht gut gelungen, wobei er sich vor allem auf die Ebene der Einzelpersonen konzentriert. In Organisationen ist das nochmal (wer hätte es gedacht) komplexer. Vielleicht schreibe ich meine Gedanken dazu irgendwann auf, sobald ich sie sortiert habe.

  • FAZ: Wir basteln uns ein Büro

    Dass auch die neue Gestaltung von Büroflächen zu einer agilen Transition dazugehört wird immer mehr akzeptiert, wie diese Umbauten in der Realität durchgeführt werden wird dagegen viel zu wenig durchdacht. Im Normalfall werden lediglich Baumassnahmen geplant, verkündet und umgesetzt - häufig mit dysfunktionalen Arbeitsumgebungen als Folge. Alexander von Erdély zeigt auf wie man es besser machen kann, unter anderem durch Vermeidung von unnötiger Arbeitsplatzverknappung, durch Einbindung der Mitarbeiter und durch die Bereitschaft die Umbau- und Sitzpläne feedbackbasiert auch in späteren Phasen anzupassen. .

  • Spiegel Online: Thüringer Tricks

    Ein Thema das indirekt mit dem letzten zu tun hat. Was Florian Diekmann hier aus Südthüringen berichtet steht weiten Teilen von Deutschland in den nächsten Jahren bevor: Fachkräftemangel. Um dem entgegenzuwirken setzen die Arbeitgeber dort auf bessere Arbeitsbedingungen, aber auch auf Mitbestimmung, Augenhöhe und respektvollen Umgang miteinander. Mit anderen Worten - man arbeitet dort an einer besseren Unternehmenskultur. Dass das als Unterscheidungsmerkmal zwischen Mittelständlern und Konzernen gesehen wird sagt viel aus, denn noch immer ist in großen Organisationen ein eher kafkaesker Umgang miteinander die Realität.

  • Barry Overeem: A Summary of the 10 Scrum Myths

    Eine Zusammenfassung einer Artikelserie der letzten Wochen. Zehn häufige Falschannahmen über Scrum werden erklärt und widerlegt. Sowohl in der Zusammenfassung als auch in den detaillierteren Einzelartikeln lesenswert. Die Serie ist auch bereits weitergegangen, mal sehen wie viele "Scrum Myths" noch kommen.

Montag, 29. Januar 2018

Weniger ist mehr

FS

Eine Tendenz die bei neu gestarteten agilen Transitionsvorhaben häufig zu beobachten ist, ist die Konzentration auf das Erschaffen von Neuem. Neue Rollen, neue Prozesse, neue Regeln, neue Visionen, neue Skalierungsframeworks, neue Tools, neue Hierarchien, neue Karrierepfade, etc., etc. Das ist auch nicht notwendigerweise falsch, es ist aber meistens ein bewusst oder unbewusst durchgeführter Versuch um das größte Problem herumzunavigieren: die organisatorischen Altlasten.

Dass eine Organisation sich überhaupt verändern möchte liegt in der Regel daran, dass sie die Herausforderungen der Gegenwart nicht mehr bewältigen kann, und das wiederum liegt fast nie an zu wenig Strukturierung und fast immer an zu viel davon. Wer in solchen Strukturen arbeitet kennt die Beispiele: selbst kleinere Ausgaben müssen über den Tisch des Bereichleiters, ein Zugriff auf bestimmte Entwicklungs- oder Testumgebungen muss schriftlich beantragt werden, jede noch so kleine neue Software ist vom Betriebsrat zu prüfen bevor sie benutzt wird. Die Liste ließe sich endlos fortsetzen.

Wenn jetzt zusätzlich zu all dem noch neue Rollen, Regeln und Prozesse eingeführt werden, dann führt das in den meisten Fällen nicht zu schnelleren und flexibleren Prozessen. Im besten Fall ändert sich nichts, im schlimmsten Fall wird sogar alles noch langsamer. Wenn dann argumentiert wird, "dass das alles nichts bringt" ist nicht abzustreiten, dass darin eine Wahrheit liegt - eine derartig durchgeführte Transition sollte hinterfragt und in vielen Fällen besser abgebrochen werden.

Ein wesentlich besserer Ansatz ist es, als erstes einen anderen Weg zu gehen, nichts Neues einzuführen und stattdessen bestehende Regeln abzuschaffen. Das ist natürlich schwierig und schmerzhaft, weil es mit langjährigen Gewohnheiten bricht und weil viele mittlere Manager darauf bestehen werden, dass gerade die von ihnen verantwortete Genehmigung unglaublich wichtig für Qualität, Transparenz, Effizienz oder Effektivität wäre. Aber diese Anstrengungen lohnen sich.

Auch hier machen Beispiele alles anschaulich: Wenn die Testabteilung nicht mehr das Monopol auf die Qualitätssicherung hat kann jedes Team sie selber durchführen und muss nicht mehr um Test-Ressourcen kämpfen und auf sie warten. Wenn nicht mehr jedes kleine Monitoring-Tool durch einen Genehmigungsprozess muss lassen sich verschiedene von ihnen schnell ausprobieren, um so das beste zu finden. Und wenn nicht mehr jeder Kleinbetrag freigegeben werden muss sinken häufig sogar die Kosten, die vorher im Wesentlichen durch die Verwaltungsabläufe entstanden sind.

Das an dieser Stelle folgende Gegenargument ist so alt wie die Bürokratie selbst: "Aber dann macht ja jeder was er will!". Und es ist gut wenn es kommt, denn ausgehend von ihm kann man jetzt über Selbstorganisation und Autonomie reden. Die sollten nämlich als nächstes entstehen, wenn die Transition ernst gemeint ist.

Donnerstag, 25. Januar 2018

Denn sie wissen nicht, wen sie rekrutieren (III)

FS
Bild: Rawpixel - CC0 1.0
Stellen wir uns folgende Konstellation vor: ein professioneller Sportverein, zum Beispiel Bayern München, muss in dem hochgradig wettbewerbsintensiven Umfeld einer Topliga bestehen. Um dazu in der Lage zu sein benötigt er Spitzenpersonal - auf jeder Position Spieler von internationaler Klasse, einen Trainer der idealerweise schon durch Titel bewiesen hat, dass er Mannschaften zum Erfolg führen kann, dazu Spezialisten wie Masseure, Platzwarte und weitere. Um diese Spitzenkräfte zu bekommen beschäftigt jeder große Verein Scouting- und Talentförderungseinheiten, in denen ausgewiesene Fachleute dafür sorgen, dass nur das beste Personal engagiert wird.

Übertragen wir es auf die IT: ein großes Technologieunternehmen, das in einem extrem volatilen und disruptiven Marktumfeld unterwegs ist, muss versuchen mit der nationalen und internationalen Konkurrenz mitzuhalten. Um dazu in der Lage zu sein benötigt es Spitzenpersonal - Entwickler, Tester, Produktmanager, UX-Designer und Scrum Master. Um diese Spitzenkräfte zu bekommen beschäftigt es ... Scouting- und Talentförderungseinheiten? Im Idealfall ja, in der Realität leider nur zum Teil. Sehr häufig wird die Personalsuche an externe Dienstleister ausgelagert, und an der Stelle beginnen die Probleme.

Auf welche haarsträubende Weise Personalvermittler und Headhunter häufig vorgehen habe ich schon mehrfach aufgeschrieben, heute soll es darum um eine andere und naheliegende Frage gehen: Warum geben viele Firmen diese extrem wichtige Aufgabe an so offensichtlich überforderte Dienstleister weiter? Aus meiner Erfahrung sehr häufig aus zwei Gründen - um Kosten zu sparen und um Verantwortung (und Schuld) zu externalisieren.

Das (scheinbare) Kostenargument hat seinen Ursprung im Zerfall vieler Unternehmen in unterschiedliche organisatorische Silos, die auch nach unterschiedlichen Zielen gesteuert werden. Ich kenne Personalabteilungen in denen es als wichtigstes Erfolgskriterium gilt wenn der Scouting- und Rekrutierungsprozess möglichst billig ist. Die offensichtliche Folge: es werden Aufträge an Billig-Anbieter vergeben, die billiges Personal beschäftigen, welches in Zeiten des Fachkräftemangels fast zwangsläufig unqualifiziert sein muss.

Die Externalisierung von Verantwortung und Schuld dagegen geht auf die Firmenkultur zurück. Wenn eine Kontroll- und Bestrafungskultur vorherrscht führt das automatisch dazu, dass bereits von Anfang an alle Arbeit so organisiert wird, dass man im Zweifel einem anderen die Schuld geben kann. Externe Dienstleister sind da ein dankbarer Sündenbock: sie sind in den Schuldzuweisungsrunden nicht dabei (können sich also nicht verteidigen) und man kann sich leicht von ihnen trennen.

In Kombination sorgen diese beiden Faktoren für zwei Ergebnisse. Zum einen werden die HR-Abteilungen intern gelobt und belohnt, denn sie können die Kosten niedrig halten und sich als durchsetzungsstark profilieren indem sie von Zeit zu Zeit einen Dienstleister zum Sündenbock machen und vom Hof jagen. Zum anderen führt der qualitativ geringwertige Rekrutierungsprozess zu Fehlbesetzungen mitsamt der erwartbaren negativen Auswirkungen auf Qualität und Effektivität, die dann aber ein anderes organisatorisches Silo ausbaden muss. Mit anderen Worten: dort wo die Probleme entstehen werden die Mitarbeiter dafür belohnt, dass sie nichts ändern, dort wo die Probleme ihre Auswirkungen haben gibt es nicht die Möglichkeit die verursachenden Prozesse zu verbessern.

Soweit die Problemanalyse, was aber wäre die Lösung? Verkürzt gesagt: die Auflösung organisatorischer Silos, die Beendigung von lokaler Optimierung auf Kosten anderer Firmenteile und die Abschaffung der kontroll- und bestrafungszentrierten Firmenkultur. Das würde zwar viel bringen, wäre aber anstrengend und langwierig. Und darum lassen viele Firmen lieber alles so wie es ist und fluchen dafür regelmässig über die eigenen Leute.

Montag, 22. Januar 2018

Design Thinking Movie

FS
Bemerkenswert, dass ich erst durch einen Bekannten darauf gebracht werden musste, dass dieser Film schon sechs Jahre existiert. Insgesamt ein geringer IT-Bezug, trotzdem (oder deswegen) sehr zu empfehlen.



Edit: mittlerweile lässt sich das Video nicht mehr einbetten, daher ist es hier durch den Trailer ersetzt. Ansehen kann man es jetzt nur noch auf dieser Seite.

Donnerstag, 18. Januar 2018

Klassisches und agiles Change Management

FS
Bild: Flickr / Ken Lund - CC BY-SA 2.0
Wenn Firmen versuchen die Kompetenz der agilen Transition bei sich zu bündeln ist es ein häufiger Ansatz das in den Change Management-Abteilungen zu tun. Grundsätzlich ist das auch richtig, alleine der berühmte agile Leitsatz "responding to change over following a plan" ist ja im Grunde nichts anderes als die Aufforderung aktiv Veränderungen zu betreiben. Trotzdem führt diese Zuordnung in der Realität immer wieder zu Problemen, da das klassische und das agile Verständnis von Change Management sich stärker unterschreiden als man annehmen würde.

Klassisches Change Management hat zwar die Veränderung als Ziel und Zweck, ist aber weiterhin eingebettet in einen Umgebungskontext in dem Stabilität und Planbarkeit übergeordnete Ziele sind. Wenn Veränderungen als notwendig erkannt werden wird daher versucht sie so schnell wie möglich hinter sich zu bringen. Mit anderen Worten: es gibt einen stabilen Ausgangszustand und einen stabilen Zielzustand. Die Aufgabe des klassischen Change Managements ist es, die zwischen diesen beiden stabilen Zuständen liegende Phase der Unruhe so kurz wie möglich zu halten.

Im agilen Vorgehen ist dauerhafte Stabilität dagegen explizit nicht vorgesehen, sie wird ersetzt durch einen Zustand des permanenten Überprüfens, Experimentierens und Ausprobierens. Auf den stabilen Ausgangszustand folgt damit nicht eine kurze Phase der Unruhe und dann ein stabiler Zielzustand. Stattdessen wird die Unruhe (positiv formuliert: ein permanenter Anpassungsprozess) zur neuen Normalität. Im Zweifel wird eine Verfestigung sogar durch Interventionen bewusst gestört.

Im Alltag zeigt sich dieses unterschiedliche Verständnis an vielen Stellen. Am offensichtlichsten dort wo beabsichtigt wird Scrum Master oder Agile Coaches nur so lange in den Teams zu lassen "bis die Transition abgeschlossen ist", aber auch dort wo gefragt wird wann der Übergang "denn endlich vorbei ist" oder dort wo ein begrenztes Change Budget irgendwann aufgebraucht ist, so dass man es bis  dahin "geschafft haben muss". Alle derartigen Aussagen sind sehr deutliche Indikatoren dafür, dass die Einführung agiler Vorgehensweisen stark gefährdet ist.

Natürlich ist all das kein zwingend vorherbestimmtes Schicksal. Auch klassische Change Management-Abteilungen können Agilität erlernen. Dafür müssen sie allerdings zulassen selber gecoacht zu werden und bereit sein ihr bisheriges Vorgehen in Frage zu stellen. Wie weiter oben gesagt: responding to change over following a plan.

Montag, 15. Januar 2018

Remote-Arbeit (II)

FS
Bild: Startup Stockphotos - CC0 1.0
Dieser Text hier knüpft an einen anderen an, geschrieben nebenan auf Medium von Martin de Wulf. Unter dem Titel "The Stress of Remote Working" zählt er auf welche negativen Aspekte es in der IT mit sich bringt wenn man nicht mit den Kollegen im Büro sitzt sondern von zu Hause aus arbeitet. Sein Focus liegt dabei auf den negativen Begleit- und Folgeerscheinungen für den Einzelnen. Allein diese Punkte sind schon ein Argument gegen derartige Remote-Arbeit, und dabei geht er auf die dazukommenden negativen Auswirkungen auf die Teamarbeit nur am Rand ein (dazu später mehr). Seine zentralen Gedanken sind:

Remote-Arbeit führt zu einer "Dehumanisierung" des Alltags. Da der Großteil der Kommunikation nicht mehr direkt mit Menschen stattfindet sondern mit dazwischengeschalteten Computerprogrammen (Jira, Trello, Slack, etc) geht der soziale Austausch verloren, mit den erwartbaren Folgen: Abnahme von Gruppenzugehörigkeit und Gruppenidentität sowie Wahrnehmung des Teams/der Firma als sozial und emotional kalte, technisch-mechanische Einheit. Im Umkehrschluss wird auch das eigene Verhalten bewusst oder unbewusst kälter und abweisender.

Abgeleitet davon kommt es zu Vereinsamungseffekten: zur Degenerierung sozialer Fähigkeiten (bzw. zur Regression auf das Niveau der zu Hause betreuten Kinder), zu Verlust von Bekanntschaften, Freundschaften und Netzwerken und in Folge dessen zu einem Rückgang von Status und Karrierechancen. Das übrigens beruht sowohl auf bewussten als auch auf nichtbewussten Faktoren wie dem Verzicht auf das Netzwerken in Kantine und Kaffeeküche (bewusst) und geringerer Wahrnehmbarkeit im Arbeitsalltag (unbewusst).

Nicht zuletzt treten Multitasking und Überarbeitung auf. Durch die Verlagerung der Kommunikation auf Mail, Chat und Tickettools kommt es zu einem ständigen Eintreffen geschriebener Nachrichten zu den verschiedensten Themen, oft zur selben Zeit parallel. Durch die zeitgleich stattfindene Vermischung von Privat- und Berufsleben entstehen nochmals weitere Störungen (Kinder, Hausarbeit, etc). In Kombination mit dem Fehlen eines Büroschlusses und der Tatsache, in der Firma primär über Arbeitsergebnisse wahrgenommen zu werden, tritt ein starker Anreiz auf die verlorene Effektivität durch Mehrarbeit auszugleichen.

Soweit de Wulf. Zusätzlich zu seinen Punkten gibt es aber noch eine weitere negative Auswirkung von Heim-, bzw. Remote-Arbeit auf die Team- und Organisationsebene: die Kommunikation und mit ihr auch der gesamte Arbeitsablauf der Firma wird ineffektiv. Ohne physische Boards und Charts tritt der Box hides answer-Effekt auf, ohne die implizite Kommunikation des informellen Austauschs in Kantine und Kaffeeküche fehlen Kontext-Informationen, ohne direkte nonverbale Kommunikation fallen unbewusste Hinweise auf Probleme unter den Tisch. Schlecht abgestimmte oder redundante Arbeit sind die Folgen.

Dass es trotzdem den verbreiteten Wunsch nach Heimarbeit gibt hat nachvollziehbare Gründe: die zu Hause zu betreuenden Kinder, die Unannehmlichkeiten des täglichen Arbeitswegs und die individueller gestaltbare Einrichtung sind einige. Angesichts der möglichen Auswirkungen sollten aber sowohl Arbeitnehmer als auch Arbeitgeber sich gut überlegen ob diese Vorteile wirklich die Nachteile aufwiegen.

Donnerstag, 11. Januar 2018

No silver bullet

FS
Bild: Flickr / Ed Schipul - CC BY-SA 2.0
Beratungssituation Nummer Eins: in einem mittelständischen Unternehmen wird Software produziert die für jedes Land lokalisiert, d.h. an die dortigen Vorlieben angepasst wird. Der für einen unbedeutenden Markt zuständige Produktmanager bekommt nur Ressourcen für Bugfixing genehmigt, sonst keine. Seine Frage - wie kann agiles Vorgehen ihm helfen trotzdem Marktforschung zu betreiben und Features zu entwickeln?
Beratungssituation Nummer Zwei: ein Projektleiter sitzt vor dem in seiner Firma zwingend vorgeschriebenen dreißigseitigen Projektbeantragungsformular. Seine Frage - wie füllt man das mit Scrum unkompliziert aus?
Beratungssituation Nummer Drei: ein Projekt besteht aus mehreren organisatorischen Silos. Fachabteilung, Entwicklung, Test. Direkte Kommunikation zwischen ihnen ist nicht zulässig, die läuft immer über das Prozessmanagement. Der Testmanager fragt - wie bekommt man da mit agiler QA bessere Qualität?

Alle drei Beratungssituationen haben sich vor nicht zu langer Zeit fast genau so zugetragen und in allen drei Fällen musste der Agile Coach antworten, dass weder Scrum, noch Kanban, noch Lean Startup noch irgendein anderer agiler Ansatz in derartigen Situationen weiterhelfen kann. In jedem dieser Fälle sind Ausgangssituation und Rahmenbedingungen so ungünstig, dass eine Verbesserung der Zustände unmöglich ist solange diese nicht geändert werden. Kein Framework und keine Methode der Welt können daran etwas ändern. Und eigentlich ist das auch so selbstverständlich, dass es dafür kein Beratungsgespräch braucht.

Das Problem: oft kommen derartige Situationen zustande weil vorher ein Berater oder Manager behauptet hat, mit agilen Ansätzen würde alles besser werden. Natürlich nicht mit diesen Worten, aber dem Sinn nach - ohne bestehende Prozesse abzuschaffen müsste nur zusätzlich dazu "agil eingeführt werden" um "signifikante Verbesserungen in allen Bereichen" zu erzielen. Und diese Anführungszeichen symbolisieren keine Distanzierung, sie sind wörtliche Zitate, die bei einem der oben genannten Kunden genau so von Management und Beratern getätigt wurden.

Die Konsequenzen dieser Situation sind einfach vorstellbar, "Agil" gilt in diesem Unternehmen nur noch als eine Ansammlung leerer, unseriöser Versprechen, es ist, wie man so schön sagt, verbrannt. Leider kein Einzelfall, denn selbst wenn die oben genannten Beispiele extrem sind - viel zu oft wird geglaubt, gehofft oder behauptet, dass es kein Problem gebe, dass sich mit "Agil" nicht lösen ließe. Nach der zwangsläufig folgenden Erkenntnis, dass das nicht so ist, ist die Enttäuschung dann um so größer.

Zu den ersten und wichtigsten Tätigkeiten einer agilen Transition sollte daher ein bei allen Beteiligten durchgeführtes Erwartungsmanagement gehören. Agile Vorgehensweisen sind keine silberne Kugel, also keine Wundermittel (und agile Skalierungsframeworks schon gar nicht!) und in vielen Fällen werden sie erst dann ihre Wirksamkeit entfalten können wenn man im Gegenzug bereit ist sich von anderen, "bewährten" Ansätzen zu trennen. Dort wo das nicht der Fall ist sollte man tun was immer ratsam ist wenn Kugeln durch die Luft fliegen: in Deckung gehen.

Montag, 8. Januar 2018

Intrapreneur

FS
Bild: Wikimedia Commons / Avij - CC0 1.0
Ab dem Jahr 2018 ist mit dem Lohntransparenzgesetz eine interessante Neuerung in Kraft getreten: Angestellte größerer Unternehmen haben jetzt das Recht zu erfahren was der Durchschnittsverdienst für ihre Position ist (mehr dazu hier). Nach dem Willen der Bundesregierung soll so ein Beitrag geleistet werden um ungleiche Bezahlung abzubauen, was auch ein gutes Ziel ist. Als Nebeneffekt kommt aber ein weiterer Vorteil hinzu - den Angestellten wird es jetzt besser möglich unternehmerisch zu denken.

In dem Moment in dem der Durchschnittsverdienst bekannt ist lässt sich einfach feststellen wieviel ein Team im Durchschnitt pro Jahr (und davon abgeleitet auch per Monat oder per Tag) verdient. Und zumindest in Wissens- und Kreativberufen wie der IT bilden die Gehälter auch den größten Teil der Gesamtkosten, weshalb auch die normalen Angestellten jetzt nachrechnen können welche Produktionskosten die von ihnen erstellten Produkte haben.

Ausgehend von diesen Produktionskosten lässt sich jetzt bis auf kleinste Features herunterbrechen was sie kosten, und zusammen mit dem Business Value (von dem wir hoffen, dass es für ihn in jeder Produktentwicklung eine Schätzung gibt) kann man Prognosen abgeben wie viel Gewinn ein Produkt erwirtschaften muss und ggf. wie lang das der Fall sein muss damit diese Investition sich rechnet. Ist auf diese Weise absehbar, dass ein Produkt oder Feature unwirtschaftlich ist kann schon früh in Frage gestellt werden ob seine Erstellung überhaupt sinnvoll ist.1

Diese Überlegung sollte zwar vor allem vom Product Owner oder Produktmanager angestellt werden, aber nicht von ihnen alleine. Auch die Teams sind gefragt wenn es darum geht auf die mittel- und langfristigen wirtschaftlichen Folgen technischer Weichenstellungen hinzuweisen, und im Fall von nach Scrum arbeitenden Teams sollte sich auch der Scrum Master mit diesen Themen beschäftigen. Für diesen Typ des unternehmerisch denkenden Angestellten gibt es sogar einen Fachbegriff, man spricht vom Intrapreneur.

Noch einfacher wird Intrapreneurship natürlich wenn nicht nur die Gehälter nachvollziehbar sind sondern alle Zahlen von allen Firmenmitgliedern eingesehen werden können. Es gibt bereits Unternehmen in denen das möglich ist (meines gehört dazu), für die meisten ist das aber noch ein langer, langer Weg.


1Man könnte zwar annehmen, dass die meisten Firmen das ohnehin tun. Aus langer Beratungserfahrung weiss ich leider, dass es in der Realität oft anders ist.

Donnerstag, 4. Januar 2018

That's what leadership is

FS
Ein junger Steve Jobs verkündet zeitlose Erkenntnisse. Angesichts seines Erfolges fragt man sich: warum werden sie von vielen Firmen bis heute nicht berücksichtigt?

Montag, 1. Januar 2018

Agile Neujahrsvorsätze

FS
Bild: Wikimedia Commons / iclifford - CC BY-SA 3.0
Zu den Ritualen jedes neuen Jahres gehören die guten Vorsätze. Dinge die zu tun man sich vornimmt um in den nächsten Monaten zufriedener, erfolgreicher oder konsequenter zu sein. Kurz vor Jahresende hat ein von mir gecoachter Scrum Master nach Ratschlägen für gute Vorsätze für sich und sein Team gefragt, die ich hiermit auch öffentlich machen möchte.

Probier etwas Neues aus

Wenn Du einen Entwicklerhintergrund hast beschäftige Dich mit Psychologie, wenn Du ein Manager bist beschäftige Dich mit Testautomatisierung, wenn Du ein Scrum Master bist schau Dir Lean Startup an, etc. Selbst wenn Du es nicht bis zum Meister schaffst wirst Du neue Blickwinkel auf Deine tägliche Arbeit bekommen und dadurch besser werden.

Stelle ein Dogma in Frage

Mit großer Wahrscheinlichkeit wird es von irgendetwas in Deiner Umgebung heissen "das geht bei uns nicht". Der Zugang zu einem System, die Vereinfachung eines Prozesses oder die Beschaffung von Hardware wird für unmöglich gehalten? Versuche es in den nächsten Monaten doch möglich zu machen, meistens lässt sich mehr verändern als man denkt.

Mach etwas im Pairing

Etwas in unmittelbarer Zusammenarbeit mit einem Kollegen durchzuführen ermöglicht unmittelbares Feedback und verbessert die eigenen Kommunikationsfähigkeiten. Egal ob Programmieren, Testen, Coachen, Moderieren oder Designen - es gibt fast nichts was man nicht auch zu zweit machen könnte. Und im Normalfall wird man auch dadurch besser.

Sei datengetrieben

Nimm Dir nicht nur irgendetwas vor, überleg Dir auch was Du erreichen willst, wie Du es messbar machen kannst und wann Du die Messung vornehmen willst. Gegebenenfalls liegen bereits Daten aus dem letzten Jahr vor auf die man aufbauen kann, möglicherweise ist auch das Sammeln sinnvoller (!) und verwertbarer (!!) Daten selbst der Vorsatz.

Überprüfe Deine Vorsätze regelmässig

Frag Dich nicht erst am Ende des Jahres was aus Deinen Vorhaben geworden ist, überprüfe es regelmässig auf Basis der gesammelten Daten (siehe oben). Jedes Quartal, Jeden Monat, jeden Sprint, vielleicht jede Woche. Und wenn Du merkst, dass Deine Vorsätze nicht ganz so viel Sinn machen wie erwartet dann pass sie an, biss wieder ein Sinn dahintersteckt. Inspect & Adapt.
Powered by Blogger.