Donnerstag, 23. Juni 2016
Teamübergreifende Konfiguration digitaler Kanban-Boards
Wer sein Board nicht nur in physischer sondern auch in digitaler Form haben will kann mittlerweile zwischen einer ganzen Reihe von Programmen wählen: Jira, Agile Manager, Redmine, Rally, ScrumDo, Trello und viele weitere können benutzt werden und sie alle funktionieren mehr oder weniger gut. Problematisch wird es aber, wenn mehr als ein Team ein gemeinsames Tool benutzt und die verschiedenen Teams unterschiedliche Konfigurationen vornehmen. Findet das ohne gegenseitige Absprachen statt kann man fest davon ausgehen, dass eines der folgenden Probleme auftreten wird:
1. Edit Wars
Der Name sagt eigentlich bereits alles. Ein Team ändert die Konfiguration und verändert damit auch alle anderen Boards. Jemand aus den anderen Teams merkt das und macht es rückgängig, jemand aus dem ersten Team wiederholt die Änderungen, etc., etc., etc. Ein solcher Edit War muss auch nicht notwendigerweise auf irrationaler Sturheit der Beteiligten beruhen - gerade in größeren Firmen, in denen 20, 50 oder noch mehr Teams ein gemeinsames Tool benutzen, kann es sein, dass gar nicht festzustellen ist wer die letzten Änderungen vorgenommen hat. Dem Verursacher sind die Folgen seines Tuns vielleicht gar nicht bewusst, und dass die veränderten Einstellungen ständig zurückgesetzt werden wird eher einem Bug zugeschrieben als einem Kollegen. Ich durfte einmal miterleben, dass die Standardkonfiguration in einer Firma über Wochen immer wieder von Story Points zu Personentagen und von Personentagen zu Story Points geändert wurden. Erst als die gesamte Belegschaft zusammengerufen wurde und alle sich melden mussten die in letzter Zeit Änderungen vorgenommen hatten hörte das Hin und Her auf.2. Kaputtkonfigurierte Tools
Auch das habe ich bereits mitmachen müssen. Jedes von mehreren Teams hatte spezielle Workflows, die es auf seinem Board sehen wollte. Für die einen waren es Spalten für Rewiew und Release, für die anderen Akzeptanztest und Resolved, wieder andere wollten anzeigen können auf welchen Umgebungen sich die entwickelten Features befanden. Die salomonische Lösung der Admins war, dass alle Wünsche gleichzeitig umgesetzt wurden, so dass die Boards am Ende 17 (!) verschiedene Spalten hatten. Den Entwicklern wurde mitgegeben, dass sie doch einfach nur die benutzen sollten, auf die sich ihre Teams geeinigt hatten, die anderen sollten sie ignorieren. Als wäre das nicht bereits kompliziert genug enthielt die Konfiguration auch noch mehrere Workflows, die beim Verschieben der Tickets einzuhalten waren - zum Beispiel To Do-In Progress-Review-Done, To Do-Design-In Progress-Test-Resolved oder To Do-In Progress-Done-Release. Wenn jetzt ein Ticket versehentlich von In Progress auf Test geschoben wurde statt auf Review konnte der Finale Status nicht mehr Done sein sondern nur noch Resolved. Da die Reports aber nur nach einem dieser Status filtern konnten wurden sie dadurch immer wieder verfälscht.3. Jenga-Konfigurationen
Im Grunde ein Sonderfall von kaputtkonfigurierten Tools. Vom ersten Eindruck her ist alles in Ordnung, jedes Team hat ein nach seinen Bedürfnissen konfiguriertes Board, alle Workflows funktionieren. Das verborgene Problem tritt auf sobald an irgendeiner Stelle eine zusätzliche Anpassung gemacht wird: wie bei einem Jenga-Turm führt nämlich jede einzelne Veränderung sofort zum Zusammenbruch des Gesamtkonstrukts. Verschiedene Boards benutzen in wilder Kombination verschiedene Workflows, Status, Verknüpfungen und Beschränkungen, und da das alles "historisch gewachsen" ist kann keiner mehr genau sagen welche Einstellung mit welcher anderen zusammenhängt. Irgendeinen Zusammenhang gibt es aber fast immer, im schlimmsten Fall sogar mit ganzen Kaskaden von Abhängigkeiten, so dass eine kleine Änderung ausreichen kann um das Gesamtsystem unbrauchbar zu machen.Legacy-Systeme
Wenn diese Proble auftreten - wie geht man mit ihnen um? Im Fall von Edit Wars ist es relativ einfach: in den meisten Fällen hilft es wenn die Kommunikation verbessert wird (siehe oben), im schlimmsten Fall muss durch einen Mehrheitsendscheid oder ein Geschäftsführer-Machtwort eine Entscheidung herbeigeführt werden. Anders ist es im Fall von kaputtkonfigurierten Tools oder Jenga-Konfigurationen. In diesen Fällen führt langfristig kein Weg daran vorbei das System wieder zu vereinfachen und zu vereinheitlichen, was häufig in kleinteilige und langwierige Arbeit ausarten kann. Die dafür nötigen Aufwände fehlen dann natürlich bei der Produktentwicklung. Um dem Management begreiflich zu machen, dass sich dieses Investment lohnt empfiehlt sich der Vergleich mit Legacy-Code. Auch der muss schließlich zeitaufwändig refactored werden um wartbar und bearbeitbar zu bleiben. So verargumentiert kann nebenbei sogar noch etwas Vorteilhaftes herausspringen: selbst technikfremde Manager können an diesem Beispiel sehr schön erkennen, welche Auswirkungen technische Schulden haben können.Montag, 20. Juni 2016
A talk that will inspire your thoughts
Ich gebe es zu, ich bin ein Blender, zumindest manchmal. Um das nötige Scrum Master-Charisma aufzubauen benutze ich von Zeit zu Zeit rhetorische und gestische Tricks um überzeugender herüberzukommen. Teams stehen auf sowas. Manager auch. Und als würde mir ein Spiegel vorgehalten - einiges davon habe ich in dem Video hier wiedergefunden. Zum Schreien komisch und absolut wahr.Mittwoch, 15. Juni 2016
Scrum Alliance gründet German Chapter
Es geschieht gerade etwas Interessantes hier in Deutschland - die Scrum Alliance gründet eine nationale Unterorganisation, das so genannte "German Chapter". Verkündet wurde es in dieser Woche per Email.
So wie es aussieht nimmt Deutschland damit eine Vorreiterrolle ein, schließlich wird dieses Chapter der Mail zufolge das erste seiner Art sein. Der weitere Inhalt ist denkbar banal, er enthält neben der hier gezeigten Einleitung nur einen Link zu einer Umfrage zur bevorzugten Sprache (deutsch oder englisch). Gleichzeitig wird aber auch angekündigt, es wäre nur die erste Nachricht von vielen, so dass man gespannt sein kann wie es weitergeht.
Ich bin mir noch nicht ganz sicher was ich von einer nationalen Scrum-Organisation erwarten kann oder will, stehe dem ganzen aber erstmal offen gegenüber. Eine Chance und gleichzeitig auch ein Risiko sehe ich darin, dass versucht werden könnte die Deutungshoheit über den Namen Scrum zu gewinnen. Zum einen könnte das der steigenden Anzahl der unseriösen Berater entgegenwirken, die unter diesem Label auch noch den größten Blödsinn verkaufen (Michael Küsters vergleicht sie nicht ohne Grund mit Wundermittel verkaufenden fahrenden Quacksalbern). Zum anderen besteht aber das Risiko, dass angestrebt wird ein Monopol auf den Begriff zu erheben, was ja anscheinend in Amerika bereits versucht wurde.
Aber wie gesagt, zunächst einmal bin ich offen und neugierig. "Embrace Change" heißt es ja. In dem Sinne - lassen wir uns überraschen.
Montag, 13. Juni 2016
Agile und Scrum funktionieren in diesem Land nicht [egal von welchem wir reden]
 |
| Grafik: Wikimedia Commons/Colomet - CC BY-SA 3.0 |
An diese Gespräche muss ich denken, wenn ich regelmässig Artikel lese wie Why Agile does not Work In Germany oder Scrum does not work here in Asia. Sie alle (genau wie die oben genannten Kollegen) nennen immer wieder die selben Argumente: Bei uns(™) legen die Menschen zu viel Wert auf Hierarchien, die Gesellschaft ist zu traditionell, es gibt keine Fehlertoleranz, die Firmen sind zu stark durch klassisches Management geprägt. Und darum können dort(™) Scrum und andere agile Methoden nicht funktionieren. Nicht im Startup und nicht im Konzern. Grundsätzlich nicht. Aus Prinzip nicht. Nie nicht. Niemals!
Anders ist es natürlich in anderen Ländern (meistens dort wo man nicht herkommt oder ist). Da ist alles viel besser. Da(™) sind die Hierarchien flacher, die Menschen offen für den Fortschritt, aus Fehlern lernt man, die Firmen erproben neue Management-Konzepte. Aber diese tollen Zustände gibt es natürlich nicht überall, sondern nur in Amerika. Oder in Schweden. Oder in England, Frankreich, Indien, Japan, der Schweiz und Deutschland. Und spätestens jetzt wird klar: alle diese Geschichten sind nichts als grober Unfug.
Zum einen gibt es in jedem Land der Welt Menschen, die hierarchieverliebt, veränderungsablehnend, Fehler-avers und von Command & Control geprägt sind. Sogar im gelobten agilen Land Amerika gibt es sie, einige der un-agilsten Manager die ich jemals getroffen habe kamen aus dem Silicon Valley. Auf der anderen Seite kommen einige der besten Scrum Master und agile Coaches die ich erleben durfte aus Indien, Japan, Russland, Singapur oder anderen Ländern, wo es sie "kulturell bedingt" gar nicht geben dürfte. Kurz gesagt - wer behauptet, in bestimmten Ländern würden Agile und Scrum nicht funktionieren, erzählt Quatsch.
Aber wenn das so ist - warum dann diese Geschichten? Aus meiner Erfahrung gibt es dafür vor allem drei Gründe: entweder um zu erklären, warum man von zu Hause weggegangen ist, obwohl dort eigentlich "alles viel besser ist" (Wetter, Essen, Laune, Leute, etc.). Oder um das eigene Scheitern zu beschönigen. "Scrum funktioniert dort nicht" ist ein viel bequemerer Grund als "Es war von Anfang an eine schlechte Idee, nur billige Junior- und Offshore-Entwickler einzustellen". Häufig aber auch, weil man einen Grund sucht um die eigenen Beratungsdienstleitungen zu verkaufen. "Ja, Ihr habt leider ein kulturelles Problem mit agilen Methoden. Aber mit mir als Scrum Coach kommt Ihr ganz sicher darüber hinweg."
Aber ganz egal warum man erzählt, dass Scrum in einem bestimmten Land aus Prinzip nicht funktioniert - wahr wird es dadurch nicht.
Donnerstag, 9. Juni 2016
Club der toten Teams
Manchmal findet man zufällig bemerkenswerte Dinge. Über einen interessant klingenden Tweet bin ich gestern auf dieses Video hier gestoßen und saß danach eine Stunde lang auf dem Balkon um es anzusehen.Das Thema des Vortrags ist Motivation, aber er streift auch verschiedene andere Bereiche und enthält immer wieder launige Anspielungen auf IT-Projekte. Und ganz nebenbei ist er ein gutes Beispiel für eine gelungene Powerpoint-gestützte Präsentation. Auch davon gibt es ja viel zu wenige.
Montag, 6. Juni 2016
Eine alternative Festlegung von Sprint-Längen
 |
| Bild: Wikimedia Commons/Photobobil - CC BY 2.0 |
Für Unternehmen die mit Scrum arbeiten kann das ein Problem sein. In den Mai-Sprints stehen weniger Arbeitstage zur Verfügung, es wird weniger vervollständigt, die Velocity sinkt. Und an dieser Stelle tritt ein Verfälschungseffekt ein: das Sinken der Velocity liegt nicht an sinkender Leistungsfähigkeit sondern eben an den Feier- und Brückentagen. Das lässt sich allerdings aus den Zahlen nicht herauslesen - sowohl in der kurzfristigen als auch in der langfristigen Auswertung wirkt das Absinken wie ein Leistungsabfall. Wenn man jetzt basierend auf der Velocity eine Prognose der verbleibenden Arbeitszeit machen will wird diese unrealistisch niedrig sein.
Ein Unternehmen mit dem ich vor ein paar Jahren zu tun hatte, hatte einen interessanten Weg gefunden mit diesem Effekt umzugehen: Sprint-Längen wurden dort nicht in Wochen festgelegt sondern in Arbeitstagen, z.B. 10 Arbeitstage pro Sprint. Ein Sprint im letzten Mai hätte demnach nicht einfach die Kalenderwochen 20 und 21 umfasst sondern wäre wegen des Feiertages am Pfingstmontag erst am 17. losgegangen und 10 Werktage später am Montag dem 30. beendet worden.
Für jedes Unternehmen das auf diese Weise vorgeht hat die Velocity eine wesentlich höhere Aussagekraft und Brauchbarkeit als für diejenigen, die noch mit Kalenderwochen arbeiten. Auf der Negativseite ist es dafür aber auch so, dass der "gefühlte Rhytmus" aus dem Gleichgewicht kommen kann, schließlich können Planning, Review und Retrospektive jetzt nicht mehr alle zwei Wochen stattfinden sondern gegebenenfalls etwas später. Vor allem bei der Einbindung von Stakeholdern kann das zu Problemen führen.
Andererseits - irgendwelche Probleme gibt es ja immer. Für mich kommt diese alternative Festlegung von Sprint-Längen auf jeden Fall auf die Liste der Dinge die ich irgendwann mal ausprobieren muss.
Donnerstag, 2. Juni 2016
Erziehung zur Normverletzung
 |
| Bild: Wikimedia Commons/Indeedous - CC BY 2.0 |
Im Kern erzählte Gysi von einer Unterhaltung mit katholischen Geistlichen, die er mit folgenden Argumenten konfrontierte: Wenn man Sex als etwas ansieht, dass nur zum Zweck des Kinder Zeugens erlaubt ist, dann reduziert sich die Anzahl der im gesamten Leben zulässigen Geschlechtsakte auf eine niedrige zweistellige Anzahl. Das ist natürlich völlig unrealistisch, den natürlichen Trieben folgend ist die Anzahl viel höher, was die Kirche auch weiß. Wenn sie trotzdem an ihren Vorschriften festhält nimmt sie bewusst in Kauf, dass praktisch jeder und jede zigfach dagegen verstößt. Gysi dachte diesen Gedankengang aber noch weiter: wenn die Kirche sehenden Auges dafür sorgt, dass die Menschen permanent gegen eine ihrer zentralen Regeln verstoßen, dann ist das nichts anderes als eine "Erziehung zur Normverletzung". Und diese hat zur Folge, dass der Respekt vor Regeln und Normen grundsätzlich beschädigt wird. Die Konsequenz ist, dass auch andere nicht mehr eingehalten werden.
In Unternehmen, vor allem in großen, kann man genau dieses Phänomen immer wieder vorfinden. Es werden Regeln aufgestellt von denen klar ist, dass sie gar nicht befolgt werden können, weshalb sie von den Mitarbeitern ständig umgangen werden. Die Folge ist dann irgendwann eine konsequente Ablehnung nahezu aller Regeln durch die Belegschaft, die strukturiertes Vorgehen jeglicher Form schwierig bis unmöglich macht (ich hatte schonmal unter dem Namen "Konzern-Anarchismus" etwas dazu geschrieben). Alleine das sollte ein ausreichender Grund sein es sich dreimal zu überlegen, bevor vorschnell irgendwelche Regeln eingeführt werden. Im Zweifel bewirken sie nämlich das Gegenteil dessen was sie bewirken sollen.
Montag, 30. Mai 2016
Kommentierte Links (XIII)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Mike Cohn: Don’t Estimate the Sprint Backlog Using Task Points
Eines meiner ersten Teams hatte ebenfalls die Idee eine Schätzung nach Task-Points zu machen, und dort habe ich es auch für einen sinnvollen Ansatz gehalten. Die Situation war allerdings eine besondere: alle Teammitglieder waren große Fans von Mob- oder Pair-Programming. Aus diesem Grund wurden fast alle Tasks gemeinschaftlich bearbeitet, weshalb es (analog zur Story) Sinn machte, eine neutrale Bewertungsmetrik zu haben. Dort wo es eher die Entwickler mit Schwerpunkten für Frontend, Backend, QA, etc. gibt, die auch alle in erster Linie ihre Spezialtasks bearbeiten, da macht es weit weniger Sinn.
Nature: A platform for the discovery of newmacrolide antibiotics
Vermutlich würden die sechzehn Verfasser dieses Nature-Artikels ihr Vorgehen nicht als agil bezeichnen (ich unterstelle einfach mal, dass sie den Begriff gar nicht kennen), letztendlich ist es aber genau das. Ausgangsproblem ist, dass Bakterienstämme durch Gewöhnung immer wieder gegen Antibiotika immun werden. Die neue Methode erlaubt es jetzt, die grundlegenden Moleküle nach einem Baukasten-System auseinanderzunehmen, zu modifizieren und wieder zusammenzusetzen. Der so enstandene Wirkstoff wird anschließend gegen die bekannten Bakterienstämme getestet. Ist er wirksam kann er in die Produktion gehen, ist er es nicht wird er erneut modifiziert und getestet, so lange bis das gewünschte Ergebnis erzielt ist. Build, inspect and adapt in der Chemie.
Verena Töpper, Leo Widrich: "Wir veröffentlichen alle Gehälter im Internet"
Irgendwie ist es ein journalistischer Reflex geworden, auf jede Firma anzuspringen, die ihre Gehälter transparent macht. Was ich an diesem Interview mit Leo Widrich interessant finde ist aber etwas völlig Anderes: ganz im Sinne der Idee selbstverwalteter Teams wurde in seiner Firma das Management abgeschafft - nur um ein halbes Jahr später wieder eingeführt zu werden. Das deckt sich mit meiner Erfahrung, dass viele Teams mit zu viel Freiheit schnell überfordert sind. Das heißt übrigens nicht, dass das so nicht geht, es geht eben nur seltener als erhofft. Leider.
Mark Poppenborg: Überwachung am Arbeitsplatz - wie sie in sechs Phasen entsteht [Edit: Link ist mittlerweile tot]
Treffend beschrieben von Mark Poppenborg. Was mir zusätzlich dazu von Zeit zu Zeit begegnet ist ein noch bemerkenswerteres Phänomen: selbstverwaltete Teams begeben sich selbst ohne Not in derartige Überwachungen hinein. Ähnlich wie in diesem Beispiel sind es zu Beginn durchaus rationale Beweggründe, zu denen allerdings bald etwas Verheerendes hinzukommt - das Bedürfnis nach Einzelfallgerechtigkeit. Sobald dem nachgegeben wird verstricken sich auch gute Teams in den absurdesten Regelwerken, denen irgendwann nur noch wie dem gordischen Knoten beizukommen ist: alles in Stücke hauen und wegwerfen.
John Cutler: Real World Kanban (A Cartoon)
Traurig, aber wahr. Und lustig. Ein bisschen.
