Dienstag, 14. Dezember 2010

Visualisierung, Teil 2: Die Tickets

In einem früheren Post zu den Prinzipien von Kanban habe ich geschrieben, dass ein sehr großer Teil der positiven Wirkung von Kanban durch die Visualisierung zustande kommt. Neben dem Kanban-Board sind die Tickets wichtige Artefakte, die zur Visualisierung dienen. Tickets sind in der Regel Karteikarten, Haftnotizen, ausgedruckte Zettel, oder auch virtuelle Tickets in einem elektronischen Tool, auf denen die wichtigsten Informationen zur jeweiligen Aufgabe vermerkt sind. Die Tickets sollten groß genug sein, damit man die wichtigsten Informationen auch aus einigen Metern Entfernung lesen kann. Im Einzelnen sollten diese Informationen auf jeden Fall auf einem Ticket vermerkt sein:
  • Möglichst sprechende Bezeichnung der Aufgabe, z.B. "Validiere Teilnehmer-Mailadresse".
  • Der Name des augenblicklichen Bearbeiters/Pairs/Teams. Bei Fragen weiß so jedes Teammitglied, an wen es sich wenden kann. Und darüber hinaus wird deutlich, welche Teammitglieder an wie vielen Tickets gleichzeitig arbeiten (und wo sich evtt. zu viel Expertentum/Wissensmonopole befindet). Einige Teams verwenden Sticker oder Magnete mit Portraits oder Avataren, die auf die jeweiligen Tickets geklebt werden. So lässt sich schnell herausfinden, welche Kollegen an zu vielen Aufgaben gleichzeitig arbeiten. Wenn man die Anzahl der Sticker/Magnete beschränkt, kann man über diese Visualisierung also auch eine einfache WIP-Limitierung pro Person vornehmen.
  • Das Eingangsdatum (also das Datum, an dem mit der aktiven Arbeit am Ticket begonnen wurde), und nach Erledigung das fertigstellungsdatum (also das Datum, an dem Das Ticket den Bereich der Wertschöpfungskette, den wir kontrollieren, verlassen hat). Das Eingangsdatum ist eine wichtige Information bei den Standup Meetings, weil ein lange zurückliegendes Eingangsdatum auf Probleme hinweisen kann und man dieses Ticket eventuell als blockiert behandeln sollte. Aus der Differenz zwischen Eingangs- und Ausgangsdatum lässt sich dann die Durchlaufzeit errechnen. Je nach Kontext kann es sinnvoll sein, zusätzlich die Daten auf dem Ticket zu vermerken, an denen das Ticket jeweils in einen neuen Prozessschritt gezogen bzw. in eine Queue geschoben wurde. Allerdings kann es verwirrend sein, alle diese Daten auf dem Ticket selbst zu vermerken, so dass es häufiger sinnvoll ist, sie nur in dem Tool festzuhalten, mit dem man auch die Tracking-Diagramme erstellt (Excel, Googel-Spreadsheets usw.)
  • Wenn ein Ticket blockiert ist, sollte dies auf den ersten Blick zu erkennen sein. Die meisten Teams kleben dafür eine rote Haftnotiz auf das entsprechende Ticket.
Zu diesen Basisinformationen können je nach Kontext weitere Elemente hinzukommen, die man auf den Tickets festhalten sollte:
  • Wenn man mit verteilten Teams arbeitet und/oder zusätzlich ein elektronisches Kanban-Tool/Bugtracker verwendet: Eine Ticket-ID, mit der man die Verbindung zum elektronischen Ticket herstellt und auf die man sich bei Telefonkonferenzen, in E-Mails usw. beziehen kann. 
  • Die Serviceklasse der einzelnen Tickets - sofern man mit unterschiedlichen Serviceklassen arbeitet. Dann ist besonders wichtig:
    • Mit welcher Priorität die Tickets behandelt werden sollen. Häufig wird dieser Kennzeichnung über die Farbe der Tickets vorgenommen (z.B. Weiß für besonders eilige Aufgaben (Expedite-Tickets)). Es gibt hierfür allerdings auch andere Möglichkeiten. Henrik Kniberg schlägt beispielsweise vor, einen roten Stern auf ein Ticket zu malen, um hohe Priorität anzuzeigen. Sollte es dann zu einem Notfall werden, wird ein zweiter Stern hinzugefügt (Panik). Dies hat den Vorteil, dass  sich die Serviceklasse leichter ändern lässt.
    • Bei Tickets, die einen fixen Liefertermin haben (d.h., dass extrem hohe Verzugskosten entstehen, wenn das Ticket bis zu diesem Termin nicht erledigt wurde), sollte dieses Datum ebenfalls direkt auf dem Ticket vermerkt werden.

Links und Literatur

Donnerstag, 9. Dezember 2010

Visualisierung, Teil 1: Das Board

In einem früheren Blogpost habe ich geschrieben, dass Visualisierung eines der Grundprinzipien von Kanban darstellt und dass häufig schon eine recht simple Visualisierung einen riesigen Erkenntnisgewinn bringt und Veränderungen anstoßen kann. Grund genug, etwas mehr zu Visualisierung zu schreiben. In diesem Post geht es um das Kanban-Board, später wird es noch je einen Post zu Tickets und weiteren Elementen geben, die es zu visualisieren lohnt.
Das Kanban-Board ist das zentrale Planungs- und Steuerungstool jedes Kanban-Teams. Die Standup Meetings sollten vor dem Board abgehalten werden, ebenso wie die Retrospektiven/Operations Reviews. Darüber hinaus lässt sich anhand des Boards besser über Probleme bei der täglichen Arbeit diskutieren. Und nicht zuletzt erlaubt das Board nicht nur dem Team Einsichten über den Prozess und den Zustand einzelner Aufgaben, sondern auch Stakeholdern und Mitgliedern aus anderen Teams. All diese Punkte machen zwei Dinge deutlich: 1) Das Board sollte so groß wie möglich sein, damit möglichst viele Details vom Arbeitsplatz aus erkennbar sind. 2) Das Board sollte so platziert werden, dass es von möglichst vielen Teammitgliedern mit dem kleinst möglichen Aufwand eingesehen und aktualisiert werden kann. Selbst wenn man nur kurz von seinem Arbeitsplatz aufstehen und einmal um die Ecke gehen muss, stellt dies oft schon eine Hemmschwelle dar, das Board so oft zu verwenden, wie es hilfreich wäre. Elektronische Tools haben übrigens immer so eine "Ecke" eingebaut: Selbst wenn es nur zwei Klicks dauert, das elektronische Board zu öffnen, stellt dies eine kleine Hemmschwelle dar. Auch wenn es logisch kaum zu erklären ist, führt dies oft dazu, dann nicht im Tool nachzusehen oder eine kleine Ergänzung vorzunehmen. Wenn man allerdings nur kurz den Kopf heben und etwas drehen muss, um die nötigen Informationen zu erlangen, so führt dies zu einer regeren Nutzung. Aus diesem Grund empfiehlt es sich, auch dann ein physikalischen board zu verwenden, wenn man parallel dazu auch ein elektronisches Tool einsetzt.

Welche Informationen sollten auf dem Board erkennbar sein? Obwohl die Details ja nach Kontext abweichen können, gibt es einige Punkte, die wohl generell für jedes Board gelten:
  • Der Workflow, also die Reihenfolge der Prozessschritte, die eine Aufgabe (normalerweise) durchläuft.
  • Die Anzahl der Aufgaben, die sich gerade im System befinden. Allein die tatsächliche Menge an Aufgaben am Board zu sehen, hat häufig einen enormen Effekt. Auch wenn man schon vorher irgendwie wusste, dass man an zu vielen Dingen gleichzeitig arbeitet.
  • Der jeweilige Prozessschritt, in dem sich eine Aufgabe befindet (in Entwicklung, beim Test usw.)
  • Der jeweilige Zustand jedes einzelnen Tickets: | In Arbeit | wartet darauf, in den nächsten Schritt gezogen zu werden | blockiert | fertig |. Der Zustand bietet einen wichtigen Anhaltspunkt, um über Verbesserungsmaßnahmen zu diskutieren, beispielsweise wenn über die Ursachen von Blockaden gesprochen wird.
  • Die Work-in-Progress-Limits für die einzelnen Prozessschritte
  • Die Reihenfolge, in der neue Tickets gezogen werden. Dieser Punkt wird in der Regel nicht allein durch das Board visualisiert, sondern durch eine Kombination aus der Anordnung der Tickets am Board, der Art der Tickets (Serviceklasse) und vereinbarten Teamregeln.
  • Der Mitarbeiter (bzw. das Pair oder das Team), der gerade an der Aufgabe arbeitet. Dies ist zum einen deshalb wichtig, damit jeder weiß, an wen er sich wenden kann, wenn er eine Frage zu einem Ticket hat. Zum anderem macht diese Kennzeichnung deutlich, wenn einzelne Teammitglieder an sehr vielen Tickets gleichzeitig arbeiten, was häufig auf Wissensmonopole hindeutet.
Das Board soll auf einen Blick die Verteilung der Aufgaben zeigen und Probleme sichtbar machen.


Zum Weiterlesen:

Montag, 6. Dezember 2010

Lean bedeutet einen Perspektivenwechsel

Anfang November besuchte ich in Hamburg einen Vortrag von Kent Beck (der "Erfinder" von eXtreme Programming und testgetriebener Entwicklung). Das Thema lautete: Software G Forces and the Effects of Acceleration. Neben vielen anderen interessanten Punkten hat dabei vor allem ein Aspekt ein Aha-Erlebnis bei mir ausgelöst: Agiel/Lean (die für mich zwei Seiten derselben Medaille darstellen) bedeutet häufig, traditionelle Sichtweisen aufzugeben und eine zuerst ungewohnte, neue Perspektive einzunehmen.
Becks Vortrag handelte davon, was geschieht, wenn ein Team/eine Organisation dazu übergeht, ihren Release-Zyklus immer weiter zu verkürzen: von jährlich auf quartalsweise auf monatlich auf wöchentlich auf täglich auf stündlich (ja, so etwas funktioniert tatsächlich, wie beispielsweise flickr eindrucksvoll beweist). Für jeden dieser Rhythmen hat Beck auf einer Folie dargestellt, was jeweils dafür nötig ist, um auf diese Stufe zu gelangen und welche Dinge man sich auf der anderen seite nicht mehr erlauben kann. 
Was ist nötig für monatliche Releases (links), und was kann man sich nicht mehr erlauben (rechts)?
 
 
 
 
 
 
Beispielsweise ist es ab einem monatlichen Rhythmus nicht mehr möglich, eine eigene Q/A-Abteilung zu haben, weil die Arbeitsübergaben und die Kommunikationsaufwände dann zu hoch wären, um so ein schnelles Tempo zu erlauben. (Intessanterweise kann man ab einem bestimmten Tempo auch keinen Bugtracker mehr haben. Stattdessen muss man es hinbekommen, dass nur noch extrem wenige Bugs entstehen, und diese wenigen Bugs müssen sofort gefixt werden - oder man muss sie ignorieren und bis in alle Ewigkeit mit ihnen leben.) 
Auf der Seite der Dinge, die nötig sind, um schneller zu werden, waren alte Bekannte zu lesen wie automatisierte Akzeptanztests, Continuous Integration und Refactorings (und zwar schon bei quartalsweisen Releases). 
Das hat mich zuerst erstaunt, aber dann ist der Groschen gefallen: Bei all diesen Praktiken geht es gar nicht in erster Linie darum, sie einzusetzen, um ein bestimmtes Ziel zu erreichen. Ich hatte vorher immer viel zu sehr von den Praktiken her gedacht. 
"Warum macht Ihr TDD?" - "Weil sich dadurch ein schlankeres Design ergibt." 
"Warum arbeitet Ihr im Pair?" - "Weil wir dann weniger Fehler machen." 
Das sind natürlich nach wie vor sehr gute Gründe. Wenn man aber die Reihenfolge umdreht, wird aus der möglichen Argumentation eine zwingende. Und sie ist besonders zwingend, wenn es um kurze Durchlaufzeiten und häufige Releases geht (was ja tatsächlich für viele Organisationen die größten Herausforderungen darstellt). Die Unterhaltung könnte dann ungefähr so aussehen: 
"Wir möchten gern wöchentlich Releasen. Geht das?" "Ja, aber nur, wenn wir Pair Programming einsetzen und TDD praktizieren." "Dann sollten wir sofort damit anfangen." "Gern, aber vorher brauchen wir etwas Zeit und Geld für Weiterbildung, andere Schreibtische und und größere Monitore." 
Pair Programming und Co. sind also keine Hindernisse für hohes Tempo, sondern eine Voraussetzung!
Dasselbe gilt übrigens für den Zusammenhang zwischen Geschwindigkeit und Qualität (ein Umstand, auf den die Poppendiecks immer wieder hinweisen): Die Alternative lautet nicht Geschwindigkeit oder Qualität. Sondern sie lautet: Schnell werden durch hohe Qualität oder langsam bleiben, weil die schlechte Qualität kein höheres Tempo zulässt. Wie im TDD-Beispiel ist es natürlich auch hier einfacher gesagt als getan, denn die Qualität zu erhöhen, ist ja alles andere als trivial. Aber wenn man schneller werden will (oder muss) führt kein Weg daran vorbei. XP-Praktiken sind nichts, was man macht, weil es irgendwie cool wäre, sondern sie stellen Bedingungen dar, an denen man nicht vorbeikommt, wenn man bestimmte Ziele erreichen möchte.
Zum Weiterlesen
  • Markus Gärtner hat mit seiner unvergleichbaren Live-Blogging-Technik den Vortrag von Kent Beck sehr schön zusammengefasst. Zur Zusammenfassung
  • Mary und Tom Poppendieck (2006): "Implementing Lean Software Development." Buch bei Amazon