Nun bist Du schon 26 Jahre alt und hast so viele Branchen in Deinen „Bann gezogen“. Warum? Weil Dein Vorschlag, ein Produkt inkrementell zu entwickeln, einfach viel erfolgsbringender ist als zu Beginn eines Projekts jeden Schritt zu planen und bei Änderungen „im Regen zu stehen“. Beim konventionellen Planungsansatz liegt nach einem definierten Zeitraum ein vollständiges Produkt vor. Doch ob die Anforderungen nach oft langen Projektlaufzeiten überhaupt noch die relevanten Wünsche des Marktes oder des Kunden treffen, ist oft fraglich. Im schlimmsten Fall ist die Entwicklung teurer und verspätet abgeschlossen und das Produkt ist „fertig“, doch keiner braucht es. Durch Deinen Fokus auf die Kundenwünsche oder die aktuelle Marktsituation und die immer wiederkehrenden Prüfungen, ob das Produktinkrement auch Relevanz hat, gehst Du in vielen Fällen als „Sieger“ hervor.
Trotzdem gibt es noch viele Unternehmen, die Probleme mit Deiner Umsetzung haben. Woran liegt das?
Zum einen liegt es an der kulturellen Änderung, die einhergeht und damit auch an einer oft maßgeblichen Veränderung in der Zusammenarbeit. Wenn bisher nach dem „Command & Control“-Prinzip Mitarbeiter Aufgaben zugeteilt bekamen und mit längerfristigen Deadlines umsetzen sollten, dann ist Dein Ansatz doch „etwas“ anders. Deine Vorgehensweise sieht Teams vor, die Verantwortung an den Ergebnissen übernehmen wollen. Mitarbeiter bringen sich ein und „holen“ sich ihre Aufgaben (Pull-Prinzip). Sie sind an dem Produkt interessiert und produzieren und planen in kurzen Zyklen. Dieser neue Weg muss von allen Beteiligten getragen und verinnerlicht werden und führt zu Verhaltensänderungen mit mehr Kommunikation und Transparenz.
Geht nicht, gibt es nicht
Eine weitere Herausforderung liegt sicherlich in Deiner technischen Umsetzung. Wie erfasse ich Epics und verfeinere sie zu User Stories? Wie bilde ich ein Product Backlog mit priorisierten User Stories?
Ein wesentlicher Schritt Deines Vorgehens ist die Festlegung, wann ein Epic oder eine Story durch welches Team umgesetzt werden soll. Die Kombination der verschiedenen Backlogs für Releases, Teams und Sprints schafft Transparenz.
Der klassische, agile Ansatz mit Whiteboards und Post its ist nett, doch schnell kommt diese Methode an ihre Grenzen. Wenn Teams an verschiedenen Standorten verteilt sind oder Nachvollziehbarkeit eine Rolle spielt, dann nutzen auch die teuren Zettel mit der besseren Klebekraft wenig. Auch über die Zusammenarbeit in unserer aktuellen gesellschaftlichen Situation mittels Pen&Paper Methode brauchen wir nicht nachdenken. Viele Unternehmen möchten mit Deinem Modell Produktentwicklung betreiben, doch fehlt Ihnen oft die richtige Infrastruktur. Es gibt zahlreiche Tools, die bestimmte Themen Deiner Methode, wie beispielsweise die Zusammenarbeit an unterschiedlichen Orten oder die Verwaltung von User Stories im Produkt Backlog gut unterstützen.
Wäre es nicht schön, wenn es nicht nur „Hammer“ und „Zange“, sondern einen ganzen Werkzeugkasten gäbe, der Deine Vorgehensweise auf allen Ebenen unterstützt?
Als Softwarehersteller mit 37 Jahren „Lebenserfahrung“ haben wir schon vor über 20 Jahren Features für anforderungsgetriebene Planung und Steuerung (actiF) in unserer Software implementiert, um „Deine Philosophie“ zu unterstützen.
Schauen wir uns mal an, was objectiF RPM heute alles bietet.
Technik, die begeistert
Du möchtest, dass jederzeit neue Anforderungen aufgenommen, bewertet und in einer Liste, dem Product Backlog darstellt werden. Der Product Owner bewertet die Anforderungen und priorisiert sie. Das Product Backlog ist zu keinem Zeitpunkt vollständig und wird mittels Backlog Refinement, früher auch Backlog Grooming, stetig entwickelt. Einträge ordnen, zusammenfassen, splitten, detaillierter beschreiben… Kein Problem!
In vielen Branchen ist Nachvollziehbarkeit das A und O. Und gerade, wenn Anforderungen Abhängigkeiten aufweisen, ist Requirements Traceability gefragt. In folgender Abbildung siehst Du, es ist alles da und Du kannst Deine Anforderungen/Epics/Stories erfassen, bewerten, einen Planaufwand vergeben und nach Absprache mit dem Team im Sprint Planning dem nächsten Sprint zuordnen. Wenn Du einen Eintrag wählst, werden auch gleich in Abhängigkeit stehende Epics/Stories farblich gekennzeichnet, wie praktisch. Und diese Traceability kannst Du ausweiten und bis hin zum Stakeholder den Ursprung einer Anforderung nachvollziehen. Das spart sehr viel Recherchearbeit und damit Zeit, wenn sich ein Kundenwunsch ändert.
Im nächsten Schritt setzen die Teams Stories in einem Sprint um. Du möchtest, dass die Teammitglieder einen Überblick zu Ihren Aufgaben haben, am besten mittels Task Board. Darf es auch ein Kanban Board sein? Folgende Abbildung zeigt, wie einfach die Umsetzung in objectiF RPM ist. Die User Stories werden per Drag&Drop dem jeweiligen Sprint zugeordnet. Man sieht sofort den Bearbeitungsstand.
Und das Team hat die Aufgaben mittels Kanban Board immer im Blick und kann Sie ebenfalls nach Realisierung und Test einfach mit der Maus in den Zustand „abgenommen“ schicken, direkt auf dem eigenen Screen. Manche Unternehmen nutzen das “WIP-Limit“ (Work in Progress), um einen guten Fluss zu gewährleisten. In objectiF RPM kannst Du die Anzahl der User Stories ganz nach Deinen Wünschen begrenzen. Das Teammitglied erhält eine Warnung, wenn das WIP-Limit überschritten wird. Es kann so einfach sein….
Transparenz im Fortschritt ist Dir wichtig. Dazu arbeiten viele mit einem Burn Down- oder einem Burn Up Chart . Auch das bietet objectiF RPM und wenn gewünscht, hast Du es sofort beim Start der Software im Dashboard. So hast Du immer im Blick, welche Stories bereits umgesetzt wurden und welche noch realisiert werden müssen – auf Sprintebene oder auf Releaseebene. Umfang und Liefertermin des Releases hat der Product Owner so auch immer im Blick.
Scrum, was sagst Du dazu? Findest Du Dein Vorgehensmodell wieder? Lass uns nun zum Thema Zusammenarbeit kommen.
Kommunikation ist alles
Deine Methode ist mit vielen Events gespickt. Zusammenarbeit wird großgeschrieben. Es wird besprochen, was im Sprint entwickelt wird (Sprint Planning). Das Daily Scrum dient als Informationsaustausch zum aktuellen Arbeitsstand. Und nach dem Sprint Review, wo geprüft wird, ob das Ziel (Produktinkrement) erreicht wurde, tauschen sich die Teams in der Retrospektive über die bisherige Arbeitsweise und mögliche Verbesserungen für die Zukunft aus. Das ist super!
Wie sieht die aktuelle Zusammenarbeit aus? Viele Menschen arbeiten seit geraumer Zeit im Home Office. Ein Team kann sich heute oft nicht mit dem Product Owner an einem Ort treffen und die User Stories für das nächste Release besprechen.
Auch dafür hat objectiF RPM eine Lösung parat. Wir haben auf die Herausforderungen des Arbeitsalltags reagiert und Anfang des Jahres viele Features für die Zusammenarbeit realisiert. Das heißt, alle können sich mit nur einem Klick online direkt im Projekt treffen und die darin erfassten Inhalte wie Anforderungen, Epics oder User Stories für das nächste Release bewerten, priorisieren und einplanen. Mittels Desktopsharing kann das nächste Produktinkrement mit allen Teams geplant werden – standortübergreifend. Der Chat Messenger macht es möglich, dass die Teams untereinander Fragen stellen können und sich zu jeglichen Themen schnell austauschen. Statusänderungen zu den Anforderungen werden auf Wunsch als Pop-Up eingeblendet und ermöglichen jedem Mitarbeiter immer auf dem aktuellen Stand zu sein. Eine User Story wurde abgelehnt und der Kollege erfährt es erst durch Zufall nach 3 Tagen? Nicht mit objectiF RPM, sobald eine Story diesen Zustand erreicht, erhält der Mitarbeiter eine System-Status-Nachricht und kann zeitnah reagieren.
Scrum für die „Großen“ – SAFe®
Immer mehr Unternehmen „setzen“ auf Dich. Gründe dafür sind bessere Projektergebnisse, die schnellere Umsetzung von Projekten und schnelleres Erkennen und Reagieren auf auftretende Probleme [1].
Und da kommt auch die Idee auf, nicht nur auf Projektebene agil zu sein, sondern im großen Rahmen, also auf Organisationsebene. Hier kommst Du an deine Grenzen, weil Dein Modell auf selbstorganisierte Teams mit 3 – 9 Mitgliedern begrenzt ist.
Und so gibt es einige Skalierungsmodelle Deiner Vorgehensweise. Das Scaled Agile Framework®, auch SAFe® genannt, ist ein Modell „ohne Grenze nach oben“. Es trägt im Kern Deine Idee und überträgt Sie durch zahlreiche Rollen, Events und Artefakte auf große Unternehmen mit 1000 Mitarbeitern und mehr. Hier bietet Dir objectiF RPM eine Infrastruktur für mehrere synchronisierte Scrum Teams, verwaltet Ergebnisse der Events wie beispielsweise das PI-Plannung und hilft mit Backlogs, Boards, Dashboards Termine, Kosten, Teams, Inkremente und Iterationen zu planen und zu überblicken.
Scrum, Du bist eine Erfolgsstory und mit objectiF RPM erst recht… 😉