Entwicklung einer Teamvision

Kürzlich habe ich für ein Software-Entwicklungsteam einen Workshop für die Erstellung einer gemeinsamen Teamvision durchgeführt. Wir wollten das Bild der Idealvorstellung der Teamsituation von allen Team-Mitgliedern abgleichen und in eine gemeinsam formulierte Vision überführen. Der Workshop war mit einer Stunde angesetzt und damit sehr kompakt. Das Team hatte schon länger zusammengearbeitet und bestand aus 5 Personen. So konnte in der kurzen Zeit ein gutes Ergebnis erzielt werden.

Der Ablauf des Workshops

  1. Begrüßung
  2. Frage: Was erwartet ihr von dem Termin heute? (Blitzlicht)
  3. Geplantes Vorgehen vorstellen
  4. Frage: Wie stellt ihr euch die optimale Arbeitssituation (Zusammenarbeit, Projekte,…) im Team vor?
  5. Vorstellung der Punkte durch die Teilnehmer
  6. Clustering und Überschriften zu den vorgestellten Punkten
  7. Überschriften gewichtet/bepunktet und damit priorisiert, Aufreihung und Ordnung
  8. individuelle Formulierungsansätze
  9. gemeinsame „Vergesellschaftung“ und Übertragung in eine Formulierung

Begrüßung und Erwartungsabfrage, Vorstellung des Vorgehens

Nach ein paar einleitenden Worten von mir haben wir in einer kurzen Blitzlicht-Runde (jeder Teilnehmer antwortet rundum in 2-3 Sätzen) die Erwartungen an den Termin abgestimmt. Dann habe ich das konkrete geplante Vorgehen vorgestellt. Auch habe ich kurz vorgestellt, was eine Teamvision, die wir als Ergebnis erhalten wollte, erfüllen sollte:

  • Sie spricht alle Beteiligten an
  • Sie beschreibt die gewünschte Situation in Gegenwarts-Form
  • Sie ist kurz und prägnant

Frage: Wie stellt ihr euch die optimale Arbeitssituation (Zusammenarbeit, Projekte,…) im Team vor?, Vorstellung der Punkte

IMG_4219 Jedes Teammitglied sollte sich einige Minuten lang in Ruhe überlegen, wie es sich die perfekte Arbeitssituation vorstellt. Jeder Aspekt sollte auf ein eigenes Post-it geschrieben werden.

Dann haben wir uns zusammen vor einer Wand versammelt und die Teammember haben nach und nach ihre Punkte vorgestellt. Bei der Vorstellung wurde auch direkt ein grobes Clustering vorgenommen, ähnliche Punkte wurden also nahe zueinander gehängt, während unterschiedliche Themen voneinander entfernter aufgehängt werden.

Clustering und Finden von Überschriften zu den vorgestellten Punkten

Das grobe Vorab-Clustering wurde dann nach Vorstellung aller Punkte noch einmal zusammen besprochen und die einzelnen Cluster haben jeweils einen eigenen Namen bekommen.

Überschriften gewichtet/bepunktet und damit priorisiert, Aufreihung und Ordnung

IMG_4223

Die Teammember konnten dann eine vorgegebene Zahl von Punkten auf die einzelnen Cluster verteilen und damit ihre Gewichtung für das entsprechende Thema zum Ausdruck bringen.

Das ganze haben wir dann noch einmal nach Gewichtung geordnet und aufgereiht. Wie auf dem Bild auf der linken Seite ersichtlich haben wir jeweils die Überschrift mit den Punkten links aufgehängt, die Post-its, aus denen sich die Überschrift ergeben hatte, rechts daneben.

Individuelle Formulierungsansätze

Gedanklich befüllt mit den bisher besprochenen Wünschen und Vorstellungen der Teammember nahmen sich jetzt alle Teammember noch einmal in Ruhe Zeit, eine individuelle Formulierung der Teamvision vorzunehmen. Nach rund 10 Minuten konnten alle Teammitglieder eine Formulierung der gewünschten Situation in einer Ist-Beschreibung in 3-4 Sätzen vorweisen.

Gemeinsame „Vergesellschaftung“ und Übertragung in eine Formulierung

Jedes Teammitglied stellte die eigene Formulierung vor. Relativ schnell fand das Team eine Formulierung, die es als Ausgangsbasis für die gemeinsame Version der Teamvision nehmen wollte. Es wurden noch verschiedene Umstellungen und Ergänzungen vorgenommen, bis eine kompakte Formulierung in zwei Sätzen, mit der alle Teammitglieder zufrieden waren, gefunden war.

Die Formulierung haben wir dann in einer schöneren Form noch einmal aufbereitet und im Teamraum aufgehängt. Wichtiger als das formulierte Ergebnis selbst war dabei das im Laufe des Workshops gefundenen gemeinsamen Bildes davon, was dem Team wichtig ist.

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz am 7. November 2013 in Wiesbaden

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.

Arbeiten im Scrumteam: Der visuelle Teamraum

Für Software-Entwicklungsteams, die für einige Zeit zusammen an einem Projekt arbeiten, ist die Einrichtung eines Teamraums eine sinnvolle Maßnahme.

Dies fördert auf unbeschreibliche Weise die Kommunikation zwischen den Projektteilnehmern und trägt damit zum Erfolg bei. Zudem ermöglicht es, einige für den Projekterfolg wichtigen Dinge deutlich sichtbar aufzuhängen.
Darüber, welche Informationen das sinnvollerweise sein sollten, ist im Blog von //SEIBERT/MEDIA ein Artikel von mir erschienen.

Zum Artikel im //SEIBERT/MEDIA Blog

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

„Das gesamte Scrum-Team besteht aus Helden“

Für mich das schönste Zitat aus „Scrum: Produkte zuverlässig und schnell entwickeln“ von Boris Gloger:

Das gesamte Scrum-Team besteht aus Helden. Sie haben die Aufgabe, täglich Entscheidungen zu treffen. Sie müssen tun, was nötig ist, um ein Ziel zu erreichen, und das erfordert Courage.

Es klingt beim Lesen erst einmal komplett übertrieben. Doch es beschreibt den Mentalitätswandel der in Teams passieren muss, um erfolgreich mit Scrum zu arbeiten. Das Team führt keine Aufforderungen aus, sondern erarbeitet Lösungen, das erfordert Entscheidungen und das … . Warum nicht gleich in den Teamraum hängen? Zitat als PDF

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: