Steuern mit dem Taskboard

Wie im ersten Teil „Taskboard Basics“ beschrieben, sind Taskboards ein einfaches, aber wirkungsvolles Mittel, um einen Überblick über den Arbeitsfortschritt von Teams zu geben. Manchmal auch mit brutaler Ehrlichkeit. So erlebt in einem Daily vor einem vielzeiligen, ein wenig zerfleddert wirkenden Taskboard. Bei vielen Storys hingen einzelne Tasks “in progress”, Punkte für hängengebliebene Tasks wurden schon nicht mehr verzeichnet und ganz unten prangte die Zeile für “Sonstiges“. Resultat: Wir rackerten uns ab, bekamen aber kein einziges Ding fertig. An priorisiertes Abarbeiten war gar nicht zu denken.
Das Resultat des Sprints waren viele offene, halbfertige User Storys. Jedes Teammitglied hatte bei fast jedem Thema ein wenig mitgestaltet. Bei vielen Storys war der letzte Schritt zur Erfüllung der Akzeptanzkriterien aber noch nicht erledigt oder sogar unklar. Spätestens nach dem nächsten Sprintwechsel verursachten die unfertigen Storys und das noch immer mit denselben Themen vollgepackte Taskboard Schmerzen – und die führen bekanntlich zur Veränderung. In unserem Fall durch eine Intervention von zwei Teammitgliedern. Das Taskboard ist immerhin nicht nur ein Reportingtool, es bietet auch die Möglichkeit, die Arbeit aktiv zu gestalten.
Nach dem Motto “Stop starting, start finishing” wurde das Taskboard umgebaut und die Regeln der Zusammenarbeit wurden geändert: Neben der User Story wurde nun das zugehörige Akzeptanzkriterium, auf das wir uns geeinigt hatten, explizit gemacht; unter der ersten User Story prangte ein dicker Strich. Die Aussage war klar: Wir greifen die zweite User Story erst an, wenn die erste User Story abgeschlossen ist. Bis dahin unterstützt jedes Teammitglied die Kollegen oder hat eben Slack. Ein gewagter Ansatz. Das Team committete sich trotzdem. Versuchszeitraum: ein Tag.

Acht Stunden später

Am Ende des ersten Tages war die Zahl der Tasks gestiegen, da Kollegen ihre Aufgaben kleiner geschnitten hatten, um Teile auf andere Teammitglieder auszulagern. 19 Tasks done, fünf andere auf “to do” oder “in progress”. Die Disziplin hatte gehalten, keine anderen Baustellen wurden aufgerissen. Die Lieferung der Story war nicht innerhalb eines Tages möglich, aber wir standen kurz vor der Fertigstellung unserer Delivery. Das Experiment hatte sich bewährt.

Unser Fazit

Durch die Fokussierung haben wir drei Ziele erreicht:

Taskboard Basics

Jeden Morgen treffe ich mich mit meinem Team aus ScrumMastern vor unserem Taskboard, jeden Morgen synchronisieren wir uns im Daily und jeden Morgen verschieben wir dabei Post-Its auf mehreren Spalten von links nach rechts. Synchronisation über den Arbeitsfortschritt, das Glücksgefühl, etwas erfolgreich abgeschlossen zu haben und auf “Done” hängen zu können oder einfach nur einen Überblick über die Aktivitäten des Tages zu bekommen – es gibt viele Gründe, die für ein Taskboard sprechen.

Wie ist ein Taskboard aufgebaut?

Wegen seiner vielen Vorteile hat sich das Taskboard schnell verbreitet. Teams passen ihre Taskboards zwar ihren Bedürfnissen an, der Grundaufbau bleibt aber immer gleich. Es besteht aus drei Spalten: Tasks „To Do“, „Work in Progress“ und „Done“.
Taskboard
Scrum-Teams stellen vor die „To Do“-Spalte außerdem noch die priorisierten User Stories, auf die die jeweiligen Tasks einzahlen. Ein Taskboard liest sich also in der Regel von links nach rechts (Fortschritt) beziehungsweise von oben nach unten (Priorisierung). Neben den Spalten nutzen Teams gerne auch horizontale Unterteilungen, sogenannte „Swim Lanes“. Diese helfen, die Zuordnung von Tasks zu einer User Story besser im Blick zu behalten.
Darüber hinaus gibt es noch verschiedenste Elemente, die die Bedürfnisse des jeweiligen Teams unterstützen:

Obwohl es mit wenigen Handgriffen gebaut werden kann, hilft uns das Taskboard, einen Überblick über unsere aktuelle Arbeit zu geben und veranschaulicht den Arbeitsfortschritt des Teams. Das Taskboard ist dabei nicht nur Reportingtool, sondern gibt Teammitgliedern vielmehr auch die Möglichkeit, Sachen auf „Done“ zu setzen und somit als fertig abzuhaken. Dank dieser Erfolgsmomente wird es von Teammitgliedern als Arbeitswerkzeug geschätzt.

Scrum Spaces oder Agilität braucht Raum

Ich habe ein neues Team, ein neues Projekt, eine neue Herausforderung. Einige der Tätigkeiten scheinen jedoch auf den ersten Blick nur wenig mit den Aufgaben eines ScrumMasters, wie man ihn aus den Lehrbüchern kennt, zu tun zu haben. Ich möchte, dass mein Team sich wohlfühlt, schließlich wird es hier, im Teamraum, die meiste Arbeitszeit verbringen. Mein Ziel: Ein Raum, in dem alle Lust haben zu arbeiten.
Scrum muss gelebt werden und um etwas zu leben, muss man es spüren – jeden Tag aufs Neue. Es ist ein aufregendes Gefühl, Teil von etwas Neuem zu sein. Scrum heißt, gemeinsam an einem Ziel zu arbeiten. Dieses Wir-Gefühl soll sich auch im Arbeitsraum widerspiegeln. Eine gute Stube. Hier sitzen ALLE Entwickler zusammen. Idealerweise finden auch ScrumMaster und Product Owner in der guten Stube ein Plätzchen zum Arbeiten. An diesem Punkt kommt oftmals die Frage: „Warum denn alle zusammen? Ich habe doch mein Büro …“ Eine einfache Antwort: Face-to-face- Kommunikation. Eine Frage oder ein Problem ist im direkten Gespräch viel schneller geklärt. Ohne Telefon, ohne E-Mail, ohne Chat. Ein Problem? Wir kreieren gemeinsam die Lösung! Tasks können in einem Teamraum einfach leichter und schneller gemeinsam bearbeitet werden. Durch das gemeinsame Arbeiten werden Wissen und Erfahrung direkt ausgetauscht und die Qualität des Arbeitsergebnis steigt dadurch erheblich.
Im Agile Manifesto liest man:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Doch wie schaffe ich es als Scrum Master, diese Prinzipien in das tägliche Arbeitsumfeld meines Teams zu implementieren? Bei der Frage nach dem perfekten Teamraum für agile Teams gibt es kein Schwarz oder Weiß. Alles, was sich gut anfühlt, ist erlaubt. Teams sitzen gerne zusammen, ob in Arbeitsinseln oder in einer U-Form. Fühlt sich das Team wohl, ist es die richtige Form. Und wenn nicht? Dann nutzen wir doch einfach zehn Minuten nach dem Daily, um ein wenig zu experimentieren … agil sein … anpacken und testen.

Wie sieht unser Teamraum nun aus?

Als ich die Teammitglieder gefragt habe, was für sie wichtig ist, stand an erster Stelle das Taskboard. Das Team wünscht sich, immer einen guten Blick auf seine Aufgaben zu haben. Wichtig ist den Teammitgliedern auch, die Sitzplätze je nach Zusammenarbeit wechseln zu können.
Wir wissen, wie wichtig die gemeinsame Arbeit an einer Tätigkeit und der disziplinenübergreifende Austausch sind. Also haben wir die Trennwände zwischen den Arbeitsplätzen abgebaut und Raumteiler entfernt. Nichts, abgesehen von den Bildschirmen, steht nun den Entwicklern und ihrem täglichen Austausch im Weg. Jeder kann so mit jedem kommunizieren und arbeiten, aufstehen, Sitzplatz wechseln, alles ist erlaubt. Feste Sitzplätze schränken das agile Arbeiten für gewöhnlich ein. Daher kann die tägliche Teamaufteilung (Pairs oder MiniMobs) je nach Bedarf wechseln. Das bedeutet auch, dass sich die Sitzordnung mit jeder Anforderung ändert. Platzwechsel als ein kleiner Ausdruck von Agilität – den Blickwinkel auch auf den Teamraum einmal ändern.
Viele Teams zeichnen und teilen gerne ihre Ideen, sie wollen die Strukturen oder Abhängigkeiten ihrer Storys und Tasks sehen. Am besten funktioniert das auf Whiteboards oder Flipcharts. Hier können neue Ideen ergänzt, Optimierungen direkt eingearbeitet und am Ende alles auf einem Foto festgehalten werden. Die zu Beginn noch weißen und leeren Wände füllen sich dann im Laufe der Zeit mit zahlreichen Visualisierungen, Zeichnungen und Artefakten. So bekommt der Raum einen teamindividuellen Ausdruck (oder Anstrich). Wichtig ist dabei, auch darauf zu achten, dass kein Information-Overflow entsteht, sondern dass nur Informationen vorhanden sind, die das Team wirklich braucht.
Wenn der Teamraum groß genug ist, würde ich als ScrumMaster noch eine Time-out-Zone einführen. Bequeme Sessel, ein Sofa – Open Areas. Dieser Bereich ist ideal für ad-hoc-Meetings, so muss nicht extra ein Meetingraum gebucht werden. Auch kann dieser Open-Space-Bereich einfach für 10 Minuten kreative Pause genutzt werden. Diese kurzen Auszeiten können für die Produktivität wahre Wunder wirken.
Agile Räume sind in meinen Augen genauso wie ihre Teams: individuell und anpassungsfähig.

Das andere Ende der Leitung: Scrum in verteilten Teams

Verteilte Teams passieren nicht. Sie entstehen, weil das Management festgestellt hat, dass erforderliches KnowHow nicht an einem Ort versammelt ist oder an einem anderen Standort günstiger zu bekommen ist. Wir müssen unser Team also dezentral organisieren. Nachdem wir uns im ersten Schritt mit der Kommunikation in verteilten Teams befasst haben, können wir uns nun daran machen, das Projektmanagement zu organisieren.

Warum bietet sich Scrum für die Organisation verteilter Teams an?

Am Ende jedes erfolgreichen Teambuilding-Prozesses steht ein gemeinsam geteiltes und verinnerlichtes Ziel. Im Scrum-Umfeld verbinden wir dieses gemeinsame Ziel in erster Linie mit dem Artefakt der Vision und mit dem agilen Wert des Commitments. Die Vision sollte bereits auf strategischer Ebende schnell, klar und deutlich verbreitet und laufend erneuert werden. Auf Sprint-Ebene ist das Commitment zu einem gemeinsamen Ziel das erste integrative Element. Es hilft dem Team, sich auf die Aufgaben des kommenden Sprints zu konzentrieren.
Scrum setzt auch im Verlauf des Sprints auf mehrere integrative Effekte. Wie bereits erwähnt ist das Peer Working ein effektiver Weg der Zusammenarbeit. Hier geht es aber nicht nur um den angesprochenen Vertrauensaustausch. Wenn es den Teamspirit stärkt, Checklisten abzuhaken hilft es uns erst recht, dieses Erfolgserlebnis zu teilen. Apropos: (Miss-)Erfolg ist der abschließende integrative Teil unserer Arbeit. Das Erreichen eines gemeinsamen Ziels kann uns als Team bestärken, Lohn für unsere Mühen sein. Ebenso kann gemeinsamer Leidensdruck Auslöser für Veränderung und Verbesserung sein.

Be part of it!

Spätestens wenn Sie versuchen, Magic Estimation mit einem verteilten Team zu spielen, werden Sie herausfinden, dass die Integration von Menschen, die sich nicht in einem Raum befinden, recht kompliziert sein kann. Hier gibt es verschiedenste Lösungsansätze, die je nach Teamsetting umgesetzt werden können. Zum Beispiel

Spätestens, wenn Sie ein großteils verteiltes Team betreuen, müssen Sie sich als ScrumMaster über eine vollkommen digital spielbare Variante der Magic Estimation Gedanken machen. Egal, um welches Meeting oder welchen Arbeitsschritt es sich handelt, die zwei wichtigsten Anforderungen sind dabei, dass

Remote. Ein Problem, das wir letzten Endes alle kennen.

Ihr Scrum-Team ist an einem Standort zusammengefasst? Herzlichen Glückwunsch! Sie werden sich im Rahmen der Zusammenarbeit gewisse Abstimmungsarbeit sparen. Das bedeutet aber nicht, dass Sie die oben genannten Grundsätze nicht beachten sollten. Irgendwie ist nämlich jedes Team verteilt. Wenn wir von Scrum sprechen, meinen wir die kontrollierte Zusammenarbeit von verschiedenen (Interessen-)Gruppen, den Rollen. Ich habe schon verschiedenste Unternehmen und Teams gesehen: Eine Konstellation, in der der operative Kern, externe Zulieferer, Management, Kunden und User nicht verteilt waren, habe ich dabei noch nie beobachtet. Die zugrundeliegenden Probleme können dabei durchaus die gleichen sein wie bei einem verteilten Scrum-Team. Somit betrifft uns das Problem des verteilten Teams doch irgendwie alle. Machen wir uns das bewusst und agieren wir dementsprechend. So können wir uns wieder ein klein wenig verbessern.

5 Punkte für ein effektives Daily

Scrum ist ein hocheffizientes Rahmenwerk für die Produktentwicklung, sofern es richtig gelebt wird. Leider erleben wir zu oft das Gegenteil. Die Scrum Meetings werden prozessual etabliert, aber es fehlt am qualitativen Mehrwert, der durch die Meetings entstehen sollte.
Immer wieder sehen wir Dailys, in denen der ScrumMaster vor dem Board steht, als gelte es sein Heiligtum zu bewachen. Das Team hat im weiten Bogen um ihn herum Aufstellung bezogen und jede Person sagt einen Satz, ohne dass sich die Kärtchen am Taskboard bewegen. Fast alle Storys hängen in der WIP-Spalte und die Tasks bekommen trotz Bewegungsfaulheit keinen Punkt dafür. Der Product Owner vergibt bei Gelegenheit noch Aufgaben an einzelne Teammitglieder und fährt anderen Teammitgliedern über den Mund.
Ein so oder so ähnlich durchgeführtes Daily ist leider ein sehr ineffizientes Daily. Gut, immerhin ist das Daily als Meeting etabliert. Es wäre weitaus schlimmer, wenn das Meeting überhaupt nicht stattfinden würde. Da es stattfindet und das auf eine transparente Art und Weise, können wir anfangen, es in eine effektive Richtung zu lenken.

1. Daily als Ort der Kommunikation

Das Daily ist KEIN Statusreport für den Product Owner und auch nicht für den ScrumMaster. Das Daily ist da, damit sich das Dev-Team austauschen und koordinieren kann. Die Mitglieder des Dev-Teams sprechen miteinander und erklären sich gegenseitig, was sie machen, wo sie bei der jeweiligen Story noch Hilfe brauchen bzw. wo es sinnvoll ist, im Pairing zu arbeiten. Der ScrumMaster achtet darauf, dass das Ganze im zeitlichen wie auch menschlichen Rahmen bleibt und ist hellhörig bezüglich Impediments. Der Product Owner steht für Rückfragen zu den Akzeptanzkriterien zur Verfügung oder kann sich einbringen, wenn er das Gefühl hat, dass das Dev-Team über das Ziel der Akzeptanzkriterien hinausschießt.
Umsetzung: Der SM fordert die Teammitglieder auf, vor dem Taskboard zu stehen und stellt sich selbst mit den Product Owner in den Hintergrund. Wenn der ScrumMaster oder der Product Owner in den Mittelpunkt der Kommunikation rutschen, erklärt der ScrumMaster wiederholt, dass das Daily nicht dazu da ist, um ihn oder den Product Owner auf den neuesten Stand zu bringen. Das Daily dient dem Informationsaustausch zwischen den Teammitgliedern. Der ScrumMaster hält bei Bedarf wiederholte Mini-Workshops ab, um den Sinn eines Dailys zu erläutern und coacht bei Bedarf den Product Owner in seiner Rolle.

2. Das Herz des Dailys – Aufbau des Tasksboards

Ein Taskboard besteht aus drei Spalten: To do, Work in Progress (WIP) und Done – nicht mehr und nicht weniger. Die horizontalen Zeilen ergeben sich aus den Storys, wo die Tasks zugeordnet sind.
Umsetzung: Der ScrumMaster baut ein Taskboard auf. Unsere beliebtesten Hilfsmittel sind: Pinnwände oder Metaplanwände, die mit Kreppband oder Garn und Stecknadeln in die Bereiche aufgeteilt werden. Moderationskarten sind optimal für die Spaltenüberschriften und die Storys, während verschiedenfarbige Post-its und Stifte das tägliche Aktionsmaterial sind.

3. Die Fragen für das Daily

Man orientiert sich an den 4 Fragen:

Diesbezüglich gibt es mehrere Optionen. Entweder man geht diese Fragen pro Teammitglied oder pro Story durch. Ich persönlich präferiere letzteres: Letztendlich geht es darum, zu sehen, ob die Storys fertiggestellt werden können und nicht darum, dass alle Teammitglieder ausgelastet sind. Wer etwas Neues ausprobieren will, geht einen Schritt weiter und lässt die Teammitglieder herzeigen, was Sie bereits produziert haben, sodass jedes Daily zum Mini-Review wird.
Umsetzung: Der ScrumMaster achtet darauf, dass zu jeder Story/Person die Fragen beantwortet werden. Wenn etwas vergessen wird, erinnert er daran. Die Fragen auf Moderationskarten neben dem Taskboard aufzuschreiben, ist eine einfache und gute Erinnerungsstütze. Beim Mini-Review sorgt der ScrumMaster dafür, dass die Teammitglieder zwischen den Präsentationen zum Taskboard zurückzugehen, um es auf den neuesten Stand zu bringen. Der ScrumMaster sorgt dafür, dass die Timebox von 15 Minuten eingehalten wird, indem er die Leute daran erinnert, sich kurz zu halten bzw. eine Uhr mitlaufen lässt, die alle daran erinnert, wie viel Zeit noch übrig ist. Tipp: Es gibt Timebox-Uhren mit kleiner werdendem Zeitbereich zu kaufen.

4. Das Team bewegt sich, nicht der ScrumMaster

Das Team bewegt die Tasks über das Taskboard. Wenn ein Task done ist, sollte er auch wirklich done sein und nicht mehr zurückkommen. Dabei hat jeder Task ein Namenskürzel. Auch wenn wir Consultants als ScrumMaster arbeiten, können wir uns nicht immer merken, wer von uns welchen Task erstellt hat – mit Namenskürzel auf dem Task hat man aber immer eine Anlaufstelle, wenn man sich über Sinn und Zweck eines Tasks im Unklaren ist. Sollte sich ein Task nicht in die nächste Spalte bewegen, bekommt er jeden Tag einen Punkt und zwar von den Teammitgliedern. Der ScrumMaster achtet auf diese Tasks und fragt während oder nach dem Daily, ob es ein bestimmtes Impediment gibt, das die Fertigstellung des Tasks behindert, oder ob der Task einfach nur zu groß ist.
Umsetzung: Der ScrumMaster bittet die Leute, selbst die Tasks zu schreiben und zu bewegen und reicht dabei auch gerne die Stifte. Auch wenn es sich am Anfang unangenehm anfühlt: Der ScrumMaster bittet die Leute wiederholt höflich (oder auch direkter), die Tasks selbst zu schreiben, zu bewegen und Punkte zu machen. Irgendwann wird er es nicht mehr tun müssen, weil es die Leute selbst tun werden.

5. Flow

Es wird immer daran gearbeitet, so wenige Storys wie möglich offen zu halten und so wenige Tasks wie möglich in progress zu haben. Im Allgemeinen gilt es, sich immer in die Richtung des Optimums einer offenen Story zu bewegen und eine Taskanzahl in progress zu haben, die geringer oder gleich der Anzahl der Teammitglieder ist. Wir wissen alle, dass Multitasking ineffizient ist und wir wollen einen schnellen Feedback-Loop mit dem Product Owner erzeugen. Sobald eine Story abgeschlossen ist, nimmt der Product Owner sie ab bzw. gibt Feedback, warum sie nicht abgenommen werden kann.
Umsetzung: Der Scrum Master vereinbart mit dem Team ein WIP-Limit auf Story-Ebene oder gibt eines vor. Er sorgt dafür, dass das WIP-Limit eingehalten wird, indem er es nicht zulässt, dass weitere Storys eröffnet werden. Sobald eine Story fertig ist, sorgt er oder sorgen die Teammitglieder dafür, dass der Product Owner davon erfährt. Der ScrumMaster sorgt dafür, dass es bald Feedback gibt, ob die Story abgenommen wird oder was die Abnahme verhindert.
 
Es gäbe noch viel mehr dazu zu sagen, aber diese fünf Punkte sind für mich die Basis für jede weitere Aktion – sie erschaffen im Kern eine gesunde Daily-Kultur. Dabei ist es wirklich schwierig, diese Punkte alle im Kopf zu behalten und kontinuierlich zu kontrollieren. Es ist ein Idealbild, dem man sich im im Laufe der Zeit annähern kann. Im Laufe der Entwicklung des Scrum-Prozesses wird der ScrumMaster immer mehr seiner Verantwortung an die Teammitglieder abgeben, sobald er sieht, dass sie das Konzept verinnerlicht haben. Am Anfang jedoch muss er durch Vorzeigen, Vorleben und häufiges Erklären die Grundlage und das Verständnis für die Vorgänge schaffen, die für langfristige Produktivität sorgen.

Ist "done" wirklich "better than perfect"?

Wenn ein Team mal wieder Ewigkeiten an etwas rumschraubt, ohne zu einem Ende zu kommen, wird in der agilen Community gerne ein Spruch verwendet: „Done is better than perfect!“ Er hat in der Zwischenzeit eine gewisse Berühmtheit erlangt, sodass ich keinen Agilisten kenne, der nicht schon drüber gestolpert ist (oder ihn im eigenen Repertoire hat) und ja, ich verwende Ihn auch gerne – sowohl für meine eigenen Projekte als auch um anderen Menschen den Kern der Agilität beizubringen. Dabei gilt es aber, eine gewisse Vorsicht walten zu lassen, da dieses Sprichwort sehr unterschiedlich verstanden werden kann. Reden wir bei „Done is better than perfect“ davon, die Tätigkeit schnell mal zu erledigen, sie in eine Ecke zu werfen und die nächste Sache anzugehen? Nein, das wäre genausowenig zielführend, wie Ewigkeiten an einem Thema zu arbeiten und darauf zu hoffen, alles perfekt zu machen, ohne andere Leute zu involvieren.

Einfach wie das Autofahren

Tatsächlich hat dieses Sprichwort viel damit zu tun, uns selbst Lernschritte zu ermöglichen –  in kleinen gut verdaulichen Häppchen, ohne dass wir von Anfang an viel zu viel Arbeit investieren. Das Sprichwort soll ermutigen, den allerersten Draft (im Sinne eines in sich geschlossenen, aber rudimentären Prototyps) so schnell wie möglich zu erstellen und in einen Feedbackzyklus mit den Kunden oder Kollegen zu gehen, um an der nächsten Iteration zu arbeiten. Man kann sich das etwa so vorstellen wie die minimalen Ausgleichsbewegungen beim Autofahren. Wir würden doch auch nicht die Augen schließen, losfahren und nach einer halben Stunde kontrollieren, ob wir auch wirklich wie geplant perfekt am Ziel gelandet wären, oder? Der Fahrer hat immer die Straße im Blick und kontrolliert damit die Korrekturbewegungen seiner Hände am Lenkrad (wir fahren in der Realität nie wirklich ganz gerade, sondern gleichen ständig aus). Beim Autofahren sorgt also ein sehr schnelle Feedback-Loop dafür, dass wir minimale Abweichungen vom Soll jederzeit korrigieren.
Ähnlich wie beim Autofahren sollten wir diese Methode in unseren Alltag integrieren. Es ist wichtig, nicht allzu lange alleine an etwas zu tüfteln, sondern so schnell wie möglich nach draußen zu gehen und andere Menschen um ihr Feedback zu fragen. Nur so kann man wissen, ob man vielleicht in eine nicht so sinnvolle Richtung abgedriftet ist und wo man vielleicht eine andere, neue Richtung einschlagen sollte. Das Feedback muss man nicht immer umsetzen, aber eine Meinung, die über das eigene System hinausgeht, ist in jeder Hinsicht wertvoll.

Nur das Ego legt sich quer

Das einzige, was uns davon abhalten kann, ist unser liebes Ego. Gibt es irgendein sinnvolles Argument, seine Ideen nicht schon recht früh jemand anderem zu zeigen? Ich persönlich sehe nur einen Grund: Die Angst davor, dass jemand die geniale Idee für doch nicht so genial halten könnte. Dabei vergessen wir aber gerne, dass selten eine Türe zugeht, ohne dass sich eine andere öffnet. Es entsteht doch immer etwas Neues, wenn wir unsere Ideen dem Umfeld zeigen, und je früher wir das tun, desto schneller können wir unser Produkt adaptieren und wirklich das erschaffen, was der Zeit und Ort gerade dringend benötigen.
Ich persönlich arbeite daran, diesem Konzept immer öfter und immer früher in meinem Leben zu folgen. Die herben Enttäuschungen werden weniger und ich werde mir immer mehr bewusst, dass es nicht darum geht, etwas alleine bis zur Perfektion zu treiben (natürlich vergesse ich manchmal darauf, aber es ist eine Tendenz erkennbar). Das ist ungemein erleichternd. Ich muss nicht mehr der Superheld sein, der die Dinge von Anfang bis Ende perfekt gestaltet, sondern ich habe die Möglichkeit, mich ständig zu adaptieren und etwas zu gestalten, das iterativ durch Feedback besser wird. Und das jederzeit im Bewusstsein, dass ich mich Stück für Stück in die richtige Richtung bewege und am Ende nicht darum zittern muss, in eine komplett falsche Richtung gelaufen zu sein.
Warum sich also das Leben kompliziert machen, wenn es auch so einfach geht, oder?

Der Testmanager in Scrum

Auf den Software Foren Leipzig im April hatten wir das Vergnügen, Kay Grebenstein, Testmanager bei unserem Partner Saxonia Systems, über den Testmanager in Scrum sprechen zu hören. Sein Vortrag war für mich deshalb so interessant, weil er uns ein Mapping der Aufgaben des Testmanagers auf die Aufgaben des Development-Teams zeigte und begründen konnte, dass Scrum-Teams tatsächlich alle Aufgaben des Testmanagers erfüllen (können). Nach den Standards des International Software Testing Boards (ISTQB) hat ein Testmanager folgende Aufgaben:

Grebenstein_Folie01

(c) Kay Grebenstein


Dabei wird zwischen strategischer Ebene – der des Qualitätsmanagers – und der operativen Ebene (Testmanager) unterschieden. Laut Grebenstein müssen wir also schauen, dass sich Scrum-Teams mit beide Ebenen befassen. Auf den ersten Blick sagt Scrum nichts darüber aus, wie getestet wird und wer dafür die Verantwortung übernehmen sollte. Sicher, es wird immer gesagt, dass in Scrum das Team testet. Aber wer trägt die Verantwortung?
Sieht man sich die Standards des ISTQB an, hat ein Testmanager Aufgaben wie
• den Aufbau eines Testteams,
• das Erstellen eines Testkonzepts,
• Erstellen der Testfälle durch die Tester,
• Erstellen und Durchführen der Testfälle durch das Testteam,
• u.v.m. (siehe unten)
Grebenstein_Folie03

(c) Kay Grebenstein


Wie passt dazu nun ein agiler Testprozess, der all das ja nicht vorschreibt? Grebenstein  zeigte uns dazu zunächst, wie in einem Scrum-Team getestet wird. Und richtig, alle von der ISTQB beschriebenen Aufgaben werden vom Team tatsächlich erfüllt.
Grebenstein_Folie04

(c) Kay Grebenstein


Die Tester im Team – oder besser das Entwicklungsteam selbst – wird nun mit diesen Dingen konfrontiert und die Kompetenz der Tester wächst, weil sie die gesamte Testpyramide abdecken müssen. Das bedeutet, dass die Tester nun sowohl für Unit-, Service- und Systemtest zuständig sind und das Testen, die Domain und das Codieren beherrschen müssen, da sie alle Tests auch automatisieren sollten, wenn nicht sogar müssen.
(c) Kay Grebenstein

(c) Kay Grebenstein


 
Schaut man sich die Aufgaben (siehe erste Abbildung) noch einmal an, ist nun die wichtige Frage, wann diese Aufgaben durchgeführt werden. Dabei werde auf der obersten Ebene – bei agilen Transitionen – die Aufgaben der strategischen als auch der operativen Ebene von den Scrum-Teams durchgeführt. Und hier das dazugehörige Mapping:
(c) Kay Grebenstein

(c) Kay Grebenstein


 
(c) Kay Grebenstein

(c) Kay Grebenstein


(c) Kay Grebenstein

(c) Kay Grebenstein


 
Genau betrachtet ist nicht viel nötig, um alle Aufgaben gemäß ISTQB durchzuführen. Dazu müssen wir nur geeignete Meetings oder Artefakte bereitstellen oder bestimmte Verfahren wie exploratives Testen tatsächlich durchführen. Dabei hilft es, die drei Stadien Testkonzeption, Umsetzung und Koordination auseinanderzuhalten und getrennt voneinander anzuschauen.
Alles in allem war der Vortrag von Kay Grebenstein ein Gewinn für die agile Community, weil er es dem ScrumMaster ermöglicht, den Qualitätssicherungsabteilungen fundiert entgegenzutreten und in skalierten Umfeldern (Scaled Agile) zu zeigen, dass Scrum alle notwendigen Anforderungen der ISTQB erfüllt.
Der Vortrag war natürlich ausführlicher, als ich es hier nacherzählen kann. Ich bin sicher, Saxonia Systems hilft bei Fragen mit Rat und Tat. Oder schickt mir eine Mail, ich kümmere mich dann drum.
Noch ein wenig Werbung in eigener Sache: Das nächste Treffen der User Group “Agilität in der IT” der Softwareforen Leipzig findet im November 2015 statt und beschäftigt sich mit der Frage: Braucht Agilität Führung? Nähere Informationen findet ihr Softwareforen Leipzig
 
 

User Storys im ERP-Umfeld

Ich gebe zu: Es freut mich sehr, dass sich immer mehr Unternehmen dazu entscheiden, für die Entwicklung und Einführung ihrer Enterprise Software auf alternative Vorgehensmodelle zu setzen. Das klassische Fachkonzept, das in einer monatelangen Analyse- und Konzeptionsphase geschrieben wird, hat ausgedient. Für die Herausforderungen der Zukunft sind agile Geschäftsprozesse, die mit den Anforderungen mitwachsen, besser geeignet. Ein paar Feinheiten sollte man im ERP-Umfeld dennoch beachten – zum Beispiel beim Schreiben von User Storys. Der Unterschied zu anderen Kontexten ist nicht gravierend, aber doch eine Besonderheit, der man ein wenig Aufmerksamkeit widmen sollte.
User Storys im ERP-Umfeld leiten sich in der Regel immer von den Geschäftsprozessen eines Unternehmens ab. Oft werden parallel zur Entwicklung und/oder Einführung einer neuen Enterprise Software auch diese Geschäftsprozesse fachlich und organisatorisch modelliert, was eine zusätzliche Herausforderung ist. Ich finde in diesem Zusammenhang das Konzept des Minimum Viable Products von Frank Robinson sehr hilfreich. Dabei soll ein Produkt geschaffen werden, das für den Markt akzeptabel genug ist, dass es verkauft werden könnte.
Werden Geschäftsprozesse für eine Enterprise Software nach dem MVP-Konzept modelliert, bedeutet das: Die Prozesse sind gerade so ausgestaltet, dass sie von den Anwendern verwendet werden können. Diese minimale Prozessausprägung sollte zudem …

Ist dieser Prozess gefunden, kann er eins zu eins als User Story übernommen werden. Ist diese Story zu groß für einen Sprint, muss noch einmal geschnitten werden. Das kann auf unterschiedlichste Art und Weise erfolgen, mir persönlich gefallen besonders diese zwei Varianten:

  1. Versuche, noch dünnere Prozessausprägungen zu schneiden, auch wenn diese kein sinnvolles MVP mehr ergeben.
  2. Versuche, den Prozess in Teilprozesse zu gliedern, um jeden Teilprozess in weiterer Folge als User Story aufzunehmen.

Variante 1

Für die erste Variante kann es sich anbieten, das Verb der User Story genauer zu untersuchen. Möglicherweise kann es weiter konkretisiert werden. Sehen wir es uns an einem Beispiel zur Auftragssteuerung für regionale Einheiten oder externe Dienstleister an. Die ursprüngliche User Story könnte in etwa so lauten:

„Als Vertriebsmitarbeiter möchte ich meine Aufträge steuern, um jederzeit Kontrolle über diese zu haben.”

Das Wort „steuern“ ist in diesem Beispiel bewusst gewählt, um zu zeigen, dass es weiter konkretisiert werden kann:

In diesem Fall haben wir die User Story nun weiter detailliert. In vielen Fällen handelt es sich jedoch nicht um solch triviale Beispiele, sodass kleinere User Storys durchaus kein sinnvolles MVP ergeben können. Nichtsdestotrotz kann ich diesen Ansatz empfehlen.

Variante 2

Bei Variante 2 wird eine Story Map (Idee von Jeff Patton) erstellt. Dazu können Hauptgeschäftsprozesse in Prozesse und diese in weiterer Folge in Teilprozesse gegliedert werden. Der Geschäftsprozess „Einkauf“ kann beispielsweise in folgende Teilprozesse untergliedert werden:

Für jeden dieser Teilprozesse kann nun eine User Story formuliert werden. Auch der Tipp aus Variante 1 bietet sich hier wieder an. So kann es in einem ersten Schritt durchaus gewollt sein, dass …

Es sind nur kleine Kniffe. Aber sie helfen manchmal sehr dabei, auch bei der Modellierung und Abbildung von Geschäftsprozessen auf die agilen Grundsätze wie eine End-to-End-Betrachtung von User Storys und den Fokus auf das „Minimum Viable Product“ zu vertrauen.

Alles Gute hat Grenzen

In der letzten Zeit habe ich immer stärker den Einfluss von Limitationen auf die menschliche Produktivität bemerkt. Vielleicht hat es damit zu tun, dass ich mich gerade in einem Selbstexperiment zum Thema Single Tasking befinde. Jedenfalls ist es unglaublich, was passiert, wenn wir Limitationen aufheben. Das beste Beispiel dafür sind räumliche Begrenzungen.
Als Consultants werden wir immer wieder dazu angehalten, uns auf Papier und Bleistift sowie Marker und Flipchart zu konzentrieren, statt auf digitale Alternativen auszuweichen. Das hat den Vorteil, dass die Begrenzung wesentlich deutlicher zutage tritt als in der digitalen Welt. Wenn wir ein Flipchart zur Verfügung haben, um ein Meeting zu protokollieren, dann ist es genau das: ein Flipchart. Das Meeting selbst wird von der Timebox umrahmt, die Zahl der Teilnehmer ist unterschiedlich. Nichtsdestotrotz bleibt der Platz limitiert. Weicht man in einem Meeting auf elektronische Möglichkeiten der Protokollierung aus, ist diese Limitation nicht mehr gegeben. Das Ergebnis ist beeindruckend: mehrere Seiten voller Notizen in Schriftgröße 12. Mir stellt sich die Frage: Wer wird das lesen und haben sich die Leute damit etwas Gutes getan?

Grenzen schaffen Ordnung

Natürlich verstehe ich den dahinter liegenden Wunsch, detaillierte Aufzeichnungen zu haben, um bei Bedarf darauf zurückgreifen zu können. Das Problem ist aber, dass dabei ein anderer Effekt verloren geht, der den Vorteil der genauen Protokollierung weitgehend in den Schatten stellt. Es ist der Effekt der natürlichen Priorisierung. Haben wir nur wenig Platz für das Protokoll zur Verfügung, diskutieren wir Dinge automatisch nach deren Wichtigkeit. Wir können nicht alles aufnehmen, wollen aber am Ende mit einem möglichst aussagekräftigen Ergebnis hinausgehen: Also mit einen Flipchart mit den wichtigsten Erkenntnissen aus dem Meeting.
In Dateien mit ihren unendlichen Weiten können wir hingegen Seite um Seite, Zeile um Zeile und Spalte um Spalte hinzuzufügen. Jede Aussage bekommt eine neue Zeile und am Ende erhalten wir eine Abschrift aller möglichen Gedanken und ein Sammelsurium an Informationen. Was wir nicht haben, ist eine aussagekräftige Arbeitsgrundlage, mit der wir die nächsten Schritte planen können.
Also, limitieren Sie sich: Bleiben Sie bei einem haptischen Taskboard, bleiben Sie bei einem Flipchart, nehmen Sie sich ein Blatt Papier, um Ihre Gedanken zum Tag festzuhalten und machen Sie eine Sache nach der anderen. Am Ende werden Sie immer einen Schritt nach dem nächsten machen können und nicht das Gefühl haben, von unzähligen parallelen Schritten überrannt zu werden.

Agiles Anforderungsmanagement mit dem Poke-Prinzip

Marco Ley, Leiter eEntwicklung bei CosmosDirekt, sprach auf den Softwareforen Leipzig letzte Woche über “Agiles Anforderungsmanagement: Das Poke-Prinzip – von harten Anforderungen zu kleinen Experimenten.“ Ich muss von diesem Vortrag erzählen, weil ich so stolz auf dieses CosmosDirekt Team bin. Ich habe nichts dafür getan, dort kennt man mich nicht, und ich will gar keine Lorbeeren einheimsen, die Marco Ley gehören, aber ich bin einfach vollkommen fasziniert.
Kennt ihr das, wenn ihr hart für etwas arbeitet und dann feststellt, dass all das, worüber ihr nachgedacht und ständig gesprochen habt, plötzlich Realität wird? Nun ja – so fühlte ich mich an diesem Morgen beim Vortrag von Marco Ley. Er sprach davon, dass seine Entwicklungsteams vollständig crossfunktional aufgestellt sind – UX, RE, Tester, Developer. Diese Teams arbeiten nicht etwa Anforderungen ab, sondern erarbeiten die User Storys selbstständig, basierend auf groben Vorgaben. Und es sind nicht etwa klassische User Storys, sondern Hypothesen, die in mehr oder weniger aufwendigen A/B Tests auf der Produktivumgebung geprüft werden, so dass die Funktionalitäten für das gesamte CosmosDirekt-Portal live gestellt werden. Die durch die Implementierung gewonnenen Daten beweisen, ob sie wirklich einen Return On Investment bringen.
Damit zeigt uns Herr Ley, dass es ihm gelungen ist, die Rolle des Product Owners so zu leben, wie es meiner bescheidenen Meinung nach sein sollte. Er kümmert sich darum, Ideen zu finden, diese daraufhin zu bewerten, ob man damit Geld verdienen kann und macht dann diese Ideen zu Hypothesen, die er von seinen Kollegen durch Implementierung überprüfen lässt. Was funktioniert, wird behalten, der Rest wieder entsorgt. Einfach toll!
Wir haben ihn natürlich gefragt, wie er erkennt, ob er Erfolg mit der Funktionalität hatte, und er sagte: „Weil wir eine Datenbasis haben.” Er trifft Entscheidungen auf Basis von Daten, die er durch Ausprobieren gewinnt und nicht durch politische Überlegungen. Chapeau!Wenn man ihm so zuhört, tut mir die übrige Online Direktversicherungsbranche leid. Sie kann sich warm anziehen, sollte sich sein Vorgehen bei ComosDirekt weiter durchsetzen. Sein Team wird allen anderen einfach davonlaufen.
Vielen Dank für diesen tollen Vortrag!
An dieser Stelle noch etwas Werbung: Die Softwareforen in Leipzig haben mit der Agilen User Group, die sich dort zwei Mal im Jahr trifft, eine wirklich tolle Veranstaltung ins Leben gerufen. Ich bin sehr dankbar, dass ich dabei sein darf. Mehr Infos hier