Folge 090 Waiting Spalte
Waiting Spalte Heute geht es um, und vielleicht kennst Du das von
Deinem Board, die Waiting Spalte. Wir haben uns bereits darüber
unterhalten, wofür wir Borads verwenden und wie man diese erstellen
kann. Heute geht es um eine konkrete Spalte,
22 Minuten
Beschreibung
vor 3 Jahren
Waiting Spalte
Heute geht es um, und vielleicht kennst Du das von Deinem Board,
die Waiting Spalte.
Wir haben uns bereits darüber unterhalten, wofür wir Borads
verwenden und wie man diese erstellen kann. Heute geht es um eine
konkrete Spalte, die von vielen Teams eingefordert wird. Die
Waiting Spalte.
Diese Folge auf YouTube: https://youtu.be/_bp0roJo5XQ
Kontext
In vielen Agilen Projekten basiert die Zusammenarbeit in Teams zu
großem Teil auf Boards. Also die Boards sind ein gutes Tool für
Kommunikation. Dabei ist es egal ob wir zum Beispiel Scrum oder
KanBan als Framework einsetzen. Es gibt fast immer ein Board um
die Arbeit zu visualisieren. Hierauf wird der Arbeitsfluss oder
Wertstrom häufig visualisiert. Nun kommt es öfter vor, dass man
zu einer Aufgabe die Rückmeldung von außen braucht. Jetzt liegt
es nahe dem Ticket irgendwo zu parken.
Personal KanBan
Viele Menschen, so auch Janina Wohlert, haben ihr KanBan mit
einem Personal KanBan angefangen. Also ein Board nur für Dich.
Diese Personal KanBans sind sehr gut um seinen eigenen
Arbeitsalltag zu strukturieren. Oder überhaupt erst einmal einen
Überblick über die Arbeit, die so ansteht und reinkommt, zu
bekommen.
Gründe
Im Personal KanBan komme ich nun häufig schnell zu dem Punkt,
dass beispielsweise der Anruf bei den Eltern gerade nicht
geklappt hat, weil niemand rangegangen ist. Nun liegt es nahe das
Thema auf Wiedervorlage oder Waiting zu setzen.
Oder wenn Du zu einer Aufgabe eine E-Mail geschrieben hast und
noch keine Antwort zurückkam. Was dann?
Deshalb kommen auch frische Teams, meist nach wenigen Wochen oder
in einer der ersten Retrospektiven, zu dem Schluss, dass sie eine
Waiting Spalte brauchen. Dies ist auch beim Zusammenspiel mit
WiP-Limits häufig zu beobachten.
Das Problem
…and tasks move into the waiting collum in order to die.
Sie verhungern da quasi. Bei vielen Teams wird das zu einer Art
Kellerraum, wo sich sowieso keiner mehr erinnert, warum die
Tickets dort sind. Und das ist schade, da wir ja vorher
priorisiert haben und so festgelegt wurde, was gerade wichtig
ist. Achtung, wichtig nicht dringlich.
Es wäre ja schade, wenn genau diese Aufgaben dann nicht gemacht
und vergessen werden würden.
Wir sprechen hier schließlich von „getting shit done“ und nicht
von „getting things into waiting“.
Da sich viele Menschen an diese Aufgaben nicht mehr so recht
erinnern können ist es häufig ein riesen Kraftakt diese Aufgaben
dort wieder rauszubekommen. Oft muss neu refined werden oder
regelmäßig eine Rückmeldung zu dem Ticket gegeben werden.
Manchmal Nachforschungen, worum es ging… Viel Aufwand eben.
Es ist besser es gleich zu erledigen, denn die Nachforschung zu
einer Waiting Aufgabe ist meist genauso Aufwendig, wie eine
Aufgabe von vorn anzufangen.
Das ursprüngliche Ziel ist ja, den Wertstrom und den der Aufgaben
im Griff zu haben. Die Waiting Spalten führen nun dazu, dass
genau dieser Strom abreißt. Sie entspricht damit nicht unserem
Prozessziel.
Wating und Blocked
Es gibt auch einen großen Unterschied zwischen Waiting und
Blocked. Also warten wir nur auf Ereignisse oder gibt es wirklich
einen Blocker zu dem Ticket, den wir gemeinsam beseitigen dürfen.
Hier kommt also auch eine gewisse Dinglichkeit hinzu.
Der Schnitt der Aufgaben oder des Teams
Eine Ursache könnte ein ungünstiger Schnitt der Aufgaben oder des
Teams sein. Aufgaben sollten möglichst nur Themen beinhalten, die
das Team von selbst lösen kann.
Die Aufgabe sollte also an der Stelle erledigt sein, wo das Thema
an eine andere Stelle übergeben wird. Man kann dann wiederum neue
Aufgaben erfassen, wenn es Rückmeldungen gibt oder dafür einen
Trigger einrichten, der diese Aufgaben im Backlog höher
priorisiert. Wenn das häufiger vorkommt, dann lohnt es sich
vielleicht die entsprechende Kompetenz auch in das Team hinein zu
holen.
Get shit done,
Janina & Henry
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen
weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du
magst verlinke @znip_academy_agile und wir teilen deinen Like mit
unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem
Veränderungsprozess begleiten lassen, eure größten
Komplexitätsnester auflösen und die besten Teamtipps bekommen?
Dann buch uns
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Board
Boards erstellen
Kommunikation
Scrum
KanBan
Agilität
Retrospektiven
getting shit done
Backlog
Connecte dich gerne hier mit uns:
LinkedIn
Instagram
YouTube
Facebook
Webseite
Facebook-Gruppe
The post Folge 090 Waiting Spalte appeared first on Znipcast -
für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.
Heute geht es um, und vielleicht kennst Du das von Deinem Board,
die Waiting Spalte.
Wir haben uns bereits darüber unterhalten, wofür wir Borads
verwenden und wie man diese erstellen kann. Heute geht es um eine
konkrete Spalte, die von vielen Teams eingefordert wird. Die
Waiting Spalte.
Diese Folge auf YouTube: https://youtu.be/_bp0roJo5XQ
Kontext
In vielen Agilen Projekten basiert die Zusammenarbeit in Teams zu
großem Teil auf Boards. Also die Boards sind ein gutes Tool für
Kommunikation. Dabei ist es egal ob wir zum Beispiel Scrum oder
KanBan als Framework einsetzen. Es gibt fast immer ein Board um
die Arbeit zu visualisieren. Hierauf wird der Arbeitsfluss oder
Wertstrom häufig visualisiert. Nun kommt es öfter vor, dass man
zu einer Aufgabe die Rückmeldung von außen braucht. Jetzt liegt
es nahe dem Ticket irgendwo zu parken.
Personal KanBan
Viele Menschen, so auch Janina Wohlert, haben ihr KanBan mit
einem Personal KanBan angefangen. Also ein Board nur für Dich.
Diese Personal KanBans sind sehr gut um seinen eigenen
Arbeitsalltag zu strukturieren. Oder überhaupt erst einmal einen
Überblick über die Arbeit, die so ansteht und reinkommt, zu
bekommen.
Gründe
Im Personal KanBan komme ich nun häufig schnell zu dem Punkt,
dass beispielsweise der Anruf bei den Eltern gerade nicht
geklappt hat, weil niemand rangegangen ist. Nun liegt es nahe das
Thema auf Wiedervorlage oder Waiting zu setzen.
Oder wenn Du zu einer Aufgabe eine E-Mail geschrieben hast und
noch keine Antwort zurückkam. Was dann?
Deshalb kommen auch frische Teams, meist nach wenigen Wochen oder
in einer der ersten Retrospektiven, zu dem Schluss, dass sie eine
Waiting Spalte brauchen. Dies ist auch beim Zusammenspiel mit
WiP-Limits häufig zu beobachten.
Das Problem
…and tasks move into the waiting collum in order to die.
Sie verhungern da quasi. Bei vielen Teams wird das zu einer Art
Kellerraum, wo sich sowieso keiner mehr erinnert, warum die
Tickets dort sind. Und das ist schade, da wir ja vorher
priorisiert haben und so festgelegt wurde, was gerade wichtig
ist. Achtung, wichtig nicht dringlich.
Es wäre ja schade, wenn genau diese Aufgaben dann nicht gemacht
und vergessen werden würden.
Wir sprechen hier schließlich von „getting shit done“ und nicht
von „getting things into waiting“.
Da sich viele Menschen an diese Aufgaben nicht mehr so recht
erinnern können ist es häufig ein riesen Kraftakt diese Aufgaben
dort wieder rauszubekommen. Oft muss neu refined werden oder
regelmäßig eine Rückmeldung zu dem Ticket gegeben werden.
Manchmal Nachforschungen, worum es ging… Viel Aufwand eben.
Es ist besser es gleich zu erledigen, denn die Nachforschung zu
einer Waiting Aufgabe ist meist genauso Aufwendig, wie eine
Aufgabe von vorn anzufangen.
Das ursprüngliche Ziel ist ja, den Wertstrom und den der Aufgaben
im Griff zu haben. Die Waiting Spalten führen nun dazu, dass
genau dieser Strom abreißt. Sie entspricht damit nicht unserem
Prozessziel.
Wating und Blocked
Es gibt auch einen großen Unterschied zwischen Waiting und
Blocked. Also warten wir nur auf Ereignisse oder gibt es wirklich
einen Blocker zu dem Ticket, den wir gemeinsam beseitigen dürfen.
Hier kommt also auch eine gewisse Dinglichkeit hinzu.
Der Schnitt der Aufgaben oder des Teams
Eine Ursache könnte ein ungünstiger Schnitt der Aufgaben oder des
Teams sein. Aufgaben sollten möglichst nur Themen beinhalten, die
das Team von selbst lösen kann.
Die Aufgabe sollte also an der Stelle erledigt sein, wo das Thema
an eine andere Stelle übergeben wird. Man kann dann wiederum neue
Aufgaben erfassen, wenn es Rückmeldungen gibt oder dafür einen
Trigger einrichten, der diese Aufgaben im Backlog höher
priorisiert. Wenn das häufiger vorkommt, dann lohnt es sich
vielleicht die entsprechende Kompetenz auch in das Team hinein zu
holen.
Get shit done,
Janina & Henry
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen
weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du
magst verlinke @znip_academy_agile und wir teilen deinen Like mit
unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem
Veränderungsprozess begleiten lassen, eure größten
Komplexitätsnester auflösen und die besten Teamtipps bekommen?
Dann buch uns
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Board
Boards erstellen
Kommunikation
Scrum
KanBan
Agilität
Retrospektiven
getting shit done
Backlog
Connecte dich gerne hier mit uns:
YouTube
Webseite
Facebook-Gruppe
The post Folge 090 Waiting Spalte appeared first on Znipcast -
für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.
Weitere Episoden
54 Minuten
vor 5 Monaten
35 Minuten
vor 8 Monaten
vor 1 Jahr
51 Minuten
vor 1 Jahr
4 Minuten
vor 1 Jahr
In Podcasts werben
Abonnenten
Wegberg
Kommentare (0)