Freitag, 28. April 2017

Kommentierte Links (XXIV)

Grafik: Pixabay / Geralt - Lizenz
  • Jason Del Rey: This is the Jeff Bezos playbook for preventing Amazon’s demise

    Über die Geschäftspraktiken und die Unternehmenskultur von Amazon kann und sollte man Diskussionen führen. Unstreitig ist allerdings, dass der Konzern es bis heute geschafft hat innovativ zu sein  - aus einem Buchhändler ist ein globaler Mischkonzern geworden, der vom Cloud Hosting bis zum Online-Lebensmittelbestellservice nahezu alles anbietet was irgendwie digital ist. In seinem jährlichen Brief an die Aktionäre beschreibt CEO Jeff Bezos die zentralen Aspekte seiner Philosophie, die diese Innovativität erhalten soll: Fixierung auf Kundenbedürfnisse, Skepsis gegenüber abgeleiteten Erfolgskriterien wie Prozesseinhaltung oder Marktforschung, Offenheit gegenüber neuen Trends und schnelles Treffen von Entscheidungen.

  • Ron Jeffries: Implications of Enterprise Focus in Scrum

  • Ich glaube, Ron Jeffries kann gar keine kurzen Texte mehr schreiben. Ich glaube ausserdem, dass seine Visualisierungsfähigkeiten genauso verbesserungswürdig sind wie meine. Unabhängig davon schreibt er hier viele kluge Dinge über die Adaption agiler Praktiken in Konzernen. Unter anderem geht er auf einen Punkt ein den auch Jeff Bezos macht - abgeleitete Erfolgskriterien sind mit Misstrauen zu betrachten, vor allem wenn es sich um das Schätzen, Planen und Überprüfen zukünftiger Aufwände handelt.

  • Martin Welker: Die Trello-Akquisition - Das letzte Teil des Puzzles

    Den Artikel habe ich bereits Anfang des Jahres auf Englisch bei The Next Web gelesen. Martin Welker geht vordergründig auf den Kauf von Trello (der beliebtesten kostenlosen Software für Anforderungs- und Taskmanagement) durch Atlassian (dem Hersteller von Jira, der beliebtesten Enterprise-Lösung) ein. Tatsächlich geht es aber um ein grundlegenderes Phänomen: darum wie und warum erfolgreiche Produkte "kaputtentwickelt" werden. Verkürzt gesagt - kommerzielle Software wird nicht mehr für die Leute optimiert die sie benutzen sondern für die die sie einkaufen. Ein in seinen Auswirkungen unterschätzer Unterschied.

  • Melissa Perri: Getting Sales + Product In Sync

    Melissa Perri betrachtet das von Martin Welker beschriebene Problem von einer anderen Seite: Um bei den Käufern kommerzieller Software gut anzukommen versprechen die Verkaufsteams denen alles Mögliche, oft auch dann wenn die entsprechenden Features noch gar nicht programmiert sind. Das unter Zeitdruck nachzuholen ist einer der Gründe dafür, dass Standardsoftware häufig so schrottig ist. Ich habe mehrfach Teams begleiten dürfen die unter einer solchen Konstellation gelitten haben und kann Perri nur zustimmen: Produkte sollten nicht auf diese Weise vertrieben werden, da sonst am Ende fast alle Beteiligten unzufrieden sind.

  • Christian Bless: Metro-Map - Agile Prozesse visualisiert man am besten kollaborativ (Edit: Link ist mittlerweile tot)

    Am Anfang dieses Artikels kommt viel Buzz, für den wesentlichen Inhalt kann man bis zur Zwischenüberschrift Metro-Map: Der Fahrplan für jeden Mitarbeiter vorscrollen. Die Idee ist nämlich ganz nett - die Prozessphasen verschiedener Personen oder Teams lassen sich als farbige Linien nebeneinanderlegen. Wenn man sie dann an gemeinsamen Phasenübergängen verbindet entsteht ein Bild das wie ein Ubahn-Plan aussieht. Beispiele finden sich unten unter dem Artikel.

Montag, 24. April 2017

Ein Bild sagt mehr als 1000 Worte (XVII)

Freitag, 21. April 2017

Wirklich crossfunktionale Teams: multimedialer Journalismus

Bild: Wikimedia Commons/Claude Truong-Ngoc - CC BY-SA 3.0
Davon reden, dass Teams wirklich crossfunktional sein sollen ist einfach, aber wie sähe das in der Wirklichkeit aus? Wenn nicht nur Softwareentwickler Teammitglieder sein sollen sondern auch alle anderen Personen die nötig sind um ein fertiges Produkt zu erstellen - an welchem Beispiel könnte man das demonstrieren? Ich nehme bei solchen Fragen gerne bestimmte Darstellungsformen des Journalismus als Anschauungsmaterial, nämlich solche bei denen die Aufbereitung der Inhalte so speziell ist, dass die entsprechenden Websites nicht nur mit Content befüllt sondern auch gesondert programmiert werden müssen. Das geht von relativ banalen Filterfunktionen bis hin zu interaktiven multimedialen Reportagen und ist vor allem im englischen Sprachraum verbreitet. Wie das im Einzelnen aussehen kann sieht man hinter den folgenden Links.
Man merkt es beim Betrachten dieser Beiträge sehr schnell - hier waren Fachleute verschiedenster Art beteiligt: Journalisten, UX-Designer, Daten-Analysten, Frontend-Programmierer, Zeichner, Cutter, Tontechniker und viele mehr. Sie alle haben dazu beigetragen, dass die Endergebnisse so beeindruckend aussehen, und das unter den Bedingungen des schnellebigen, aktualitätsgetriebenen Nachrichtengeschäfts. Gerade im Vergleich zu normalen Zeitungs- und Webartikeln wird klar wozu crossfunktionale Teams in der Lage sein können - wenn man sie einfach machen lässt.

Dienstag, 18. April 2017

10 Dinge die man bei einer Kanban-Einführung beachten sollte

Grafik: Wikimedia Commons/Ian Mitchell - CC BY-SA 2.5
Beim bonner Scrumtisch der letzten Woche drehte sich eine sehr unterhaltsame Session um das Thema der größten Fehler die man im Rahmen einer Kanban-Einführung machen kann. Eigentlich wollte ich auch darüber schreiben, allerdings habe ich mich dann doch entschieden der Sache einen positiven Spin zu geben. Daher umgekehrt: was sollte man auf jeden Fall beachten? Hier sind die Ergebnisse der Diskussion:

1. WIP-Limits einhalten

Man kann es auch umgekehrt formulieren: Multitasking vermeiden. Nur wenn es für jeden Beteiligten eine begrenzte Zahl parallel möglicher Arbeiten gibt kann vermieden werden, dass halbfertige Aufgaben lange Zeit unvollendet liegenbleiben.

2. Nach Verbesserungen suchen

Start where you are und visualize the flow - damit geht es immer los. Das alleine reicht aber nicht, sobald der Arbeitsfluss einmal erkannt ist muss er auf Blocker und Flaschenhälse untersucht werden an deren Beseitigung dann gearbeitet werden kann. Nur so wird die Arbeit effizienter.

3. Messen was man tut

Entscheidungen aus dem Bauch heraus treffen ist schlecht, Entscheidungen datengetrieben treffen ist besser. Wie sind die Kennzahlen für Lead Time, Cycle Time, Wartezeiten und Cost of Delay? Erst wenn man sie kennt kann man messen ob sie sich verbessern.

4. Regelmässig Retrospektiven durchführen

Ständige Verbesserung klingt zwar gut, geht aber häufig im Alltag unter. Für ein bewusstes Inspect & Adapt muss man sich Zeit nehmen, und zwar regelmässig.

5. Fokussiert und sequentiell an einzelnen Aufgaben arbeiten

Bezieht sich nicht auf einzelne Augaben sondern auf größere Vorhaben. Wer hier permanent hin und her springt wird sich verzetteln und durch ständige Kontext Switches ineffizient werden. Das geordnete Abarbeiten bringt frühere und bessere Ergebnisse.

6. Ein echtes Kanban Board/Kanban System aufsetzen

To Do - In Progress - Done ist kein Kanban Board, da hier nur ein einziger, zu generischer Arbeitsschritt vorkommt. Sinnvoll wäre zum Beispiel To Do - In Development - Review - Test - Deploy - Done. Hier lassen sich einzelne Arbeitsschritte erkennen und optimieren.

7. Keine Hidden Steps haben

Passt zum letzten Punkt. Wenn einzelne Arbeitsschritte (z.B. das Deployement) nicht sichtbar gemacht werden kann sich Arbeit unbemerkt und intransparent hierhin verlagern.

8. Niemals "fertig werden"

Ein häufiger Trugschluss: man führt Kanban einmal ein, es funktioniert und man kann es unverändert immer weiter benutzen. Leider ist das nicht so, es gibt immer Optimierungspotential - alleine weil jede neue Optimierung Seitenauswirkungen auf bestehende Prozesse hat. So geht es immer weiter.

9. Informationen immer aktuell halten

Wenig ist sinnloser als ein Haufen alter und dadurch nicht mehr verwendbarer Daten. Nur wenn sie aktuell sind bringen sie einen Mehrwert, schließlich will man die Gegenwart optimieren und nicht die Vergangenheit.

10. Pragmatisch sein

Pragmatisch ist etwas anderes als Beliebig. Bei allem was man tut sollte immer klar sein was man damit erreichen will. Wenn einem das bewusst ist weiß man auch wo man das Vorgehen anpassen kann und wo nicht.


Diese Liste ist natürlich selektiv und subjektiv, man könnte noch vieles weitere hineinbringen. Für den Anfang bietet sie aber eine gute Übersicht. Und sich alleine daran zu halten würde einige Teams die ich kenne deutlich voranbringen.

Freitag, 14. April 2017

Digitalisierung (II) - die agile Grossküche

Bild: Hans / Pixabay - Lizenz
Dass Digitalisierung eine der Voraussetzungen für eine gelungene Einführung von Scrum/Agile ist hatte ich bereits geschrieben, sie ist aber in den meisten Fällen auch unumgänglich wenn ich in einem agil operierenden Unternehmen Prozesse weiter optimieren möchte. Nehmen wir als Beispiel einen großen Münchner Restaurantbetrieb, etwa den in einem Bräuhaus1. Regen oder Staus können die Zahl der Gäste verringern, ankommende Touristenbusse dagegen schlagartig hochtreiben. Und je nachdem wer aus diesem Bus steigt (Rentner, Messebesucher, Schulklassen, Chinesen, Sportmannschaften) können die plötzlich in der Küche eintreffenden Bestellungen völlig andere sein. Eine Herausforderung an dieser Stelle ist: wie lassen sich die Kommunikationswege zwischen Bestellung aufnehmen (Kellnerin) und Mahlzeit zubereiten (Koch) möglichst beschleunigen, so dass die Gäste nicht zu lange warten müssen?

Zunächst durch eine Digitalisierung bestehender Prozesse. In den meisten Gastronomieen notiert die Kellnerin die Bestellung auf einem Zettel, geht zu einer Durchreiche in die Küche und gibt ihn einem Küchengehilfen, der ihn an die Köche weitergibt. Allein hier führt der Einsatz von Technik schon zu deutlicher Beschleunigung: wenn die Kellnerin die Bestellung in ein Handheld eingeben und an einen Drucker in die Küche mailen kann muss sie sich seltener durch den vollen Gastraum drängen, während gleichzeitig in der Küche die Probleme mit dem Entziffern unleserlicher oder verschmierter Schrift wegfallen. Aber das ist erst der Anfang.

In den meisten Großküchen müssen die verschiedenen Köche und Hilfskräfte von einem Küchenchef koordiniert werden. Es gibt verschiedene Spezialisten (z.B. für die Zubereitung von Fleischgerichten oder Nachtischen) die ihre Arbeit zeitlich aufeinander abgestimmt verrichten müssen. Nur so bekommt jeder Gast seinen jeweiligen Gang zum jeweils richtigen Zeitpunkt serviert. Mit dem digitalen Bestellungs-Input kann auch hier optimiert werden: wenn jeder Koch an der Wand vor sich einen Touch-Bildschirm hat kann er dort angeben, dass er gerade eine Zubereitung abgeschlossen hat, er bekommt direkt die nächste Besellung angezeigt und kann kurz darauf melden, dass er fertig ist und das Gericht abgeholt werden kann. Eine Koordination durch hektisches Durcheinanderschreien ist nicht mehr nötig.

Zur Schlusspointe: ein solches System kann nicht nur die Bestell- und Küchenprozesse agilisieren, es kann auch selbst agil erstellt werden. Zuerst Handhelds für die Kellnerinnen, dann ein "digitaler Leitstand" für den Küchenchef, zuletzt Computerprogramme die Verteilung und Timing der Zubereitungs-Aufgaben automatisiert durchführen - iterativ-inkrementelle Arbeit wie im Lehrbuch, mit der Möglichkeit zu ständigen Feedbackschleifen und Verbesserungen. Und wenn am Ende der Küchenchef seine Berufsbezeichnung zum CTO ändert ahnt man, zu welchen Umwälzungen die Digitalisierung führen kann.


1Ich bin mir nicht mehr sicher in welchem ich diese Einblicke bekommen habe, ich glaube aber, dass es das Weiße Bräuhaus war.

Dienstag, 11. April 2017

Agile HR

Bild: Pexels / Fauxels - Lizenz
Zu den Hype-Themen der letzten Jahre gehört sicher die "Agile HR". Agil ist modern, agil ist zukunftsträchtig, also will jeder dabei sein, auch die Personalabteilungen. Bei näherer Betrachtung steckt leider viel zu häufig Cargo Cult dahinter, erkennbar an den Antworten auf die einfache Frage "Was ist denn agil bei Euch?". Klassische Antworten darauf sind "Wir haben jetzt auch ein Board", "Wir machen jetzt auch Sprints" oder "Wir haben jetzt auch ein Daily Meeting". Es werden also lediglich die Rituale kopiert, sonst bleibt alles beim Alten.

Bleibt die Frage - wenn es das nicht ist, was ist es dann? Ist Agile HR überhaupt mehr als ein Buzzword? Ich glaube ja. Obwohl es keine offizielle Definition gibt (von wem auch?) kann man sich den Begriff aus den Grundideen der Agilität herleiten. Agilität im Management-Sinn ist nichts anderes als Reaktionsgeschwindigkeit, also die Fähigkeit möglichst schnelles Inspect & Adapt zur Anpassung an nicht vorhersehbare Veränderungen durchführen zu können. Beispiele für für einen solchen Anpassungsbedarf im HR-Kontext sind der Bedarf nach neuen Rollen (bzw. deren obsolet werden), schnelle Qualifikationsmassnahmen als Reaktion auf technische Herausforderungen oder das häufige Wechseln von Mitarbeitern zwischen Abteilungen. Anders als in der IT, wo technische Aspekte eine wichtige Rolle spielen (Modularisierung, Lastfähigkeit, Automatisierung), wird diese Reaktionsgeschwindigkeit in der HR nur durch organisatorische Faktoren beeinflusst. Zu nennen wären dabei vor allem zwei - der Hierarchiegrad der Organisation und der Strukturierungsgrad der Prozesse. Legt man sie als X- und Y-Achse übereinander entsteht dieses Schaubild:


Die Auswirkungen der beiden Parameter sind klar benennbar: ein hoher Hierarchiegrad verlangsamt alles, schließlich führt er dazu, dass sehr wenige Personen an sehr vielen Entscheidungen beteiligt werden müssen, wodurch Entscheidungen in Warteschleifen stecken bleiben. Auch stark strukturierte Prozesse haben diese Auswirkung. Wenn alles bis in die Details geregelt ist muss für jede Anpassung der offizielle Prozess geändert werden, bis dahin müssen Anpassungen liegenbleiben. Die meisten klassischen HR-Abteilungen sind aber geprägt von Hierarchien und Prozessen, wodurch sie automatisch un-agil werden. Umgekehrt sind geringe Hierarchiegrade (idealerweise dezentralisiert) und schwach strukturierte Prozesse (ersetzt durch Erfahrung und gesunden Menschenverstand) sehr gute Voraussetzungen für Agilität. Je weniger Menschen einer Entscheidung zustimmen müssen und je weniger fest definierte Vorgehensweisen umgeschrieben werden müssen um etwas Neues auszuprobieren, desto schneller kann man sich an Veränderungen anpassen.

Bevor man sich das zu einfach vorstellt - praktisch jede größere Organisation wird sich mit diesem Vorgehen sehr schwer tun. Neue Rollen einführen ohne Verhandlungen zwischen Management und Betriebsrat? Deutschkurse für neue Mitarbeiter, auch wenn das Weiterbildungsbudget eigentlich für Workshops zur Diversitätsförderung verplant ist? Temporäre Übernahme von Führungsrollen in der Nachbarabteilung und danach Rückkehr auf die vorherige Position? Das alles sind harte Brüche mit üblichen Vorgehensweisen, zum Teil verbunden mit deutlichem Macht- und Bedeutungsverlust einiger Akteure, nicht zuletzt in den Personalabteilungen selbst. Aber erst wenn diese angenommen werden kann agile HR überhaupt erst entstehen.

Donnerstag, 6. April 2017

Der Unsinn der 'Lines of Code' - Eine Argumentationshilfe

Bild: Max Pixel - CC0 1.0
Eigentlich mag man es kaum glauben, aber bis heute gibt es noch Manager die es für eine gute Idee halten den Outcome von Entwicklern an geschriebenen Code-Zeilen (Lines of Code) zu messen. Das ist natürlich Unsinn, gefährlicher Unsinn sogar, jeder Entwickler wird das bestätigen. Das Problem: die Manager die diese Messungen durchführen wollen haben in der Regel keinen echten IT-Hintergrund und können die von Entwicklern vorgebrachten Argumente nicht nachvollziehen. Eine Übersetzung ist notwendig, z.B. diese hier.

Stellen wir uns die Lines of Code wie Baumstämme vor, die zum Bau von Blockhäusern verwandt werden. Das fertige Blockhaus entspricht in diesem Fall der zu bauenden Anwendung. Nun könnte man natürlich so argumentieren: je mehr Baumstämme ein Bautrupp verbaut, desto schneller ist das Haus fertig. Diese Zahl nach oben zu treiben ist also scheinbar sinnvoll. Eine Einschränkung müssen wir dem Bautrupp-Leiter (Manager) allerdings mitgeben - genau wie er von der Software-Anwendung nur die Oberfläche sieht, wird er von dem Haus nur die Aussenseite sehen. Wie es innen aussieht weiss er nicht. Und mit diesem Wissen schauen wir uns einige mögliche Blockhäuser einmal näher an.
  • Haus I besteht aus je zwei Seitenwänden zu je 10 Stämmen, zwei Giebelwänden zu je 14 Stämmen und einem Dachstuhl aus 12 Stämmen, in Summe sind hier also 60 Stämme verbaut.
  • Haus II ist eigentlich baugleich zu Haus I, allerdings sind die Wände an den Ecken des Hauses nicht richtig zusammengebaut, wodurch sie sich nicht mehr gegenseitig gerade halten. Um sie zu stabilisieren werden sie von innen durch diagonale Balken gestützt, wodurch in Summe 68 Stämme verbaut wurden.
  • Haus III entspricht weitestgehend auch Haus I, wurde von seinem Bautrupp aber durch eine Innenwand geteilt. Das stand so nicht im Bauplan, erschien dem Team aber irgendwie sinnvoll. Verbaut wurden 70 Stämme.
  • Haus IV wurde mit doppelt so dicken Wänden gebaut, jede Wand ist also zwei Baumstämme dick. Immerhin der Dachstuhl bleibt einfach, im Haus wurden also "nur" 108 Stämme verbaut.
  • Haus V ist nicht benutzbar. Um die Vorgaben zu erfüllen und möglichst viele Stämme zu verbauen wurde der gesamte Innenraum mit ihnen zugestapelt. 200 Stämme fügen sich zu einem massiven, hausförmigen Block.
Man könnte die Beispiele fortführen, es ist aber auch so klar worum es geht. Obwohl in Haus I die wenigsten Stämme verbaut wurden ist es am besten konstruiert worden - Haus II ist instabil und notdürftig stabilisiert, Haus III hat die nicht benötigte Innenwand, bei Haus IV hätte man mit halb so viel Material ein genau so gutes Ergebnis erzielt, Haus V ist einfach nur unsinnig.

Das beste Vorgehen wäre es in diesem Fall gewesen nicht die Anzahl der verbauten Stämme zu messen sondern zu überlegen wie mit möglichst wenig Material ein stabiles und nutzbares Gebäude erstellt werden kann. Und an dieser Stelle beenden wir die Analogie und kommen zurück zu den Lines of Code, bei denen es sich genauso verhält. Es bleibt die Frage: wie soll ein Manager ohne IT-Hintergrund erkennen ob eine Anwendung gleichzeitig schlank, stabil und benutzbar ist? Vielleicht kann er das gar nicht? Nun, wenn das so ist soll er das Urteil darüber anderen Leuten überlassen. Mit dem Erheben sinnloser und kontraproduktiver Metriken hilft er jedenfalls niemandem.

Montag, 3. April 2017

Agile Dilbert

Bild: Wikimedia Commons/Ripounet (1, 2, 3, 4) - CC BY-SA 3.0
Nahezu jeder der in großen Organisationen arbeitet kennt die Dilbert-Comics von Scott Adams, in denen der Büroalltag satirisch überspitzt dargestellt wird. Über die Jahre hat Adams sich an den verschiedensten Themen abgearbeitet, darunter auch an der agilen Softwareentwicklung und agilen Organisationsformen. Ich wollte schon immer mal sammeln was er dazu gezeichnet hat, hier ist die (laufend vervollständigte) Liste:

Agile

Scrum

Extreme Programming

Standup Meetings

Design Thinking

Minimum Viable Products