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.

Agile Coach Camp 2012 – Zusammenfassung

Das Agile Coach Camp 2012 fand von Freitag, den 22. Juni abends bis Sonntag 24. Juni  in Rückersbach statt. Wir konnten dieses Mal endlich dabei sein, da wir im Zeitfenster von nur zwei Stunden (alle Plätze waren nach dieser Zeit vergeben) unsere Anmeldungen abgaben.

Einige Bilder zum Agile Coach Camp befinden sich hier: Agile Coach Camp 2012 – Bilder.

Freitagnachmittag ging es in Frankfurt Höchst nach einem kurzen Sightseeing für Nancy Van Schooenderwoert und Claudius sowie etwas warten auf Markus in einem vollen Auto los Richtung Rückersbach.

Nach der Ankunft und dem unkomplizierten Check In konnten wir eine Menge Bekannter beim abendlichen Grillbuffet treffen und uns neben Socializing auf die  kommenden zwei Tage freuen.

Samstag

Nach einem umfangreichen Frühstück mit vielen Gelegenheitem zum Austausch begann der „offizielle Teil“ des Camps mit einer Vorstellungsrunde des Orga-Teams. Leider konnte Marc Löffler, einer der Mitorganisatoren, wegen einer Erkrankungn nicht teilnehmen, woraufhin an einer Grussbotschaft gearbeitet wurde, die ihm auch etwas Freude machen konnte:

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.

Die Motivation und Velocity des Teams spielerisch steigern

Nach den teilweise kritischen Kommentaren meines Teams (in der vorletzten Retro) und den inspirierenden Kommentaren zu meinem Artikel „Velocity einzelner Team-Mitarbeiter visualisieren“, haben wir im letzten Sprint eine verbesserte Version der Visualisierung gewählt.

Diese stellt nicht zwingend den schnellsten Entwickler über die anderen Teammitglieder, sondern bevorzugt ein gemeinsames Abarbeiten von Stories im Team.

Wir nennen es:

Storypointopoly

Velocity einzelner Team-Mitarbeiter visualisieren?

Im letzten Sprint – als ich in der „Done“ Spalte nach einem gewissen Ticket suchte – musste ich mit großer Überrschung feststellen, dass einer der Entwickler DEUTLICH mehr Tasks erledigt hatte, als die Anderen.

Es ist korrekt, dass die Tickets, die er bis zu diesem Zeitpunkt gemacht hatte, vom Aufwand kleiner waren als die, die sich andere Mitglieder des Teams vorgenommen hatten – der Unterschied war aber gravierend.