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.

Agile RE Blog 1: Was ist Requirements Engineering

Ich fange mit auf dem Allgemeinplatz an, als Einstieg, sozusagen in der Komfortzone. Dieser Allgemeinplatz ist die Frage, was ist Requirements Engineering eigentlich?!

Ich mir sicher bin, dass ich bei 100 Experten dazu 200 verschiedene Antworten bekomme. Das nutze ich, die meine einfache Antwort im Kontext des Themas zu geben. Diese lautet: Requirements Engineering ist ein Hilfsmittel, wenn auch ein sehr wichtiges Hilfsmittel. Requirements Engineering ist eines der Hilfsmittel, um ETWAS zu erschaffen. Dieses ETWAS ist in der kommerziellen Welt typisch ein Produkt (wie ein Handy, Auto oder eine käufliche Software), ein Service (wie Bankkonto, Telephonie, Internetanschluss oder Cloud Service), eine Dienstleistung (Hausverwaltung, Consulting oder Kundendienst) oder eine Mischung aus all dem.

Abbildung 1: Das Produkt steht im Mittelpunkt, Requirements Engineering ist ein Hilfsmittel

Das Produkt - ich sage im Weiteren vereinfachend für alles dies Optionen - ist der Gegenstand unseres eigentlichen Bestrebens. Damit verdienen wir unser Geld. Also ist es besser als nur ein Produkt zu erschaffen, dieses mit möglichst niedrigen Total Cost of Ownership (TCO) zu erschaffen.

Requirements Engineering ist also ein HILFSMITTEL, um ein vom Markt verlangtes Produkt zu erschaffen und dies in einer Art und Weise, dass die Ideenfindung dazu, die Herstellung und der Verkauf, eben die TCO, billiger sind als der Erlös.

Dieses "in einer Art und Weise" ist nun genau der springende Punkt. Gute Produkte (oder Services oder Dienstleistungen) sind diejenigen, die mit den richtigen Eigenschaften zum richtigen Zeitpunkt auf dem Markt kommen. Nehmen wir an, wir haben bereits ein Produkt - oder auch zwei oder mehrere Produkte zum Verkaufen in unserer Organisation, die wir am Markt anbieten.

Nun ist klar, dass „Morgen“ die Produkte anders aussehen müssen, wir müssen sie umbauen oder erweitern, damit sie attraktiv bleiben. Wir müssen eine neue Version der Produkte erstellen. Diese Erkenntnis ist trivial. Das typische Gefäß, um Produkte zu erstellen oder zu erweitern sind Projekte. Ein Projekt ist laut Definition eine temporäre Organisationsform, um einen bestehenden Zustand, in dem Fall den Zustand des Produkts (ein Projekt kann auch andere Dinge treiben als Produkte) in einen neuen Zustand zu überführen. Wir haben somit ein oder mehrere Projekte, um von einem Produkt eine neue Version zu bauen oder auch ein komplett neues Produkt zu erschaffen. Irgendwo rund um oder in das Produkt und Projekt stecken wir auch das Hilfsmittel Requirements Engineering hinein, die notwendig ist, um die neue Version des Produkts zu erschaffen.
Ich möchte an der Stelle wiederholen: ein „GUTES PRODUKT“ bringt die richtigen Eigenschaften zum richtigen Zeitpunkt an dem Markt. Eine erfolgreiche Organisation kümmert sich aktiv um diese beiden sehr abstrakten Eigenschaften „RICHTIGE EIGENSCHAFTEN“ und „RICHIGER ZEITPUNKT“. Wichtigen Eckpfeiler dafür ganz am Anfang Innovationsprozesse mit der Identifikation der Produkte, dann die Definition unseres Produktportfolios und die darauf abgestimmte Release Planung. Mit der Release Planung entstehen die Projektportfolios als ausführende (operative) Ebene unterhalb der Produktportfolios. Aus Sicht der Organisation ist die Definition des Produktportfolios die strategische Ebene, das Management und Releasemanagement des Produktportfolios die taktische Umsetzung der Strategie und die Projekte die operative Ausführung von Strategie und Taktik(Regieanweisung: Grafik erweitern).

Die strategische Ebene lasse ich im Weiteren einfach unberücksichtigt. Die taktische Ebene, also das Management des Produktportfolios mit Releaseplanung der Produkte und die damit verbundenen Aktivitäten, das alles ist wichtig jedoch wichtig für die weiteren Überlöegungen. Darin steckt Requirements Engineering und die Chance zur Agilität. Denn Requirements Engineering beschäftigt sich mit den Eigenschaften, die sich bereits in den Produkten befinden und auch mit den Randbedingungen unter denen sie erstellt und eingesetzt werden, wie zum Beispiel regulatorischen Auflagen. Requirements Engineering arbeitet mit dem Innovationsprozess in Form neuer Ideen, welche als neue Anforderungen Eingang finden für kommende Produktversionen. Requirements Engineering arbeitet mit der Marketingabteilung, mit Kunden und / oder mit dem Kundendienst. Requirements Engineering betrachtet die Randbedingungen der Technik und der Erstellungsprozesses, um wirtschaftliche Aspekte zu beachten und den TCO zu optimieren.

Wir haben nun das Bild, wo Requirements Engineering im Kontext der Überlegungen zu finden ist. Wir bewegen uns also noch in der Komfortzone und haben den Einstieg in den nächsten Schritt erarbeitet.

Abbildung 2: Das Ökosystem der Produktentwicklung mit strategischer, taktischer und operativer Ebene

Wenn wir nun das Ökosystem der Produktentwicklung (siehe Abbildung 2) betrachten, dann fallen zusammen fassend zwei Dinge ins Auge:

1. Es existiert eine Ebene oberhalb des Projekts, die Ebene des Produktportfolios (auch, wenn sich darin nur ein einziges Produkt befinden sollte). Auf dieser Ebene müssen taktische Entscheidungen getroffen werden, wie sich die Produkte weiter entwickeln sollen, oder welche neuen Produkte benötigt werden. Die Release Roadmap mit resultierendem Projektportfolio ist die taktische Umsetzung des strategischen Produktmanagements. Das Bewirtschaften (Management) eines Produktportfolios ist ein kontinuierlicher Prozess, welcher Marktbedürfnisse, Innovationen, den Zustand meiner Organisation und kommerzielle Randbedingungen gegeneinander abgleicht. All das benötigt ein gutes Maß an Requirements Engineering, welches dafür sorgt, dass unsere Organisation das RICHTIGE Produkt zum RICHTIGEN Zeitpunkt am Markt verkaufen kann. (ANMERKUNG: An der Stelle kann gestritten werden, ob es sich um Requirements Engineering handelt, oder ob das ein Teil der Business Analyse oder ein beliebiger anderer Begriff ist. Wenn wir uns die benötigten Fähigkeiten und in die ausgeführten Tätigkeiten der Personen ansehen, welche hier aktiv werden, so sehen wir, dass diese zu einem hohen Grad deckungsgleich mit Requirements Engineering sind. Ich nenne es daher einfach Requirements Engineering).
2. Es existiert die operative Umsetzungsebene der Produktreleasemap, die Projekte. Diese Projektebene, eben das Projektportfolio spielt zu definierten Synchronisationspunkten mit der Prozessebene des Produktmanagements eng zusammen. Ein wesentlicher Aspekt fällt hierbei sofort auf: Die taktische Ebene und die operative Ebene verwenden Informationen und Wissen, dass in beiden Ebenen entstanden sein kann und transparent zwischen den Ebenen wandern können muss. Ich denke zumindest auf dieser Ebene sind wir uns einig, dass es sich um Requirements Engineering handelt.

Zusammenfassend stellen wir fest, dass RE in der taktischen Ebene und in der operativen Ebene steckt. Beide Ebenen müssen eng miteinander zusammenarbeiten. Requirements Engineering ist ein wichtiges Bindeglied in der Kommunikation zwischen den beiden Ebenen, eine Schlüsseldisziplin, also eines der wirklich wichtigen Hilfsmittel. Erfolg oder Misserfolg der Organisation hängt ganz stark damit zusammen, ob das Requirements Engineering zwischen diesen beiden Ebenen effizient gestaltet und gemäß der Strategie der Organisation gelebt wird.

Im nächsten Schritt möchte ich das Ökosystems des Projekts unter die Lupe nehmen. Ganz erstaunliche Dinge lassen sich in dem Ökosystem erkennen, die zur Agilität führen und nicht die Wurzel im Agile Manifesto besitzen oder in den Bücher von Mary Poppendieck (die jedoch ihre Bedeutung daher nicht verlieren).

Agile Requirements Engineering - Eine Blog Serie

Sorry, this blog series about agile requireemnts engineering is in German. Reason is the source - a German conference, where I was asked to talk about this topic. So if somebody is interested in a translation, please let me know and I will care for.

---

In meiner Rolle als Board Member des IREB International Requirements Engineering Boards e.V. erhalte ich immer wieder Anfragen, wie es denn mit Agilität in Zusammenhang mit Requirements Engineering aussieht. Anfang habe einfachgeantwortet, dass es für mich hier keinen Unterschied zu einem agilen Vorgehen an sich gibt.

Die Anfragen regten mich jedoch an, mich einmal intensiver mit dieser Frage zu beschäftigen und zu hinterfragen, ob es denn eine spezielle Sicht aus dem Blickwinkel des Requirements Engineering auf agiles Arbeiten gibt. Die Antwort war ja – wenn der Kontext weiter gezogen wird als alleine das agile Arbeiten in einem Projekt. Agilität alleine im Projektkontext ist meiner Meinung nach nämlich eine klare Einschränkung.

Das Ziel einer beliebigen Organisation kann ja nicht sein effizient Projekte durchzuziehen. Projekte sind zeitlich begrenzte Vorhaben, um Organisationsziele zu erreichen. Das kann eine Innovation sein, um die Zukunft zu sichern, ein Produkt zu erstellen, um damit Geld zu verdienen oder einfach ein Vorhaben um die Organisation zu optimieren.

Das war der Start meiner Überlegungen, welche Verantwortung dem Requirements Engineering in einer Organisation übertragen ist und welchen Einfluss ein agiles Arbeiten dann auf die Gestaltung dieser Verantwortung ausübt. Aus den Überlegungen wurde ein Vortrag, den ich testweise an einer Konferenz gehalten habe, um ein Feedback zu den Überlegungen zu erhalten. Das dieses Feedback motivierend war und ein vorhandenen Interesse gezeigt hat, setze ich eine Blogreihe zu den Überlegungen auf