Buch-Rezension zu „Java by Comparison“

Java by Comparison“ von Simon Harrer, Jörg Lenhard und Linus Dietz erschien 2018 bei The Pragmatic Programmers. Dieses Buch wagt sich an eine grosse Herausforderung: Wie kann man das über Jahre angeeignete Expertenwissen in einfacher Form Programmier-Anfängern zugänglich machen?

Buch-Rezension zu „Java by Comparison“ weiterlesen

Technische Schulden verfolgen mit NDepend 2017.2

NDepend nutzte ich mittlerweile häufig zur Analyse meiner Anwendungen. Die statische Codeanalyse liefert zwar kein vollständiges Bild zum Zustand einer Anwendung, aber man erhält genügend Informationen um Probleme frühzeitig zu erkennen. Die früheren Versionen hatte ich bereits hier und hier beschrieben.
Technische Schulden verfolgen mit NDepend 2017.2 weiterlesen

Erfahrungen mit Kanban

Ich nutze Kanban nun bald 2 Jahre. Neben Personal Kanban nutzte ich diese Methode um Präsentationen vorzubereiten, Software zu entwickeln, Reisen zu planen und noch vieles mehr. Dabei konnte ich zahlreiche Erfahrungen sammeln von denen ich hier die wichtigsten vorstellen möchte.

 

Kanban lässt sich beliebig einsetzen

Kanban ist sehr einfach, flexibel und lässt sich schnell erklären. Damit ist es sehr gut geeignet um überall dort zum Einsatz zu kommen wo man eine Verbesserung herbeiführen will. Damit zeigt sich aber auch gleich die Grenze von Kanban. Wenn alles optimal läuft oder man keine Verbesserung erzielen will sollte man auf Kanban verzichten. In diesen Situationen ist es nur ein Zusatzaufwand der in keinem Verhältnis zum möglichen Ertrag steht.

 

Kanban profitiert von einer Definition of Done

Auch wenn Kanban nirgends von einer Definition of Done spricht, so ist eine gemeinsam definierte Minimalanforderung an jeden Task eine hilfreiche Sache. Dabei müssen die Anforderungen aber zum Inhalt passen. „Ist in der Versionsverwaltung eingecheckt“ funktioniert nicht für den Task „Kaffeemaschine entkalken“.

 

Kanban erzwingt Transparenz

Das erste heikle Problem kann bei Kanban bereits beim Visualisieren der Arbeitsabläufe auftreten. Was soll man dort modellieren? Der Ablauf nach Prozess X oder das was gelebt wird? Richtig funktionieren wird Kanban nur wenn man die gelebte Realität abbildet. Man kommt nicht umher die Diskrepanzen zwischen Soll und Ist anzugehen und zu schliessen. Kann oder will man dies nicht machen sollte man gleich ganz auf Kanban verzichten. Man erspart sich so endlose Diskussionen.

Arbeitet man im Team warten die nächsten Herausforderungen: Was macht man wenn sich die Tickets immer am gleichen Ort stauen? Wie geht man damit um das sich einzelne Mitglieder nicht beteiligen wollen?

Auch wenn dies nicht ein Kanban spezifisches Problem ist, so wird es hier doch ins Scheinwerferlicht gerückt. Die dadurch erzwungene Transparenz ist eine grosse Chance für Verbesserungen an den Stellen die wirklich einen Einfluss haben. Aber auch dies muss man wollen.

 

WIP-Limits helfen beim fokussieren

Die bewusste Einschränkung auf einige wenige (gleichzeitige) Arbeiten finde ich äusserst hilfreich. Macht man zu viele Dinge nebeneinander kommen zwar immer viele Tasks ein klein wenig voran – aber viel zu oft wird nichts davon wirklich fertig. Investiert man Wochen für Dinge die dann doch alle nur 90% fertig sind ist dies demotivierend.

Kanban zwingt einem mit den WIP-Limits dazu die angefangenen Arbeiten zu vollenden bevor man hinter die nächste Aufgabe geht. Natürlich kann man hier viel tricksen und hohe WIP-Limits setzen.
Nur dadurch bleibt alles wie gehabt und die ganzen Arbeiten sind dann nur teure Mehrarbeit. Aus meiner Erfahrung ist es daher umso wichtiger den Fortschritt regelmässig zu prüfen und stetig an einer Verbesserung zu arbeiten – denn nur so geht es mit den wenigen Regeln von Kanban wirklich vorwärts.

 

Neben den WIP-Limits auch den Prozess optimieren

Für mein Personal-Kanban Board experimentiere neben den WIP-Limits auch mit dem Pro-zess. Da nur ich davon betroffen bin geht dies sehr einfach und ich habe den nötigen Spiel-raum für Veränderungen. Ich kann dies sehr empfehlen, vor allem wenn man ein nicht genauer definierbares Gefühl hat das irgendetwas an den Abläufen noch nicht so ganz passt.

Nach einigem hin und her bin ich nun wieder auf der Startversion von Leankit angekommen, allerdings mit einer zusätzlichen Spalte „this week“. Darin stehen alle Arbeiten die in dieser Woche erledigt werden müssen. Für mich ist die Unterteilung in Wochen hilfreich da ich so einen guten Kompromiss von Freiraum und Einschränkungen habe. Eine Unterteilung nach aktuellem Tag war für mich viel zu eng und bei einem Monat fehlte mir die Fokussierung.

 

Aufwandschätzung minimieren

Ich schätze alle Aufgaben die auf mein Kanban-Board sollen nur minimal ab und nutze dafür diese 3 Grössen:

  • 1 für ganz kleine und schnell zu erledigende Aufgaben
  • 2 für Aufgaben die zwischen 1-2 Stunden brauchen
  • 3 für abendfüllende Aufgaben

Grössere Aufgaben unterteile ich bis diese in eine dieser 3 Schubladen passen. Die Idee dazu kommt vom Messen mit T-Shirt Grössen (S, M, L). Statt 1, 2 oder 3 könnte die Unterteilung auch S, M oder L sein. Da die von mir verwendete Software von Leankit allerdings nur Zah-len als Grösse unterstützt wurde es halt 1, 2 und 3.

Obwohl diese Unterteilung nur sehr Oberflächlich ist kann ich damit recht gut (oder genauer gesagt genügend genau) abschätzen bis wann meine Aufgabenliste abgearbeitet sein wird. Wie ich durch das Messen der erledigten Aufgaben herausfand ist die Schwankung der erledigten Arbeiten von Woche zu Woche deutlich grösser als die Schätzungenauigkeit. Möchte ich eine genauere Vorhersage über den Abschluss eines grösseren Arbeitspaketes haben müsste ich dementsprechend nicht bei den Schätzungen sondern am gleichmässigeren abarbeiten ansetzen.

 

Karten schieben alleine genügt nicht

Obwohl man bei Kanban Karten herum schiebt geht es dabei um weit mehr als nur das schie-ben dieser Karten. Die Karten repräsentieren eine Aufgabe und das herumschieben deren Be-arbeitung. Wenn die Aufgabe keinen Wert hat und nur gemacht wird damit man etwas schie-ben kann hat man das Ziel verfehlt. So ist man zwar beschäftigt, erzielt aber keinen Fortschritt und verschwendet damit nur seine Zeit.

Daher sollte man unbedingt regelmässig überprüfen ob die vorhandenen Karten wirklich noch benötigt werden. Das Backlog muss wie bei Scrum gepflegt werden. Aufgaben die sich erle-digt haben oder nicht mehr benötigt werden sind zu löschen. Also nicht einfach auf die Seite legen oder in einer anderen Liste führen, sondern wirklich unrückholbar löschen. Sollte wirk-lich einmal etwas zu früh gelöscht werden wird diese Aufgabe wieder verlangt werden.

 

Kanban macht die Arbeit nicht alleine

Auch wenn man Kanban einsetzt muss die Arbeit immer noch gemacht werden. Man kommt nicht daran vorbei die Tasks auch wirklich zu bearbeiten. Kanban hilft einem beim Visualisieren der Arbeitsschritte und beim fokussieren – es nimmt einem die Arbeit aber nicht ab.

 

Fazit

Kanban ist kein Allerheilmittel und es gibt Situationen wo der Einsatz kontraproduktiv ist. Will man aber eine Veränderung herbeiführen und glaubt an die schrittweise, inkrementelle Verbesserung ist Kanban ein sehr guter Ansatz.

Um zu starten braucht es wenig und wenn es für einen nicht stimmt kann man ohne grossen Verlust weiter machen wie bisher. Wer eine Verbesserung seiner Arbeitsorganisation möchte soll nicht zögern: Ein Blatt Papier und Post-It Zettel genügen für den Start…

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Buch-Rezension zu „Kanban and Scrum“

Kanban and ScrumKanban and Scrum – making the most of both“ von Henrik Kniberg und Mattias Skarin erschien Ende 2009 bei InfoQ. Kanban und Scrum sind 2 Begriffe die im Zusammenhang mit agiler Softwareentwicklung immer häufiger fallen. Aber was ist nun Kanban? Und wie verhält sich dies zu Scrum? Auf diese und noch viele weitere Fragen liefert das Buch auf rund 100 Seiten eine Antwort.

Bei dieser Seitenanzahl darf es einem nicht verwundern wenn man keine umfassende Erklärung in alle Details rund um Kanban und Scrum bekommt. Den Autoren gelingt es aber dennoch alles Wesentliche auf den Punkt zu bringen. Man kann so in kurzer Zeit abschätzen ob Kanban oder Scrum etwas ist was man vertiefter anschauen will.

 

Teil 1: Vergleich von Scrum und Kanban

Im ersten Teil macht Henrik Kniberg einen Vergleich zwischen diesen beiden Ansätzen. Er zeigt objektiv auf was die beiden Modelle für Gemeinsamkeiten haben und wo die Unterschiede liegen. Man merkt schnell das Scrum mehr Regeln mitbringt als Kanban und so viel mehr Einfluss auf den Arbeitsablauf ausübt. Kanban erlaubt einem aber durchaus die Teile von Scrum zu übernehmen die einem dort besonders gefallen.

Dieses Fallweise übernehmen von Vorgaben und Empfehlungen bietet einem eine sehr flexible Lösung. Wem Scrum zu fix ist sollte einen Blick auf Kanban werfen. Und wem Kanban zu wenig konkret ist kann sich bei Scrum umschauen.

 

Teil 2: Detailliertes Fallbeispiel

Mattias Skarin beschreibt im zweiten Teil was für Erfahrungen er machte bei der Einführung von Kanban in einer skandinavischen Firma. Die Entwickler die nach Scrum arbeiten treffen auf den technischen Betrieb, der sowohl die Entwickler unterstützen wie auch den Betrieb aufrecht erhalten soll. Ein sofortiges lösen von Betriebsproblemen lässt sich nur schwer mit den Iterationen von Scrum in Einklang bringen. Kanban dagegen ist flexibel genug um auch solche Dinge zu ermöglichen.

Wo fängt man aber mit Kanban an und wie integriert man es mit Scrum? Skarin beschreibt dies meiner Meinung nach sehr gut: Egal wo wir anfangen, wir werden es ändern müssen. Also beginnen wir einfach und machen Änderungen sobald diese nötig werden.

Ein tägliches Stand-up Meeting, eine Retrospektive am Iterationsende und das Führen eines Impediment Backlog sind Aktivitäten mit denen Kanban in diesem Fallbeispiel angereichert wurde.

 

WIP Limits für schnelles Angehen eines Problems

Unter dem Titel „One day in Kanban-land“ gibt es ein sehr gutes Beispiel zum Wert von WIP Limits (also einer maximal erlaubten Menge von Arbeit die in einem Verarbeitungsschritt gleichzeitig in Bearbeitung sein darf).

Kanban-Board mit WIP

Für die Tätigkeit Entwicklung wurde ein WIP Limit von 2 vorgegeben. Diese Grenze gilt dabei sowohl für das was gerade entwickelt wird wie auch für die Pakete die aufs testen warten. Gibt es im Test (wo das WIP Limit 1 ist) ein Problem staut sich die Arbeit in der Entwicklung. In kurzer Zeit erreichen die Entwickler ihre Grenze und können keine neue Arbeit beginnen. Die so vorhandene Kapazität kann man nun nutzen um die Probleme im Test anzugehen.

Kanban-Board: WIP erreicht

Wird in der Entwicklung nicht die geforderte Qualität erreicht merkt man dies in diesem Beispiel nach dem 3. Arbeitspaket. Man kann so mit einer Verbesserung in der Entwicklung starten wenn der Schaden noch klein ist. Dies ist deutlich billiger und schneller als wenn man dies erst am Ende beim Abnahmetest bemerkt…

 

Download

Das Buch gibt es sowohl als Paperback wie auch als E-Book zum kostenlosen Download. Vom E-Book gibt es mittlerweile zahlreiche Übersetzungen, die leider nicht alle an die Qualität des Originals heran kommen.

 

Fazit

Wer einen Einblick in Kanban haben möchte oder wissen will wo die Unterschiede zu Scrum sind ist mit diesem kleinen Buch sehr gut bedient. Man bekommt in sehr kurzer Zeit alles Wesentliche mit und hat eine gute Grundlage um sich vertieft mit Kanban oder Scrum zu beschäftigen.

 

Zum Buch

Kanban and Scrum – making the most of both“ von Henrik Kniberg und Mattias Skarin, 2009 InfoQ, ISBN: 978-0-557-13832-6, 120 Seiten, Englisch

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Werkzeuge für Kanban

Auch bei den Werkzeugen ist Kanban sehr flexibel. Um den Arbeitsablauf (oder Prozess) zu visualisieren benötigt man ein Kanban-Board. Wie dies auszusehen hat und wie man dies organisiert bleibt jedem selber überlassen.
Was für erfahrene Anwender von Kanban sehr praktisch ist stellt Neulinge vor eine Herausforderung. Zu nutzen was für einen am besten passt ist ein gut gemeinter Ratschlag – zu Beginn fehlt einem aber die Erfahrung um damit auch etwas anfangen zu können.

Aus diesem Grund stelle ich heute 4 verschiedene Möglichkeiten für ein Kanban-Board vor, denn es muss nicht immer ein Whiteboard sein. Arbeitet man an verschiedenen Orten oder in Teams ist eine elektronische Lösung oft praktischer. Die Liste hier ist nicht abschliessend und ich würde mich über Kommentare freuen bei denen zusätzliche Möglichkeiten vorgestellt werden. Gleiches gilt für andere Werkzeuge, die einem bei den Arbeitsabläufen unterstützen können.

 

Minimal

Macht man Kanban nur für sich alleine und hat keine grosse Infrastruktur zur Verfügung kann man mit einer ganz minimalistischen Umgebung arbeiten. Im Grunde genügen Post-it Zettel und der eigene Schreibtisch.

So lange man nur wenige Tätigkeiten verwalten will kann man jeden Task einzeln auf einen Post-it Zettel schreiben. Was links von einem auf dem Schreibtisch klebt ist zu tun, das was man direkt vor sich hat ist in Arbeit und was rechts klebt ist erledigt. Die gleichzeitig bearbeiteten Aufgaben minimiert man in dem man bewusst nur dann eine zusätzliche Aufgabe startet wenn das gesetzte WIP-Limit noch nicht erreicht ist.

Nutzt man verschiedene Farben für unterschiedliche Prioritäten kann man recht einfach seine Arbeiten auswerten. Waren die meisten Arbeiten ganz dringende ungeplante Tätigkeiten kann man für die nächste Woche seine Erwartungen hinsichtlich dem Fortschritt der Taskliste entsprechen anpassen.

Mit dieser Minimalversion kann man einen Prozess beschreiben (bereit, in Arbeit, erledigt), eine WIP-Limite setzen und bekommt Feedback für Verbesserungen. Auswertungen müssen hier alle von Hand gemacht werden, dafür benötigt man fast keine Infrastruktur.

 

Whiteboard

Der Klassiker für Kanban ist ein Whiteboard und Post-it Zettel. Gibt es einen zentralen Ort der für alle Kanban-Teilnehmer gut zu erreichen ist empfiehlt sich dieser Ansatz. Die Post-it-Zettel kommen auch hier zum Einsatz, da sie sehr flexibel sind und beliebig beschrieben werden können.

Gegenüber der Minimalversion ist ein Whiteboard übersichtlicher und bietet mehr Platz. Dies ist gerade für komplexere Abläufe sehr hilfreich. WIP-Limits lassen sich für alle sichtbar oberhalb der einzelnen Spalten aufschreiben.

So lange man keinen Permanent-Marker verwendet lassen sich die Unterteilungen schnell an die neuen Gegebenheiten anpassen.

Der Arbeitsablauf ist hier wie auch bei den anderen Ansätzen immer gleich: Tasks werden am linken Rand eingefügt, schrittweise nach rechts über das Board gezogen und sind am Ende bereit für eine Archivierung.

 

LeanKit Kanban

Bei grösseren Teams oder wenn man immer und von überall her zugreifen will sind elektronische Kanban-Boards eine gute Wahl. LeanKit bietet eine webbasierte Lösung die für bis zu 3 Benutzer kostenlos ist.

Lean ist dabei nicht nur Teil des Herstellernamens, sondern findet sich auch im Produkt wieder. Mit sehr wenig vorarbeiten (Seite aufrufen und registrieren) ist man gleich soweit um mit Kanban zu beginnen. Standardmässig besteht das Board aus den Spalten „TODO„, „DOING“ und „DONE“ sowie dem Backlog und dem Archiv. Neue Karten kann man über den Knopf „New Card“ erzeugen und schon ist man bereit um die Karte mit der Maus über das Board zu bewegen.

Leankit

Mit gefallen an diesem Dienst die vielen einfachen Anpassungsmöglichkeiten. Die Spalten mit ihren WIP-Limits lassen sich sehr einfach verändern und neue Kategorien sind schnell erzeugt. Bei all dieser Personalisierung darf natürlich eine Auswertung nicht fehlen. Bei allen Aktionen durch die Benutzer werden im Hintergrund die Kennzahlen nachgetragen. Egal ob WIP-Limit Verstösse, Lead-Time Veränderungen oder der Arbeitsfortschritt – alles lässt sich einfach auswerten und in einem Report darstellen.

Leankit_Stats

 

Flexilio

Wie LeanKit Kanban ist Flexilio eine Webapplikation. Obwohl beide Anwendungen ein Kanban-Board implementieren haben sie diese Aufgabe ganz unterschiedlich umgesetzt.

Bei Flexilio dreht sich alles um Projekte und (User-) Stories. Eine Story gehört zu einem Projekt und wandert vom Backlog aufs Board und nach der Bearbeitung ins Archiv. Auf dem Board kann man für jede Story beliebig viele Tasks erzeugen diese dann einzeln durchs Board bewegen.

Flexilio

Flexilio zeigt einem immer direkt an zu welcher Story ein Task gehört. Wenn man Story-orientiert arbeitet ist es so viel einfacher die Übersicht zu behalten als bei LeanKit. Dafür muss man bei Flexilio aber immer zuerst eine Story haben bevor man einen Task erzeugen kann.

 

Fazit

Bei Kanban kann man die Werkzeuge einsetzen die am besten zu den eigenen Anforderungen passen. Ob dies eine ganz minimale Implementierung, ein Whiteboard oder eine elektronische Lösung wie LeanKit oder Flexilo ist – wenn es passt soll man es verwenden.

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban