Visualisierung: Behübschung oder Mehrwert für den Scrum Flow?

Überall dort, wo Menschen aufeinandertreffen, um miteinander Dinge zu erarbeiten, zu besprechen und zu planen, ist Visualisierung sinnvoll – zum Beispiel bei Meetings, Tagungen, Konferenzen, Seminaren, Trainings und Workshops. Obwohl es unzählige Möglichkeiten gibt, verstehen viele unter „Visualisierung“ noch immer nur PowerPoint-Präsentationen und vergeben sich damit die Chance auf einen nachhaltigen Eindruck. Was bleibt nach der x-ten PowerPoint-Präsentation in Erinnerung? Endlose Folienschlangen, dicht bepackt mit Zahlen, Daten und Fakten – kaum etwas davon bleibt erwiesenermaßen im Gedächtnis der Zuhörerschaft hängen.
Auch die Wissenschaft zeigt: Visuals schaffen es deutlich besser, die Zuhörer und Zuschauer zu binden. Laut einer Studie der Universität von Minnesota gemeinsam mit der 3M Corporation, die den Einfluss visueller Hilfen im Präsentationssetting untersuchte, kann das menschliche Gehirn Visualisierungen bis zu 60.000 mal schneller verarbeiten als reine Textinhalte. Da 90 Prozent der vom Gehirn absorbierten Informationen visueller Natur sind, können im Anschluss visualisierte Inhalte wesentlich besser abrufen werden.

Visualisierung

Beispiel einer unterstützenden Visualisierung zum Thema “Methodenevolution” während einer interaktiven Meetingform

Das ist ideal für den agilen Kontext, der von der Interaktion, der Freiwilligkeit und Bereitschaft im Team lebt, gemeinsam an Produktlieferungen zu arbeiten. Visualisierungstechniken schaffen es, die Menschen in Arbeitssitzungen und Lernumgebung stärker zu aktivieren. Als Visual Facilitator kann ich hier komplexe Inhalte und unterschiedliche Perspektiven sichtbar machen, dem Team Impulse für den Dialog geben, Gedanken strukturieren und schließlich wichtige Ergebnisse sichern. Neben den zahlreichen Vorzügen zeigen sich in der Unternehmenspraxis allerdings auch einige Herausforderungen, die man beachten sollte, wenn man die Vorzüge der Visualisierung im agilen Kontext nutzen will:

  1. Halten Sie eine lebendige Präsentation. Gehen Sie nicht mit vorgefertigten Flipcharts in eine Präsentation. Als Live-Zeichner sollten Sie die Darstellung im Laufe der Präsentation entwickeln, um die Zuhörer abzuholen, den Erinnerungswert zu steigern und Publikumsfeedback direkt einfließen lassen zu können. Der Zuhörer und Betrachter wird dadurch zweifach kognitiv stimuliert – der Erinnerungswert steigt.
  2. Vermeiden Sie die Ornamentierung von Scrum. Auch wenn Prozess, Inhalte und Ergebnisse in visueller Sprache, d.h. in Kombinationen von Text, Bild und Containern gut sichtbar gemacht werden können, schlägt im Zweifel der Inhalt die Form. Konzentrieren Sie sich auf die Präsentation und nutzen Sie Visualisierungshilfen nur zur Unterstützung Ihrer Kernaussagen.
  3. Lassen Sie sich als ScrumMaster nicht auf die Rolle des Facilitators reduzieren – ein mit bunten Visuals geschmückter Scrum-Meeting-Raum ist keine Garantie für einen funktionierenden Change Prozess. Dem Team und den Stakeholdern hilft die Transparenz, die durch Visualisierungen in Meetings, von Artefakten und auf Boards entsteht. Übernehmen Sie aber nicht alle zeichnerischen Leistungen, sonst werden Sie schnell auf die Rolle des Visual Facilitators reduziert – als ScrumMaster haben Sie noch wesentlich wichtigere Aufgaben!

Nicht nur, aber besonders im agilen Umfeld bieten ausdrucksstarke Visualisierungen die Möglichkeit, den Wert und die Wichtigkeit von Aussagen zu unterstreichen und klarer zu machen. Vom Teammeeting bis zur Großgruppenveranstaltung mit mehreren Hundert Teilnehmern haben Sie ein kraftvolles Tool in der Hand, wenn Sie die damit verbundenen Herausforderungen ernst nehmen.

Foto: CC0 Creative Commons – pixabay, AlexanderStein

Transparenz und Synchronisation mit ETEO und eteoBoard

 
In meinem Buch “Scrum Think b!g” gibt es Beiträge von Partnern und Freunden, die schon lange mit den Ideen arbeiten, über die ich schreibe. Dazu gehört auch Dr. Vincent Tietz, der zum Zeitpunkt, als “Scrum Think b!g” entstanden ist, Senior Consultant und ScrumMaster bei der Saxonia Systems AG war. In seinem Beitrag erzählt er, wie man elektronische Tools und das Prinzip der Informationsweitergabe auf strategischer Ebene einsetzen kann und wie aus einer problematischen Situation ein Produkt wurde.
 
Anfang 2010 standen wir, die Saxonia Systems AG, vor einer großen Herausforderung. Durch die 2008 beginnende Halbleiterkrise verloren wir als IT-Dienstleister bis Ende 2010 ein ganzes Kundensegment und ca. 40 Prozent des regelmäßigen Auftragsbestands. Die parallel ausbrechende Finanzkrise erhöhte den Druck, schnellstmöglich Maßnahmen zu ergreifen, die das Unternehmen stabilisieren und ihm eine langfristige Perspektive geben konnten. Zur gleichen Zeit machten wir positive Erfahrungen mit agilen Projektmanagementmethoden. In unseren Softwareentwicklungsprojekten, sowohl Inhouse als auch in Kundenprojekten, setzten wir zunehmend auf Scrum und wir begannen darüber nachzudenken, ob sich die Prinzipien von Scrum nicht auch auf das Management und dessen Strategieplanung und -umsetzung übertragen ließen.
Im Oktober 2010 begann das Management damit, strategische Ziele zu identifizieren und diese wiederum in mehrere strategische Initiativen zu zergliedern, die mit Product Backlog Items vergleichbar sind. Sie wurden entsprechend priorisiert und für mindestens einen der viermonatigen Strategiesprints (unterjähriger Tripel-Turnus) eingeplant. Das gesamte Unternehmen sollte Klarheit darüber erhalten, welche strategischen Ziele verfolgt werden und wer diese umsetzt. Neben der flexiblen Planung und der Fokussierung der Ressourcen erhoffte man sich die Einbeziehung aller Mitarbeiter, die gleichermaßen an der Umsetzung mitwirken konnten. Wie Scrum in der Softwareentwicklung lebt auch der agile Strategieprozess von Transparenz und Synchronisation. Wertschätzung und Sichtbarkeit der eigenen Arbeit sind genauso wichtige Antreiber wie Freiwilligkeit und Pull-Prinzip.
Wie erreicht man Transparenz und Synchronisation? Scrum-Teams nutzen eine Zettelwand, die im aktuellen Sprint die Aufgaben bereithält und deren Bearbeitungsstand visualisiert. Das Daily Stand-up nutzen die Teammitglieder, um sich über die getane und geplante Arbeit auszutauschen. Nicht zuletzt entstehen dabei Synergien, die dabei helfen, Hindernisse aus dem Weg zu räumen. Alle im Team achten gemeinsam darauf, dass die Arbeit fokussiert und zielgerichtet verläuft. In Analogie dazu haben wir im Strategieprozess ein Stand-up etabliert, das jede zweite Woche mit allen unseren Mitarbeitern stattfindet. Wir tauschen uns dabei über die gerade anliegenden strategischen Initiativen aus. Verdeckte Projekte sind damit kaum mehr möglich und Synergien sowie weiterführende Ideen entstehen oft ganz nebenbei.

Aus der Not wird ein Produkt

Die Saxonia Systems AG war damals ein Unternehmen mit den fünf Standorten Dresden, Leipzig, Görlitz, München und Hamburg. Heute sind es mit Berlin insgesamt sechs Standorte. Weil unsere Consultants viel reisen und es standortübergreifende Teams gibt, begannen wir uns Ende 2010 Gedanken darüber zu machen, wie wir – trotz gegenteiliger Empfehlungen der agilen Community – die verteilte und agile Zusammenarbeit verbessern konnten. Unseren Ansatz nannten wir „Ein Team
Ein Office“ (ETEO). Der ausschlaggebende Punkt schien uns die fehlende Interaktion von Angesicht zu Angesicht zu sein. Daher statteten wir zu Beginn ein Team mit einer Videokonferenzanlage aus, die permanent und in Lebensgröße Teilteams miteinander verband. Für unsere Teams war das ein riesiger Schritt, trotzdem kam das Daily Stand-up nicht richtig in Schwung.
Es war mühselig, mehrere Zettelwände an mehreren Standorten zu synchronisieren, ebenso das Navigieren durch Aufgabenmanagementsysteme an einem PC. Deshalb entwickelten wir ab Januar 2012 auf eigene Initiative unserer Softwareentwickler das digitale und touchbasierte eteoBoard. Wichtig für uns waren die Visualisierung und der Flow-Effekt während der täglichen Stand-up-Meetings – Features, die wir zu diesem Zeitpunkt bei vergleichbaren Lösungen vermissten. Gleichzeitig machte das eteoBoard den Projektfortschritt als einen integralen Bestandteil des Projektraums permanent sichtbar. Heute ist es somit unser Werkzeug für Transparenz und Synchronisation sowohl in unseren Softwareteams als auch bei der Umsetzung des agilen Strategiesprints.
Das eteoBoard synchronisiert jede Interaktion mit allen Standorten, die untereinander verbunden sind. Dabei ist es gleich, ob ein Zettel bewegt, ein Bild eingeblendet oder ein Bearbeiter zugewiesen wird. Jeder Schritt wird durch effiziente Datenübertragung an allen Boards identisch in Echtzeit dargestellt. Es liefert damit einen enormen Mehrwert für verteilte Teams, die bisher entweder mit Zettelwänden oder mit anderen Task-Managementsystemen zu kämpfen hatten. Für uns ist das Tool so wichtig geworden, dass wir es in allen unseren Projekten einsetzen und unseren Kunden in gemeinsamen Projekten ebenfalls zur Verfügung stellen. Unsere Kunden wissen die Transparenz zu schätzen und können damit eher auf den Erfolg vertrauen. Gleichzeitig dient das eteoBoard als Kommunikationstool für verteilte Teams – als Mittel zur täglichen Synchronisation.

Vom Tool zur strategischen Initiative

Was in den verteilten Scrum-Teams funktionierte, übertrugen wir auf unseren Strategieprozess. Dabei erfüllt das eteoBoard zwei wichtige Funktionen: Einerseits dient es als Visualisierung der aktuellen strategischen Initiativen. An jedem Standort gibt es mindestens eine Instanz des eteoBoards zur Visualisierung aller aktuellen strategischen Initiativen. Die Nutzer des eteoBoards können den Detailgrad der Darstellung verändern und die Inhalte der einzelnen Aufgaben einsehen, ohne die Inhalte, den Status oder die Zuteilung zu Bearbeitern verändern zu können. Andererseits dient es uns während der Stand-ups mit allen Mitarbeitern als interaktives Aufgabenboard. Jeden zweiten Freitag versammeln sich die Mitarbeiter zum traditionellen Pizzaessen. Anschließend berichten die Bearbeiter der strategischen Initiativen über den Stand der Arbeiten und die aktuellen Herausforderungen. Da jeder Standort ein eteoBoard mit Videokonferenzanbindung besitzt, können diese das Meeting auf freiwilliger Basis direkt verfolgen oder aktiv werden. Zusätzlich ist es für alle 230 Mitarbeiterinnen und Mitarbeiter möglich, zum Beispiel auf Reisen oder aus dem Home Office via Skype for Business teilzunehmen. Der bisherige Rekord liegt bei 85 Teilnehmerinnen und Teilnehmern. So schaffen wir es, alle Mitarbeiter in einem verteilten Unternehmen zu synchronisieren und gemeinsam an strategischen Aufgaben zu arbeiten.
Nachdem wir die Tragweite der verteilten und agilen Zusammenarbeit erkannt hatten, hielten wir es für richtig, unser Konzept ETEO ebenfalls zu einer strategischen Initiative zu erheben und ab Anfang 2015 inhaltlich mit Unterstützung eines externen Team-Coaches weiter zu verfolgen. In Interviews mit unseren Kollegen sammelten wir die Erfahrungen aus unseren bisherigen Projekten, um zu erfahren, welche Probleme und Chancen sie in der verteilten Teamarbeit sahen und welche
Maßnahmen sie in ihren Projekten ergriffen hatten. Dabei stellten wir fest, dass erfolgreiche verteilte und agile Teamarbeit von mehreren Faktoren abhängt als nur von einer Videokonferenzanlage und einem digitalen Scrum-Board. Wir sammelten Best Practices für die Gestaltung des verteilten Projektraums, sammelten Werkzeugideen und Empfehlungen für die Gestaltung der verteilten Rollen und Prozesse in agilen Projekten: Wer unterstützt den ScrumMaster in einem Team, das über mehrere Standorte verteilt ist? Von welchem Standort aus agiert der Product Owner? Können beide ihren Rollen vollends gerecht werden oder braucht man gegebenenfalls einen Stellvertreter? Besteht das Team ausschließlich aus internen Mitarbeitern oder bilden wir ein Team mit unserem Kunden? Verstehen die Führungskräfte die Implikationen der Verteilung?
Darüber hinaus stellten die Teams fest, dass es schwieriger ist, eine vertrauensvolle Atmosphäre, eine Identität und den Teamzusammenhalt aufzubauen und zu erhalten. Daher entwickelten wir gemeinsam mit einem Team-Coach eine Toolbox, die vom ScrumMaster und vom gesamten Team genutzt werden kann, um ein Team in der verteilten und agilen Softwareentwicklung zu stärken. Grundlage ist ein Wertekompass, der auf den fünf Scrum-Werten Fokus, Offenheit, Verpflichtung, Respekt und Mut aufbaut. Wir ergänzen die Werte Identität, Empathie, Kollaboration, Vertrauen und Einfachheit. Gerade die letzten beiden Werte sind häufig eine Herausforderung in verteilten Teams. In Retrospektiven kann der Wertekompass einem Team dabei helfen, die Werte zu diskutieren, zu bewerten und darauf aufbauend Maßnahmen zur Verbesserung abzuleiten.
 

Der Wertekompass (Copyright: Christian Chalupka)

Der Wertekompass (Copyright: Christian Chalupka)


 

Das Wissen verteilen

Nach unserem Empfinden ist der Aufbau einer guten Umgebung für verteilte und agile Teamarbeit recht anspruchsvoll. Daher begleiten wir die Projekte von Beginn an, unterstützen den Aufbau des Projektraums, helfen bei der Werkzeugwahl und beraten hinsichtlich der Rollen und Organisation eines verteilten Projekts. Bei unseren Kunden schaffen wir mit Management- und Team-Workshops die nötigen Voraussetzungen für ein erfolgreiches verteiltes Team. Während des Projekts unterstützen wir die ScrumMaster und setzen bei Bedarf abgestimmte Workshops an, um die Teams zum Beispiel im Rahmen der Ausbildung ihrer Fähigkeiten zu motivieren und zu synchronisieren. Bei Projektende werten wir die Erfahrungen aus und geben sie an neue Projektteams weiter. Es erstaunt uns noch heute, was im Rahmen einer strategischen Initiative entstehen kann, wenn man den Ideen Raum gibt, sich zu entfalten. Die Früchte der agilen Strategieentwicklung, des ETEO-Konzepts und des eteoBoards ernten unsere Teams und unsere Kunden.
Verschiedene Quellen berichten, dass ein Großteil (bis zu 40 %) aller Entwicklungsprojekte weltweit gezwungenermaßen verteilt realisiert wird (vgl. Ambler 2012). Agilität und Verteilung sind kein Widerspruch, sondern eine Chance. Eine gelungene Kombination agiler Methoden und moderner Kollaborationswerkzeuge macht selbst verteilte Projekte und Organisationen gut beherrschbar. Die Transparenz und Synchronisation sowie die kontinuierliche Verbesserung ermöglichen es uns, den Herausforderungen erfolgreich zu begegnen. Bereits im Frühjahr 2012, nach dem sechsten Sprint, waren die wichtigsten strategischen Initiativen umgesetzt. Unsere Scrum-Teams konnten ihre Reisetätigkeit reduzieren und weiterhin gute Software abliefern. Darüber hinaus sprechen uns Kunden an, um mit uns gemeinsam auch verteilte IT-Projekte zu realisieren. Wir haben aus der Krise gelernt und mit einem agilen Ansatz auf allen Ebenen unserer Organisation einen spannenden Weg in die Zukunft gefunden. Sie hat bisher ungeahnte Ressourcen und Ideen freigesetzt. Wohin uns das führen wird, wissen wir heute noch nicht. Aber es wird gut werden.
 
 
Foto Dr. Vinzent TietzDr. Vincent Tietz ist Projektmanager und Agile Coach bei OSP in der Otto Group in Dresden. Seine Leidenschaft sind eingespielte Teams, die Exzellenz im Handwerk, Mehrwert für den Kunden und echte Zusammenarbeit in den Mittelpunkt stellen. Bei der Saxonia Systems AG war er Softwareentwickler, Scrum Master und für die Optimierung der agilen und verteilten Zusammenarbeit verantwortlich. Heute arbeitet er bei OSP an der Etablierung einer agilen Organisationsentwicklung.
XING
Twitter
LinkedIn
https://www.vincent-tietz.de/
 

Das Burndownchart: Erfolgsmesser und Analysewerkzeug

In einem Projekt saßen wir mit sechs ScrumMastern in einer Runde und diskutierten den Nutzen und das Führen eines Burndowncharts.
Es handelte sich um ein Projekt mit sechs Scrum-Teams und interessant dabei war, dass es erhebliche Unterschiede und Eigenkreationen in der Ausführung gab, die wir näher betrachteten. Einige ScrumMaster führten ihr Burndownchart auf Task-Ebene, einige auf Story-Ebene, beklagten aber, dass häufig kein Erfolg zu sehen sei und der Graph immer erst zum Ende eines Sprints abfalle. Es entstand eine spannende Diskussion mit fruchtbarem Ende.
Betrachten wir die beiden Beispiele näher und machen wir uns bewusst, was uns das Burndownchart zunächst einmal sagen soll:
Auf der horizontalen Achse finden wir die Sprinttage. Auf der vertikalen Achse finden wir die Anzahl der noch zu bearbeitenden Storypoints des aktuellen Sprints, die im Estimation Meeting geschätzt und im folgenden Sprint Planning 1 vom Entwicklungsteam committet, sprich als lieferbar zugesagt wurden.
Pro abgeschlossener Story kann im Sprint nun markiert werden, wie viele Storypoints noch zu bearbeiten sind. Im Normalfall ergibt sich so über den Sprint ein treppenförmiger Graph mit Abwärtstrend, der zum Sprintende oder auch schon vorher die horizontale Achse treffen sollte. Die Teammitglieder können so ihren Fortschritt auf einfache Art und Weise visualisieren.
Wie kann es nun im oben genannten Beispiel dazu kommen, dass sich der Graph in gewissen Fällen parallel zur horizontalen Achse bewegt und erst am Ende eines Sprints einen steilen Abfall nach unten macht, man also meinen könnte, es gäbe keinen Fortschritt?

First things first lautet doch die Devise. Wir arbeiten der Priorisierung nach eine Story nach der anderen ab. So ist die sinnige Idee.
In vielen Fällen wird jedoch über den gesamten Sprint gleichzeitig an mehreren Stories gearbeitet, was eigentlich nicht vorgesehen ist. Dadurch werden die Stories erst spät oder ganz zum Sprint-Ende abgeschlossen und man kann erst hier einen Erfolg ersichtlich machen. Auf die Frage, warum an mehreren Stories gearbeitet werde, sagte eine ScrumMasterin zu mir, es ginge nicht anders, da die Stories ja voneinander abhängig seien.
Das gibt einen Hinweis darauf, dass die Stories nicht der Abhängigkeit entsprechend im Backlog standen. Natürlich muss eine Story, die von einer anderen abhängig ist, weiter unten im Backlog stehen. Wir sehen also, dass das Burndownchart auch Analysezwecken dienen kann. In unserem Beispiel könnten wir also mit dem verantwortlichen Product Owner die Priorisierung des von ihm geführten Backlogs besprechen.
Ein zweiter, typischer Grund für ein Burndownchart, das erst zum Sprint-Ende abfällt, kann die Tatsache sein, dass eine/die Story/s schlichtweg so groß ist/sind, dass man den ganzen oder fast den ganzen Sprint an ihr/ihnen arbeitet. Das Risiko, nicht fertig zu werden, ist also zu groß. Wir können somit aus der Analyse des Charts lernen, dass unser Product Owner die Stories kleiner schneiden muss.
In beiden Beispielen zeigt sich also, dass das Burndownchart ein wunderbarer Indikator für die Priorisierung und Schätzung bzw die Größe der Stories ist.
Was bewegte nun den ScrumMaster, der das Burndownchart auf Taskebene führte? Auf diese Frage berichtete er, dass er täglich einen Erfolg sehen möchte, um mit gutem Gefühl nachhause zu gehen. Es störe ihn nämlich genau der zuerst beschriebene Fall, dass der Erfolg häufig gar nicht oder erst sehr spät zu sehen sei. Die Tatsache, dass er den Erfolg doch an den sich horizontal über das Taskboard bewegenden Tasks sehen kann und unsere Diskussion überzeugten ihn letztlich, das Burndownchart ebenso auf Story-Ebene zu führen. Tun wir dies nicht, stehen uns nämlich die beschriebenen Analysemöglichkeiten nicht zur Verfügung, zumal den Tasks ja keine Storypoints zugeordnet sind. Worauf sollte man also das Führen des Burndownchart dann basieren lassen?
In der beschriebenen Runde mit unseren ScrumMastern beschlossen wir, dass die Charts gesammelt an einer Wand im Büro aufgehängt werden, um so den Erfolg jedes einzelnen Teams transparent für alle zu machen und somit einen positiven Synergie- und Lerneffekt enstehen zu lassen.
Wenn wir nun zusammenfassen, sehen wir, welchen großen Sinn es macht, das Burndownchart auf Story-Ebene zu führen und dass es viel mehr ist, als nur eine visualisierte Information zum Fortschritt des aktuellen Sprints.