Was kennzeichnet ein gutes Product Backlog?

Deep WatersDas Product Backlog enthält alle Arbeiten, die für die Erstellung eines erfolgreichen Produkts erforderlich sind. Es hat einen erheblichen Einfluss auf die Team-Produktivität, ob mit einem guten oder einem schlechten Product Backlog gearbeitet wird. Daher sollte sich gerade der Product Owner auch Gedanken über die Qualität des Backlogs machen. An welchen Kriterien können sich Product Owner und Team orientieren, um die Güte ihres Backlogs einschätzen zu können?

Eine Orientierung bieten die DEEP-Eigenschaften, die ein gutes Product Backlog aufweisen sollte. DEEP ist dabei ein Kürzel für:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Betrachten wir uns diese Eigenschaften eines guten Product Backlogs einmal genauer.

Detailed appropriately

Die Grundregel hierbei heißt: Je näher ein Backlog Item an die Umsetzung heranrückt, desto granularer sollte es sein.
Dadurch gibt es im Product Backlog verschiedene Größen von User Stories:

  • Items, die im nächsten Sprint umgesetzt werden sollen, werden in detaillierter Form vorgehalten, etwa als kleine Stories.
  • Für die darauf folgenden Sprints angedachte Idems können mittelmäßig detailliert in Form von großen User Stories vorgehalten werden.
  • Noch weiter von einer Umsetzung entfernte Odems können in Form von groben Epics festgehalten werden.
  • Es wird auch deutlich, dass ein optimaler Product Backlog keinesfalls so ausschaut, dass alle Anforderungen bis ins kleinste Detail ausformuliert sind.

Emergent

Ein Product Backlog ist nie in Stein gemeißelt. Es ist lebendig und wird ständig gemeinsam von Product Owner und Team und Unterstützung der Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von Backlog Grooming-Workshops, aber z.B. auch im Rahmen des Review-Meetings wird über das Backlog und mögliche Anpassungsbedarfe gesprochen.

Estimated

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, wie etwa das Planning Poker oder das Estimation Game. Im Rahmen von Schätzmeetings oder Backlog Grooming-Sessions kann sichergestellt werden, dass eine Beschätzung für alle Backlog-Einträge vorliegt. Für Backlog-Einträge, die noch weiter von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised

Die geplanten Aufgaben sollten stets priorisiert sein. Die Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben Orientierung, worauf Product Owner und Team achten sollten. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein. Ein Product Backlog Board kann hierbei eine gute Hilfe sein.

Foto: von tassoman

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Englische Version des Artikels

Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: „Ist das Daily Standup für Teammitglieder zwingend?“
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung „daily scrum“ verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

  • Was wurde seit dem letzten Standup-Meeting gemacht?
  • Was wird bis zum nächsten Standup-Meeting erledigt?
  • Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

  • Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
  • Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
  • Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
  • Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit „Strafen“, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
  • Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

Foto: tomnatt

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Hyperproduktive Teams mit Scrum: „From Good to Great“

Wie können gute Teams mit Hilfe von Scrum zu großartigen Teams werden? Damit beschäftigt sich Scrum Co-Founder Jeff Sutherland schon seit vielen Jahren. Vor einiger Zeit hat er hierzu in seinem Blog geschrieben.

Jeff Sutherland macht allen motivierten Teams Hoffung, dieses Ziel erreichen zu können. Nach dem aktuellen Forschungsstand soll jedes Team in der Lage sein, hyperproduktiv zusammenzuarbeiten, auch wenn das Unternehmen, in dem das Team arbeitet, nicht die optimalen Bedingungen bietet.

Auf welche Punkte sollten Teams unbedingt achten, wenn sie hyperproduktiv zusammenarbeiten möchten?

  • Alle Teammitglieder müssen in Scrum geschult sein.
  • Der Backlog muss READY seine, bevor er in einen Sprint übernommen wird.
  • Das Software-Inkrement muss am Ende jedes Sprints DONE sein.
  • Immer wenn nur eine Person eine Aufgabe erledigt werden kann, sollte sofort mit Pair Programming gearbeitet werden.
  • Volle Fokussierung – kein Multitasking.
  • Das Team nutzt ein physisches Scrum Board / Taskboard.
  • Kurze Sprints, häufig von nur einer Woche.
  • Der Burndown erfolgt auf Story Point-Ebene (nicht Tasks oder Stunden)
  • Alles (inklusive Support) wird durch den Product Owner priorisiert.
  • Die höchstpriorisierten Hindernisse müssen aus dem Weg geräumt werden.
  • Die Führung des Teams erfolgt nach dem „Servant leadership“–Gedanken.

Eine Verdopplung der Produktivität ist laut einer Untersuchung bereits dann möglich, wenn darauf geachtet wird, dass alle Arbeiten am Ende des Sprints auch wirklich DONE sind. Die Fehlerquote konnte bei den betrachteten Scrum-Teams damit um ganze 40 Prozent reduziert werden. Wenn die Teams konsequent daran arbeiten, Hindernisse aus dem Weg zu räumen und ihre Arbeiten wirklich DONE abzuschließen, können sie leicht ihre Produktivität drastisch erhöhen. Leider tun dies nur geschätzte 50 Prozent der Scrum-Teams auf der Welt.

Eine weitere Verdopplung der Performance des Teams kann erreicht werden, wenn der Backlog einen hohen Grad von READY erreicht. Dies wirkt sich direkt auf die Effizienz in der Story-Umsetzung aus. Wenn Teams es schaffen, ihre Arbeiten jeweils entsprechend der Definition of DONE abzuschließen und auch einen sauberen Backlog pflegen, der hochgradig READY ist, können sie den Untersuchungsergebnissen nach durchaus mit der vierfachen Produktivität eines Durchschnittsteams erreichen.

Ein weiteres Level der Produktivität kann erreicht werden, wenn es sich um selbstorganisierende Teams handelt, die an der Maximierung ihrer (nachhaltigen) Team Velocity arbeiten und gemeinsame Ziele verfolgen. Dies erfordert flache Organisationsstrukturen und enge Zusammenarbeit.

Auch wenn es einfach klingt, ist es mit Sicherheit herausfordernd in der Umsetzung. Auch hier zeigt sich, dass eine gute Anwendung von agiler Softwareentwicklung viel Disziplin erfordert. Angesicht der starken Produktivitätsverbesserungen, die möglich sind, lohnt es sich denke ich dennoch, sich weiter in diese Richtung zu entwickeln. Dabei hilft diese Präsentation von Jeff Sutherland:
A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity (PDF)

Foto: drewgstephens

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Microblogging im Unternehmen

Wie kann die Kommunikation im Unternehmen verbessert werden? Das ist eine Frage, die uns ständig begleitet. Viele verschiedene Ansätze habe ich in den letzten Jahren in der Praxis erlebt. Sowohl für die Verbesserung der direkten Kommunikation, etwa mit der Einführung von Teamräumen für Gruppen, die intensiv miteinander an einem gemeinsamen Projekt arbeiten. Als auch für die indirekte Kommunikation. Haben wir vor vielen Jahren dabei noch vornehmlich auf E-Mails und das Telefon zurückgegriffen, sind in den letzten Jahren zahlreiche Systeme gekommen und teilweise auch wieder gegangen.
Seit über zweieinhalb Jahren habe ich mittlerweile Erfahrungen mit internen Microblogs gesammelt. Sie eignen sich sehr gut für eine Steigerung der Transparenz in Projekten und bieten das Potenzial, das E-Mail-Aufkommen stark zu reduzieren. Über die Motivation, ein Microblog einzuführen, über Anwendungsfälle eines Microblogs sowie über grundlegende Kriterien für die Auswahl eines der verfügbaren Systeme könnt ihr in einem aktuellen Artikel bei Gründerszene mehr erfahren:

Wie ein „internes Twitter“ (nicht nur) die Projektkommunikation verbessert

Einen guten Überblick über die Stärken, Schwächen, Chancen und Risiken eines Microblogs gibt die folgende Präsentation von Joachim Niemeier:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Wie Führungskräfte mit Fehlern anderer richtig umgehen

Der Vorstandsvorsitzende von IBM, Thomas Watson, rief einen seiner leitenden Angestellten in sein Büro. Dieser hatte gerade ein Projekt mit einem Budget von 10 Millionen Dollar in den Sand gesetzt. Die Erwartung des Angestellten: „Der wird mich jetzt mit Sicherheit feuern“. Aber Watson dachte gar nicht daran. Im Gegenteil. Er meinte:

Feuern? Ich habe 10 Millionen US-Dollar in Ihre Ausbildung investiert. Ich bin sicher, dass sich das auszahlen wird.

(Es kursieren sehr viele verschiedene Versionen des genauen Ablaufs. Z.B.: 1, 2, 3. Die Botschaft bleibt aber gleich.)

Dieser Umgang mit Fehlern entspricht nicht dem, was wir erwarten. Fehler sind bei uns oftmals Tabu. In letzter Zeit konnte ich indirekt ein paar Personen im Umfeld betrachten (im Vereinswesen und aus Erzählung eines Bekannten), die in ihrer Vorbildfunktion oder Vorgesetztenfunktion ganz unterschiedlich reagiert haben.

In zwei Fällen ist dies wenig glücklich verlaufen. Führungskräfte, insbesondere in einer „Sandwich-Position“ (dem mittleren Management), tun sich häufig mit dem Umgang mit Fehlern anderer schwierig. Viele reagieren dann so, dass sie ihre Kollegen „im Regen stehen lassen“ und deutlich herausstellen, dass sie persönlich nichts mit diesem Fehler zu tun haben. Das erinnert dann an „Nach oben buckeln, nach unten treten“. Der Betroffene weiß i.d.R. bereits selbst, dass er einen Fehler gemacht hat. Zusätzlich kommt jetzt ein Nachtreten durch eine Person, die eine wichtige Rolle im Leben der Person spielt. Die Folge dieses Verhaltens für die Beziehung zwischen Mitarbeiter und Führungskraft ist leicht vorhersehbar. Der Mitarbeiter verliert das Vertrauen und den Respekt in die Führungskraft. Beides ist aber essentiell.
Repräsentative Studien von Towers Perrin und Gallup belegen: Der wichtigste Motivationsfaktor für Mitarbeiter ist die Wertschätzung durch den Vorgesetzten und die stärkste Mitarbeiterbindung wird durch Vertrauen erzielt. Beides wird nachhaltig geschädigt.

Eine andere Führungskraft ist mit dieser Herausforderung ganz anders umgegangen. In einem Stil, der eher Watsons Verhalten entspricht. Gemeinsam wurde an einer Lösung der Herausforderung gearbeitet. Zu keiner Zeit kam bei dem Mitarbeiter das Gefühl auf, dass er alleine damit steht. Die Führungskraft sprach von „wir“, wenn der Fehler gegenüber Dritten dargelegt wurde. In der Folge fühlte sich der Mitarbeiter sehr gut unterstützt und hat eine große Achtung vor der Führungskraft entwickelt.

Wer mit seinen Mitarbeitern erfolgreich sein möchte und nicht trotz seiner Mitarbeiter, sollte sich die Reaktion von Watson auf Fehler eines Mitarbeiters von Zeit zu Zeit vor Augen führen.

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Wie wir mit Stattys Haftfolien effiziente Workshops gestalten

„Stattys – Geniale Methode für Workshops etc.“ titelte Stefan Hagen seinen neuesten Blogposts. Darin beschreibt er, wie mit elektrostatischen Folien Meetings und Workshops sehr effizient gestaltet werden können. Er weist dabei auch darauf hin, dass wir bei //SEIBERT/MEDIA mit Stattys-Folien arbeiten, was wir in der Tat sehr intensiv machen. Aufmerksam wurden wir auf Stattys durch unseren Kollegen und Freund Gerrit Eicker gemacht. Seit den ersten Erfahrungen damit haben sie einen festen Platz in unseren Moderationskoffern.

Wir nutzen sie häufig in Workshops und verwenden sie um Gedanken zu erfassen, zu strukturieren, zu priorisieren und ähnliches.

Anwendungsbeispiel

Wie kann die Nutzung solcher Folien konkret ausschauen? Ein Beispiel von einem Workshop, wie er regelmäßig in ähnlicher Form bei uns abläuft.
Wir möchten gemeinsam besprechen, welche Aufgaben wir als nächstes für die Entwicklung eines Neuprodukts angehen möchten. Im ersten Schritt sammeln wir in einem Brainstorming die möglichen Aufgaben. Wir schreiben dabei jeweils eine Idee auf einen Zettel und hängen diese Zettel an eine große freie Wand. Wenn die Brainstorming-Phase abgeschlossen ist, präsentieren wir nacheinander unsere Beiträge. Dabei beginnen wir auch mit dem „Clustern“ der Ideen. Das bedeutet, dass wir ähnliche oder gleiche Beiträge zu Gruppen verdichten, in dem wir die Zettel aneinander legen. Anschließend nehmen wir eine Priorisierung vor. Dazu verschieben wir die Zettel und Cluster so, dass die unserer Meinung nach wichtigsten Aufgaben nach oben rutschen, die unwichtigeren nach unten.

Meine Einschätzung

Während ich mit der Bezeichnung von Stattys als Methode nicht einverstanden bin, sondern es vielmehr als ein Werkzeug zur Unterstützung der Anwendung von Methoden wie Brainstorming betrachte, stimme ich der folgenden Einschätzung von Stefan Hagen zu:

Stattys gehören in den Methoden-Koffer eines Projektleiters.

Stattys versus Post-its

In den Kommentaren zu Stefans Artikel kam auch die Frage auf, ob nicht Post-its gleichermaßen gut nutzbar sind. Erst kürzlich hatten wir in einem Meeting wieder beides im Einsatz, Stattys und Post-its. Es zeigt sich, dass bei obiger Verwendung, die mit einem mehrmaligen Umkleben und auch übereinander hängen einhergeht, Post-its nicht wirklich mithalten können. Sie lassen sich z.B. bei Diskussionen über die Priorisierung nicht einfach x-fach hin und her schieben, ohne sichtbar an Klebkraft zu verlieren. Bei 40-50 Zetteln in einer Session kann es nervig werden, wenn immer wieder welche herunterfallen. Dies passiert insbesondere auf sehr rauen Untergründen, wie Raufasertapete. Stattys lassen sich auch davon nicht beeindrucken, sondern einfach verschieben.

Stattys und elektronische Systeme

Wir setzen bei unserer Arbeit sehr intensiv auf unser Confluence-Wiki und unser Aufgaben-Management-System JIRA. Daher bleibt die Dokumentation der Workshops in einem der Systeme nicht aus. So sind die Ergebnisse leicht Personen zugänglich zu machen, die nicht am Workshop teilgenommen haben.

Fazit

Stattys gehören für uns mittlerweile einfach dazu und unterstützen uns, Workshops unter Einbeziehung aller Teilnehmer durchzuführen. Es wird dadurch sehr ergebnisorientiert und fokussiert zusammen gearbeitet.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Produktmanagement Lesetipps: Tipps für Startup-CEOs, Lean Startups, Getting Nix Done, Agile Softwareentwicklung, Facebook größer als Google

Eine ganze Reihe von interessanten, lesenswerten Artikeln und Blogbeiträgen ist in der letzten Zeit erschienen. Eine Auswahl für Internet-Produktmanager:

13 Dinge, die jeder Startup-CEO jede Woche tun sollte
Welche Dinge sollte ein Startup-CEO in jedem Fall regelmäßig machen? Jason Goldberg, ehemals Chief Product Officer bei Xing und mehrfacher Startup-Gründer, hat 13 relevante Dinge zusammengestellt.

9 Women can’t make a baby in a month
Dieser Post ist schon vor einigen Monaten bei TechCrunch erschienen, ist aber durch die Monster-Investments bei AirBNB und Wimdu so aktuell wie nie: 9 Women can’t make a baby in a month. Es ist ein Aufruf, den lean startup-Gedanken zu leben. Mit einem minimalen Produkt starten und es mit Hilfe von Feedback der User weiter auszubauen und zu optimieren. Zu hohe Finanzierungsrunden können sich schädlich auf das Unternehmen auswirken, es wird einfach nur noch drauf los entwickelt und Verschwendung erhält Einzug. Ein gutes Produkt braucht Zeit zu reifen. 9 Frauen können ein Baby nicht in einem Monat bekommen.

Getting nix done
Ein unterhaltsamer und interessanter Artikel von Michael van Laar über die (Nicht-)Anwendung von Getting Things Done-Prinzipien in der eigenen Freizeit. Seine Gedanken und seinen Lösungsansatz teilt er freundlicherweise mit uns.

Agile Softwareentwicklung erfordert viel Disziplin
Agile Softwareentwicklung scheint bei einigen Managern den Ruf zu haben, ein unstrukturiertes Vorgehen zu sein, dass auf mangelnde Disziplin zurückzuführen ist. Bei genauerer Betrachtung lässt sich jedoch feststellen: Agile Softwareentwicklung erfordert viel Disziplin! Nur so kann ein agiles Team erfolgreich sein.

Facebook wird genauso gross wie Google
Ein gutes Interview von Lars Hinrichs mit NZZ Online. Der relevanteste Part:
„Wenn man im Internet selber nicht für etwas bezahlt, ist man meist selbst das Produkt für andere – dies vor allem über Werbung, sei dies in direkter oder indirekter Form. Facebook und Google haben beide ungefähr ähnlich viele Nutzer und Seitenzugriffe. Der grosse Unterschied ist aber, dass Facebook deutlich mehr Monetarisierungsmöglichkeiten hat als Google.“

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnierenoder mir auf Twitter folgen: @pherwarth.

QR-Codes zur Aktualisierung von Taskboards – 7 Fragen an Matt Müller


Wer den Raum eines Softwareentwicklungs-Teams betritt, dass sich die Vorteile der agilen Softwareentwicklung zunutze macht, wird in der Regel eines sehen können – ein Taskboard mit Aufgabenbeschreibungen auf Karten, das vom Team zur Organisation der Aufgaben genutzt wird.
Immer wieder sind Besucher bei uns irritiert über diese Rückkehr zu Tafel und Papier, ausgerechnet in einer Softwareschmiede. Viele Teams setzen dabei neben dem Offline-Taskboard zusätzlich auf eine elektronische Aufgabenverwaltung. Die Verwaltung der Aufgaben an einem Taskboard im Teamraum sorgt für eine hohe Transparenz und macht den Arbeitsfluß in einem besonderen Maße sichtbar. Die Verwaltung von Aufgaben in einem elektronischen System hat ebenfalls ihre Vorteile. So lassen sich dort auch große Mengen von Vorgängen dauerhaft für die spätere Bearbeitung vorhalten, einfach mit Links und Grafiken versehen und es kann eine Anbindung an ein Zeiterfassungssystem erfolgen. Die Verwendung von beidem führt jedoch zu einer Herausforderung: Änderungen am Status einer Aufgabe (z.B. „offen“, „in Bearbeitung“, „geschlossen“) müssen in beiden Systemen, digital und analog, erfolgen.

Umso spannender fand ich es, bei meinem ehemaligen Kollegen Matthias Müller von einer selbst entwickelten Lösung für einen einfacheren Abgleich zwischen Taskboard im Teamraum und elektronischer Aufgabenverwaltung zu lesen.
Matthias hat sich bereit erklärt, mir ein paar Fragen zu seiner Lösung zu beantworten.

Matthias, erzähl‘ uns erst einmal wer Du bist und was Du machst.

Hallo Paul! Ich arbeite als Softwareentwickler bei der Rhein Main Multimedia GmbH in Mainz. Wir sind eine Tochtergesellschaft der Verlagsgruppe Rhein Main und somit als Dienstleister hauptsächlich im Umfeld der Onlineangebote unserer Tageszeitungen im Bereich CMS und allen Randgebieten unterwegs. Im Kern der RMM sind wir neben Online Sales und Projektkoordination ein Team von fünf Kollegen, die sich um die Planung und Umsetzung neuer Projekte und Anforderungen an bestehende Systeme kümmern. Im Bereich der agilen Softwareentwicklung sind wir noch Rookies – wir beschäftigen uns seit Anfang des Jahres damit. Dabei machen wir nicht „Scrum by the Book“, weil dies als alleiniges Toolkit für die Vielzahl der von uns betreuten Applikationen nicht als tauglich erschien, sondern bewegen uns in einer gesunden Mischung der unserer Ansicht nach nützlichsten Komponenten aus Scrum und Kanban.

In den letzten Wochen hast Du in Deinem Blog „any-where“ über eine von Dir entwickelte Lösung berichtet, um einen Abgleich zwischen einem Offline-Taskboard und der elektronischen Aufgabenverwaltung mit trac herzustellen. Wie kamst Du auf die Idee und wie funktioniert Deine Lösung?

Hoffentlich hole ich jetzt nicht zu weit aus. Ich arbeite seit 2010 bei RMM und war bis Ende letzten Jahres in ein großes Projekt mit einem unserer spanischen Dienstleister als technischer Berater involviert. Das Projekt scheiterte leider. Wie ich nun weiß, aufgrund der vielen üblichen Fehler, die man machen kann: Falsche Anforderungsanalyse, fehlende Transparenz, das parallele Arbeiten an vielen Tasks und Komponenten, Terminfixierung statt Qualitätsfixierung, fehlende Prioritäten und der Plan eines Big Bang Releases. Erkannt wurde dies früh, aber leider nicht angegangen aufgrund der politischen Struktur des Unternehmens und des Projekts. Anfang des Jahres beschlossen wir, dass dies so nicht mehr passieren darf. Wir begannen, unsere Arbeitsweise hin zu mehr Agilität und Effizienz zu bewegen. Eine Entscheidung übrigens, die direkt aus dem Team heraus angestoßen wurde und einen wirklich spannenden Prozess folgen ließ, der eine merkliche Verbesserung unserer täglichen Organisation und vor allem der Transparenz aller Aufgaben und Projekte mit sich brachte. Ich will das gar nicht im Detail ausführen. Aber unter anderem hängt in unserem 4-Mann-Büro nun ein großes Taskboard, das über alle Projekte hinweg unsere Tasks erfasst und jeden Morgen in einem Daily Stand-up besprochen wird. Auf der Suche nach einem OpenSource-Tool für agile Entwicklung stieß ich auf Agilo als (recht) brauchbare Erweiterung für Trac. Dieses setzen wir nun ein und brauchten quasi sofort eine einfache Möglichkeit, das Offline-Medium Board mit dem Online-Medium Agilo zu verheiraten. Agilo und Trac bringen von Hause aus keine Unterstützung mit. Deshalb entwickelte ich ein kleines Java-Tool TracPrinter, welches aus einem Applet heraus das Drucken von Task-Cards erlaubt. Mit diesem schafften wir den Weg in die eine Richtung: Aus dem Intranet ans Board.

Nun kommt es bei uns oft vor, dass ein Ticket bearbeitet wurde, in „Done“ auf dem Board verschoben, aber in Agilo nicht aktualisiert wurde. Das ist ärgerlich, weil es neben dem Aufwand des nachträglichen Änderns in Agilo viele zu beantwortende Nachfragen gab, wenn die Tickets in Agilo kontrolliert wurden. Wir brauchten also einen einfachen Weg, Tickets in Agilo schnell schließen zu können. Da quasi jeder Zugang zu einem iPhone oder Android-Gerät mit WI-FI-Zugang zum Intranet hat, dachte ich, dass es das einfachste wäre, über das Smartphone eine Möglichkeit zu schaffen, Tickets in Agilo zu bearbeiten. Als einfachste Lösung schienen hier QR-Codes in Frage zu kommen: Somit wurde TracPrinter erweitert um eine Funktion, welche QR-Codes mit einem hinterlegten internen Link zu einem einfachen PHP-Script auf die Ticket-Karten schließt. Nach Scannen des QR-Codes öffnet der Browser dieses Script auf dem Server im Intranet. Derzeit schließt dieses wirklich nur „hart“ das Ticket. So haben wir erreicht, dass Tickets direkt nach Fertigstellung oder im Daily Stand-Up innerhalb von Sekunden geschlossen werden können.

Wie bewährt sich diese Lösung bei Euch im Praxis-Einsatz?
Die Gesamtlösung mit TracPrinter und der neuen QR-Code-Lösung unterstützt unsere Prozesse recht gut. Wie bei allen Dingen steht und fällt dies natürlich mit der Gewohnheit der User: Man muss natürlich dran denken, den TracPrinter zu nutzen, um ein Ticket, das man gerade erstellt hat, auch ans Board zu bekommen. Hier kommen wir öfter an den Punkt, dass ein Ticket zwar in Agilo ist, aber nicht am Task-Board hängt. Aber wir werden besser. Das korrekte Schließen des Tickets in Agilo wird im Daily Stand-Up mittlerweile abgefragt und im Zweifel direkt per Smartphone geschlossen. Hier haben wir wirklich einen Gewinn.

Welche weiteren Entwicklungspotenziale siehst Du für Deine Lösung?
Noch ist alles eine Sammlung loser Tools: Agilo hat seine eigene URL, der TracPrinter ist unter einer eigenen URL im Intranet erreichbar, ebenso das Script, welches Requests via QR-Codes entgegennimmt. Das klappt natürlich – geplant ist allerdings, alles zusammen in eine Erweiterung für Trac zu überführen, um alles an einer Stelle zu haben und den manuellen Schritt des Druckens von Karten direkt in die Erzeugung von Tickets zu integrieren. Darüber hinaus habe ich ja erwähnt, dass via QR-Code die Tickets hart geschlossen werden: Man kann noch nicht differenzieren, ob ein Ticket done oder invalid ist. Auch eine Schnittstelle zur Kommentarfunktion von Agilo existiert nicht. Da die Lösung aber gut angenommen wird, ist der Plan, ein mobiles Interface für Agilo zu schaffen, das es erlaubt, direkt alle Informationen über ein Ticket abzurufen und eine Möglichkeit zu schaffen, den verschiedenen „Schließmöglichkeiten“ in Agilo gerecht zu werden. Somit kann man noch mehr Zeit vor dem Board statt vor Agilo im Notebook verbringen 🙂 Das wird die Kommunikation über Tickets bestimmt weiter fördern.

Ein dänisches Scrum-Team von Vodafone hat vor einigen Monaten eine Lösung für den Abgleich zwischen JIRA und einem Offline-Taskboard mittels RFID-Technologie vorgestellt und dafür einige Aufmerksamkeit bekommen. Wie siehst Du die QR-Lösung im Vergleich zu einer RFID-Lösung? Was hat mehr Potenzial für die Zukunft?

Ja, die RFID-Lösung ist sehr fancy. Vor allem das automatische Einblenden des Burndown-Charts ist spektakulär und wirklich motivierend! Man sieht in Echtzeit den Effekt der Abarbeitung des eigenen Tickets. Tatsächlich war das Video, das ich im Dezember in Deinem Blog über diese Lösung gesehen habe, durchaus ein Impulsgeber für die Ideen, die hier mit Trac und QR-Codes nun umgesetzt sind. Das Problem, Onlinetools mit Offlinemedien zu synchronisieren, ist im Bereich der agilen Entwicklung sicher an vielen Stellen aktuell. Die Entscheidung, Papier zu nutzen und nicht auf einen „großen Touchscreen“ als digitales Board zurückzugreifen und alles direkt online abzubilden, wird ja bewusst getroffen. Nun sind QR-Codes sehr billig, RFID aber leider nicht. Das ist sicher auch einer der Gründe, weshalb wir auf QR-Codes setzen 🙂 Ich weiß ehrlich gesagt nicht, ob und welche Möglichkeiten es bereits mit QR-Codes für marktführende Tools wie Jira gibt. Ich kann mir aber durchaus vorstellen, dass dies eine tolle Unterstützung für viele Projekte sein kann. Uns nutzt es sehr – und solange nicht jeder die Möglichkeit hat, einen RFID-Scanner hinter sein Board zu hängen, ist dies sicher die effizientere Variante. Wenn das Vodafone-Modell aber in Serie geht, werde ich hier sicher vorschlagen, das zu kaufen 🙂

Wie siehst Du in Zukunft die Entwicklung zwischen elektronischem Taskmanagement und Taskboards in Teamräumen. Was für Möglichkeiten werden sich uns da in den nächsten 5-10 Jahren bieten?

Es dauert sicher nicht lang, bis der erste Anbieter ein elektronisches Hardware-Board für den kommerziellen Vertrieb bereitstellt. Auf welcher Technologie dies basiert, sei mal offen gelassen. Aber ich kann mir sehr gut vorstellen, dass es sehr interessante Lösungen geben wird, die in Richtung der Vodafone-Version gehen werden. Das Problem hier ist m.E. nicht unbedingt die technische Machbarkeit und die Kosten sondern vielmehr die Vielzahl der Produkte im Bereich „Taskmanagement“ und die Eigenarten der agilen Arbeit in Organisationen. Dem gerecht zu werden ist sicher eine Herausforderung für Hersteller. Am Ende ist ein einfaches Whiteboard doch schneller den persönlichen Bedingungen angepasst. Natürlich könnte ein Anbieter speziell für die Schnittstelle zu Jira (oder warum auch nicht Agilo/Trac?) ein solches Board herstellen. Ich bin selbst gespannt, was hier kommen wird. Ob RFID hier eine Lösung ist oder tatsächlich mit QR-Codes gearbeitet wird, die von einem Scanner direkt im Board verarbeitet werden können, ist sicher eine Frage der Kosten. Papier ist billiger als RFID. Aber wer weiß, wie sich das entwickelt.

Zum Schluss noch einmal zum Thema QR-Codes: Werden diese dauerhaft interessant und vielfältig im Einsatz sein oder stellen sie nur einen Übergang zu neuen Technologien und Lösungen dar?

Für mich ist unsere QR-Lösung tatsächlich der erste Fall, wo ich – jenseits von logistischen oder produktionstechnischen Anwendungsfällen – einen persönlichen professionellen Nutzen in QR-Codes sehe. Jetzt nutze ich sie täglich als Unterstützung meiner täglichen Arbeit 🙂 Im Consumerbereich sieht das anders aus: Für Endanwender sind QR-Codes ja schon heute bspw. für Ticketing oder Check-ins vielfältig im Gebrauch. Ihr Gebrauch ist einfach und kostengünstig. Wir arbeiten hier auch an Projekten, in denen QR-Codes im Bereich des Couponings und Location Based Services eine Rolle spielen werden. Somit werden sie uns noch eine Weile begleiten 🙂

Vielen Dank, Matthias!
Sehr gerne!

So sehen die Printouts mit QR-Code dann aus:
QR-Codes zur einfachen Aktualisierung eines Taskboards (Foto: Matthias Müller)

Blogartikel von Matthias Müller zu seinen Erweiterungen für trac:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

%d Bloggern gefällt das: