Ein agiles Team durchläuft in seiner Teamentwicklung vier Schritte von dem Aufstellen eines vielleicht ersten vermeintlichen product backlogs bis zur messbaren Wirkung auf das Geschäftsmodell des Unternehmens. Dieser Entwicklungsweg ist herausfordernd und darf begleitet werden durch Haltung und Methoden. In diesem Podcast beleuchten wir diese Entwicklungsschritte und was unsere Erfahrungen damit in Unternehmen uns gelehrt hat.
Heute gehen wir mit einem Prinzip aus dem agilen Manifest den kollektiven Burnout an, das uns hilft „nein“ zu sagen. Wir erklären Dir, warum es schwer ist nein zu sagen und welche vier Bedingungen Du in Deinem Projekt oder Produkt brauchst, damit Du nein sagen kannst, damit wir am Ende „ja“ zu den wirklich wichtigen Dingen sagen können.
9 neue Erkenntnisse für agile Teams mit Magic Maze
Dieser Artikel ist Ursprünglich im Januar 2020 erschienen.
Magic Maze für agile Teams -Was bisher geschah…
In meinem letzten Artikel zu Magic Maze hatte ich die uns bis dato 9 bekannten Erkenntnisse zusammengefasst und mit euch geteilt. Seitdem ist natürlich nicht Schluss gewesen. Ich selbst hatte bei Kunden mehrfach die Gelegenheit Magic Maze einzusetzen und zusammen mit meinem
Kollegen Veit sowie Stefan Zumbrägelbeim Global Scrum Gathering in Wien eine Open Space Session zu Magic Maze zu hosten. Mein Highlight bezüglich Magic Maze dieses Jahr war allerdings ein Certified Scrum Master Training mit Björn Jensen . Ich war als Co- Trainer mit dabei und konnte mit den Teilnehmern recht früh am ersten Tag eine Runde Magic Maze
Neun neue Erkenntnisse für agile Teams mit Magic Maze spielen, um sie für agiles Arbeiten zu sensibilisieren. Das hat nicht nur sehr viel Spaß gemacht, sondern auch noch richtig gut funktioniert. An dieser Stelle nochmal „Danke an Björn“ für diese tolle Gelegenheit und das Vertrauen!
Aber warum erzähle ich euch das alles? Es gab natürlich neue Erkenntnisse, insgesamt 9 neue Erkenntnisse für agile Teams mit Magic Maze. Und genau das treibt mich an, Magic Maze weiter mit Teams und in Trainings einzusetzen. Ich werde die bisher bekannten Erkenntnisse nicht nochmal hier zusammenfassen, dafür bitte den oben verlinkten Artikel lesen.
Feedback aus der Community
Kurz nach dem letzten Beitrag kam schon der erste Kommentar von Abigail Leijten, in dem sie zwei Erkenntnisse geteilt hat.
„Mut: es gehört Mut dazu, am Anfang dich als erste am Tisch zu setzen, wo du gar nicht genau weißt, was passieren wird.“ Das kann ich bestätigen, ich habe mehrfach größere Gruppen gehabt, bei denen wir auch die Rolle des Beobachters hatten und sich der Tisch somit erst zögerlich gefüllt hat. Das kann man in Retrospektiven auch oft beobachten. Man bittet das Team Beobachtungen zu teilen und es dauert eine Weile, bis sich der Erste traut oder freiwillig spricht. Sowohl im Spiel, als auch in der Retro, passiert aber nichts Schlimmes, wenn man die Initiative ergreift. Schönes Thema über das man im Debrief sprechen kann.
„Als Teil des „Agiles Mindset“ ist auch ein Satz „Jeder hat seine eigene Geschwindigkeit“. Wir hatten den Fall, wo manche Leute 3 Runden gebraucht haben, bevor sie den Teleporter komplett verstanden haben. Auch das war für die Gruppe ein schönes Learning.“ Das ist eine weitere tolle Erkenntnis, wie ich finde. Mir fällt das auch oft auf. Ich interpretiere da auch rein, dass man Leute nicht mit Informationen überladen und erwarten kann, dass es alle sofort verstanden haben. Man kann das Spiel noch so oft und ausführlich erklären – erst wenn es los geht, merkt man, ob es wirklich verstanden wurde.
Vielen Dank Abigail, dass du diese tollen Impuls mit uns geteilt hast!
Was wir neues gelernt haben
Ich knüpfe gleich an. Ich würde noch einen Schritt weitergehen und die Erkenntnis ziehen „einfach mal Machen“. Bei der Produktentwicklung wissen wir nicht, ob wir das Richtige bauen, bis wir den Kunden um Feedback bitten. So geht es mir als Facilitator des Spiels auch oft. Ob die Spieler meine Anweisungen verstanden haben, sehe ich erst, wenn sie es spielen. Und bisher hatte es keine Gruppe zu 100% verstanden. Das konnte dann aber schnell angepasst werden im Spiel. Ich weiß nicht, wie viel Zeit es gekostet hätte, um die Missverständnisse beim Erklären auszuschließen bzw. ich glaube es ist nicht möglich. Also Erkenntnis bzw. Parallele zu agilem Arbeiten, einfach mal machen und Feedback einholen!
Es gilt die Prime directive (von Norman L. Kerth). „Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“ Übersetzt: „Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen, den Ressourcen und unseren individuellen Fähigkeiten getan hat.“ Wie sehr diese Haltung hilft, erkennt man bei Magic Maze in den Phasen, in denen gesprochen werden kann. Ist das erste Fingerpointing vorbei, haben die Teams in der Regel verstanden, was ihnen weiterhilft ihr Ziel zu erreichen und was nicht. Fingerpointing hilft nie! So ist es auch in Retrospektiven. Nicht umsonst ist die Prime directive dort so wichtig. Dieser Punkt baut ebenfalls sehr schön auf den Punkten 11 und 12 auf, wie ich finde.
Läuft man bei Magic Maze ein Feld zu weit, kann man diesen Fehler selbst nicht korrigieren. Man braucht Hilfe aus dem Team. Diese Erkentiss hat dazu geführt, dass die Runde gemerkt hat, dass es auch im Alltag OK ist, um Hilfe zu bitten, wenn man sich in eine Sackgasse manövriert hat. Denn man bedenke Punkt 13, es gilt die Prime directive; man hat es ja nicht absichtlich gemacht.
Der letzte Punkt aus meinem vorherigen Artikel bezog sich darauf, dass man durch lange Planung am Anfang nicht besser vorhersagen kann, wie sich das Labyrinth aufbauen wird. Ein Team hat dies noch um die Aussage „eine Schätzung am Anfang wäre sehr sehr ungenau“ ergänzt. Das Team weiß, dass es alle Mittel hat, um die Aufgabe zu lösen, aber es hätte sich nicht gut gefühlt eine feingranulare Schätzung abzugeben. Sicher ein tolles Learning für Personen außerhalb eines Entwicklungsteams. Nehmt den Punkt gerne gezielt mit ins Debrief, wenn ihr im Alltag Probleme mit den Ansprüchen an Schätzungen habt.
In den Phasen auf der Sanduhr wird immer fleißig gesprochen und geplant. Doch dann kommt oft alles anders. Das führte zu der Erkenntnis, dass eine gemeinsame Sprache und gemeinsames Wording nicht selbstverständlich sind. Auch das ist bei Scrum oft zu beobachten. Daher führe ich sehr gerne Grundlagentrainings mit neuen Teams durch, um die verschiedenen Taxonomien ans Licht zu bringen und eine gemeinsame zu verankern.
Der „Tu was Stein“ kann von jedem Spieler genutzt werden, um einem andren Spieler zu signalisieren, dass er etwas tun kann, das dem Team weiterhilft. Im Spiel passiert das sehr natürlich und unverzüglich, sobald eine solche Situation erkannt wird. Die Analogie zu Scrum ist das Impediment. Ein Spieler hält unwissentlich den Betrieb auf. Es ist total OK und auch wichtig, dies sofort anzusprechen. Im Spiel passiert das von alleine. Warum sollte das also im Alltag nicht ebenso selbstverständlich werden?
Ich schließe mit einem für mich schönsten Sätze in einem Debrief, der auch keiner weiteren Erklärung bedarf „Das Spiel hat aus Fremden innerhalb kürzester Zeit ein Team gemacht“
Wir konnten mal wieder die Klappe nicht halten 🙊, was die Einführung agiler Methoden betrifft. Vom Einzelteam zur größeren Landschaft teilen wir Erfahrungen, Muster und Bitte-Nicht‘s!
Wir haben zwei Tage überlegt, ob wir diese Podcast-Folge ausstrahlen.
Wer uns zuhört, der weiß, dass wir versuchen so ehrlich und authentisch wie möglich zu sein, weil wir der Meinung sind, dass unsere Arbeitswelt das braucht: Mut, Offenheit, Verletzlichkeit.
Möge die Folge anderen in harten Veränderungen helfen, Kraft zu finden und neue Wege zu gehen.
Der Weg hin zu einer agilen Organisation ist mit vielen Hürden und Problemen gespickt. Anforderungen, Ziele und Rahmenbedingungen ändern sich innerhalb von wenigen Tagen und Wochen.
Um so mehr Teams mit agilen Vorgehensweisen arbeiten, umso mehr Hindernisse auf Organisationsebene werden deutlich. Themen, die die Teams davon abhalten, effizient Software zu entwickeln und voranzukommen. Ungelöste Zuständigkeiten, unklare Rollenbilder und Karrierepfade, zu lange dauernde Entscheidungsprozesse, inkonsequentes oder nicht vorhandenes Portfolio- oder Programmmanagement.
Doch wie begegnet man dieser Komplexität, den Risiken und der Vielfalt der Stakeholder einer Agilen Transition?
Auch Software-Entwicklungsteams sind ständig mit veränderlichen Anforderungen und technisch sowie fachlicher Komplexität konfrontiert. Was für diese Teams funktioniert, ist auch bei einer Unternehmenstransition das Mittel der Wahl: Scrum. Durch seine mehrfachen eingebauten Feedback-Schleifen versteht es das Scrum-Rahmenwerk, die Komplexität zu adressieren. Eine Enterprise Transition Community kann so auf die häufig erst bei der Umsetzung auftretenden Hindernisse und Ideen eingehen und in kurzen Zyklen lernen, was funktioniert und was nicht.
Eine Gemeinschaft als Taktgeber für die Veränderung
Die Veränderung hin zu Agilem Vorgehen benötigt Menschen aus den unterschiedlichsten Bereichen eines Unternehmens.
Eine Enterprise Transition Community (kurz: ETC) ist ein Scrum-Team, dass die Transition hin zu agilem Vorgehen in einem Unternehmen durchführt.
Dieses Team arbeitet nach Scrum, produziert aber keine Software. Es liefert Organisationsveränderung in kleinen Schritten je Sprint. Es wurde von einem der beiden Begründer von Scrum, Ken Schwaber, im Jahr 2007 bekannt gemacht (siehe The Enterprise and Scrum) und seitdem in verschiedenen Variationen neu veröffentlicht und in etlichen Unternehmen praktisch eingesetzt (siehe z.B. BMC,EWE oder Amazon).
In dem hier dargestellten Prozess kommen auch die bekannten Artefakte und Rollen von Scrum zum Einsatz:
Product Owner – der Fokusgeber
Der Product Owner einer ETC trägt die Verantwortung dafür, dass das Team fokussiert an den Veränderungen mit dem höchsten Wert für das Unternehmen arbeitet. Er verwendet dazu ein Transition Backlog, welches die zu lösenden Organisationsthemen beinhaltet. In regelmäßigen Backlog Refinements werden die teils großen Organisationsveränderungsthemen (Epics) in Sprint-gerechte User Stories zerlegt.
Teammitglieder – Umsetzer und Gestalter
Die Teammitglieder sind Personen des Unternehmens, die ein Interesse an der Veränderung hin zu Agilität haben und sich einbringen möchten mit ihrer Zeit. Die Teammitglieder haben die Umsetzungsverantwortungen der organisatorischen Veränderungen. Sie sollten aus den Bereichen stammen, die maßgeblich von den Veränderungen betroffen sind und diese auch maßgeblich beeinflussen können. Am besten sie gehen die Themen selbst in der Umsetzung an. Falls es aber notwendig sein sollte, sollten sie dazu die Arbeit maximal eine Ebene delegieren, behalten aber die Verantwortung
ScrumMaster – Servant Leader und Facilitator
Der ScrumMaster einer ETC moderiert die Besprechungen, sorgt für das Prozessverständnis von Scrum und arbeitet an Lösungen von Hindernissen, die die ETC davon abhalten, hochproduktiv zu sein. Manchmal unterstützt er in Agilität unerfahrenere Teammitglieder bei der Vertiefung des Verständnisses und der Findung „agiler Lösungen“ für Organisationsthemen. Er dient dem Team und führt Kraft Anerkennung.
Die Organisation teilhaben lassen
Die Stakeholder einer Enterprise Transition Community sind oft breit gestreut im Unternehmen. Jeder betroffene Mitarbeiter und jede betroffene Führungskraft hat ein Interesse an den Ergebnissen dieses Teams. Nach einer anfänglichen Findungsphase der ETC sind sie gerne gesehene Feedbackgeber für „ETC Entwicklungsteam“ und ETC Product Owner im Review-Meeting.
Wer mehr zu dem Thema lesen möchte, empfehle ich die Szenen einer Scrum Transition (englisch), welche auch meine Abbildung inspiriert haben.
Der Product Owner ist eine der drei Rollen in Scrum. Er verantwortet den Produkterfolg. Doch welche Fähigkeiten helfen dabei, diesen zu erreichen?
Überzeugungskraft
Immer weniger Menschen möchten heutzutage an fraglichen, vielleicht gar sinnlosen Projekten arbeiten. Software entwickeln als Lohn-und-Brot Job? Egal, ob das Produkt jemand später einsetzt? Das Entwicklungsteam muss an die Vision des Product Owners glauben, um motiviert zu sein.
Dazu braucht es einen überzeugenden Product Owner. Und nicht nur das Team will glauben können, auch die Kunden und Anwender des Scrum-Teams. Beide muss der Product Owner davon überzeugen, dass er die richtigen Entscheidungen trifft zum Wohl des Produkterfolgs.
Was Sie als Product Owner zur Stärkung tun können:
ein Produkt suchen, hinter dem Sie wirklich stehen
ein Rhetoriktraining besuchen, um Ihre Botschaft zu verstärken
Visual Facilitation erlerne, also mit Bildern und Metaphern kommunizieren
die Zukunft des Produkts mit guten Geschichten lebhaft ausmalen
Fachwissen über die Domäne und Durchsetzungsfähigkeit
Der Product Owner trifft nahezu täglich Produktentscheidungen: In welcher Reihenfolge werden die Anforderungen umgesetzt, welche kommen hinzu, welche werden gestrichen? Und in welcher Ausprägung wird eine Anforderung realisiert? Diese Entscheidungen benötigen ein Fachwissen in der Domäne des Produkts und die Fähigkeit, die Entscheidungen dann auch durchsetzen zu wollen.
Was Sie als Product Owner zur Stärkung tun können:
Fachzeitschriften und Bücher zur Domäne lesen
Fachkonferenzen besuchen und Kollegen interviewen
Sich öfter in einem klarem „Ja“ und „Nein“ üben, auch wenn es unbequem sein sollte
Empathie für den Kunden und Anwender
Um die richtigen Entscheidungen zu treffen, braucht es aber nicht nur Fachwissen sondern auch ein gutes Gespür für den Kunden, die Anwender und den Markt.
Gerade technischen Product Ownern fällt es oft schwer, die Nutzerbrille aufzusetzen. Was will der Anwender wirklich? Was sind seine Bedürfnisse? Warum möchte er etwas?
Was Sie als Product Owner zur Stärkung tun können:
In User Stories den WARUM-Teil des Satzes vom Anwender erläutern lassen
Ein Werkzeug wie das Vision Board verwenden, um den Anwender besser zu verstehen
Den (potenziellen) Anwender bei seiner täglichen Arbeit beobachten
Beim Formulieren von Anforderungen auf technisches Jargon verzichten
Teamfähigkeit
Der Product Owner ist Teil des Scrum Teams. Und der Erfolg dieses Teams steht und fällt mit dem Zusammenspiel aller Teammitglieder. Wie gut findet man gemeinsame Lösungen für Konflikte und Probleme statt sich hinter seiner Rollenbeschreibung und Verantwortlichkeiten zu verschanzen?
Was Sie als Product Owner zur Stärkung tun können:
Lassen Sie sich von Ihrem Entwicklungsteam bei der Erfüllung Ihrer Rolle helfen. Auch Teammitglieder können User Stories schreiben
Fragen Sie Ihr Entwicklungsteam, ob Sie an der Retrospektive teilnehmen dürfen
Betrachten Sie sich und das Team als „alle im selben Boot“ und suchen Sie aus dieser Haltung Lösungen
Diese Beitrag wurde inspiriert durch Fragen der Teilnehmer meines gemeinsamen CSPO-Trainings mit Peter Beck.
Der ScrumMaster ist ein Veränderer in Unternehmen. Seine Aufgaben sind umfangreich und oft herausfordernd. Wie schafft man es, motiviert zu bleiben in Umfeldern, die keine täglichen Erfolgserlebnisse garantieren?
Die intrinsische Motivation aufrecht erhalten
Suchen Sie sich einen kleinen Bereich, den Sie zu großen Teilen und mit einfachen Mitteln selbst beeinflussen können und gestalten Sie diesen mit agilen Methoden. Tun Sie dies, aus Freude an der Sache selbst ohne einen Zweck für andere damit zu verfolgen.
Praxis-Tipp: Gestalten Sie z.B. Ihre eigene Arbeit und genießen Sie die positiven Effekte einfach für sich selbst. Ich mache das zum Beispiel fast täglich mit der Pomodoro – Technik, eine Art von Timeboxing, um beim Arbeiten in einem guten Fluss zu bleiben.
Inspirierende Themen anschauen
Es gibt weltweit viele agile Konferenzen die teilweise mitgeschnitten werden. Spannende Perspektiven auf aktuelle Themen und Erfahrungsberichte helfen dabei, Dinge in neuem Licht zu sehen und Inspiration wiederzuerlangen.
Praxis-Tipp: Schauen Sie sich eine Keynote auf Youtube an oder stöbern Sie in den inspirierenden Videos von TED.
Sich nicht herunterziehen lassen
Wenn man auf inspirierende Menschen trifft, neigen wir dazu, uns selbst als weniger brilliant, erfahren oder intelligent anzusehen. Dieser Vergleich bringt einen nicht weiter. Genießen Sie die Einzigartigkeit Ihrer Erfahrungen und Ihres Lebens. Niemand wird je das Erleben, was Sie erleben. Diese exakte Kombination Ihrer Fähigkeiten und Denkweisen gibt es nur einmal – in Ihnen.
Praxis-Tipp: Denken Sie einige Minuten in Ruhe darüber nach, was Sie in Ihrem Leben bereits alles erfahren haben und klopfen Sie sich selbst einmal auf die Schulter mit dem Gedanken: „Wow, das war eine Menge und das Meiste habe ich tatsächlich wirklich gut hinbekommen!“.
Sich in die Community begeben
In Deutschland gibt es wie in vielen anderen Ländern auch sehr aktive Gemeinschaften von Menschen, die ähnliche Erfahrungen und Ziele wie Sie haben. Oft stellt man im Austausch mit Anderen fest, dass man mit seiner Herausforderung nicht alleine ist und erhält neue Ideen, die einen voranbringen.
Praxis-Tipp: Besuchen Sie doch einmal Ihre lokale Usergroup. Falls Sie im Rhein-Neckar Gebiet wohnen können Sie gerne zum Agile Monday Rhein-Neckar vorbeischauen. Die Veranstaltungen eigentlich aller Communities sind kostenfrei und ein guter Ort, um neue Kontakte zu knüpfen.
Das Energieniveau im Blick haben
Abhängig von vielen verschiedenen Faktoren variiert unsere Energie. Nehmen Sie sich Zeit, auf diese Impulse zu hören und das zu tun, was ihre Batterien wieder auflädt, wenn Sie wenig Energie haben.
Praxis-Tipp: Für viele Menschen ist Natur erholsam – können Sie eine Besprechung draußen bei einer Runde um das Gebäude abhalten?
Einen Schritt zurückgehen, um voranzukommen
Um zu wachsen, begeben wir uns oft an den Rand der Komfortzone. Das ist gut, um sich zu entwickeln, kann aber auf Dauer auch recht anstrengend sein. Sich für eine Weile dorthin zu bewegen, wo wir meisterlich gut sind, macht Spaß und erholt.
Praxis-Tipp: Suchen Sie sich ein Meeting, dass Sie besonders gerne moderieren und gestalten Sie es so, dass es Ihnen besonders viel Freude macht und leicht von der Hand geht. Das bringt Sie in einen guten Fluss und andere merken Ihren Elan.
Nicht alles auf einmal ändern
Viele ScrumMaster und Coaches, die ich kennengelernt habe, sind sehr wissbegierige Menschen die leidenschaftlich gerne Neues lernen. Die Balance zu finden zwischen Zeiten der Veränderung und Zeiten der Beständigkeit ist da nicht immer leicht.
Praxis-Tipp: Limitieren Sie Ihre gleichzeitigen Lernthemen mit einem sortierten Backlog und erlauben Sie sich ausreichend Zeit, das Neue in Ihre Arbeit zu integrieren, bevor Sie an das nächste Thema herantreten.
Dieser Blogpost wurde inspiriert durch Roman, der als Musiker und Komponist arbeitet.
Mein Team lag in den letzten Zügen – das Sprintende war nur noch wenige Stunden entfernt, die letzte User Story noch nicht vom Product Owner abgenommen. Konzentrierte Stille im Teamraum mischte sich mit wachsender Anspannung. Während der internen Abnahme kam er dann, der Fehler in letzter Minute. Entwicklerin Natalie und unser Product Owner saßen vor dem PC und hatten den Testfall entdeckt, der den Prozess zum Abbruch bringt. Das Review Meeting mit eingeladenen Kunden und Anwendern in nur 3 Stunden brachte besorgte Gesichter. Wir wollen ihn schaffen, diesen Sprint!
Natalie war innerlich zerrißen. Bei der Fahrradtour vor einer Woche war eine Flasche Rotwein über die Handtasche einer Freundin gelaufen. Und diese Freundin hatte nun morgen Geburtstag. Eigentlich müsste Natalie jetzt in die Stadt und der Freundin die Longchamp-Tasche besorgen, um das wieder gutzumachen. Und eigentlich müsste sie auch an der Story weitermachen, um das Team jetzt nicht hängen zu lassen.
Unser Product Owner stellte schelmisch grinsend fest:
„Das ist doch ein Impediment, oder?“
Mit dem geliehenen Audi meines Product Owners und einem befreundeten Coach auf dem Beifahrersitz fuhren wir in die Innenstadt – zwei ScrumMaster gehen eine Handtasche besorgen – absurd?! Ist das noch die Rolle des ScrumMasters? Oder das Gegenteil davon? Eine Karrikatur der Produktivitätssteigerung? Geht das nicht zu weit? Der ScrumMaster als Kerl für alles?
Während ich darüber laut nachdachte, stellte mein Beifahrer die entscheidende Frage: „Macht es Dir Spaß?“ Ich lachte: „Total!“
Wir ScrumMaster sind für die Produktivitätssteigerung von Teams verantwortlich. Die Frage die ich mir stellte, gehört zu den klassischen Fragen dieser Rolle:
„Was kann ich jetzt gerade und langfristig tun, um mein Team optimal zu unterstützen?“
Manchmal ist es die Suche der richtigen Ansprechpartner, das Herausheben der agilen Perspektive oder die Moderation von Teamworkshops.
Manchmal sind es schwerfällige Prozesse in der Organisation, gegenläufige Interessen verschiedener Gruppen oder mangelnde Kommunikation.
Und manchmal ist es der Einkauf einer Handtasche.
Das Team hat den Sprint übrigens erfolgreich abgeschlossen.
Es ist eine Kunst, mit Anforderungen in IT-Projekten gut umzugehen. Denn agile Teams benötigen für ihre Arbeit klein geschnittene und gut definierte Features, damit sie diese in einem kurzer Zeitraum (wie z.B. einem Sprint) bearbeiten können.
Doch die Anwender moderner Anwendungen sind umfangreiche Features und Funktionen gewohnt, die eigentlich nicht in so kurzer Zeit wie einem Zwei- oder Vierwochenfenster umsetzbar sind.
Als Produktverantwortlicher (die Scrum’ler nennen sie Product Owner) könnte ich mir also die Frage stellen:
Wie schneide ich eine Anforderung richtig, damit mein agiles Team optimal damit arbeiten kann?
Wie zerlege ich große Features in kleinere, die unabhängig voneinander geplant und umgesetzt werden können?
Wie komme ich weg von der „alles ist Prio 1“ Sichtweise hin zu differenzierteren Betrachtungen und damit mehr Handlungsoptionen im konkreten Projekt?
Es gibt ein gutes Hilfsmittel, um diese Fragen zu beantworten, welches ich gerne im Agile Coaching einsetze: Richard Lawrence hat ein tolles Flowchart „Userstories aufteilen“ entwickelt, welches ich nun ins Deutsche übersetzt habe.
Die Datei enthält den grundlegenden Workflow, wie man Stories zerlegt und beinhaltet die beliebtesten Muster dazu in einer übersichtlichen Darstellung. Hintergrundinformationen zu den einzelnen Pattern bietet Lawrence dazu auch nochmal in seinem Blog an.
Sie können es kostenfreihier herunterladen (PDF-Format), um damit in Zukunft leichter User Stories zu zerteilen und Ihre Teams optimal zu unterstützen. Viel Erfolg beim Einsatz!
Der Weg hin zu einer agilen Organisation ist mit vielen Hürden und Problemen gespickt. Anforderungen, Ziele und Rahmenbedingungen ändern sich innerhalb von wenigen Tagen und Wochen.
Der Product Owner trifft nahezu täglich Produktentscheidungen: In welcher Reihenfolge werden die Anforderungen umgesetzt, welche kommen hinzu, welche werden gestrichen? Und in welcher Ausprägung wird eine Anforderung realisiert? Diese Entscheidungen benötigen ein Fachwissen in der Domäne des Produkts und die Fähigkeit, die Entscheidungen dann auch durchsetzen zu wollen.
Um die richtigen Entscheidungen zu treffen, braucht es aber nicht nur Fachwissen sondern auch ein gutes Gespür für den Kunden, die Anwender und den Markt.
Der Product Owner ist Teil des Scrum Teams. Und der Erfolg dieses Teams steht und fällt mit dem Zusammenspiel aller Teammitglieder. Wie gut findet man gemeinsame Lösungen für Konflikte und Probleme statt sich hinter seiner Rollenbeschreibung und Verantwortlichkeiten zu verschanzen?
Der ScrumMaster ist ein Veränderer in Unternehmen. Seine Aufgaben sind umfangreich und oft herausfordernd. Wie schafft man es, motiviert zu bleiben in Umfeldern, die keine täglichen Erfolgserlebnisse garantieren?
Sich in die Community begeben
Mein Team lag in den letzten Zügen – das Sprintende war nur noch wenige Stunden entfernt, die letzte User Story noch nicht vom Product Owner abgenommen. Konzentrierte Stille im Teamraum mischte sich mit wachsender Anspannung. Während der internen Abnahme kam er dann, der Fehler in letzter Minute. Entwicklerin Natalie und unser Product Owner saßen vor dem PC und hatten den Testfall entdeckt, der den Prozess zum Abbruch bringt. Das Review Meeting mit eingeladenen Kunden und Anwendern in nur 3 Stunden brachte besorgte Gesichter. Wir wollen ihn schaffen, diesen Sprint!
gen Ansprechpartner, das Herausheben der agilen Perspektive oder die Moderation von Teamworkshops.