Archiv der Kategorie: Allgemein

ScrumMasters – The Good, the Bad and the UglyScrumMasters – The Good, the Bad and the Ugly

Ende Oktober hatte ich die Freude beim Google Developer Fest zu sprechen. Da die meisten Teilnehmer Entwickler sind, hatte ich meine Session speziell für Teams entworfen: „ScrumMasters – The Good, the Bad and the Ugly“

https://www.youtube.com/watch?v=f_3q1m6pJ_8I had the pleasure to speak at the Google Developer Fest in late october. As most participants were developers – I wrote a session just for them: „ScrumMasters – The Good, the Bad and the Ugly“

Scrum of Scrums dienen zur Koordination und nicht zur Planung

Ein weiterer Kritikpunkt ist, dass die Stärken eines Scrum of Scrums hauptsächlich im Austausch und Koordination zwischen Teams liegen und weniger in einer übergreifenden Planung. Ein Scrum of Scrums ist kein Planungsprozess im eigentlichen Sinne sondern ein stetiger Austausch. Wird ein konsolidierter Plan benötigt, so muss dieser gesondert erstellt werden.

Anatomy of Agile Enterprise

In dem Artikel „Scaling Aile Beyond Team“ greift Janne J. Korhonen ebenfalls den Ansatz von Scrum of Scrums auf, nennt die Limitationen dieser Team of Teams und führt eine weitere Skalierungebene, die “Agile Unit” ein. Teams innerhalb der Agile Unit koordinieren sich auch über Kontext-Grenzen hinweg. Diese “Kontext-Grenzen” sorgen immer wieder für Herausforderungen bei der Agilisierung von Unternehmensteilen, da ihre Auswirkungen auf selbstorganisierte Teams unterschätzt wird.

Agile Unit
Eine „Agile Unit“ fasst Team of Teams zusammen.

Demnächst: Scaling Agile & Lean – Patterns of Enterprise Scrum & Scaling Lean/Agile Development.

TaskBoards müssen nicht gleich aussehen

Update: English version available.

Es gibt unzählige Artikel im Netz, wie man ideale Taskboards – (Kanban/Scrumban/Scrum-Boards)  für agile Teams erstellen kann. Mein Team versucht zur Zeit ein sich oftmals änderndes Projekt mit weniger als 12 Zwei-Tages Sprints umzusetzen.

Die Idee war nun, unser Taskboard den sich ändernden Umständen anzupassen und eine völlig andere Form für dieses Board zu finden.

Das Ergebnis erfüllt zur Zeit all unsere Anforderungen. Tasks (Frontend-Elemente) werden abgearbeitet (siehe Magneten der Entwickler) und können abgehakt werden, wenn sie unserer Definition of Done entsprechen. Dinge die nicht im skizzierten Userinterface ersichtlich sind (z.B. Profiling-Tasks, CSS-Änderungen,…) haben eine eigene Bubble in der die entsprechenden Teammitglieder kleben.

Altlasten in Form von maintainance oder Bugs werden als Postits ans Board geklebt oder anders dargestellt.

Taskboard 2.0

Da ein skizziertes Board schlecht mit Priorisierungen einher gehen kann, schrieben wir die entsprechende Priorität des UI-Elements einfach auch ans Board. Dies bedeutet zwar, dass man ein wenig länger suchen muss, um das nächst-wichtige Steuerelement zu finden, dies ist aber ein kleiner Preis den man für solch ein Taskboard zahlen muss.

Durch die spielerische Art, mit der die UI skizziert ist, wurden auch noch während des Arbeitens Änderungen eingebracht und gleich im nächsten Zwei-Tages-Sprint umgesetzt.

Bis jetzt mögen wir unser Board; aber wir sind ja auch erst im zweiten Sprint – was noch viel Raum für Veränderungen lässt. Wenn Ihr gute Ideen für uns habt, lasst es uns wissen. Frei nach dem Motto: „inspect and adapt“.