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

Video

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“

https://www.youtube.com/watch?v=f_3q1m6pJ_8

A new new taskboard for product development

There are loads of blog posts covering topics on how to shape the perfect taskboard (Kanban/Scrumban/Scrum/Task-boards) for your agile team. My team tries to complete an ever changing project with less than twelve two-day sprints, which puts our regular board design to its limits. We tried to create a board that can actually accommodate our ever changing ideas (and solutions) and thereby created a completely different kind of taskboard.

This is how we did it:

Product Owner, UX experts and the development team sketched the components (and interactions, events, …) for a new feature onto a plain whiteboard and thereby drew the goal for the next iterations. By doing so the board even became part of the documentation as all UI elements are already displayed (and prioritized) as part of the daily work. This clearly increased the teams product focus and made the goal of the current super short iteration visible: Finish the component you are currently working on!

The current task for each developer is shown with his very own magnet. Our WIP-Limit at hand is one – so there is just one magnet per team member. Whenever a task (e.g. frontend-element) is finished the developer reviews it with another team member. If both agree, that it fulfills our definition of done (DoD) both just put a checkmark on it.
Things that are not sketchable on the board like profiling, backend-services or stylesheets have their bubbles outside the drawn userinterface.
As many other teams we also have technical dept. For bugs we have our very own fastlane bubble where bugs can be placed and the next free developer can start working on them.

On a board like this it is difficult to visualize the priority of work items. For that reason we scribbled the priority of the UI elements directly onto the front end elements. That leads to the drawback that one has to search the board when looking for the “next important” element, but this seems to be a small price to pay for such a taskboard.

By the way, since the task board has been designed and the elements have been visualized ,we were much more successful to identify further important improvements (to be addressed in the next 2 day iteration) while working on the elements.

At the moment we are very satisfied with the results we get – but we are still in the beginning of our project with only a few two-day sprints finished. We believe that there are still loads of opportunities to further improve the design of the taskboard and the way we are working with it.

Our “inspect and adapt” cycle has just started.

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“.

Die „Power-Week“ als Produktivitätsfaktor

Galerie

Diese Galerie enthält 12 Fotos.

Nach einigen Diskussionen über die nicht änderbaren schlechten Schallschutzmaßnahmen in unserem alten Großraumbüro (Straßenlärm bei geöffneten Fenstern, Drucker die von dem ganzen Stockwerk genutzt wurden,…), und einem neuen Mitglied in unserem Entwicklerteam, entschieden wir uns dem Occupy-Movement zu folgen. Wir … Weiterlesen

Organisation von Selbstorganisation

Ich habe heute einen Vortrag zu oben genanntem Thema gehalten und dachte ich teile hier meine Erfahrungen.

Im vergangenen Herbst nahm ich an den XP Days in Karlsruhe teil, wo am dritten Tag Jens Coldewey eine Session zum Thema Selbstorganisation hielt. Er machte dabei spannende Übungen mit den Teilnehmern und gab eine kurze Einführung in das CDE-Modell.

Das Agile Manifest unterstützen

Kurzmitteilung

Vielleicht eine schöne Möglichkeit um Management oder Team Buy In symbolisch sichtbar zu machen? Vor kurzem habe ich herausgefunden, dass es auf der Seite des Agilen Manifests eine Möglichkeit gibt, seine Unterstützung mittels symbolischem Unterzeichnen der Charta auszudrücken! So lassen sich die Verbindlichkeit und das Bewusstsein für das Manifest und die Prinzipien stärken.