APM 11 – Taskboards

In dieser Episode geht es um elektronische und physische Taskboards (nicht etwa physikalische, wie ein verwirrter Podcaster behauptet). Was macht man mit Boards, wie viele Spalten braucht man, und was ist dieser Schneepflug?
avatar Toby Baier Paypal Icon Amazon Wishlist Icon Bitcoin Icon
avatar Alexander Fürstenau Paypal Icon Amazon Wishlist Icon

Start und Begrüßung

00:00:00

Thema heute: Taskboards

00:00:51

"Das zentrale Element um sich abzustimmen" (Alex) — Eine Wand wo visualisiert wird, woran man arbeitet — physische Wand, Fenster, irgendeine Fläche — Karteikarten, auf denen die Aufgaben stehen — Wand bildet den Workflow ab: (arbeit kommt ins Team — wird bearbeitet — wird fertig und verlässt das Team)  — Spalten und Zeilen (Zeilen für einzelne Karten, die von links nach rechts wandern)  — Spalten: mindestens links "To-Do", Mitte "in progress", rechts "done" — weitere Spalten für z.B. Qualitätssicherung, Review, Live-Schaltung oder anderes — Taskboards im arabischen Raum: rechts nach links? — Exkurs: Gewohnheiten ändern um den Kopf fit zu halten (invert Y-Axis) — Toby sieht gesteigerte Komplexität am Board eher skeptisch — Spalten am Board können nie explizite Kommunikation ersetzen — "Das Minimum ist nicht immer das Optimum" (Alex) — 130 Tickets am Taskboard sind auch nicht sinnvoll — Es sollte sich lieber das Board der Realität anpasst, als die Realität dem Board — Indikator: wenn sich das Board nicht ändert, sollte man seinen Prozess und das Board überprüfen — Am Board hängen Karten mit Aufgaben, z.B. User Stories — Board dient der Gesprächsunterstützung beim Daily Stand-Up.

Zustandsvisualisierung

00:12:48

Anhand des Fortschritts der Karten von links nach rechts den Fortschritt im Sprint erkennen — Blocker auf den Karten visuell darstellen.

Schneepflug

00:15:52

Die obersten Karten sollten die wichtigsten sein und zuerst "nach rechts" wandern — Wenn Stories weiter unten zuerst bewegt werden, sollte man darüber nachdenken — Ersetzt möglicherweise auch das Burn Down Chart — Wenn man Dinge tut, die nicht hilfreich sind, sollte man sie sein lassen — Sprint-Ziel am Board hilft beim Fokussieren — Definition of Done und Ready (Vertrag, der beschreibt, wann eine Story in die nächste Spalte kann)  — Achievements — Legende: was bedeuten Farben und Namenskürzel — Board nicht zu weit weg vom Team aufstellen!.

Elektronische Boards

00:21:46

Atlassian Jira — Redmine — Trello — Tickets elektronisch verwalten — Einschränkung der Flexibilität, spontane Ideen sind nicht leicht umzusetzen — Issue Tracking, Bug Tracking — Bugzilla — Jira Agile, ehemals Greenhopper — Scrum oder Kanban Board — Issues als virtuelle Karte verwalten, gestützt durch Datenbank — Vorteile: (Workflow muss eingehalten werden — Reports werden automatisch erstellt — nicht ortsgebunden — Statusänderungen werden automatisch protkolliert)  — Planning Mode der Scrum Boards vor allem für Product Owner sehr wertvoll — Jira Tastaturkürzel — Nachteil von elektronischen Boards: (Änderungen schwieriger umzusetzen)  — Elektronische Boards sind sehr gut zur Vorbereitung und Dokumentation — Physische Boards sind besser in Teams, die gemeinsam davor stehen.

Fallstricke

00:31:52

Board wird nicht benutzt -> veraltete Information — Board wird nicht geändert -> Arbeitsweise passt sich nicht mehr der Wirklichkeit an — Synchronisierung von elektronischem und physischem Board -> welches führt? (man könnte die feinere Granularität dem physischen Board vorenthalten)  — Sichtbarkeit und Rechte in elektronischem Board zu gering -> die richtigen Leute können nicht sehen oder damit arbeiten — "Das Board soll helfen, die Arbeit zu visualisieren, die man normalerweise nicht sieht." (Alex) — Automatisches Verlinken von git commits und Jira Tickets.

Ende

00:37:15

4 Gedanken zu „APM 11 – Taskboards

  1. Susanne

    Verdammt,
    hätte ich doch diesen Podcast früher gehört. Ich habe über jetzt echt sechs JAHRE versucht einen perfekten OnlineShop mit Wawi mit kleinem Geld zu realisieren. Ich könnte jetzt Romane schreiben über Dienstleister, verschiedene Arten und Sorten von Komunikationskatastrofen und kiloweise Selbsterfahrungen. Na ja, ihr kennt das ja beruflich.
    Heute erkenne ich : Ich bin kein Produktmanger. Und -noch besser- ich bin so froh, daß kein Shop online ist, daß Ruhe im Mailordner ist, keine neue WiderufsBelehrung bis Mitternacht umbesetzt werden muß.
    Dir Toby und deinen Gästen danke ich für notwendige Sätze, die mir einen ruhigen Abschied von meinem “Projekt” erleichtern. Außerdem habt ihr gesagt: auch Profis und deren Projekte scheitern, öfter. Geld haben wir auch offline schon unklug verteilt…

    Antworten
  2. Susanne

    wie bestimmt ihr, wann ein projekt als gescheitert gilt ?
    und wird es dann formvollendet beerdigt, oder gut dokumentiert abgelagert, vielleicht taugt das ja nochmal für was?

    Antworten
    1. Toby Beitragsautor

      Hallo Susanne,
      das kann man so einfach nicht beantworten, hängt immer vom Projekt und den Rahmenbedingungen ab. Am besten legt man gleich zu Anfang ein paar Kriterien fest, ab wann das Projekt als gescheitert betrachtet wird und stimmt dies mit allen Stake Holdern ab, aber wer macht das schon? :)

      Antworten
  3. Andreas

    Hi Toby,

    eure Podcast Serie ist super! ich würde gerne mal eure Meinung hören zu der Theorie ob der Product Owner der Single Wringable Neck sein sollte? Oder ob das Team (inklusive PO) die Verantwortung teilen kann.

    VG,
    Andreas

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.