Montag, 24. April 2017

Ein Bild sagt mehr als 1000 Worte (XVII)

FS

Freitag, 21. April 2017

Wirklich crossfunktionale Teams: multimedialer Journalismus

FS
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

FS
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 Großküche

FS
Bild: Hans/Pixabay - CC0-1.0
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

FS
Bild: Unsplash/Timon Studler - CC0-1.0
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

FS
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

FS
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. Ich wollte schon immer mal sammeln was er dazu gezeichnet hat, hier ist die (laufend vervollständigte) Liste:

Agile

Scrum

Extreme Programming

Complex Products

Donnerstag, 30. März 2017

Kommentierte Links (XXIII)

FS
  • Produktbezogen: Management vs. Produkt. Der ewige Kampf.

    Man lernt immer wieder dazu. Christian Becker zitiert hier aus The Art of Action, dem Buch eines Militärhistorikers namens Stephen Bungay. Basierend auf einem Organisationsmodell der preußischen Armee (woran erinnert mich das?) werden dort drei Wissenslücken beschrieben, mit denen in komplexem Umfeld operierende Organisationen konfrontiert sind:
    1. Knowledge Gap: The difference between what we would like to know and what we actually know.
    2. Alignment Gap: The difference between what we want people to do and what they actually do.
    3. Effects Gap: The difference between what we expect our actions to achieve and what they actually achieve.
    Im Grunde wäre diese Ausgangslage ideal für agile Vorgehensweisen geeignet, im klassischen Management ist aber im Regelfall das Gegenteil der Lösungsansatz - mehr Berichtspflichten, mehr Vorschriften, mehr Kontrolle. Ausführlicher steht das bei Bungay selbst.

  • Extreme Uncertainty: The myth of culture change

  • Weise Worte von Leon Tranter: eine Unternehmenskultur kann man nicht nur durch Anordnungen ändern, dazu ist sie zu tief in den Prozessen verankert. Was bringen zum Beispiel alle Bekenntnisse zu einer Kultur der Verantwortungsübernahme und Selbstorganisation wenn immer noch die Einhaltung aller Vorgaben, Detailreporting und Gruppenkonformität verlangt werden? Im Sinne eines Function follows Form-Ansatzes geht Tranter davon aus, dass erst geänderte Arbeitsbedingungen eine neue Kultur ermöglichen, bzw. sie zum Resultat haben. Erst wenn die Mitarbeiter selbst entscheiden können (und müssen) welche Arbeit sie bis wann erledigen wollen wird sich überall die entsprechende Kultur herausbilden. Das kann man so sehen, es kollidiert aber z.T. mit anderen Sichtweisen (zum nächsten Absatz bitte).

  • Lars Vollmer: Organisationskultur ist keine Frage der Entscheidungen

    Man kann sich mit vollem Recht fragen: warum muss eine Firma immer eine einheitliche Organisationskultur haben? Sind die Menschen dafür nicht zu unterschiedlich? Und hätte das nicht zur Folge, dass ein Teil der Mitarbeiter sich immer verbiegen muss um den Erfordernissen der Firmenkultur zu entsprechen? Vollmer erklärt das hier am Beispiel von zwei unterschiedlichen Abteilungen (Elektrotechniker und Biologen), aber selbst innerhalb einzelner Abteilungen kann man die Frage stellen wie zielführend eine Einheitskultur ist. Welche Auswirkungen eine Vereinheitlichung auch da haben kann hat fast zeitgleich Sal Freudenberg unter der treffenden Überschrift When the culture becomes the cult aufgeschrieben. Nicht zum Nachmachen empfohlen.

  • Zeit: Der Mitarbeiter, das Versuchskaninchen?

    Menschenversuche. Klingt böse, ist aber letztendlich nichts anderes als die konsequente Umsetzung von Inspect & Adapt in der Organisationsentwicklung. Was Nico Rose hier schreibt ist nämlich State of the Art der Wissenschaft: nur durch den Vergleich mehrerer Versuchsgruppen kann man erkennen, welche Lösungsansätze funktionieren und welche nicht. Und darüber hinaus: nur durch eine zufällige Auswahl nicht eingeweihter Probanden lassen sich Laboreffekte vermeiden. In der Realität großer Organisationen dürften solche Experimente allerdings an der Geheimhaltung scheitern. Was dagegen vorkommen kann ist das Arbeiten nach verschiedenen Methoden aufgrund politischer und/oder historischer Ursachen. Auch das lässt sich auswerten: Ich habe einmal ein Nebeneinander von agilen und nichtagilen Teams erleben dürfen. Am Ende waren die agilen Teams den anderen um ein Jahr voraus.

  • Retrospective.co: Brilliant Jerks Cost More Than They Are Worth

    Vor einigen Jahren war es ein kurzzeitiger Hype bei einigen meiner Kunden "Rockstars" anzuheuern, worunter Entwickler verstanden wurden, die (angeblich) so gut waren, dass sie kritische Situationen im Alleingang retten konnten. Das Problem: sie neigten auch dann zu Alleingängen wenn das gar nicht nötig war und waren dann meistens nicht kritikfähig. Neben den in diesem Artikel genannten zersetzenden Auswirkungen auf die Arbeitsatmosphäre führte das zu verschiedenen Formen von Code Ownership. Meines Wissens nach spielen alle diese "Rockstars" heute Solotourneen.
Powered by Blogger.