Aus den bisherigen Betrachtungen können wir wesentliche Schlüsse ziehen für eine Veränderung in Richtung Agilität. Zwei Gedankenexperimente möchte ich dazu plakativ aufzeigen in Form von zwei Extremen.
Extrem 1: das Dokument-lastige Arbeitsmodell
Stellen Sie sich vor: Ein Unternehmen hat sich entschieden das komplette Wissen in Form von Informationen in Dokumentation zu bewahren. Das gilt für Prozesswissen als auch für Produktwissen. Eine entsprechende Q-Sicherung prüft die Vollständigkeit der abgelegten Informationen in beiden Bereichen. Beginnend beim Strategieprozess auf Produktebene über den Aufbau des Produktportfolios bis hin zur Definition und Ausführung von Projekten ist das komplette Wissen in Dokumenten zu bewahren.
Extrem 2: Das Team orientierte und agile Arbeitsmodell in Extremform
Wir verzichten auf jede permanente Dokumentation. Das Team setzt alleine temporäre Dokumentation für das Treiben des Prozesses ein (wohlgemerkt Produkt bezogene Dokumentation entsteht sehr wohl, etwa ein UML-Modell des Produkts, Handbücher oder – wenn von FDA gefordert – eine Traceability Matrix). Diese Prozessdokumentation hilft dem Team in der täglichen Arbeit, also Kärtchen am Scrum oder Kanban Board oder was auch immer das Team entscheidet zu nehmen. Das komplette Prozess- und möglichst viele Details des Produktwissens sind in den Köpfen der Teams und werden dort permanent weiter entwickelt. Dieses Arbeitsmodell ist natürlich hoch effizient in einem lokalen und kleinen Team, das beständig zusammen arbeitet.
Vorteile des Dokument-lastigen Arbeitsmodells
Zu jeder Zeit kann ein Mitarbeiter ersetzt werden (das hat doch Charme für das Management, oder?). Über die Dokumentation und geeignete Trainings erarbeitet sich ein neuer Mitarbeiter das Prozesswissen und das Produktwissen, um anschließend produktiv, den Standards folgend, tätig zu werden.
Abbildung 8: das Dokument-lastige Arbeitsmodell
Ein Vorteil besteht, wenn ein Produkt nicht permanent weiter entwickelt wird. Es kann zum Beispiel 2 Jahre unverändert verkauft oder eingesetzt werden. Niemand entwickelt das Produkt weiter, es wird lediglich „produziert“. Das Team, welches das Produkt entwickelt, ist also nicht mehr existent. Wird dann wieder ein Projekt aufgesetzt, wenn eine neue Version des Produkts zu erstellen ist, so sind die Informationen vorhanden, um ein neues Projektteam aufsetzen zu können.
Ein weiterer Vorteil (so zumindest oft zitiert) ist, dass ein beliebiger Teil der Fertigungskette Offshore vergebbar ist, es ist „einfach“ die Prozess- und die Produktdokumentation offshore zu transportieren. Das entspricht den oft vorgetragenen Argumenten der globalen und verteilten Teams, Flexibilität und "atmende Work Force". Ich denke dass dieser Vorteil erfreulicher Weise mittlerweile aus Kosten- und Effizienzgründen differenziert diskutiert wird.
Das Arbeitsmodell verlangt nach einer hohen Standardisierung des Arbeitsmodells. Das gilt für die Rolle des Requirements Engineers wie für jede andere Rolle auch. Sie ist klar und eindeutig mit Tätigkeiten beschrieben. Es ist klar, welche Eingangsdokumente ein Requirements Engineer bekommt und welche Ergebnisse er in Form von Dokumentation erzeugt. Es ist klar, wie er über Schulungen ausgebildet werden kann. Das Jobprofil ist klar und kann dem HRM kommuniziert werden. Oft gibt es in großen Unternehmen Pools von Jobfamilien wie den Pool an Requirements Engineers.
Nachteile des Dokument-lastigen Arbeitsmodells
Diese Vorgehensweise geht offensichtlich völlig zu Lasten der Effizienz. Die Informationen werden – zumindest auf der Prozessseite – von Personen basierend auf Basis rein expliziten Wissens dokumentiert. Dieser dokumentierte Stand der Arbeitstechnik ist zudem strukturell immer veraltet, da das Erlernen, Dokumentieren, Freigeben, Lehren und Anwenden (einschließlich eventuell einer unterstützenden Tool Chain) nun einmal Zeit zur Umsetzung benötigt und damit dem „state of the art“ hinterher hinkt.
Auf implizites Wissen eines Teams wird kein Wert gelegt, es wird in dem Extrem bewusst darauf verzichtet. Das gilt für das Team, das nach einem Projekt zerschlagen und wieder neu aufgesetzt wird. Jedes Projektteam fängt dann praktisch von Null an und muss durch Dokumentenstudium lernen, was das Vorgängerteam hinterlassen hat. Dafür kann es natürlich zu einem beliebigen Zeitpunkt installiert werden. Dieses Prinzip gilt auf Teamebene und ebenso für die Zusammenarbeit der einzelnen Disziplinen im Projekt. Der Business Analyst schiebt Dokumente zum RE, der RE zum Testmanager, weiter zum Architekten und zum Designer und so weiter. Zwischen allen diesen Personen gelten die oben besprochen Punkte der Problemlösung, des Erarbeitens impliziten Wissens und dem Aufwand Wissenslücken schließen zu müssen über Lernen. Das vollkommene Extrem wäre erreicht, wenn die Personen ein direktes Kommunikationsverbot hätten und alleine über den Austausch von Dokumentation interagieren dürften.
Die Spezialisierung der Personen auf Rollen ist ebenfalls zweischneidig. Genauso, wie ein Requirements Engineer gezielt ausgebildet werden kann, ist er aber auch nur gezielt einsetzbar. Im härtesten Fall taugt er nur für das Requirements Engineering in einem Projekt. Ich persönlich habe einmal ein konkretes Projekt in einem Großunternehmen betreut, in dem 30% einer RE-Kapazität eingesetzt wurde – in Rolle und als Person. Dazu wurde dem Projekt ein Mitarbeiter zugeordnet, der 1.5 Tage die Woche anwesend war. Ein halber Tag davon wurde im wöchentlichen Projektmeeting benötigt. Der Wirkungsgrad dieses Mitarbeiters tendierte gegen Null – obwohl er gut war als RE. Das Projekt hat nach einem Monat auf seine Mitarbeit verzichtet und der Projektleiter hat die Rolle RE übernommen. Über die Gestaltung eines interessanten, vielseitigen und motivierenden Arbeitsplatzes für solch einen in einem Schema eingezwängten Wissensarbeiter möchte ich hier gar nicht philosophieren.
Kann das Modell funktionieren? Ja, es kann, die Praxis beweist es. Ich kenne Unternehmen, die zu diesem Extrem tendieren und erfolgreich sind. Unternehmen die so operieren müssen diese Ineffizienz lediglich wirtschaftlicher betreiben als ihre wohl ebenso ineffizienten Konkurrenten.
Konsequenzen eines agilen Arbeitsmodells in Extremform
Ein agiles Arbeitsmodell in Extremform hat deutliche Konsequenzen für die Arbeitsorganisation. In einem Team müssen alle Fähigkeiten vorhanden sein und jeder im Team muss mehr als eine Disziplin beherrschen. Das hat Konsequenzen für die Rolle Requirements Engineering, des Testmanagers, des Architekten und alle anderen Rollen. Es gibt sie nicht mehr, den Mister Requirements Engineer, den Chefarchitekten. Die Berufsbilder in Reinform sind verschwunden, die benötigten Disziplinen müssen jedoch vom Team professionell und ausgewogen beherrscht werden.
Jeder Entwickler muss zum Beispiel zu einem gewissen Teil das Requirements Engineering beherrschen, sonst wäre er nicht in der Lage eine User Story zu zerlegen und umzusetzen. Manche sind natürlich „besser“ als andere und ziehen sich deswegen die Tasks zu sich, welche die höhere Expertise einfordern.
Ein Profi im Requirements Engineering muss der unbedingt der Product Owner sein (ich verwende hier einmal den Scrum Jargon) oder allgemeiner gesagt: der Vertreters des Business oder des Fachbereichs oder des Kunden – ja nach Kontext des Projekts die Person, die sich für den fachlichen Inhalt des Produkts verantwortlich fühlt und diese Verantwortung nach innen und außen wahrnimmt. Hier sehen wir auch die typische Schwierigkeit: Er muss viel im Projektteam vorhanden sein. Er muss viel außerhalb des Projektteam aktiv sein bei den Stakeholdern. Er ist Teil des gemeinsamen Problemlösungsprozesses, des Schließens von Wissenslücken und dem permanenten begleitenden Lernen. Er ist Träger von wesentlichem implizitem Wissen.
Abbildung 9: Das Team orientierte und agile Arbeitsmodell
Vorteile des Team-orientierten und agilen Arbeitsmodells
Ganz eindeutig ist die hohe Effektivität bei gleichzeitig hoher Effizienz der Vorteil eines agilen Teams. Das gemeinsam getragene Wissen vermindert die Anzahl an Defekten, da Fehlinterpretationen durch permanentes Feedback sofort offensichtlich werden und keine Defekte daraus entstehen beziehungsweise diese sofort offensichtlich werden und adressiert werden können.
Nehmen wir an die Personen, welche das Requirements Engineering vor allem treiben, einschließlich Product Owner, bekommen beständig Feedback von Business und Stakeholdern. Dies ist der geeignete Vermittlungsweg, um eine hohe Zielerreichung der Wünsche des Business zu erreichen (Effektivität). Das im Agilen möglichst konstante Projektteam kann das Prozess- und Produktwissen aufbauen, optimieren und anwenden und erreicht durch diesen beständigen Lernprozess eine hohe Effizienz. Insgesamt bedeutet das in Summe eine individuelle und eine Team-orientierte Produktivitätssteigerung und damit Wettbewerbsvorteil.
Ein weiterer Vorteil ist das Vermeiden von Spezialistentum. Generalist wäre das falsche Wort, Mitarbeiter in agilen Projekten beherrschen jedoch typisch ein breiteres Skillset als Mitarbeiter in nach Rollen organisierten Unternehmen.
Wenn wir das so hören, dann fragen wir uns, warum arbeiten wir überhaupt noch auf eine andere Art und Weise. Gibt es auch Nachteile dieser Arbeitsorganisation. Welche sind diese?
Nachteile des Team-orientierten und agilen Arbeitsmodells
Ein Nachteil ist, dass bei einer in der Extremform gefahrenen agilen Arbeitsform typisch das Produkt stirbt, wenn das Projektteam zerfällt. Das Unternehmen muss seine Teams „lebendig“ halten, um das Produkt lebendig zu halten. Es ist ein permanenter Invest in die Teams notwendig in Form von Vision aufzeigen, Motivation erhalten, Skills aufbauen, damit diese Zusammenhalt gewahrt bleibt und die richtigen Skills vorhanden sind.
Eine wichtige Frage ist zum Beispiel: Was ist eine gute Mischung an Disziplinen-Verständnis bei einem Projektmitarbeiter, der typisch das Requirements Engineering in einem agilen Projekt vorantreibt, also etwa ein Product Owner. Das durchaus reale Problem für ein Unternehmen lautet allgemein: Wie finde ich diesen multidisziplinären Mitarbeiter auf dem Markt und wie entwickle ich ihn weiter, wie beurteile ich seine Leistung. Dieser Typus Mitarbeiter ist „schwieriger“ zu „verwalten“ und zu „entwickeln“ als ein Spezialist.
Ein weiterer Nachteil besteht, wenn ein Produkt nicht beständig entwickelt werden muss, eine „Pause“ in der Entwicklung besteht. Wenn wir an ein Großunternehmen denken mit einer Serviceplattform wie eine Großbank oder eine Versicherung in der mehrere hundert Anwendungen diese Service-Plattform bereit stellen, so wird nicht an allen Anwendungen permanent gearbeitet werden. Tatsächlich wird nur ein Bruchteil der Anwendungen zu einem Zeitraum parallel angefasst und weiter entwickelt. Auch ist der Begriff „Produkt“ in diesen Unternehmen nicht trivial zu definieren. Das geeignete Identifizieren von Produkten und das geeignete Identifizieren von Projekten, also Produkt- und Projektportfoliomanagement sind in diesem Kontext per se komplex und anspruchsvoll und weder klassisch noch agil trivial umzusetzen.
Nicht ein Nachteil, aber als Gefahr besteht, dass sich eine komplett agil aufgebaute Organisation, in der sich die einzelnen Zellen selbst organisieren und optimieren, sich vollkommen der Standardisierung zum Beispiel in Richtung Technologien, Architektur und Tooleinsatz entzieht und aufgrund lokaler Optimierung (Gärtchendenken) sogar schädlich für die Gesamtorganisation wirken. Ich behaupte hier, ohne den Beweis zu liefern oder liefern zu können, dass dies nur eine bedingt vorhandene Gefahr ist. Nach meinen Erfahrungen unterwerfen sich WRKLICH agile Organisationen einer freiwilligen strengen gelebten Selbstdisziplin. Scheinagilen Organisationen mit ausgeprägtem Gärtchendenken fehlt Transparenz als Grundprinzip und damit die Kultur der gesunden Selbstdisziplin.
