“Alle, die ihre Aufgaben, Projekte und Termine im Berufsleben, Privatleben und sozialen Leben stressfreier und effektiver organisieren möchten.”

Mit dieser Beschreibung, die auf dem Buchrücken zu finden ist, fühlt sich jeder sofort angesprochen und möchte mehr erfahren. Auch das Vorwort von Arne Roock (www.software-kanban.de) trägt dazu bei. Die Autoren machen es dann sehr schnell im Buch deutlich, wie Personal Kanben jemanden dabei unterstützen kann:

• Stellen Sie Ihre Arbeit bildlich dar und
• Machen Sie nicht zu viel auf einmal. 

Um diese zwei “einfachen” Regeln geht es grundsätzlich im Großteil des Buches. Die Autoren beschreiben verständlich, geschmückt mit vielen Beispielen, Regeln, Prinzipien und wichtigen Begriffen wie bspw. “Backlog”, “Wertstrom”, “Ziehen”, “Puffer” oder “WIP”. Mir gefallen hierbei die Erzählungen und Beispiele besonders. Wenn ich mich in eine Person hineinversetzen müsste, die nichts mit dem Thema im Vorfeld zu tun hatte und einen Weg sucht, Aufgaben selbstständig zu organisieren, dann erhält diese Person im Buch einen guten Überblick und Anstoss. Klar ist natürlich, dass was der Buchrücken verspricht, kann nur durch jeden selber belebt werden. Es geht darum, den inneren Schweinehund zu überzeugen, einfach loszulegen und mit etwas Disziplin diese praktische Methode in den Alltag übergehen zu lassen.

Die Rezensionen zum Buch spalten sich nicht nur deshalb in zwei Lager. Eines das viele Sterne vergibt und in eines, dass empört ist, weil das Buch “nur wenig an verwertbaren Informationen” enthält. Ich kann diese Meinungen nicht teilen. Auch wenn ich mit dem Konzept vertraut bin, sind die Beschreibungen für (Privat)Personen, die Personal Kanban privat oder im Berufsalltag anwenden möchten, hilfreich und notwendig. Einen Punktabzug gibt es für mich jedoch für die Illustrationen und Fotos im Buch, die mir optisch nicht zusagen, nicht stringent sind und manchmal von schlechter Qualität.

Wer den Blog zum Buch noch nicht kennt, sollte ihn auf jeden Fall zu seiner Leseliste hinzufügen oder via Twitter folgen.

Andreas Heilwagen

Wir möchten unser Mitgefühl ausdrücken und bedauern dieses schreckliche und schwere Ereignis zutiefst. Alle Worte der Anteilnahme können sicherlich im Moment nicht über den schweren Verlust hinweghelfen. Familie, Verwandte und Freunde werden viel Kraft brauchen, die Realität zu ertragen.

Andreas war immer eine Quelle der Inspiration mit seiner umfangreichen Projektmanagement-Erfahrung, wichtigen Beiträgen zum Ausbau von Projektmanagement-Standards und agilen Methoden wie Scrum.

Wenn ich Scrum in einem Unternehmen einführe, geschieht dies in der Regel in den folgenden Stufen:

1. Durchführung eines Scrum Basics Workshops mit möglichst vielen Mitarbeitern, damit alle die neue Arbeitsweise verstehen und mit den Begriffen und Artefakten von Scrum vertraut sind
2. Operative Arbeit als Scrum Master mit mindestens einem Team, um nicht nur über Scrum zu reden, sondern es aktiv mit den Kollegen zu leben. Meistens geht dies mit der Rolle als Agile Coach für das gesamte Unternehmen einher

Sowohl als Scrum Master als auch als Agile Coach erkläre ich den Product Ownern aus meiner jeweiligen Perspektive, wie sie ihre Rolle ausfüllen sollen. Aber jetzt hat sich etwas geändert: Kürzlich habe ich selbst die Rolle des Product Owners übernommen. Diese Erfahrung hat meine Perspektive von der Arbeit eines Product Owners signifikant verändert.

Als Scrum Master ist es einfach:

• Der Product Owner ist im Sprint Planning nicht ausreichend vorbereitet? Erklär ihm, wie man User Stories schreibt, lass ihn regelmäßige Backlog Grooming mit dem Team durchführen, unterstütze ihn dort, wo es nötig ist.
• Der Product Owner zögert, eine Entscheidung zu treffen? Mach ihm klar, dass Entscheidungen treffen zu seinem Job gehört.
• Oh, er will seinen Allerwertesten retten sich beim Head of Product absichern, der aber erst übermorgen wieder verfügbar ist? Stell sicher, dass der Product Owner weiß, dass er verantwortlich ist und dass das Team jetzt eine Antwort braucht. “Hab Rückgrat! Übernimm Verantwortung!“

Als Coach ist es ähnlich, allerdings weniger fordernd:

• “In dieser Situation würde ein guter Product Owner folgendes tun: …“
• “Hast du … in Erwägung gezogen? Dies hat sich in meiner Erfahrung bewährt.“

Nachdem ich die beiden obigen Schritte bei meinem aktuellen Kunden durchlaufen hatte, habe ich die Scrum-Master-Rolle an einen internen Kollegen abgegeben und mich auf die Rolle als Agile Coach beschränkt. Unglücklicherweise hat ein Product Owner das Unternehmen kurzfristig verlassen und es gab intern niemanden, der die Rolle übernehmen konnte, daher habe ich angeboten, interimweise einzuspringen. Mit meinem Wissen und meiner Erfahrung sollte das ja kein Problem sein. War es eigentlich auch nicht. Eigentlich. Denn hinsichtlich Arbeitsbelastung und täglichem Kleinkram sehe ich die Rolle des Product Owner inzwischen aus einer völlig neuen Perspektive.

Da ich ja nach wie vor die Rolle als Coach wahrnahm, nahm ich mir vor, als Product Owner mit besonders gutem Beispiel voranzugehen.

• Ich wollte perfekte User Stories für mein Team schreiben, sie gründlich durchdenken, bevor ich sie dem Team vorstellte, inklusive Akzeptanzkriterien und How-to-demo-Abschnitt. Ihr glaubt ja gar nicht, wie viel Zeit dabei draufgeht. Und man wird niemals perfekt sein, es wird immer Fragen vom Team geben, an die man vorher nicht gedacht hat. Die Herausforderung besteht darin, den schmalen Pfad zwischen dem noch sinnvollen Aufwand zur Story-Vorbereitung und dem gemeinsamen Story-Writing mit dem Team zu finden.
• Ich versuche, immer ansprechbar für mein Team zu sein. Die gleichzeitige Rolle als Coach allerdings erfordert auch meine Anwesenheit in anderen Teams und Meetings. Es ist fast unmöglich, ein vorbildlicher Product Owner zu sein, wenn man diese Rolle nicht Vollzeit innehat.
• Manchmal hat mein Team sehr detaillierte Fragen an mich. Ich weiß sehr wohl, dass ich als Product Owner in der Verantwortung bin, richtungsweisende Entscheidungen zu treffen, aber manchmal kann ich es einfach mangels Domänenwissen nicht. Und bevor ich irgendeine unqualifizierte Entscheidung treffe, frage ich lieber einmal nach.

In fast allen Firmen, die ich kennengelernt habe, verfügt der Product Owner nicht über die im Scrum Guide geforderten Kompetenzen. Meist gibt es einen Head of Product, der produktübergreifende Entscheidungen trifft.

Meine aktuelle Rolle als Product Owner enthält noch nicht einmal Dinge wie Entscheidungen für oder gegen Fetaures, dass Durchführen von User Experience Tests, Einholen von Kundenfeedback oder umfassendes Markt-Knowhow. Aber trotz dieser reduzierten Aufgabenstellung spüre ich die Herausforderungen, mit denen ein Product Owner sich tagtäglich konfrontiert sieht.

Versteht mich nicht falsch: Ich mag die Product Owner-Rolle und ich bin dankbar dafür, dass ich sie jetzt einmal “von innen” erleben darf. Mit meiner neu gewonnenen Erfahrung als operativer Product Owner verstehe ich die Bedürfnisse und Ängste meiner Coachees nun viel besser und werde hoffentlich in der Zukunft in der Lage sein, sie noch besser zu unterstützen.

In diesem Sinne: Chapeau! all den Product Ownern, die tagein tagaus einen großartigen Job machen und für herausragende Produkte kämpfen!

Diesen Artikel gibt es auch auf englisch.

Bevor es jedoch hier weiter geht, ist es Zeit, einige  Tage durchzuatmen. Allen Lesern wünschen wir viel Zeit und Ruhe für Besinnlichkeit sowie einen schönen Ausklang des Jahres.

Eine herzlich frohe Weihnachtszeit und ein gesundes und erfolgreiches Neues Jahr!

• Tannenwald - mein Backlog
• Tanne - eine sortierte Eingangs Queue (WIP = 10)
• Ich schmücke den Baum - in Bearbeitung (WIP = 2)
• Strahlend geschmückter Weihnachtsbaum - Fertig

Ich wünsche euch Muse und Gemütlichkeit für die Feiertage!

Personal Kanban im Weihnachtsdesign

Der größte positive Effekt dabei, dass alles viel entspannter ist. Im Büro scheine ich nahezu nichts mehr zu vergessen und ich fühle mich total gut organisiert. Zuhause sind Problemthemen, wie “Zähneputzen” plötzlich Spaß, weil mein Sohn mitbestimmt wann die Karte “Zähneputzen” dran ist. Wir malen die Karten, besonders mein Sohn malt, so weiß er was auf den Karten steht und das System ist sowieso kinderleicht. Ausserdem finde ich, dass die Agilen Werte für Kinder so wohltuend sind: Kinder auf Augenhöhe begegnen, Respektvolles Miteinander, Zuhören, Mut, Offenheit, ständige Verbesserung,…

Also, aller Unkenrufe zum Trotz – es macht Spaß und ich experimentiere weiter.

Personal Kanban Board auf dem Bürotisch

Personal Kanban Board zu Hause

Ich drücke Ihnen die Daumen!

Boris Gloger schrieb vor einiger Zeit, dass Denken in Auslastung blödsinnig ist. Angeregt durch den Beitrag und das Thema, fielen mir Situationen ein, bei denen Manager auf mich als Scrum Master oder meinen Product Owner zukamen und behaupteten, dass die Teams, mit denen ich arbeitete, nicht ausgelastet seien. Nach einem kurzen Gespräch mit den Managern und betroffenen Teammitgliedern, konnte ich mir dann schnell ein Bild von der eigentlichen Situation machen und die Kommunikation in die richtige Richtung lenken. Wie kam es zu der Annahme und was tue ich in diesen Situationen?

Das Missverständnis

Treffen sich ein Manager und Entwickler auf dem Flur. Sagt der Manager „Na, wie läufts bei euch im Team, kommt ihr voran?“ Darauf sagt der Entwickler „Diesen Sprint habe ich nicht wirklich etwas zu tun, da das Sprint Backlog nur Backlog Items für die Frontend-Entwickler enthält.“ Denkt sich der Manager „Hmmm…, da sitzt jemand rum und hat nichts zu tun!“.

Sie merken, dieser angedeutete Witz hat keine Pointe, weil diese Situation in vielen Unternehmen zum Alltag gehört. Was so nebenbei beim Small-Talk ausgetauscht wird, wirkt sich häufig in falschen Annahmen aus. Leider ist es bei vielen Managern immer noch so, dass sie annehmen, eine 100% Auslastung sei erstrebenswert. Wenn also jemand sagt, dass er „nichts zu tun hat“, dann bedeutet dies für den Manager, dass nicht effizient gearbeitet wird oder der Drang zum regulierenden Eingreifen steigt. Als Scrum Master ist es in diesen Situationen wichtig, in Richtung Management und Scrum Team zu kommunizieren.

1. Missverständnisse beseitigen

Als Scrum Master weiß man, was in seinem Scrum Team los ist und hat dementsprechend auch die notwendigen Argumente parat, um auf solch eine Situation zu reagieren. Situationen wie diese machen deutlich, dass ein Gespräch mit dem Manager (oder eine Schulung der Führungsebene) sinnvoll ist.  In Richtung des Managements sollte man sich dann dem Thema Auslastung annehmen und argumentativ vorbringen, dass der Wunsch nach Auslastung an die Obergrenze, zum Verlust von Kreativität und Motivation führt. Die „Ressourcen“ die an einem kreativen Prozess wie der Softwareentwicklung beteiligt sind, benötigen Freiraum, um bspw. Risiken aufzudecken, Verbesserungen hinzuzufügen, sich selber oder Innovationen zu entwickeln. Ein ständiger Lauf im Hamsterrad würde diesen Blick versperren und zudem die Motivation senken.

Darüber hinaus ist es hilfreich, über die Selbstorganisation in Scrum zu sprechen und deutlich zu machen, warum diese so wichtig für das Zusammenspiel eines Scrum Teams ist. Gehen sie auf die Werte und Prinzipien der agilen Arbeit ein. Gehen sie auch darauf ein, dass es einen Unterschied macht, ob jemand „idle“ ist oder seine Arbeitszeit verschwendet, bspw. durch Wartezeiten, dauernde Unterbrechungen oder Abhängigkeiten (vgl. die Serie zu Lean Software Development von Kelly Waters).

Grundsätzlich sollte die Konsequenz nicht sein, dass jemand das Gefühl hat „es gäbe nichts zu tun“. Nicht auf der Seite eines Managers und auch nicht auf der Seite eines Team Mitglieds. Dies war nämlich in keiner der Situationen der Fall, in die ich involviert war. In Richtung des Managements und in Richtung des Scrum Teams kommuniziere ich folgende Optionen, um Situationen wie “Diesen Sprint habe ich nicht wirklich etwas zu tun…” entgegenzuwirken.

2. Alternativen deutlich machen

„Ich habe nichts zu tun“ bedeutet oftmals, dass der- oder diejenige nichts in der Domäne zu tun hat, in der er seine Spezialisierung sieht. In einem Scrum Team gilt dies jedoch nicht, denn jeden geht jede Aufgabe etwas an und neben dem Spezialwissen, ist eben auch die Ausweitung des Wissens in die Breite gefragt. Im Sinne der Selbstorganisation des Scrum Teams liegt die Gestaltung des Arbeitstages oder des Sprints selbstbestimmt beim Scrum Team. Gerade bei jungen oder nicht eingespielten Teams, sind folgende Alternativen – gefühlten „Leerlauf“ zu vermeiden – mein Rat, um den Impuls entgegenzuwirken, nichts zur Bearbeitung des Sprint Backlogs beitragen zu können. Zum Beispiel können die Teammitglieder:

• die anderen Teammitglieder bei der Abarbeitung des Sprint Backlogs unterstützen (auch wenn es eben nicht Backlog Items aus der Domäne des jeweiligen Spezialisten sind) oder
• kommende Sprint Backlog Items (oder die Arbeit an ihnen) vorbereiten.

Neben diesen beiden essentiellen Punkten, die häufig im Mittelpunkt meiner Arbeit stehen, gibt es aber noch viele weitere Aspekte, die wichtig für die Entwicklung des Teams bzw. der Software sind und einen wertvollen Beitrag liefern, wie bspw.:

• das Aneignen von Fachwissen, welches für die Arbeit im Projekt notwendig ist (durch das Lesen von Fachbüchern, Blogs oder das Ansehen von Online-Vorträgen bzw. -Tutorials),
• das Verfassen von Backlog Items mit eigenen Produktideen oder technischen Verbesserungen,
• die Bearbeitung von Aufgaben aus einer Retrospektive (die das Team / ein Teammitglied angenommen hat),
• der Austausch mit Kollegen / anderen Teams, um Fragen oder Probleme zu klären oder
• die Realisierung von Produkt- oder Prozess-Innovation (siehe die hervorragende Serie “Slack to the rescue” von Bernd Schiffer).

Es steht jedem offen innerhalb des Teams, die eigene Auslastung in vielerlei Hinsicht selbstbestimmt zu gestalten. Wenn man nicht selbstständig etwas findet, um seine “Idle Time” zu überwinden, dann findet man sicherlich zusammen mit den Teammitgliedern etwas, um Wert zu generieren und um damit zu unterstützen, zu optimieren, zu prüfen oder vorzubereiten. In “erwachsenen” Scrum Teams funktioniert diese Selbstregelung innerhalb des Teams von alleine. Bis dahin ist man als Scrum Master gefordert, das Team auf diesen Weg zu begleiten bzw. zu führen.

Um meine Teams dabei zu unterstützen, ihre selbstauferlegten Qualitätskriterien (=Definition of Done) zu erfüllen, schlage ich manchmal vor, einen sogenannten Story Owner für jede User Story zu benennen. Allgemein gesprochen sorgt der Story Owner dafür, dass eine bestimmte User Story unter Beachtung aller vereinbarten Rahmenbedingungen in den Status „Done“ überführt wird. Der Story Owner muss dabei nicht notwendigerweise alle Schritte selbst erledigen, sondern ist dafür verantwortlich, dass sie erledigt werden. Die konkrete Ausprägung der Aufgabe ist teamabhängig; folgende Tätigkeiten könnten zum Beispiel dazugehören:

• Sicherstellen der Fertigstellung der Arbeit an den höchstpriorisierten User Stories: Wenn der Story Owner der obersten noch nicht erledigten User Story am Scrum-Board sieht, dass jemand aus dem Team an einer weniger hoch priorisierten Story arbeitet, sollte er denjenigen bitten, zunächst die Arbeit an der höher priorisierten Story zu unterstützen.
• Überprüfung der Definition of Done, bevor die User Story dem Product Owner gezeigt wird
• Einholen der Akzeptanz des Product Owners

Wie bereits oben erwähnt, handelt es sich lediglich um einen Vorschlag. Es ist eine Entscheidung des Teams, ob es Story Owner benennen will und welches die konkreten Todos sind. Man sollte aber darauf achten, dass diese Aufgabe nicht zu viel Gewicht bekommt. Es handelt sich nicht um eine „Rolle”, vergleichbar mit den drei Scrum-Rollen, sondern eher um eine „Patenschaft“. Insbesondere bei Teams mit wenig Erfahrung in der Selbstorganisation ist dies ein gutes Hilfsmittel, um den Fokus auf die wichtigsten Stories und Tasks zu lenken.

Dieser Artikel wurde aus dem Buch ”Scrum in der Praxis” abgeleitet. Im Buch finden sich viele nützlich Tipps und Tricks für die tägliche Arbeit als Scrum Master. Auch auf der Webseite zum Buch finden sich nützliche Links, Checklisten und Literaturempfehlungen sowie alls im Buch verwendeten Grafiken zur freien Verfügung.

Dieser Artikel ist auch auf englisch verfügbar.

So halte ich es für wichtig von Zeit zu Zeit die Zusammenarbeit und die Beziehung der Teammitglieder untereinander unter die Lupe nehmen, um Vertrauen und einen offenen Umgang im Team zu fördern. Eine tolle Methode ist hier das Speed-Feedback, das ich neulich kennengelernt habe. Dabei geben Mitglieder des Teams einander paarweise in einem geschützten Raum Feedback. Gesprächsregeln sind nicht vorgegeben. Im Sinne eines respektvollen Gesprächsverlauf sollte jeder natürlich die Regeln des Feedback-Gebens beachten.

Nun zum sehr einfachen Ablauf: die Teilnehmer sollten einige Tage vor der Retrospektive vom geplanten Speed-Feedback wissen, damit sie sich auf die Gespräche vorbereiten können. Zum Beginn des Meetings zieht jedes Teammitglied eine Karte aus einem vom Moderator vorbereiteten Stapel von paarweise gleichen Planning-Pokerkarten. Jeweils gleiche Karten ergeben eine Speed-Feedback-Paarung. Für jedes dieser Paare sollte ein eigener Raum oder zumindest ein separater Bereich zur Verfügung stehen, um eine ungestörte Atmosphäre zu schaffen. Jede Feedback-Runde dauert 10 Minuten, dann wird erneut gelost.

Ich habe als Teilnehmerin eines solchen Speed-Feedbacks die Erfahrung gemacht, dass keine Runde der anderen gleicht. Hatten sich einige meiner Gesprächspartner intensiv vorbereitet, haben sich andere sehr spontan überlegt, was sie mir sagen könnten. Eine Kollegin beispielsweise kannte ich noch nicht, da sie noch neu im Team war. Also haben wir die 10 Minuten zum Kennenlernen genutzt.

Habe ich aus den strukturiert vorbereiteten Gesprächen eine Menge darüber gelernt, wie ich gesehen werde, haben mir auf der anderen Seite auch die lockeren Gespräche einiges gebracht. So habe meine Kollegen sehr viel besser kennengelernt und insbesondere Vertrauen zu ihnen aufgebaut. Besonders auffallend war übrigens die lockere und gelöste Stimmung im Team nach drei Feedbackrunden.

Viel Spaß beim Nachmachen!