35. Treffen der Limited WIP Society Cologne – Visualisierung der Arbeit:

Dieses mal stellten David Schmithüsen und Harald Schlüter einige Beispiele ihrer Visualisierungen vor – und natürlich wurde entsprechend darüber diskutiert.

Es ging um das persönliche Board eines Scrummasters, unterschiedliche Visualisierung der gleichen Informationen und die Planung und Organisation von Wartungs-Teams.
My_Board5_Unternehmen_Gesamtflow_Tampermonkey Akquisen_und_Projekte

Hier nur kurz ein paar Erläuterungen zu den Dingen, die die Bilder nicht selbsterklärend sagen.

Board eines Scrum-Masters

(Auf dem Treffen vorgestellt von David Schmithüsen)

Persönliches Board

Persönliches Board eines Scrum-Masters

Persönliches Board eines Scrum-Masters

Backlog (nicht mit abgebildet)

WIP-Limit theoretisch 12, Eingang für die Wochenplanung
Hier werden aufgaben gesammelt, die in regelmäßigen Abständen in das eigentliche Board überführt werden sollen. Dieses Board dient auch der Abstimmung mit den anderen Stakeholdern.

This Week

WIP-Limit = 3 x 6
Todo – 1 = höhere Priorität
Todo – 2 = niedrige Priorität
Todo – 3 = „Rangierbahnhof“ und Dinge niedriger Priorität

Auf diesem Teil des Boards werden immer alle Ativitäten sichtbar gehalten und konsolidiert sobald die WIP-Limits anzuschlagen drohen.

Today

Theoretisches WIP-Limit von 12, wird faktische meistens nicht erreicht.
Explitites Überführen von Wochenaufgaben in Tagesaufgaben, wo nötig mit Work-breakdown.

Blocked:

Hat ein explizites WIP-Limit von 6 – und das reicht in der Tat auch für 2 Wochen.

Was passiert, wenn eine Aufgabe nicht gelöst werden kann?

Verschiedene Möglichkeiten:
– Nachhaken
– Anderen Weg finden
– Auflösen der Verfolgung (Ticket fallen lassen)

Karten werden nicht dauerhaft in „blocked“ belassen!

Done

Hier wird auf dem gelben Zettel oben Rechts getracked – danach wird Done geleert.
Statistik auf dem Done-Board wird vor allem wichtig, wenn die Arbeit an Bodenhaftung zu verlieren scheint.

Sonderregeln:

– Wiederholende Aufgaben werden in diesem Fall über andere Dinge – automatisierte Kalender etc. – geregelt.
– Hängt öffentlich, für zwei beteiligte Teams sichtbar, im Raum und wird auch von den Teams entsprechend angenommen.

Weitere Zettel auf dem Board:

Das SCARF Model nach David Rock,
Ein Modell für viele Fragen zu personellen Interaktionen.

Aus dem Buch „Brain at Work“
S tatus
C ertainty
A utonomy
R elatedness
F airness

Behavior / Outcome Matrix

Eine sehr hilfreiche Einordnung, wann denn eigentlich (individuelles und organisatorisches ´) Lernen stattfindet.
Aus „Management 3.0 Workout“, von Jurgen Apello, derzeit nur zum herunterladen, aus dem Kapitel Yay! Questions and Celebration Grids.

Verschiedene Sichten auf die gleichen Dinge

Unternehmen, Scrum Team, Dev Team – Visualisierung mit Jira und Tampermonkey JS
(Auf dem Treffen vorgestellt von David Schmithüsen)

Dev-Board

Es beginnt mit einem Klassisches Development-Board in Jira
1_DEV_Board

PO-Board

2_PO&BA_Board
Erweiterung des DEV-Boards nach links
Modelliert vor allem die unterschiedlichen Zustände des Backlogs und sorgt für deutlich besseres Backlog-Grooming.
Das bedeutet vor allem auch eine klar vereinbarte „Definition of Ready“ für den Eingang in das Dev-Board.

Gesamtflow

3_Team_Gesamtflow_Jira_Board
Vereinheitlicht die Sichten des PO-Boards und des Dev-Boards.
Die eigentliche Live-Stellung erfolgt teilweise direkt durch den Fachbereich (PO)!

Anmerkung des Schreibenden: Geht also auch! 😉

Tampermonkey-Skripts

4_Team_Gesamtflow_Tampermonkey
5_Unternehmen_Gesamtflow_Tampermonkey
Zeigen pro Team / PO wo die unterschiedlichen Staus im Fluß sind.

Sonstige Erkenntnisse

Statistiken werden ausserhalb gepflegt
Fachliche Bewertungen werden über ein separates Excel-Sheet gepflegt und haben zu einer starken Versachlichung der Diskussionen um die Priorisierung geführt.

Zitat:

„Manchmal sind Sachen, die ich in ein paar Minuten manuell ausfüllen kann einfach effizienter als die Einführung automatisierter Tools – wenn ich das Ergebnis bekomme, indem ich kurz 10 Zahlen von hand eintrage, dann tue ich das halt“

Visualisierung von Projekte/Akquisen und Aufgaben in einem (Softwarewartungs-)Team

(Auf dem Treffen vorgestellt von Harald Schlüter )
Die Aufgabe, die hier betrachtet wird ist vor allem die Wartung im Rahmen des Projektgeschäftes. Ein Thema, das hier explizit ausgeklammert ist, ist der Mix von Wartung- und Entwicklungsaufgaben, der sicherlich noch mal ein Abendfüllendes Thema für sich sein könnte.

Board „Akquisen und Projekte“

Akquisen_und_Projekte
Wird ca. alle zwei Wochen in einer Telko aller beteiligten neu bewertet.
Je weiter links, desto weniger konkret – je weiter rechts, desto konkreter muss die Umsetzungsplanung betrieben werden (Welches Team, wieviel Aufwand etc.)

Auf der Projektseite bedeutet weiter rechts, weniger Aufwand und eher „normale“ Wartung

Eine weitere Unterteilung der Spalten in Diskrete Zustände bringt erfahrungsgemäß keinen Zugewinn

Linke Hälfte ist auch wichtiger Inputgeber für die Personalaufstellung in der folgenden Planungsperiode.

Frage: Vorteil gegenüber einer Excel-Tabelle?

  • Besseres Verständnis für den Gesamtumfang
  • Weniger „Waste“ (Keine Überflüssigen Informationen)
  • Abstimmungsmeetings mit Excel deutlich demotivierender.

Aufgaben

Des Weiteren gibt es noch ein Board für Nicht-Projektbezogene Aufgaben.
Aufgaben
Beispiele:

  • Firmenevents organisieren
  • Vorlagen für bestimmte Dokumententypen erarbeiten
  • Regeln für bestimmte Aufgabentypen erarbeiten

hierbei handelt es sich um ein „Ready“, „Doing“, „Done“ Board (nach Personal Kanban) mit Erweiterung um „Waiting“, „Running“ und ein zweites „Done“

Waiting = Wartet auf input von dritten
Running = Werden aktiv von anderen bearbeitet, sollen aber getracked werden
zweites Done = Done für Running

Team-Visualisierung (hier nicht abgebildet)

Unterscheidung der unterschiedlichen Rollen und Visualisierung der Kapazität.

Tätigkeiten ausserhalb des Boards

Regeltermine etc. werden auch hier über elektronische Kalender gelöst.

Sonstige benefits

Tatsächlich können alle diese Boards eins zu eins für die Kommunikation mit Dritten benutzt werden, so dass die Kommunikation hier nicht mit extra erstelltem Material – das möglicherweise nicht mehr aktuell ist und zudem Aufwändig zu erstellen sein kann – gearbeitet werden muss.

Advertisements

Über Michael Mahlberg

Traveling the world, living life and building another software and consulting business - perhaps. Although I've been dubbed "serial entrepreneur", I'm still caring about the craft of software development & have been consulting on software development processes and architecture since the last millennium.
Dieser Beitrag wurde unter Treffen, Visualisierung veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s