Teil 1 aus der Praxis-Serie \u201eHinter den agilen Kulissen\u201c – Ein- und Ausblicke f\u00fcr die agilen Profis von heute und morgen. In der 5-teiligen Blog-Artikel-Reihe geht es um zentrale Werkzeuge und Denkmodelle agiler Arbeit.<\/p>\n
Sicher kennt die oder der geneigte Lesende den Begriff \u201eSelbstorganisation\u201c. Es ist ein Modebegriff, der gut zu den Ideen neuer, weniger hierarchischer F\u00fchrungssysteme passt. Was viele in der Benutzung \u00fcbersehen: Selbstorganisation bedeutet streng genommen Selbst\u00fcberlassung. Das System wird von den Elementen des Systems selbst gestaltet, also nicht fremdorganisiert.<\/p>\n
Wenn man das im System Unternehmen ernst nimmt, hat das radikale Auswirkungen zum einen auf die F\u00fchrung der Organisation, zum anderen auf die Art, was Teams und Mitarbeitende leisten m\u00fcssen, um ihre Zusammenarbeit weiter funktionieren zu lassen. Das Ergebnis in den meisten Organisationen ist eine Balance aus rahmengebenden Ma\u00dfnahmen der F\u00fchrungskr\u00e4fte und mehr Verantwortungs\u00fcbernahme der Mitarbeitenden. Selbstorganisation, das wird schnell klar, ist ein hoher Anspruch.<\/p>\n
Ein \u00e4hnliches Spannungsfeld tut sich f\u00fcr manch eine:n Einsteiger:in in die agile Welt auf. \u201eAgil\u201c, so h\u00f6rt man nach den ersten Stunden der Besch\u00e4ftigung mit Scrum & Co., \u201edas soll uns doch freier machen. Weg vom Arbeiten nach der Wasserfall-Methode, schneller, flexibler. Warum gibt es dann ein so detailliertes Framework f\u00fcr agiles Arbeiten?\u201c<\/p>\n
Beispielhaft f\u00fcr diese Fragestellung steht der \u201eAgile Backlog\u201c, eins der zentralen Tools im agilen Werkzeugkasten. Auf viele Dinge, das werden einem erfahrene Agile-Profis best\u00e4tigen, k\u00f6nnte man verzichten, auf irgendeine Art von Backlog nicht. Der Backlog, so w\u00fcrde man auf Englisch sagen \u201eis the backbone of agile problem solving.\u201c<\/p>\n
Der Backlog oder auch Product Backlog ist die Liste aller Aufgaben, Funktionen und Elemente, die erledigt werden m\u00fcssen, um das Ziel des Projekts zu erreichen. Diese vom Team laufend aktualisierte ToDo-Liste hat vor allem zwei Aufgaben: Den \u00dcberblick \u00fcber das Projekt zu behalten (anders formuliert: Das auf dem Weg nichts verloren geht) und die Aufgaben zu priorisieren.<\/p>\n
Agile Teams haben die Aufgabe, ein Produkt zu erstellen und dieses im Laufe eines Projekts immer weiterzuentwickeln. Agiles Projektmanagement unterscheidet sich von traditionellem Projektmanagement dadurch, dass es keinen in Stein gemei\u00dfelten Projektplan gibt. Das hei\u00dft aber auf keinen Fall, dass es keinen Plan gibt. Auch gibt es eine klare Vorstellung von der L\u00f6sung, der Weg dorthin ist aber nicht festgelegt. Er entsteht in einem st\u00e4ndigen Wechsel von Entwicklung, Beobachtung und Anpassung.<\/p>\n
Der Backlog als agile ToDo-Liste spiegelt dieses \u201eMitgehen mit dem Problem\u201c: Tauchen auf dem Weg der Entwicklung neue, unerwartete Herausforderungen auf, so werden die n\u00e4chsten Entwicklungsschritte neu bewertet, es entsteht ein neuer Wegabschnitt.<\/p>\n
Nun lautet eines der Prinzipien des Agilen Manifests aus dem Jahre 2001, dass \u201efunktionierende Software wichtiger ist als umfassende Dokumentation\u201c. Damit wollten die Pioniere der agilen Bewegung aber nicht sagen, dass der laufende Arbeitsprozess g\u00e4nzlich sich selbst \u00fcberlassen werden kann.<\/p>\n
Insbesondere die Arbeit in Teams braucht Antworten auf die Fragen: Wer macht was und in welcher Reihenfolge. Dies und noch einiges mehr beantwortet ein gut gepflegter Product Backlog.<\/p>\n
\u00dcblicherweise werden in einem Backlog vier Kategorien von Informationen erfasst:<\/p>\n
Diese Elemente sind im Backlog immer an eine konkrete User Story, eine f\u00fcr die Kunden wertvolle Funktion gekn\u00fcpft. Diese Story dient vor allem dazu, den Entwickler:innen ein klares Bild der Funktion und des damit verbundenen Kundennutzens zu vermitteln ohne die L\u00f6sung zu diktieren.<\/p>\n
Die Product Features sind die Produkt-Elemente, die zur Erf\u00fcllung der jeweiligen Funktion zwingend notwendig sind und aus der sich unmittelbar Entwicklungsaufgaben ergeben.<\/p>\n
Fehler passieren selbst dem besten Entwickler:innen-Team. Weil \u201eBugs\u201c allerdings den Wert des Produkts und damit die Kundenzufriedenheit unmittelbar negativ beeinflussen, kann es sinnvoll sein, einen \u201eBug Fix\u201c im Backlog deutlich h\u00f6her zu priorisieren. Was auch bedeuten kann, dass das Team einen aktuellen Sprint unterbrechen muss. Empfehlenswert ist, die erkannten Fehler im Product Backlog weit oben zu platzieren, damit sie auf keinen Fall in Vergessenheit geraten.<\/p>\n
Wenn wir von \u201eTechnischen Schulden\u201c reden, dann meinen wir unbearbeitete Aufgaben im Backlog. \u00c4hnlich wie bei finanziellen Schulden, bedeutet das Ignorieren h\u00f6here Kosten, sprich: Zinsen. Wenn also bestimmte Aufgaben im Backlog immer weiter nach unten rutschen, wird es immer schwieriger, sie abzuarbeiten. Genau dazu gibt es aber den Backlog: Dass es keinen Aufgabenstau oder vergessene ToDos gibt.<\/p>\n
Schlie\u00dflich noch ein Blick auf die vierte Kategorie von Informationen im Backlog, das erworbene Wissen. Sinn und Zweck dieser laufenden Notizen im Backlog, ist die Sammlung und das Teilen von Informationen, die das Team f\u00fcr die Erledigung zuk\u00fcnftiger Aufgaben ben\u00f6tigt. In der Praxis k\u00f6nnte sich daraus eine Recherche, ein Protoyp oder ein Proof of Concept ergeben, das dem Scrum-Team dabei hilft, bessere Entscheidungen zu treffen.<\/p>\n
Das Backlog ist das zentrale Steuerungselement des Product Owners<\/a>. Die Verantwortung des Backlogs liegen somit beim Product Owner. Diese komplexe Aufgabe beinhaltet unter anderem die Pflege des Backlogs, das Einbringen oder Ablehnen der Stakeholder-Anforderungen, des Festlegen der Priorit\u00e4ten und der Abgleich mit der Produktvision ab. Ein gekonnter Umgang mit dem Backlog bedarf viel Erfahrung und Weiterbildung.<\/a><\/p>\n Grundlage eines Backlogs ist die Product Roadmap, ein Fahrplan, der die Ver\u00e4nderung des Produkts im Laufe des Entwicklungsprozesses auf \u00fcbergeordneter Ebene beschreibt. Er vermittelt die langfristige Vision f\u00fcr die Produktentwicklung, was nicht hei\u00dft, dass er im Laufe der Zeit an aktuelle Entwicklungen angepasst werden kann.<\/p>\n Auf Basis der Roadmap k\u00f6nnen Team-Mitglieder nun alle Eintr\u00e4ge f\u00fcr den Product Backlog auflisten. Es kann sich anfangs um sehr konkrete, dringliche, aber auch eher abstrakte Ideen handeln. Der Austausch mit allen Beteiligten des Projekts ist hier unbedingt notwendig, um sicherzustellen, dass alle notwendigen Produkteigenschaften mit in die Entwicklung einbezogen werden.<\/p>\n Nach der Erfassung der Eintr\u00e4ge gilt es, diese zu sortieren und zu priorisieren. Die wichtigste Frage bei der Priorisierung sollte immer lauten: Wo schaffen wir den gr\u00f6\u00dften Kundennutzen?<\/p>\n Der Backlog ist ein lebendiges Dokument, das zwingend von allen Team-Mitgliedern genutzt und laufend aktualisiert wird. Dementsprechend m\u00fcssen auch die Priorisierungen der Aufgaben immer wieder vom Product Owners<\/a> angepasst werden. Am Ende dieser laufenden Koordinationsarbeit steht das Festlegen der n\u00e4chsten Entwicklungs-Etappe, in der agilen Welt \u201eSprint\u201c genannt.<\/p>\n Ein Product Backlog verbessert die Organisation und Zusammenarbeit im agilen Team. Es ist das zentrale Werkzeug zur Verwaltung und Abstimmung der Arbeit, in Kombination mit einem Multi-Channel-Messenger (wie z.B. Slack) bildet es auch das kommunikative R\u00fcckgrat der Entwicklung.<\/p>\n Das Prinzip des iterativen Arbeitens, d.h. des Verzichtens auf einen fixen, komplett ausgearbeiteten Plan zugunsten von kleinen, zeitlich limitierten Arbeitspaketen, w\u00e4re ohne die Orientierung eines Backlogs schlicht und einfach nicht m\u00f6glich.<\/p>\n Die Team-Mitglieder sind selbst verantwortlich f\u00fcr die Erledigung ihrer Aufgaben, denn nur sie k\u00f6nnen wirklich beurteilen, welche Aufgabe wie anspruchsvoll ist. Es entsteht im besten Fall eine Mannschaft aus selbstorganisierten H\u00f6chstleister:innen, die laufend und ohne \u00dcberlastung zu einem besseren Produkt beitragen.<\/p>\n Fazit<\/strong> Hier lesen Sie Teil 2<\/strong> aus der Praxis-Serie „Hinter den agilen Kulissen“ Hier lesen Sie Teil 3<\/strong> aus der Praxis-Serie „Hinter den agilen Kulissen“ Hier lesen Sie Teil 4<\/strong> aus der Praxis-Serie „Hinter den agilen Kulissen“ Teil 1 aus der Praxis-Serie \u201eHinter den agilen Kulissen\u201c – Ein- und Ausblicke f\u00fcr die agilen Profis von heute und morgen. In der 5-teiligen Blog-Artikel-Reihe geht es um zentrale Werkzeuge und Denkmodelle agiler Arbeit. Das agile Framework Sicher kennt die oder der geneigte Lesende den Begriff \u201eSelbstorganisation\u201c. Es ist ein Modebegriff, der gut zu den<\/p>\nWie bauen Product Owner den Backlog?<\/h2>\n
Warum brauchen Product Owner den Backlog?<\/h2>\n
\nDas Backlog ist ein wichtiges Steuerungselement f\u00fcr Product Owner, welches die Pflege, Priorisierung und Abstimmung von Aufgaben und Anforderungen einer Produktentwicklung erm\u00f6glicht. Es ist ein lebendiges Dokument, das laufend von allen Team-Mitgliedern genutzt und aktualisiert wird und dient vor allem dem \u00dcberblick \u00fcber Projekte und der Aufgabenpriorisierung.<\/p>\n
\nStakeholder managen und Teams f\u00fchren<\/a><\/p>\n
\nBusinessstrategien f\u00fcr Product Owner<\/a><\/p>\n
\nKundenfokussierte Product Owner: Data-und UX-Profis<\/a><\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"