Archiv

Posts Tagged ‘Projektführung’

Erfahrungen mit Kanban

4. Oktober 2013 1 Kommentar

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

 

Schlagworte: , ,

Buch-Rezension zu “Kanban and Scrum”

3. Oktober 2013 Kommentare aus

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

 

Buch-Rezension zu “Kanban”

1. Oktober 2013 Kommentare aus

Kanban: Successfull Evolutionary Change for your Technology Business” von David J. Anderson gilt als Standardwerk zu Kanban. Anderson gelang es als einem der ersten das in der Produktion beheimatete Kanban auf die Softwareentwicklung zu übertragen.

 

Einführung & Nutzen von Kanban

Im ersten Teil zeigt Anderson was er alles für Methoden versuchte bevor er bei Kanban angelangt ist. Diese Einführung hilft einem den Kontext zu sehen und festzustellen ob man die gleichen Probleme zu lösen versucht. Sollte dies nicht der Fall sein ist Kanban wohl nicht die passende Lösung.

Im zweiten Teil wird erklärt was Kanban ist und auf was man bei der Implementierung achten soll. Anderson erklärt sehr verständlich wieso man die WIP-Limits (Work in Progress) tief setzen soll und wie man dadurch den Durchsatz erhöhen kann.

Das Kaizen (die kontinuierliche Verbesserung) nicht nur eine Worthülse sein muss wird an mehreren Beispielen aufgezeigt. Gerade wenn das gegenseitige Vertrauen fehlt kann durch eine stetige Lieferung und Verbesserung der Abläufe gezeigt werden dass man es ernst meint mit der Zusammenarbeit.

 

Kanban implementieren und verbessern

Nach dem das Wieso geklärt wurde geht es im dritten Teil ums Wie. Dies beginnt ganz simpel mit dem Aufbau des Kanban-Boards und wie man seinen Prozess darauf abbilden kann. Die Hinweise zum Setzen von Grenzen sollte man unbedingt beachten, da man sich so viel unnötigen Aufwand ersparen kann. Es folgt eine Erklärung zum Aufbau der einzelnen Karten und wie man diese durchs Board bewegt.

Obwohl Kanban nicht festlegt wie man das Board befüllen soll stellt Anderson einige praxisgetestete Ansätze vor. In einem seiner Beispiele konnte auf die aufwändige Schätzung der einzelnen Tasks verzichtet werden und hatte so mehr Zeit zum Erledigen der nötigen Arbeiten.

Ein ganzes Kapitel widmet sich den Kennzahlen die man bei Kanban messen kann. Dies umfasst das überwachen der WIP-Limiten, der Lead Time und geht bis zum messen des Durchsatzes. Die so gewonnenen Werte sollen wiederum mittels Kaizen stetig verbessert werden. Wie man dies genau angehen kann zeigt der vierte und letzte Teil.

 

Takeaways & Beispiele

Ich fand die Auflistung der wichtigsten Punkte am Ende jedes Kapitels äusserst praktisch. Die Zusammenfassung ist eine gute Erinnerung an das was man gerade alles gelesen hat und hilft einem auch später wenn man etwas Bestimmtes finden will.

Anderson hat einige sehr passende Beispiele gefunden um seine Ideen zu erklären. Das Kanban nicht nur mit Produktionssystemen benutzt werden kann zeigt er am Einlasssystem des Imperial East Gardens in Tokyo. Dort werden Kanban-Karten als Limitierung der Besucher verwendet. So lange es Karten hat können Besucher den Park betreten. Sind die Karten weg muss gewartet werden bis andere Besucher den Park verlassen haben. Ein ganz simples System das Kanban nutzt und mit wenig Verwaltungsaufwand auskommt.

Ein anderes Beispiel das mir besonders in Erinnerung blieb zeigt den Unterschied von Durchsatz und Kapazität anhand einer Autobahn. Die maximale Anzahl von Autos die auf einem Strassenstück stehen können erreicht man wenn man ein Auto hinter das andere stellt. Nur hat man so einen Parkplatz und der Durchsatz ist entsprechend gering.

 

Was fehlt

Anderson ist von Kanban überzeugt und hat damit mehrmals erfolgreich Teams neu organisiert. Ich hätte es begrüsst wenn auch ein Beispiel gezeigt würde wo Kanban nicht funktionierte. Kanban ist schliesslich keine Allzwecklösung und durch entsprechende Beispiele könnte man besser abklären ob Kanban für die eigene Situation wirklich passt.

Was leider auch fehlt ist der Hinweis dass man mit Kanban nicht gleich im ganzen Team starten muss. Dies macht vor allem dort Sinn wo es grosse Wiederstände gegen alternative Ansätze gibt und man mit dem eigenen Projekt die Machbarkeit „beweisen“ soll.

 

Fazit

Die vielen praktischen Beispiele und ausführlichen Erklärungen helfen einem die simplen Regeln von Kanban mit den komplexen Vorgängen der Softwareentwicklung zu verbinden. Die Tipps aus der Praxis helfen einem dabei mit Kanban zu starten und schrittweise die eigenen Abläufe zu verbessern.

Für mich ist dieses Buch ein Must-Read wenn man sich mit Kanban in der Softwareentwicklung beschäftigen will.

 

Zum Buch

Kanban: Successfull Evolutionary Change for your Technology Business” von David J. Anderson, 2012 Blue Hole Press, ISBN 978-0984-5214-01, 278 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

 

Durchstarten mit Kanban

30. September 2013 3 Kommentare

Kanban ist eine Methode zur Arbeitsorganisation. Dies tönt erst einmal langweilig und formal. Zu viele Methoden haben uns erzählt dass wir alles falsch machen und unsere lieb gewonnenen Eigenheiten aufzugeben haben.

Kanban ist anders: Es gibt fast keine Regeln, Flexibilität ist nicht nur ein Stichwort und man kann ohne grossen Bruch mit dem Status Quo an einer Verbesserung arbeiten. Und will man schneller und aggressiver eine Veränderung herbeiführen ist auch dies machbar – aber man wird für einmal nicht dazu gezwungen.

In dieser Serie will ich Kanban näher bringen und zeigen was mir daran so gefällt. In den folgenden Beiträgen werde ich Werkzeuge vorstellen und Tipps für den Start mit Kanban geben. Aber beginnen wir erst einmal mit dem Grund wieso man Kanban anschauen soll und überprüfen wir meine Aussage von den wenigen Regeln.

 

Weil ToDo-Listen nicht genug sind

ToDo-Listen haben für mich nie wirklich funktioniert. Kaum hatte ich die Liste geschrieben gab es neue Dinge die noch hinein mussten. War im ersten Durchgang alles schön nach Priorität sortiert hatte ich so gleich das erste Durcheinander. Weder immer wieder die Liste neu zu erstellen noch eine Vergabe von Prioritäten hat für mich funktioniert. Nach kurzer Zeit habe ich aufs führen einer Liste verzichtet. Es ging ja auch ohne und war erst noch viel besser.

Schreibt man die Arbeiten nirgends auf hat man das nächste Problem: Entweder gehen sie vergessen oder man muss ständig daran denken. Beides ist nicht wirklich angenehm. Nach etlichen Versuchen mit alternativen Methoden landete ich schliesslich bei Kanban.

 

Regeln

Kanban verfügt über sehr wenig Regeln. Genau genommen sind es sogar nur 2:

  1. Visualisiere den Workflow
  2. Limitiere die gleichzeitige Arbeit

Durch die Visualisierung des Arbeitsflusses sieht man auf einen Blick wo die Arbeit liegt. Limitiert man die Arbeit an der man gleichzeitig ist kann man sich auf die wichtigen Tätigkeiten fokussieren. Für mich gibt es noch eine weitere Regel die ich für einen erfolgreichen Einsatz von Kanban als nötig erachte:

  1. Überprüfe den Fortschritt

Ohne diesen Zusatz fehlt einem die Motivation für eine Verbesserung. Der dafür häufig verwendete japanische Begriff ist Kaizen und meint die stetige Verbesserung (auch in ganz kleinen Schritten).

 

Mit Kanban starten

Für den Start in Kanban empfiehlt es sich die eigenen Arbeiten zu verwalten. So kann man die ersten Erfahrungen sammeln ohne gleich die ganze Umwelt mit einem halb verstandenen Konzept zu überrennen.

Zu Beginn genügen kleine Post-It Zettel und ein Blatt Papier. Das Papier dient als Kanban-Board und wird in 3 Bereiche unterteilt:

Initiales Kanban-Board

Nach der Visualisierung geht es nun an die Limitierung der gleichzeitigen Arbeit. Dies wird als WIP-Limit bezeichnet, wobei WIP für Work in Progress steht. Man sollte sich für den ersten Versuch nicht zu viele Gedanken über die Limiten machen. Diese kann man gleich wie die Spalten später immer noch anpassen. Um zu beginnen kann das Limit für die Spalte in Arbeit auf 3 gesetzt werden.

Kanban-Board mit WIP-Limite

Als nächstes werden alle Arbeiten die anstehen auf die Post-It Zettel geschrieben – pro Zettel nur 1 Aufgabe. All diese Zettel landen in der Spalte Bereit. Fürs erste kann man sowohl auf eine Aufwandsschätzung wie auch auf eine Priorisierung verzichten. Es geht vorerst einmal darum zu sammeln. Durch die Regel 3 kann man später immer noch darauf zurückkommen – falls man dies noch als wichtig erachtet.

Kanban Tasks erfassen

Mit allen offenen Arbeiten vor sich wählt man nun die Arbeit aus, die man jetzt beginnen kann und die am wichtigsten ist. Diesen Zettel zieht man in die Spalte in Arbeit und beginnt mit der Arbeit. Ist man damit fertig zieht man den Zettel in die Spalte Erledigt. Diesen Ablauf wiederholt man bis alle Arbeiten durchs Board gezogen wurden und erledigt sind.

Mit der Arbeit beginnen

Dieses ziehen macht das Pull-Prinzip aus. Wenn ich über freie Kapazität verfüge hole ich mir eine neue Arbeit. Im Gegensatz zum Push-Prinzip wo mir von aussen Arbeiten zugeschoben werden – unabhängig davon ob ich überhaupt Zeit dafür habe.

 

Blockierte Arbeiten

So einfach wie gerade beschrieben wird man wohl nicht arbeiten können. Oft geht es nicht lange und man ist blockiert. In dem Fall prüft man ob das WIP-Limit erreicht ist. Hat man noch freie Kapazität holt man die nächste Aufgabe in die Spalte in Arbeit und beginnt mit dieser. Wird man auch bei dieser Arbeit blockiert wiederholt man diesen Ablauf so lange das WIP-Limit nicht erreicht ist. Bevor man zusätzliche Arbeiten beginnt sollte man aber überprüfen ob sich eine Blockade mittlerweile aufgelöst hat.

Ist das WIP-Limit erreicht muss man die Ursachen der Blockaden angehen. Erhöht man einfach das WIP-Limit hat man in kürzester Zeit nicht nur 3 blockierte Aufgaben, sondern 10 oder 20.

Kanban-Board blokiert

Die Ursache hinter den Blockaden herauszufinden ist oft nicht einfach. Vorgehensweisen wie die 5-Whys können einem mit überschaubarem Aufwand an die Quelle der Probleme führen. Bleibt auch dies ohne Erfolg hat man immer noch die Möglichkeit das WIP-Limit zu erhöhen.

 

Wie Priorisieren und Aufwand schätzen?

An der Art wie man die Aufgaben priorisiert oder auch den Aufwand schätzt ändert sich mit Kanban nichts. Man kann genau so weiter machen wie man es sich gewohnt ist. Erst beim abarbeiten sollen nur noch so viele Aufgabenangegangen werden wie es das WIP-Limit erlaubt.

Nutzt man die Anzahl Karten als WIP-Limit braucht man die Aufwände der einzelnen Arbei-ten nicht extra zu schätzen. Bei der Priorisierung kann man es sich ebenfalls einfach machen und die Arbeiten in der Reihenfolge angehen, wie diese in der Spalte Bereit aufgelistet sind. Eine Repriorisierung der Aufgaben beschränkt sich so auf das Verschieben der Karten an die passende Stelle.

All dies ist nicht nur erlaubt sondern man soll auch explizit alles nutzen, was einem bei der Produktivitätssteigerung hilft. Ein anpassen und erweitern ist keine Verletzung der Prinzipen von Kanban sondern explizit gewünscht.

 

Zusätzliche Arbeit

Sobald man mit der einen Aufgabe begonnen hat taucht schon bald die nächste noch wichtigere Arbeit auf. Im Gegensatz zu Scrum kann jederzeit eine neue Aufgabe aufgenommen werden. Ist das WIP-Limit noch nicht erreicht könnte man gleich mit der neuen Aufgabe beginnen, andernfalls landet diese in der Spalte Bereit.

Diese Flexibilität ist besonders für Software-Projekte hilfreich bei denen sich das gleiche Team um die Entwicklung und den Betrieb kümmert. Kanban geht auf diese Bedürfnisse ein und ermöglicht eine komplette Rundumsicht auf alle gemachten arbeiten.
So zeigt das Kanban-Board auf den ersten Blick wie viele Supportfälle angefallen sind und wie viel Zeit die Entwickler mit dem Lösen von Produktionsproblemen verbringen.

 

Wo anfangen?

Wie bereits erwähnt fängt man am besten mit seinen eigenen Tätigkeiten an. Dazu braucht man nicht mit den bestehenden (teamweit) verwendeten Werkzeugen zu brechen. Es genügt vollends die Aufgaben die einem zugewiesen wurden auf dem eigenen Kanban-Board unter Bereit aufzulisten, bei in Arbeit ein passendes WIP-Limit zu setzen und mit der Abarbeitung zu beginnen.

Dieser kleine Schritt ermöglicht einem Kanban ohne grossen Aufwand auszuprobieren. Selbst mit so einer kleinen Anwendung kann man von der Fokussierung auf die wichtigen Tätigkeiten profitieren. Wenn Kanban einem gefällt ist es ein kleiner Schritt all seine Aufgaben zu erfassen. Und wenn nicht kann man das Experiment beenden ohne viel zu verlieren.

Kanban-Board: Arbeiten erledigt

 

Ausblick

In der nächsten Folge werde ich das Buch „Kanban“ vorstellen. Darin wird von David J. Anderson gezeigt dass Kanban nicht nur in der Produktion von Fahrzeugen sondern auch für die Software-Entwicklung sehr gut geeignet ist.

 

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

 

Schlagworte: , ,

Buch-Rezension zu „Waltzing with Bears“

27. Juni 2011 1 Kommentar

Waltzing with Bears: Managing Risk on Software Projects“ von Tom DeMarco und Timothy Lister erschien 2003 bei Dorset House. Risikomanagement ist etwas was nicht erst in den letzten Jahren aktuell wurde. DeMarco und Lister haben ihre Erfahrungen in dieses knapp 200 Seiten umfassenden Buch einfliessen lassen. Wie meist bei DeMarco ist das Buch trotz der vielen Theorie sehr angenehm zu lesen.

 
 
 
 
Die einzelnen Teile des Buches gehen diesen Fragen rund ums Risikomanagement nach:

  • Warum?
  • Wann nicht?
  • Wie?
  • Wie viel?
  • Wird’s gemacht?

Im ersten Teil wird auf anschauliche Art erklärt was Risiken sind und wieso man vor ihnen nicht weglaufen kann. Projekte die ganz ohne Risiko sind haben meist auch nur sehr wenig finanzielle Anreize, wodurch man früher oder später hinter die risikoreichen Projekte muss.

 
Wann auf Risikomanagement verzichten?
Teil 2 geht dann auf die Situationen ein, wo man besser auf ein Risikomanagement verzichtet. Dies mag einen erstaunen, doch gibt es solche Situationen wirklich. Es macht schlicht keinen Sinn in einer Firma die nur Ja-Sager will von Dingen wie Risiken zu sprechen. Bei Risiken spricht man von Möglichkeiten und Unsicherheiten. Ein Firmenmotto wie

It’s okay to be wrong, but not okay to be uncertain.

steht diesem Vorhaben im Weg. Eine andere Situation ist wenn Glück integraler Bestandteil des Projektplans ist. Dabei ist nicht gemeint dass man mit ein wenig Glück vielleicht ein wenig früher fertig wird. Sondern das man bei allen Schritten viel Glück braucht damit man überhaupt auch nur im Entferntesten diesen Plan umsetzen kann.

 
Wie managt man Risiken?
Gut die Hälfte des Buches widmet sich der Frage wie man Risiken managen kann. Als erstes Beispiel dient das Risiko des verpassten Liefertermins. Mittels Terminkurven wird die Wahrscheinlichkeit des Lieferzeitpunktes untersucht. Die eine Grenze bildet der frühestmögliche Zeitpunkt (N) unter optimalsten Bedingungen, die andere ist der Termin bei dem man sicher fertig sein wird (und damit viel weiter in der Zukunft liegt als das Projekt dauern soll).

Der Punkt N wird hier als Nano-Prozent Datum definiert. Die Chancen zu diesem Zeitpunkt zu liefern sind grösser als 0, aber immer noch verschwindend gering. Leider wird dieser Zeitpunkt aber oft als Liefertermin benutzt, was zu all den bekannten „Verzögerungen“ führt.

Wie geht man nun mit diesem Risiko um? Die Autoren schlagen vor Anzeichen für ein Eintreten zu sammeln und zu überwachen. Davon erhofft man sich bei ersten Anzeichen noch reagieren zu können. Allerdings gilt es bei grösseren Risiken Vorkehrungen zu treffen. Genau wie bei einer Versicherung muss man sich vor dem Eintreffen des Schadensereignisses darum kümmern. Dabei muss man wieder abwägen wie viel einem eine Vorkehrung für etwas das nur vielleicht eintreffen wird wert ist. Es wäre kein Buch von DeMarco wenn es dazu nicht auch zahlreiche Formeln und betriebswirtschaftliche Grundlagen gäbe.

Neben der Terminüberschreitung gibt es auch zu anderen häufigen Risiken bei Software Projekten (wie Explosion der Anforderungen oder Personalfluktuation) Beispiele die nach dem gleichen Muster angegangen werden.

 
Risiken minimieren
DeMarco und Lister haben auch etliche Ansätze zum Reduzieren der Risiken. Für die Lieferverzögerung ist ihr Ansatz die Software in mehreren Teilen zu liefern. Mit doch recht vielen Worten wird ein vorgehen erklärt das anhand des Nutzens für den Kunden Teile abgrenzt und zu Lieferpaketen gruppiert. Aus heutiger Sicht ist einem so ein Vorgehen aus Scrum oder XP bekannt und bräuchte weniger Erklärungsbedarf.

 
Kosten, Nutzen und Risikobereitschaft
Wie auch bei „Software by Numbers“ sollten für etliche Berechnungen sowohl die Kosten wie auch der Nutzen vorliegen. DeMarco und Lister sind diesbezüglich aber ein wenig realistischer:

Cost = $6,235,812.55
Benefit = „We gotta have it.“

Ein wenig mehr Erklärung wie man dann aber doch zu genügend guten Zahlen kommt hätte in dem Buch noch Platz finden sollen.

Ein weiteres schönes Zitat zur Risikobereitschaft zeigt eines der grossen Probleme bei Software Projekten:

Take lots of risks when the benefit is negligible. How else can we possible get costs down enough to justify this loser project?

Dies steht im Wiederspruch zu dem was man eigentlich erwarten würde: Viel Risiko wenn es viel zu gewinnen gibt, wenig Risiko wenn der mögliche Nutzen minimal ist. All die Death-March Projekte zeigen aber das DeMarco und Lister auch hier recht haben. Leider.

 
Fazit
Ich finde das Buch ist ein guter Einstieg ins Thema. Es deckt die 20% des Themas Risikomanagement ab die rund 80% des Nutzens beinhalten. Damit ist aber auch klar dass man nach dem Lesen kein Experte für Risikomanagement sein kann.

Ein wenig mehr Wissen über Risiken im Entwicklerteam würde noch so manchem Projekt gut tun. Dazu kann man dieses Buch gut nutzen.

 
Zum Buch
Waltzing with Bears: Managing Risk on Software Projects” von Tom DeMarco und Timothy Lister, 2003 Dorset House

Schlagworte: , , ,
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 254 Followern an