Agile RE Blog 5: Das Wissen anwenden

Die Eigenschaft zwei von Wissen war Nutzen aus den zu Wissen verknüpften Informationen zu ziehen. Nutzen aus den Wissensinhalten zu ziehen, bedeutet das Wissen anzuwenden. Irgendetwas anzuwenden, also eine Aufgabe durchzuführen,  bedeutet automatisch einem Prozess zu folgen. Ein Prozess ist definiert über die Definition von Rollen (die von Mitarbeitern temporär oder permanent eingenommen werden), die Definition von Tätigkeiten, welche eine bestimmte Rolle ausübt (die hierbei bereits bestehende Arbeitsergebnisse verwendet), und die Definition der Arbeitsergebnisse, welche über eine Tätigkeit entstehen. Zusätzlich werden die Tätigkeiten durch die Definition von Workflows in eine zeitliche Folge gebracht.

Beispiel: Hans Müller kommt morgens in die Firma und setzt – weil er immer der erste ist – den Kaffee für alle auf, die in den nächsten 15 Minuten auch eintreffen werden. Er nimmt also die Rolle des Teamsupporters ein, er übernimmt Verantwortung für das Wohlbefinden des Projektteams und produziert über die Tätigkeit Kaffeekochen das Artefakt Kaffee. Danach nimmt er sich die Notizen des gestrigen Interviews mit einem Stakeholder vor und erarbeitet daraus Use Cases oder User Stories. Hans Müller arbeitet nun in der Rolle des Requirements Engineers und erzeugt als Artefakt einen Teil der RE-Spec.
Das interessante ist nicht der Prozess an sich, in dem Hans Müller arbeitet. Interessant ist die Entstehungsgeschichte des Prozesses, also der Lernprozess den Hans Müller durchlaufen hat, so dass er weiß, wie er als RE diese Tätigkeit zu verrichten hat. Woher nimmt er die Interviewnotizen, wie transformiert er diese Notizen in Use Cases und woher weiß er den Ablauf und die einzelnen Schritte dieser Transformation eines Interviews in Use Cases.

Sehen wir dazu ein zwei Beispielszenarien an:

Szenario 1: Die Firma folgt einem reifen und dokumentierten Prozessmodell (z.B. V-Modell nach CMMI Maturity Level 3). Es existiert die ausführliche Prozessdokumentation, in der alle Rollen, deren Tätigkeiten mit deren Abfolge und Abhängigkeiten, die eingehenden und erzeugten Artefakten einschließlich Temples vollkommen beschrieben sind. Hans Müller hat 20 Tage Schulung erhalten, welche ihm diesen Prozess in der Theorie gelehrt hat. Im Projekt hat er die stellenweise – oder auch komplett – abweichende Anwendung des Prozesses gelernt. Coach waren seine Kollegen. Dass der Prozess – zumindest formal – eingehalten wird, dafür sorgen die regelmäßigen Prozessreviews durch die Q-Abteilung. Zumindest wird der Q-Abteilung immer die Einhaltung des Prozesses vorgeführt. Es soll hierbei auch schon zu Schattenwirtschaften und U-Booten in Unternehmen gekommen sein...

Interessant ist zu verfolgen, wie das Wissen bei Hans Müller in Szenario 1 entstanden ist. Zuerst wurde der Prozess durch andere entworfen. Diese anderen besitzen hierbei nicht unbedingt das Wissen um den optimalen Prozess, da sie ja selber den Prozess nicht leben und ihn nur indirekt vermittelt bekommen. Diese Experten der Prozessbeschreibung legen die Ihnen wichtig erscheinenden Informationen in Dokumenten ab. Diese Informationen werden von einem Trainer aus den Dokumenten geholt und über eine Schulung in theoretisches Wissen im Kopf von Hans Müller umgewandelt. Das ist eine Art stille Post (wir kennen das Spiel aus der Kindheit, in dem ein Wort im Kreis von Ohr zu Ohr geflüstert wurde). Was die Prozessgruppe im Kontext Prozessdefinition entworfen hatte unterscheidet sich zu dem, wie es der Trainer im Kontext Schulung interpretiert und zu dem, wie es Hans Müller versteht. Diesen Unterschied glättet die Realität des Projekts, das heißt das try and error im täglichen Leben und die konkrete Projektarbeit mit Kollegen. Also auch wieder Coaching und Lernen im Kontext und im Team.

Interessant ist auch das Verfahren einer Prozessverbesserung: Hans Müller und ein paar seiner Kollegen stellen fest, dass ein anderer Ablauf, etwa der Einsatz von User Stories statt Use Cases, in dem Projekt besser wäre. Nun haben sie zwei Möglichkeiten: Die erste ist die Prozessverbesserung einzureichen und zu warten, bis diese offiziell wird. Die zweite ist einfach die Prozessverbesserung im eigenen Projekt durchzuführen. Das ist ok, solange die Leitplanken nicht überschritten werden, die der Standardprozess aufstellt (erlaubtes Tailoring des Prozesses). In konkreten Fall muss es erlaubt sein User Stories zu verwenden anstatt Use Cases. Oft werden die Leitplanken jedoch auch überschritten - manchmal unbemerkt, manchmal bewusst. Die Folge des bewussten Übertretens ist ein U-Boot Prozess, der nach außen Compliance vortäuscht. Doppelarbeit in der Prozessabwicklung ist vorprogrammiert, der optimale Prozess wird intern im Projekt gefahren und der vorgeschriebene Prozess nach außen vorgetäuscht. Perfektes Szenario von Effizienzkillern.

Szenario 2: Hans Müller nimmt sich die Notizen von gestern vor, um die im Meeting mit Product Owner und Fachexperten aus dem Fachbereich besprochenen User Stories weiter zu bearbeiten. Das Team hat in der letzten Retrospektive beschlossen, dass es sinnvoll ist erst einen Low fidelty paper based GUI Prototypen zu designen und mit diesem zusammen nochmals Ablauf und Akzeptanzkriterien mit dem Fachbereich zu prüfen. Erst wenn die Akzeptanzkriterien stehen, wird mit der Implementierung begonnen und zwar mit der Entwicklung der automatisierten Akzeptanztests. Diese Aufgabe wird gemeinsam in einem RE-Workshop im Sprint durchgeführt. Die einzigen Randbedingungen des Unternehmens sind in einer sehr dünne Prozessdefinition, die wesentlich Synchronisationspunkte zwischen Projekten und weiterhin übergreifende Done Kriterien für ein Deployment vorgibt.

In Szenario 2 ist klar, wie der Prozess entstanden ist. Ausgehend von einem (hier unbekannten, allerdings interessant zu diskutierenden Startpunkt) hat sich das Team einen Prozess erarbeitet und kommuniziert. Dazu dienen die Retrospektiven. Qualitätskriterien wurden auf diese Weise definiert und diese zu den Done Kriterien hinzugefügt, in die übrigens auch der Q-Beauftragte der Firma seinen Input liefert. Das Team trägt viel mehr implizites Wissen mit sich, als in Szenario 1.

Hier sind wir nun am Punkt des effizienten Arbeitens im agilen Kontext. Die Feedbackschlaufen und Retrospektiven, die fester Anker agilen Arbeitens sind, schaffen genau die Lernatmosphäre, die dem Wissenserwerb dient und eine effiziente Anwendung des Wissens ermöglicht durch beständige Verbesserung des aktuell eingesetzten Prozesses. Sehr viel des Wissens – sowohl des Produktwissens, als auch des Prozesswissens – ist hierbei als implizites Wissen verankert, also in der effizienten Form der Wissens. Auch der geforderten Flexibilität ist Rechnung getragen, da der beständige Lernprozess die Anpassung des Wissens an einen sich verändernden Kontext in sich als Grundwert verankert hat.

Der Bogen zwischen Requirements Engineering und agilem Arbeiten ist somit geschlagen – allerdings erst im Kontext des Projekts. Dies ist jedoch erst die halbe Wahrheit. Die taktische Ebene des Requirements Engineering ist noch nicht analysiert worden in Bezug auf Effizienz und Flexibilität. Hier herrscht noch kein Zusammenhang mit agilem Arbeiten. Das nächste Blog beschäftigt sich mit dieser Ebene.