Umgang mit einem Kanban-Teammitglied in Teilzeit

Ein Kanban-Entwicklungsteam hat ein WIP-Limit von 4 für seine In-dev-Spalte.

Eines der Teammitglieder ist Teilzeit, dh nicht 100 %, und sie arbeiten an einer Story und halten daher 1 Platz in der WIP-Dev-Spalte. Das Teammitglied hat viele andere Aufgaben und konzentriert sich daher nicht zu 100 % auf diese Geschichte.

Sollten wir das Teammitglied entfernen und ein Kanban-Board speziell für sie erstellen, um alle ihre Aufgaben zu verwalten, oder was ist eine gute Lösung?

Wofür verwenden Sie das Kanban-Board?
@BartekKobyłecki Alle Entwickler-User-Storys werden durch das Kanban-Board geschoben, dh wir verwenden es, um die Arbeit des Entwicklerteams zu verfolgen und zu verwalten
Wenn der Prozess also so ist, lassen Sie das Board unverändert. Versuchen Sie nicht, "für Augen zu optimieren" :-)

Antworten (2)

Ein Teilzeit-Teammitglied zu haben, ist wahrscheinlich eine schlechte Idee.

Wenn etwas getan werden muss, das nicht in der Ihnen zugewiesenen Zeit erledigt werden kann, ist das Verschwendung. Wenn Sie sie bis zum Niveau eines Vollzeitmitglieds trainieren und vertraut machen müssen und dann kein Vollzeittraining mit ihnen erreichen können, ist das Verschwendung. Wenn sie nach ein paar Tagen aufholen müssen: Verschwendung. Und so weiter .

Lassen Sie das Brett so, wie es ist. Einer der Gründe, warum Sie ein Board haben, besteht darin, Ihnen dabei zu helfen, Prozessverbesserungen zu identifizieren. Sie fühlen sich unwohl, weil Ihr Board richtig funktioniert.

Rückblickend habe ich mich entschieden, eine Endlosschleife zu erstellen und sage, dass ich El Toro Bauldo zustimme , wenn es darum geht, wie Teilzeitkräfte am besten genutzt werden.

Ich stimme Nathan zu . Ein Teilzeit-Teammitglied, das für einen WIP - Artikel verantwortlich ist, ist eine schlechte Idee. Wenn das Teilzeit-Teammitglied jedoch einen Beitrag leisten kann, ohne störend zu wirken, siehe Brooke's Law, dann würde ich vorschlagen, dass er/sie sich mit einem der WIP-Elemente paaren könnte.

Bei unseren Scrumban- Entwicklungen versuchen wir, WIP zu minimieren , indem wir uns bemühen, dass das gesamte Team jeweils nur an einer Story arbeitet.