Best B&B in south west of Australia

Last evening was just - as the Aussies would say - outstanding.
It is more then a year since I met my old school friend Michi and his wife Birgit. Since years they live in the south western part of Australia in Augusta.
You need a magnifier to find it on the map, so better follow http://augusta.wa.au/. You have to hit the break in time, otherwise you will miss the town. I you managed to stop in time you will find a lovely place to stay - prerequisite is that you love small villages at the far end of the road...
Nevertheless, if you plan to stop there, take the chance for an overnight stop in the private room old friend Michi and his wife Birgit are offering, see http://www.airbnb.com/rooms/27046

There is wale watching from the veranda, windsurfing in the Blackwood River or offshore in Flinders Bay (no sharks, no no, never...onla wales and dolphines) and be sure a friendly welcome and a thousand tales...

As Michi and Birgit are world travelers there is a chance to rent that house for two or three months a year. Just ask them...

So - hit the road jack and don't you come back no more, no more, no more, no more....

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.

Agile RE Blog 4: Informationen miteinander vernetzen und zugänglich machen

Betrachten wir doch einmal das „ganz normale Projekt“ unter dem Aspekt Wissensmanagement und sehen wir uns die Eigenschaften von Wissen in diesem Zusammenhang an.

Die erste Eigenschaft von Wissen war: Informationen miteinander zu vernetzen und zugänglich zu machen. Nun könnten wir in den Raum stellen eine qualitativ gute Dokumentation (RE-Spez, Architekturdokument, …) erfüllt dies. Eine gute und qualitativ hochwertige Requirements Spezifikation enthält im Idealfall richtige Anforderungen und diese in korrekter Art und Weise beschrieben. Die Traceability zwischen den Anforderungen sichert die Vernetzung der Informationen zu. Wenn die Dokumentation nun auch jedem zugänglich ist, etwa auf einem Projektshare oder in einem Tool, dann ist diese auch verfügbar.

Genau an diesem Punkt möchte ich einhaken. Denken wir an ein X-beliebiges Projekt und stellen uns die wirklich absolut perfekte Requirements Spezifikation vor (I had a dream):

• Sind in dieser Requirements Spezifikation alle notwendigen Informationen enthalten, um ausgehend alleine von dieser Dokumentation das komplette benötigten Produktwissen ohne Verlust zu erarbeiten und das Projekt weiter voran zu treiben?
• Sind darin alle notwendigen Vernetzungen der Informationen in Form von Traces abgelegt, die benötigt werden, um das Projekt erfolgreich abzuwickeln?

Und gehen wir noch einen Schritt weiter und verweben die Disziplin des Requirements Engineering mit den anderen Disziplinen, die notwendig sind, um das Projekt abzuwickeln:

• Ist es möglich das komplette Wissen eines Projekts als Informationen in Dokumente zu gießen, also nicht nur das notwendige, sondern auch das hinreichende Wissen?
• Ist es möglich alle notwendigen und hinreichenden Vernetzungen in Form von Traces zu dokumentieren?

Die Antwort ist ein klares NEIN. Um dieses klare NEIN zu bestätigen dient das folgende Gedankenexperiment: Stellen Sie sich zwei Teams vor, die völlig unabhängig voneinander diese perfekte RE-Spec in die Hand bekommen und das Produkt erstellen. Wenn Sie völlig überzeugt sind, dass die von den beiden Teams unabhängig voneinander erstellten Produkte VÖLLIG IDENTISCH sein werden, dann gilt das nein nicht...

Sinnvoller Weise ist Dokumentation aus Aufwandsgründen beschränkt. Zudem enthält eine Dokumentation kein Wissen, sondern lediglich die Informationen, mit denen ein Wissen aufgebaut werden kann.  Also – und auch dies ist eine ganz wichtige und anerkannte Tatsache: Dokumentation hält nur Informationen und die Dokumentation eines Produkts enthält nur einen Teil der Informationen, die notwendig sind, um das komplexe Problem, das mit dem Erstellen des Projekt verbunden ist, erfolgreich zu lösen.

Die spannenden Fragen sind: Wo kommt der Rest der Informationen her, die ein Projekt benötigt? Wie werden alle Informationen, also die in der Dokumentation enthaltenen Informationen und die „restlichen“ nicht in der Dokumentation zu findenden Informationen in Wissens verwandelt um ein Projekt erfolgreich durchzuführen?

Die Antwort ist einfach: In den Köpfen des Teams, das an dem Projekt arbeitet. Woraus sich die nächste spannende Frage ergibt: Wie ist das Wissen in die Köpfe gekommen? Etwa nach dem Prinzip wie in dem Movie MATRIX: Wir setzen den Mitarbeiter in einen Stuhl, er bekommt ein Stecker in den Kopf gesteckt und wir laden die beiden Programme „So sieht das Produkt aus“ und „So werden wir das Projekt in unserem Unternehmen abwickeln“!!

In der Realität gibt es genau zwei Methoden: Entweder die Menschen nehmen explizit an einer Ausbildung teil, oder sie bilden sich explizit (Coaching) implizit (Learning on the job, Trainee Programme) untereinander weiter. Ausbildung ist sinnvoll, um fehlendes Wissen in die Organisation zu tragen. Coaching und Learning on the job funktioniert, wenn das Wissen bereits in Köpfen der Organisation steckt und „lediglich“ weiter verbreitet werden soll (an dieser Stelle kann übrigens das Dreyfus Modell des Wissenserwerbs sehr gut heran gezogen werden). Gemeinsam ist: Wissensaufbau bedeutet Lernen. Moderne Lernformen im professionellen Umfeld bauen zudem auf selbstmotiviertes Lernen in Lerngruppen mit dem Lehrenden als Coach. Kommunizieren zum Wissensaufbau, Anwenden des Wissens und direktes Feedback anhand der Resultate der Anwendung sind Schlüssel, um Wissen, das nicht über Dokumentation erworben werden kann in die Köpfe der Mitarbeiter zu bringen und dort zu verankern.

Als Fazit stellen wir fest: Kommunikation und Feedback sind wesentliche Grundprinzipien um Wissen im Projektteam zu verbreiten und zu verankern. Wenn wir es schaffen Kommunikation und Feedback in einem Projekt zu optimieren, dann beschleunigen wir den Wissenserwerb und damit die Effizienz. Und schon bekommen Daily Standups, Reviews und Retrospektiven wie sie Scrum zum Beispiel kennt, einen ganz unverhofften und erweiterten Sinngehalt, ach ja, übrigens auch die Kaffeepause morgens um 10:30 oder das (alkoholfreie ;-) Feierabendbier. Das Feierabendbier als Mittel der Effizienzsteigerung, Wow!
Nach einem Glas Feierabendrotwein, welches ich heute nicht zum Wissenserwerb nutze, werde ich im nächsten Blog das Anwenden von Wissen betrachten.

Agile RE Blog 3: Requirements Engineering ist Wissensarbeit

Nun zum Thema Agilität: Organisationen verfolgen unter dem Stichwort Agilität typisch die Ziele einer verkürzten Time to Market und der verbesserter Flexibilität gegenüber Änderungen im Geschäftsmodell durch äußere oder innere Einflüsse. Wenn wir auf die bisherigen Erkenntnisse reflektieren, so ist eine wichtige Maßnahme den Wissenserwerb und den Wissenserhalt effizient zu gestalten. Einzelne konkrete Maßnahmen dazu stehen schon im agilen Manifest, das seit 15 Jahren auf dem Internet zu finden ist. Wir erinnern uns:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Neben anderen Zielen (das agile Manifest entstand aus dem Bestreben den Mensch, anstatt den Prozess, in den Mittelpunkt zu stellen) adressieren diese Maßnahmen genau das Ziel den Lernprozess im Team zu optimieren, um die Wissenslücken des komplexen Problems zu erarbeiten und zu füllen. Interessant ist diese einmal andere Sicht auf das agile Manifest.

Nun ist es notwendig den viel verwendeten Begriff „Wissen“ im Kontext der Arbeitswelt zu verstehen, denn Requirements Engineering beschäftigt sich wesentlich mit dem Aufbau von Wissen im Unternehmen Interessante Fragen sind:

• Was ist denn Wissen eigentlich?
• Wie manifestiert sich Wissen in einer Organisation?
• Und zur Unterstützung der taktischen und operativen Ebene im Unternehmen: Kann Wissen geschaffen, bewahrt und konserviert werden und wenn ja, wie?

Wissen im Kontext der Arbeitswelt wird nach aktueller Auffassung (siehe [Wiki-1] und [HDM-1]) über drei wesentlichen Eigenschaften definiert und in zwei Formen eingeteilt. Die drei Eigenschaften von Wissen sind:

1. Es sind dazu  INFORMATIONEN als Wissensinhalte miteinander zu vernetzen und zugänglich zu machen
2. Es gilt einen NUTZEN aus dem Wissen zu ziehen, das bedeutet das Wissen ANZUWENDEN
3. Wissen hat nur eine Bedeutung in einem SOZIALEN KONTEXT, in dem das Wissen zur Verfügung gestellt wird. Das Wissen hat somit nur in einer Gruppe von Menschen eine Bedeutung, die in einem gemeinsamen Kontext, wie zum Beispiel in einem Projekt, stecken.

Abbildung 5: Die drei wesentlichen Eigenschaften von Wissen

Die existieren zudem zwei Formen von Wissen:

1. Explizites Wissen: Wenn eine Person klar und strukturiert, wie eine Formel oder ein Beweis, eine Antwort auf eine Frage- oder Problemstellung geben kann, dann handelt es sich um explizites Wissen
2. Implizites Wissen: Wenn eine Person eine (zumeist korrekte) Handlung oder Entscheidung trifft, deren Herleitung sie nicht eindeutig und klar beschreiben kann, eventuell nicht einmal die Hintergründe der Handlungsweise aufzeigen kann. Beispiele dazu sind vielfach vorhanden und belegt, so etwa Diagnosen von Ärzten anhand von Krankheitsbildern und Symptomen, die keinen direkten Rückschluss erlauben.

Implizites Wissen wird oft auch als Bauchgefühl oder Intuition bezeichnet. Der Begriff des impliziten Wissens ist anerkannt und kann belegt werden (siehe Abbildung 6).

Es werden deutlich mehr Entscheidungen und Handlungen über implizites Wissen abgewickelt, als wir vermuten würden. Das ist auch gut so, das genau ist nämlich ein Grundpfeiler für Effizienz. Eine korrekte implizite Handlung oder Entscheidung steigert die Effizienz. Es müssen nicht erst Informationen aufgenommen und analysiert werden und mittels eines expliziten Wissens daraus Schlüsse gezogen werden. Dieser explizite Prozess würde zwar oft funktioniere, er ist jedoch bei weitem weniger effizient. In vielen Fällen würde der explizite Prozess auch nicht funktionieren, da es nicht gelingt die Entscheidungsfindung oder Handlungsmotivation zu beschreiben, da die herangezogenen (impliziten) Kriterien selbst dem Fachmann nicht im vollem Umfang bewusst ist.

Gott sei Dank beherrschen wir als Menschen den Umgang mit implizitem Wissen, stellen Sie sich vor, Sie müssten vor jeder Email, die Sie schreiben eine Anleitung herausholen. Dieser Anleitung entnehmen Sie die korrekte Anrede, anschließend Textbausteine zur Einleitung in das Thema, Textbausteine zur Beschreibung ihres Problems (hier wird es schon schwer) und dann noch den Textbaustein für die Abschlussformel und so weiter... Ich nehme an nach 10 Emails würden Sie streiken... Nun gut, es gibt Leute, die damit ihren Tag füllen…

  

Abbildung 6: Implizites Wissen (=Bauchgefühl) ist ein Fakt und wertvoll

Nehmen wir ein konkretes Beispiel für das effiziente Wirken von impliziten Wissen aus dem Requirements Engineering: die Entscheidung über die Klassifizierung von Anforderungen, zum Beispiel welchen Abstraktionslevel eine Anforderung einnimmt (ist es ein Business Requirement, ein Produkt Requirement, ein User Requirement oder etwas technisches, ist es schon eine User Story oder doch eher noch ein zu verfeinerndes Epos).
 
Die im Kopf für diese Einteilung vorgenommenen Erfahrungen und Kriterien kann wohl niemand einfach ad hoc auf ein Papier schreiben. Stellen Sie sich vor, sie müssten mit einer Gruppe Experten einen Kriterienkatalog aufstellen, dessen Anwendung die Klassifizierung eines Requirement liefert. Einmal abgesehen, ob das Sinn macht, bestimmt würde in diese Selbstbeschäftigung ein Personenjahr Arbeit investiert werden, um überhaupt zu einem Konsens über die Kriterien zu finden. Dennoch sind solche
 
Entscheidungen bei Ingenieuren, die Requirements Engineering auf dem Level Experte beherrschen, hoch effizient, schnell und mit hoher Trefferquote. Entscheidungen dieser Art stehen in Projekte vielfach an – und das übrigens nicht nur im Requirements.

Die drei Eigenschaften von Wissen (siehe Abbildung 5) geben einem Team auch eine ganz neue Bedeutung und zwar aus der Sicht des Wissensmanagements.  Das wird Inhalt meines nächsten Blog Eintrages sein.

Agile RE Blog 2: Das Ökosystem des Projekts

Im letzten Blog haben wir den Kontext aufgebaut und das Requirements Engineering ist in dem Kontext positioniert. Es ist geklärt, welche Aufgaben Requirements Engineering hat: Taktisch die RICHTIGEN Produkt zum RICHTIGEN Zeitpunkt für Markt definieren im Produktportfolio und die detaillierte wirtschaftliche Ausarbeitung der Eigenschaften des RICHTIGEN Produkts – unter Beachten der organisatorischen und technischen Randbedingungen – in Projekten als operative Ebene der Organisation.

Nun ist noch in keinem Satz das Wort „AGIL“ vorgekommen. Es wird also Zeit sich diesem Punkt zu nähern.

Dazu möchte ich die kleinere Einheit an, das Projekt unter die Lupe nehmen. Ich gehe davon aus, dass es das Produkt schon gibt, was wohl der Regelfall sein wird. Das Projekt dient also der Überführung des bestehenden Zustandes des Produkts in den neuen Zustand des zu DIESEM ZEITPUNKT RICHTIGEN Produkts.

Bei einem Projekt handelt es sich um ein zeitlich begrenztem Ökosystem, das ein mehr oder weniger klar definiertes Ziel (eine Vision) erreichen will (in die Realität umsetzen will). Umgangssprachlich bedeutet dies: Ein Team von Leuten arbeitet an einem Produkt, welches einer oder mehreren Benutzergruppen anschließend zur Nutzung übergeben wird. Das Team, welches das Produkt erstellt, ist in einem sozialen Kontext in die Umgebung eingebunden, in der das Produkt geschaffen wird. Dieser soziale Kontext hat eine enge Wechselwirkung auf das Team und somit auch auf das Ergebnis des Teams, also dem Produkt. Mit einem Wort, das Team und die Einbettung des Teams im Kontext der Organisation (mit Kunden, mit Abteilungen wie Marketing oder Operations oder dem Chef selbst) spielt eine große Rolle für eine erfolgreiche Projektarbeit.

Nun ist es eine Aufgabe des Requirements Engineering diesen Kontext zu untersuchen und die Wechselwirkungen zwischen dem zu schaffenden Produkt und dem Kontext herauszufinden. Das hilft und die RICHTIGEN Eigenschaften im Detail zu erkennen und – über Beachten der Randbedingungen – den TCO zu erhöhen. Im Requirements Engineering werden dazu Stakeholder abgeholt, andere Informationsquellen angezapft und alles miteinander verknüpft und vernetzt und es muss damit umgegangen werden, dass sich das Ziel des Projekts (die Vision) während dem Arbeiten verändert.

Nach allgemeiner Auffassung der Forschung [Dir2011] entsprechen diese Eigenschaften (viele Stakeholder, viele Informationsquellen, viele Abhängigkeiten, moving Target) der Definition eines komplexen Problems. Abstrakt formuliert beschäftigt sich ein Projekt mit dem Lösen einer komplexen Problemstellung (siehe Abbildung 3). Dazu kann nach allgemein annerkannter Auffassung der Forschung [Dir2011] kein mechanisches Fertigungsverfahren eingesetzt werden, wie zum Beispiel zum Herstellen von Hamburgern (Brötchen, Hackfleisch, Majo, Ketchup, Gurke, Salat in definierten Arbeitsschritten zusammen pappen). Um eine komplexe Problemstellung zu lösen bedarf es Wissensarbeiter, die in einer möglichst effizienten Art und Weise zusammenarbeiten und mit Wissen arbeiten beziehungsweise sich Wissen erarbeiten.

 

Abbildung 3: Produkte über Projekte erstellen und verbessern bedeutet das Lösen eines komplexen Problems

Um das Produkt von einem Zustand in den nächsten Zustand zu überführen, wird also Wissen benötigt und es werden Fähigkeiten benötigt, das Wissen zu erarbeiten und mit dem Wissen zu arbeiten. Wesentliche Teilaspekte des Wissens sind hierbei:

1. Das Wissen um die Eigenschaften und Fähigkeiten, welche die aktuelle Version des Produkts besitzt und das Wissen um die Eigenschaften und Fähigkeiten, welche das neue Produkt in Zukunft besitzen soll è Produktwissen also
2. Das Wissen und die Fähigkeiten, wie das Produkt entwickelt wird und produktiv gesetzt wird è das Wissen, um das Vorgehensmodell, also Prozesswissen.

Mit den Eigenschaften und Fähigkeiten des Produktes an sich beschäftigt sich genau das „Hilfsmittel“ Requirements Engineering. Wesentlich für einen Projekterfolg sind jedoch ebenso die Fähigkeiten, WIE das Produkt entwickelt wird, also auch WIE das Hilfsmittel Requirements Engineering eingesetzt wird. Beide Aspekte spielen untrennbar zusammen.

Eine wesentliche Eigenschaft der Wissensarbeit zum Lösen einer komplexen Problemstellung ist, dass bei Start eines Projekts das Wissen noch nicht vollständig, oft sogar nur sehr rudimentär vorhanden ist – was genau ein Problem zu einem komplexen Problem macht. Das Projektteam besitzt in keinem Fall das volle Wissen über die Eigenschaften und Fähigkeiten des zukünftigen Produkts, sondern nur eine mehr oder weniger klar umrissene Vorstellung davon. Es ist ja gerade Aufgabe des Requirements Engineering dies im Projekt zu präzisieren. Das Projektteam besitzt jedoch genauso wenig das volle Wissen, wie das Produkt entwickelt wird, da die Stakeholder eventuell unbekannt sind (wie sollen wir also mit diesen zusammen arbeiten), ebenso wie das Testen (was können wir Automatisieren und wo brauchen wir noch den Mensch im Testen), aber auch der Vorgang des Deployments und viele andere Details. Zudem ändert sich alles dies auch noch im Verlauf der Projektarbeit.

Abbildung 4: Das Ökosystem Projekt löst das gestellte Problem wirtschaftlich

Ganz allgemein kann gesagt werden, dass am Anfang eines Projekts das Wissen nicht ausreichend geschweige denn vollständig vorhanden ist und vom Team erst erfahren und gelernt werden muss. Das notwendige Wissen, um das Problem des Projekts zu lösen, hat erhebliche Lücken in jeder Hinsicht. Eine wesentliche Aufgabe eines Projektteams ist es diese Wissenslücken zu füllen. Das gilt für Lücken im Domänenwissen, ebenso wie für fachlich- technisches Wissen und für das Prozesswissen.

Das klingt alles so Abstrakt, also möchte ich hier ein paar Beispiele aus meiner persönlichen Erfahrung wiedergeben (anonymisiert):

In einem Projekt erstellte unser Team ein Planungssystem für Zugfahrten. Zum Domänenwissen gehört zum Beispiel dass die im Kursbuch stehenden Zeiten für Ankunft und Abfahrt nur für den Bahnkunden relevant sind. Intern, im Führerstand der Lokomotive zum Beispiel gelten durchaus andere Zeiten, die im sogenannten technischen Fahrplan für den Lokomotivführer stehen. Nur wenige alte Hasen im Projektteam hatte vor dem Projekt überhaupt eine Ahnung, dass es hier unterschiedliche Sichten gibt. Erst das Arbeiten mit den Fachleuten brachte diese Erkenntnis für alle.

Technisches Wissen beschäftigt sich zum Beispiel mit der Build- und Deployumgebung, also mit dem Stagingprozess eines Produkts bis es schließlich für die Produktion freigegeben ist. Eine internationale Bankingsoftware muss für jedes Land durch die Abnahmetests der dort geltenden gesetzlichen Regelungen gejagt werden, bevor die Software dort die Freigabe zur Produktion erhält. Ich wusste zum Beispiel lange Zeit nicht, dass unter anderem gefordert werden kann, dass gewisse Daten physikalisch in einem Land abgespeichert sein müssen, also zum Beispiel nicht in einer Amazon Wolke sein können, die irgendwo schwebt. Die Durchführung von Abnahmetests muss die Verfügbarkeit von Testdaten berücksichtigen.

Organisatorisches Wissen setzt dem Projekt Randbedingungen, in welchem die Entwicklung abläuft. Bei einem bestimmten Kunden zum Beispiel darf ein Projekt aus organisatorischen Gründen erst mit einer neuen Phase anfangen zu arbeiten, wenn die vorhergehende Phase in einem offiziellen Review als erfolgreich abgenommen gilt. Ich habe es selbst erlebt, dass Projekte in der Review Phase zu zwei Wochen Stillstand verurteilt waren. Das war mir bei Start des Coaching eines Projektteams in dieser Organisation nicht bewusst und – ganz ehrlich – ich hätte es vorher auch nie geglaubt. Dieser Fall ist schon ein Hinweis für mögliche Ansatzpunkte von mehr Agilität.

Fassen wir die bisherigen Erkenntnisse zusammen:

1. Das Ziel einer Organisation ist es das RICHTIGE Produkte zum RICHTIGEN Zeitpunkt herzustellen
2. Ein Produkt oder die bessere Version des Produkts wird über ein Projekt erstellt
3. Ein Projekt ist ein soziotechnisches Ökosystem
4. Ein Projekt startet mit einem komplexen Problem zu dessen Lösung sich das Projektteam Wissen erarbeiten muss, da Wissenslücken jeder Art vorhanden sind.
5. Das Wissen fällt in die beiden Kategorien:
   a. Wissen WIE das Produkt gebaut werden soll, das Prozesswissen
   b. Wissen, WAS das Produkt können soll, hierzu setzen wir als Hilfsmittel Requirements Engineering ein

Dieser Blog hat uns also die Erkenntnis gebracht, dass Projektarbeit Wissensarbeit ist. Ein Projektteam ist eigentlich eine Art Lerngruppe. Ein Projektteam ist dann erfolgreich, wenn es sich effizient die richtige Menge Wissen erarbeitet und dieses effizient zum Bau des Produktes einsetzt.