»Agiles Arbeiten« ist Mode geworden. Auch wir, das Team der Abteilung »Digital Society Ecosystems« am Fraunhofer IESE, arbeiten bei der Entwicklung neuer Lösungen für unsere Digitale-Dörfer-Plattform agil. Doch was genau ist »Agiles Arbeiten« überhaupt? Wie lässt sich Agiles Arbeiten bei uns am Fraunhofer IESE umsetzen? Und was hat das Ganze mit Vorgehensmodellen und -methoden wie »Scrum« oder »Kanban« zu tun? – Eines sei vorweg gesagt: Agiles Arbeiten ist auch ohne feste Modelle und Methoden möglich. Wie genau das funktioniert, möchten wir am Beispiel der Zusammenarbeit unseres Projektteams der »Smart Rural Areas« in diesem Blog-Beitrag kurz vorstellen.
Unsere Herausforderungen
Kernaufgaben
Im Smart Rural Areas bzw. Smart City- und Smart Region-Team des Fraunhofer IESE arbeiten wir an vielen verschiedenen Lösungen für den ländlichen Raum. Diese Lösungen interagieren alle mit einer Plattform, die zentrale Dienste bereitstellt und Kernaufgaben übernimmt. Ein Beispiel hierfür ist die Nutzerverwaltung. Daraus ergeben sich bei der Entwicklung unserer Produkte gewisse Abhängigkeiten zwischen einer konkreten Lösung, wie dem DorfFunk, und der Plattform.
Nebenaufgaben
Darüber hinaus erarbeiten wir einige kleinere Lösungen mit begrenztem Aufwand. Beispiele hierfür sind die DorfPages oder die BestellBar, welche auf dem Content-Management-System WordPress basieren. Für solche kleineren Produkte, die geringere Aufwände erfordern, können wir kein dezidiertes Vollzeit-Team abstellen. Ein Vorgehen mit Scrum würde dies allerdings implizieren. Stattdessen wird bei uns produktübergreifend gearbeitet. Unsere Spezialisten arbeiten also an mehreren Produkten, anstatt sich auf ein einzelnes zu fokussieren.
Rapide Veränderungen
Häufig müssen wir bei unserer Arbeit schnell auf Veränderungen reagieren. Gewinnen wir z.B. eine Ausschreibung für ein Projekt, werden Kapazitäten für das Projektteam benötigt. Zudem kann es auch vorkommen, dass einige unserer Team-Mitglieder kurzfristig bei anderen Projekten außerhalb des Smart-Rural-Area-Kontextes Unterstützung leisten müssen.
Aufgrund der genannten Herausforderungen arbeiten wir nicht nach einem festen Vorgehensmodell wie Scrum. Allerdings haben wir uns einiger Scrum-Ansätze bedient. Es bietet sich daher an, unser Vorgehen mit dem Vorgehen nach dem Scrum Guide zu vergleichen.
Das Team-Setup
In Scrum entscheidet die/der Product Owner darüber, wie welche Aufgaben am Produkt zu priorisieren sind. In einer idealen Welt entscheidet er/sie also selbstständig über die Verwendung der Gelder und darüber, was damit passieren soll.
Betrachten wir den Rahmen des Forschungsprogramms Smart Rural Areas. Hier übernimmt Steffen Heß als Programmmanager bzw. Abteilungsleiter »Digital Society Ecosystems« die Aufgabe des Product Owners. Er verteilt Personen und Aufwände auf Produkte und Teilprojekte. Dadurch priorisiert er diese implizit. Das Priorisieren konkreter Arbeitsschritte in einzelnen Teilprojekten übernehmen dann die zugehörigen Projektleiter. Werden mehrere Produkte im Rahmen eines Forschungsprojekts entwickelt, wird die Entscheidungsgewalt über die konkrete Priorisierung der Arbeiten an einem Produkt an einen spezifischen Product Owner delegiert. Dieser hat dann zwar keine Budgethoheit, entscheidet allerdings, in welcher Reihenfolge die Aufgaben umgesetzt werden.
Außerdem besteht ein Scrum-Team laut Scrum Guide neben dem Product Owner und dem Scrum Master aus einem Entwicklungsteam. Dieses Scrum-Team mitsamt dem Entwicklungsteam ist genau einem Produkt zugeordnet. Folglich arbeiten alle Mitglieder des Entwicklungsteams an genau einem Produkt.
Wie zu Beginn erwähnt, entsprechen unsere Anforderungen eher der klassischen Matrix-Organisation:
- Wir haben Spezialisten verschiedener Fachgebiete, wie UX-Designer, Requirements Engineers, Backend-Entwickler*innen, Frontend-Entwickler*innen, Test-Spezialist*innen usw.
- Wir haben einzelne Produkte, wie den DorfFunk oder die DorfNews, für die es spezifische Tätigkeiten aus einem oder meist mehreren dieser Fachgebiete zu erledigen gibt.
Bei uns hat sich deshalb folgende Praxis für unsere Product-Teams bewährt:
- Es gibt einen festen Kern an Personen je Product-Team. Diese arbeiten den Großteil ihrer Zeit an dem ihnen zugeordneten Produkt, wenn dies technisch komplex ist und viel Aufwand bedarf. Wenn das Produkt weniger Komplexität besitzt oder weniger Aufwand benötigt, arbeiten die Mitglieder des Teams nur einen kleineren Teil ihrer Zeit an diesem Produkt.
- Werden für gewisse Aufgaben weitere Spezialisten eines bestimmten Fachgebiets benötigt, unterstützen diese partiell die Produktentwicklung. Wenn beispielsweise eine anstehende Aufgabe einen großen Einfluss auf die Gesamtarchitektur unseres Ökosystems hat oder es für die Umsetzung der Aufgabe viel Kommunikation mit anderen Produkten bedarf, unterstützen in der Regel Architekten das Product-Team.
Das Vorgehen
Gemäß Scrum arbeitet das Scrum-Team in gleich langen Iterationen, den Sprints. Zu Beginn eines Sprints wird zunächst im Sprint Planning festgelegt, welche Aufgaben am Produkt in diesem Sprint erledigt werden sollen. Dafür bedient man sich aus der Liste aller Anforderungen, dem Product Backlog, und eine Teilmenge davon wird genutzt, um das Sprint Backlog zu formulieren. Während des Sprints wird dieses Sprint Backlog täglich im Daily Scrum inspiziert und der Fortschritt der Aufgaben wird besprochen. Ziel des Sprints ist es, mit dem Product Increment das Produkt jeweils ein kleines Stückchen zu verbessern. Das Inkrement ist meist ein Stück Software, das ein oder mehrere Features beinhaltet. Dieses Inkrement wird zum Abschluss in einem Sprint Review begutachtet und beurteilt. Anschließend analysiert das Scrum-Team die Arbeitsweise des letzten Sprints in der Sprint Retrospective, um ggfs. Maßnahmen zu Prozessverbesserungen abzuleiten. Diese Maßnahmen werden dann im folgenden Sprint Planning mit eingeplant.
Genau wie in Scrum arbeiten auch wir in gleich langen Sprints. Bei uns dauert ein Sprint zwei Wochen. Da zwischen Product-Teams Abhängigkeiten entstehen können, startet und endet der Sprint für alle Teams zum gleichen Zeitpunkt. Wir arbeiten also in einem synchronisierten Vorgehen.
Auch wir planen zu Beginn eines Sprints, welche zu erledigenden Aufgaben am Produkt in dieser Iteration umgesetzt werden sollen. Als Voraussetzung dafür existiert für jedes Produkt eine Liste mit Anforderungen und Aufgaben, die zu erledigen sind. Somit arbeiten auch wir mit Sprint und Product Backlogs.
Obwohl wir uns täglich in einer gorßen Runde mit allen Smart-Rural-Area-Mitarbeitenden abstimmen, gibt es in den Product-Teams noch eine separate Abstimmung, die individuell gehandhabt wird. Der Grund dafür liegt erneut in der unterschiedlichen Komplexität der Produkte und den unterschiedlichen Aufwänden, die dafür bereitstehen. Arbeitet ein Team-Mitglied nämlich an mehreren kleinen Produkten, würde eine tägliche Abstimmung je Produkt sehr viel Abstimmungsaufwand nach sich ziehen. Für ein großes und komplexes Produkt wie den DorfFunk hingegen hat sich eine tägliche Abstimmung aller Beteiligten als sinnvoll erwiesen.
Am Ende unserer Iterationen steht schließlich auch ein Inkrement. Meist deckt sich das mit den Sprint-Zielen und besteht aus einem großen Feature oder mehreren kleinen. Allerdings fällt unser Sprint Review sehr kurz aus. Anstatt das Inkrement je Product-Team zu analysieren und das Product Backlog zu inspizieren und anzupassen, treffen sich bei uns alle Mitglieder des Smart-Rural-Area-Teams. In dieser Runde werden größere Features des letzten Sprints vorgestellt, sodass sich das zugehörige Product-Team Rückmeldung von allen Mitarbeitenden holen kann. Hat ein Product-Team im vergangenen Sprint nur kleinere Veränderungen am Produkt vorgenommen, stellt es kein Feature vor.
Retrospektiven stellen bisher keinen festen Bestandteil unserer Arbeitsweisen dar. Sie haben (noch) keinen festen Platz und wurden in der Vergangenheit nur sehr sporadisch durchgeführt. Maßnahmen zur Verbesserung des Prozesses müssen also von Einzelnen im Rahmen des Alltagsgeschäfts vorgeschlagen und umgesetzt werden.
Fazit
Modernes und agiles Arbeiten stellt bei uns am Fraunhofer IESE einen ganz wesentlichen Bestandteil unseres täglichen Tuns dar. Doch anstatt festen Prozessen zu folgen, arbeiten wir nach einer für uns passenden, flexiblen Vorgehensweise. An feste Vorgehensmodelle halten wir uns gezielt nicht, da sie unserem Alltagsgeschäft mit vielen kurzfristigen Veränderungen und Anpassungsbedarfen in der Regel nicht gerecht werden. Schließlich ist unser Verfahren genau aus der Notwendigkeit heraus entstanden, auf kurzfristige Veränderungen angemessen reagieren und ursprüngliche Planungen entsprechend anpassen zu können. Unsere Arbeitsweise folgt damit ganz klar dem letzten Leitsatz des agilen Manifests » Responding to change over following a plan« und ist somit vor allem eines, nämlich: innovativ und »agil«.