Agile RE Blog 8: Von der Projektebene zur Produktebene

Bisher habe ich mich in meinem Gedanken vorwiegend auf die Ebene des Projekts bezogen. Es ist selbstverständlich, dass diese Aussagen im Sinngehalt identisch auf der Produktebene gelten.

In der folgenden Abbildung sind zwei verschieden Kontextebenen aufgeführt: Die Projektebene und die Produktebene. Projekt- und Produktebene sind jeweils ein eigener Kontext in einer Organisation.


Kontext Ebenen des RE: Produkt und Projekt

 Zwei Kontextebenen: Projekt und Produkt

Wir erinnern uns, dass gemäss der dritten Eigenschaft von Wissen, dieses nur in einem Kontext gültig ist. Das hat zur Folge, dass diese beiden Kontextebene voneinander unabhängige aber eng verknüpfte Teams in der Organisationseinheit darstellen. Das ist genau eine der Schwierigkeiten, die ich in Unternehmen erkenne. Es wird verkannt, dass in beiden Kontextebenen zwar zu einem grossen Teil die identischen Informationen vorhanden sind, jedoch ein anderes Wissen aus diesen Informationen gewonnen und benötigt wird. Jedes Team benötigt sein eigenes Wissen um die Produkteigenschaften und den Prozess.

Das im Idealfall beständig zusammen arbeitende Projektteam hat hierbei eine gute Chance den Kontext zu nützen und Effektivität und Effizienz herauszuarbeiten. Das bedeutet auf der operativen Ebene der Produktentwicklung, in den Projekten nämlich, ist agiles RE möglich und sinnvoll und hilft das „GUTE PRODUKT“ mit den „RICHTIGEN EIGENSCHAFTEN“ zu erschaffen – vorausgesetzt es wird so im Produktkontext eingebettet, dass dieses dem Projekt auch möglich ist. Schlagworte sind: On-Site Kunde, permanente - oder zumindest ausreichende - Anwesenheit der Fachperson und so weiter.

Die Kontextebene Produkt als Sorgenkind des agilen Requirements Engineerings

Im Kontext des Produkts, auf der taktischen Ebene ist dies deutlich schwerer. Die dort wirkenden Personen sind typisch nicht beständig zusammen. Der Aufbau eines gemeinsamen Wissens ist deutlich erschwert. Jeder der in diesem Kontext arbeitet, sollte sich einmal fragen wie viel Zeit pro Woche er mit seinen Peers in Kommunikation verbringt und wie viel Zeit er alleine für sich arbeitet. Was im Projekt offensichtlich ist, nämlich das gemeinsame Lösen eines komplexen Problems durch Aufbau von Wissen, das Schließen von Wissenslücken und beständige Zusammenarbeit, ist auf der Produktebene deutlich erschwert. Hier ist ein Wechsel der Arbeitsform in Richtung Agilität deutlich schwerer und noch viel enger mit Firmenkultur verbunden als auf Projektebene.

Ursachen und Konflikte

Hinzu kommt, dass die Protagonisten auf der Produktebene typisch – und ganz besonders betroffen ist davon das mittlere Management – keinen Vorteil in der agilen Arbeitsweise erkennen. Das liegt oft an der persönlichen Situation des mittleren Managements. Diese ist typisch geprägt durch Erfolgsdruck, Budgetknappheit, Arbeit an der eigenen Karriere und Überlast. Unter solchen Umständen wird kein neues Arbeitsmodell ausprobiert, da dies weitere Arbeitslast und ein nicht kalkulierbares Risiko für die eigene Karriere bedeuten kann. Nur über den Schutz eines Top Management ist dies möglich.

Wichtig ist zu erkennen, dass einzelne Personen zudem gleichzeitig in beide Kontextebenen eingebunden sind. Das ist die ideale Form um Wissen zwischen den Teams zu transportieren. Diese Personen stehen allerdings nun in einem Konflikt, wenn sie agil in dem einen Kontext arbeiten und Dokumenten-getrieben im Produktkontext.

Gravierender ist, dass diese – ich nenne es jetzt Kultur – auf der Produktebene auch ein agiles Arbeiten im Kontext des Projekts erfolgreich verhindern kann, zum Beispiel weil bestimmte Voraussetzungen nicht erfüllt werden, wie etwa Feedback durch einen On-Site Kunden.

Willkommen im realen Leben

Nun gut, wie bereits gesagt besitzt dies rein strategisch auf oberster Organisationsstufe (leider) keine Bedeutung solange die Konkurrenz identisch arbeitet. Die Werte für Effektivität und Effizienz, also für Produktivität, werden bei sich ähnlichen Organisationen ähnlich groß oder klein sei, die damit ja auch eine ähnliche Kultur und Historie besitzen und sich typisch in einer Domäne gleichzeitig entwickelt haben. Meine persönliche Meinung: Die "new kids on the block" werden kommen und in bestehende Domänen mit einer anderen Kultur und eventuell abweichendem Geschäftsmodell einbrechen und den bestehenden Organisationen das Leben schwer bis unmöglich machen. Ist das eventuell eine neue Sicht auf den Erfolg von Unternehmen wie Apple, Google, Facebook, Doodle, ...

Interessant ist übrigens auch noch eine Messung des Instituts für Technologie in Blekinge im Rahmen des Requirements Abstraction Models dass auf Produktebene weniger als 40% des gesamten Produktwissens benötigt wird, um auf dieser Ebene erfolgreich arbeiten zu können. Es werden diese 40% vom Team jedoch in der Form von taktischem Wissens benötigt und nicht als operatives Lösungswissen wie im Projekt.
(Referenz: T. Gorschek and C. Wohlin, "Requirements Abstraction Model", Requirements Engineering Journal, Vol. 11, No. 1, pp. 79-101, 2006, zu finden unter http://gorschek.com/doc/publications.html, wie viele weitere interessante Informationen)

Arbeiten auf Basis von Visionen im Sinne von Zukunftsbildern

Meine persönliche Feststellung: Agiles Arbeiten auf der Produktebene – und damit auch agiles Requirements Engineering auf dieser Ebene – stellt eine Herausforderung dar.

Unternehmen, die darin erfolgreich sind arbeiten typisch mit einem Produktportfolio und einer Produkt Roadmap, welche mit Visionen zu Produkten arbeitet. Eine Vision sollte wie folgt sein: Ein einfach zu verstehendes und einprägsames, ideal mit Hilfe oder Einbezug von Prototypen oder Exemplaren beschriebenes, Zukunftsbild eines Produktes. Visionen sind für verschiedene Zeitpunkte in der Zukunft (3 Monate, 6 Monate, ein Jahr, 3 Jahre) mit dem Team auf der Produktebene aufzubauen und beständig zu überarbeiten. Ein zeitlich nahes Zukunftsbild kann und sollte hierbei sehr konkret sein, die 3 Jahre Vision ist bestimmt abstrakter und weniger detailliert.

Das Überarbeiten aller Visionen erfolgt mit den typischen Stakeholdern wie Marketing, Forschung, Entwicklung, Kunden, Kundendienst, jdeoch agil, permanent, in einem Kontext mit gemeinsam erarbeiteten und gepflegten Wissen.