Vier Thesen zum agilen Requirements Engineering
Als Zusammenfassung möchte ich hier vier Thesen zum agilen Requirements Engineering aufstellen, begründen und gerne diskutieren:
Erste These: Es gibt kein agiles Requirements Engineering für sich alleine. Alle Disziplinen sind gleich agil oder nicht agil, also Requirements Engineering, Design, Entwickeln, Testen, die Architektur, Management in der Form des Lean management, einfach alles.
Zweite These: Der möglich Grad an Agilität hängt von Randbedingungen und Kultur der Organisation ab. Das bedeutet, dass bei Vorliegen bestimmter Randbedingungen die Vorteile der Agilität oder des Lean Thinking durch die Nachteile überschattet werden.
Dritte These: Wenn eine Organisation, oder ein Teil einer Organisation agil / lean ist, wird dieser Teil erheblich effektiver und effizienter, also produktiver, arbeiten als wenn er Dokumenten-lastig und Informationsgetrieben arbeitet – vorausgesetzt natürlich die Randbedingungen lassen das zu (These zwei).
Vierte These: Es existieren zwei Ebenen des Requirements Engineerings in Unternehmen: das operative Requirements Engineering auf Projektebene und das taktische Requirements Engineering auf Produktebene. Das operative Requirements Engineering auf Projektebene kann immer agil Arbeiten ohne dass zwingend die Produktebene agil ist. Das Unternehmen muss jedoch zwingend auf Projektebene agile arbeiten, wenn es auf Produktebene ebenfalls agil arbeiten will.
(Anmerkung): In den Expertengemeinden von Requirements Engineers und Business Analysten gibt es Religionskriege, was eigentlich ein Requirements Engineer ist und was ein Business Analyst. Vielleicht könnten diese Kontextebenen verwendet werden, um die Berufsbilder zu prägen... das ist nur ein Vorschlag (Ende Anmerkung)
Ich denke die erste These ist aus dem bisherigen Talk deutlich geworden. Agilität bedeutet Effizienz in der Wissensarbeit und das bedingt ein anderes Arbeitsmodell, das zwingend alle Disziplinen mit einbezieht.
Die zweite These wird anhand der Extreme klar. Um komplett agil zu arbeiten, über alle Ebenen hinweg, operativ im Projekt, taktisch auf Produktebene und eventuell sogar strategisch, sind permanent zusammen arbeitende Teams notwendig. Diese müssen gut miteinander verzahnt arbeiten und dies sehr diszipliniert und selbst organisiert. Das Management muss permanent in die Teams, in die Zusammenarbeit der Teams und in das Thema Selbstdisziplin investieren. Selbstdisziplin wiederum ist eine Eigenschaft eines im Kontext gut ausgebildeten und motivierten Mitarbeiters.
Sind wir in Organisationen, in denen ein Produkt einfach einmal zwei, drei Jahre liegen bleibt, so hat ein agiles Vorgehen ein Problem zu überwinden. Typisch stirbt ein ruhendes Produkt, wenn das Team sich aufgelöst hat. Eine weitere wichtige Aufgabe des Managements muss es somit sein beständig eine verständliche Vision der Zukunft am Leben zu halten und hoch motivierte Teams beständig in einer Selbsterneuerung zu halten und jedes Produkt beständig zu pflegen. Alternativ kann auch vorab in der Produktstrategie damit umgegangen werden. Eventuell ist es günstiger das Wissen einen Team bewusst zu verlieren und später, nach n Jahren, wieder aufzubauen, als permanent in ein Team zu investieren, nur damit das Wissen (ungenutzt) vorhanden bleibt. Keine leichte Aufgabe hier richtig zu entscheiden. Bei bestimmten Randbedingungen oder bei einer vorhandenen Historie ist agiles / lean Handeln eventuell einfach nicht möglich.
Tatsache ist: Nur in seltenen Fällen bewältigen es bestehende große Organisation (500, 1000, … Mitarbeiter) die Veränderung, den Change in dieses Arbeitsmodell durchzuführen und komplett agil zu werden, um Ihre Produkte oder Services zu erstellen.
Einschränkende Randbedingungen in Organisationen
Die bestehende Kultur und Struktur eines Unternehmens enthalten einschränkende Randbedingungen, die bestimmen ob ein agiles Vorgehen möglich sein kann und Erfolge bringen wird. Typische Randbedingungen sind:
Vorgabe der Ziele Top Down ohne Visionsbildung und Buy-In von Peers, d.h. ein klassischer Top-Down Strategieprozess ohne Einbindung von Kunden und Wissensträgern im eigenen Unternehmen.
Das Fabrikbild der Produktion als Leitbild um Wissensarbeit zu gestalten. Dies einhergehend mit einer Fehlinterpretation, was durch Standardisierung und Spezialisierung möglich ist.
Unflexible Budgetierung
Das Wissen auf taktischer Ebene ist organisatorisch und personell völlig getrennt vom Wissen auf operativer Ebene (der viel besprochene Bruch zwischen Business und IT)
Der Kunde (auch der interne) ist ein externer und nur punktuell einbezogener Stakeholder
Eine sich zu schnell und beständig aus unternehmens- oder personalpolitischen Gründen verändernde Organisation mit Wechsel von Wissensträgern.
Agiles Arbeiten bedingt es auch die Organisation zu einem großen Teil an agilen und lean Prinzipien auszurichten. Der Poolgedanke von Spezialisten im Resourcing, wie der Pool an Requirements Engineers oder Architekten ist ein Widerspruch zum agilen Arbeiten an sich. Die Work Force im Unternehmen muss nach anderen Kriterien aufgebaut, geschult und auf Projekte verteilt werden. Projekte sind unterschiedlich zu schneiden und zu etablieren. Das ist ein erheblicher Wandel für klassische Unternehmen.
Sinnvolles Justieren des "Agilitätsgrades"
Ich habe in dem Talk die beiden Extreme vorgestellt, die komplett Dokumenten-lastige, ineffiziente aber sichere und standardisierte - fast Fabrik hafte Form auf der einen Seite und die komplett agile, hoch effiziente, aber auch mit Risiken für die Gesamtorganisation behaftete Form der Zusammenarbeit.
Ich denke jedem Menschen mit einem gesunden Menschenverstand ist klar, dass die Extreme in Reinform nur in wenigen Fällen vorhanden sein werden. Die Extreme werden an den Randbedingungen scheitern. Also werden sich reale Konstrukte irgendwo in der Mitte befinden. Wenn wir über agiles Requirements Engineering reden, dann ist es die Aufgabe des Managements sich bewusst zwischen diesen beiden Extremen zu positionieren (siehe folgende Abbildung). Es ist die Aufgabe zu entscheiden, wie auf der operativen Projektebene und auf der taktischen Produktebene gearbeitet werden soll.
Abbildung 11: Positionieren Sie Ihre Organisation bewusst zwischen den Extremen
Haben Sie sich als Vertreter oder Mitarbeiter eines Unternehmens schon einmal gefragt, WO Ihr Unternehmen zwischen den beiden Extremen steht? Nehmen Sie sich doch an der Stelle einmal ein paar Sekunden Zeit und überlegen, wo Sie ihr Unternehmen, das Sie lenken oder in dem Sie arbeiten, positionieren würden.
Haben Sie sich schon einmal gefragt WARUM Ihr Unternehmen auf dieser Position steht? Ist das Zufall, Strategie, Firmenkultur oder ein Chef der sagt "so geht's"? Was sind die Gründe?
...und vor allem dieses: Ist in Ihrem Unternehmen die Kultur überall identisch oder muss eventuell pro Bereich des Unternehmens eine andere Position zwischen Dokumentation-getriebenen Management und Wissensmanagement markiert werden?
...und immer hinterfragen: Was ist das Ziel, das mit Agilität und Lean Management verfolgt wird
Ich persönlich kenne keine komplexe Organisation mit Historie, die den Wandel zu agiler Arbeitsweise komplett durchgeführt hat, also auch ein agiles Requirements Engineering in allen Ebenen und in allen Teilen erreicht hätte. Meiner persönlichen Meinung ist das auch nicht das Ziel. Das Ziel einer Organisation sollte sein zu prüfen, ob das agile Arbeitsmodell für diesen oder jenen Teil geeignet ist und die Produktivität steigert. Ziel muss es sein mehr Effizienz bei mindestens gleicher Effektivität zu erreichen.
Ich behaupte mehr Agilität ist in vielen Teilen von Organisationen möglich und ein erheblicher Schritt bezüglich Effizienz und Effektivität. In den Worten des Business ausgedrückt ist der Gewinn „Time 2 Market“ und „Flexibilität“, also das RICHTIGE Produkt zum RICHTIGEN Zeitpunkt.
Begründung der vier Thesen
