Im Rahmen von v-arc haben wir uns gefragt, wäre die Agile Anforderungsmanagement-Methode (agiles RE) für jene Projekte in welchen wir gerade arbeiten, geeignet. Die Antwort was sofort „Es kommt darauf an…“, also es gibt keine allgemeingültige.

Wir haben schnell festgestellt, daß es von vielen Faktoren abhängt: von der Organisation in welcher man arbeitet, vom Umfeld, von der Projektart usw.  Projektart selbst kann viele Dimensionen haben, und diese benötigen unterschiedliche Herangehensweise an die methodische Einführung des agilen RE.

In diesem Artikel, suchen wir aus unserer Sicht die geeigneten Schritte für die Einführung des agilen RE, sowie die notwendigen Rahmenbedingungen, damit die Anwendung der Methode ein Erfolg wird.

Wir wollen dabei eine Art Checkliste erstellen, welche man durchlaufen muß, und in den einzelnen Schritten die relevanten  Einflußfaktoren berücksichtigen sollte.

Was ist das Ziel?

Was ist das minimale Zielzustand, welches wir erreicht haben wenn wir meinen „wir praktizieren Agiles Anforderungsmanagement“? Was ist eigentlich unser Ziel?

Ziel ist eigentlich nicht agiles RE selbst zu praktizieren, sondern die Zielgenauigkeit der IT Lösungen zu erhöhen, wobei diese die angedachten Geschäftsziele unterstützen.

Dieses Ziel zu erfüllen, hilft die agiles RE in dem sie die Ergebnisse eines wiederholten (iterativen) Anforderungsprozesses in ein genauso wiederholbares Entwicklungsprozeß  mündet, und die Ergebnisse – die Softwareinkremente den Benutzern, Anforderen, Analytikern, und dem Team präsentiert. Durch die Präsentation der Ergebnisse, entsteht ein wertvolles Feedback, welches in die nächste Analyse-Iteration einfließt.

Somit sind wir überzeugt, daß agiles RE als „Insel-Praktika“ ohne dahinterliegender Entwicklung keinen Sinn ergibt.

Also, hier kommt eine – bestimmt unvollständige Liste der Schritte, welche zu dem erfolgreichen agilen RE in einem Projekt führen.

Check #1: „Analyse Jour Fixe etablieren“

Etabliere ein regelmäßiges Analysetermin mit Anforderern/Kunden und der Entwicklung um Slots zu haben, wo die agile Praktiken gelebt werden: Backlog – Priorisierung, Präsentation der Zwischenergebnisse, Aufwandsschätzung-Kommunikation.

In der iterativen Vorgehensweise ist es essentiell eine Kultur der immer wiederkehrenden Tätigkeiten zu etablieren. Dazu ist es sinnvoll sog. „Analyse-Serie“ zu etablieren.

Plane die „Analyse-Serie“ in 1-2 Monaten in der Zukunft, definiere  zu besprechenden Themen, damit Kunde (Anforderer-Team) die richtigen Ansprechpartner holen kann.

Definiere die Praktiken in dem Analysetermin und klare Ergebnisse:
–    Präsentation der Zwischenergebnisse geht immer auf der Grundlage der definierten Akzeptanzkriterien.
–    Aufwandsschätzung ist immer die Schätzung des Entwicklers(Teams) ohne Puffer
–    Feedback mündet nur in das Backlog

Check #2: „Analyse Backlog etablieren“

Erarbeitung des Analyse Backlogs ist einer Grundlage für den iterativen Analyseprozess.

Die Fähigkeit, die kommunizierten Anforderungen so zu „schneiden“ damit sie klein aber zugleich sinnvoll sind, ist ein Paradigmenwechsel und benötigt einen Umdenkprozeß – ähnlich dem Umstieg eines Entwicklers von einer prozeduralen auf eine objektorientierte Programmiersprache.

Ein Beispiel in Scrum ist z.B. Anspruch daß die User Stories Charakteristiken erfüllen sollen, welche unter dem Akronym „INVEST“ zusammengefaßt sind (siehe z.B. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/)

Check #3: „Dokumentation der Analyseergebnisse – Kollaboration über die Inhalte statt Review- und Freigabeprozesse “

Ausgehend von den Punkten aus dem Agilen Manifesto:

–    Funktionierende Software mehr als umfassende Dokumentation
–    Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

ist es essentiell daß man in Projekten, in welchen sich starre Review- und Freigabeprozesse der großen Dokumente etabliert haben, versucht aufzuweichen.

Die Kultur des Einfrierens der Dokumente (Spezifikationen) muß aufgebrochen werden, und Team dazu bewogen, daß man die Dokumente jederzeit ändern kann.

Dokumentation ist da, den aktuell korrekten Stand der geplanten Entwicklung abzubilden, und als Träger für die Entwicklung bzw. QA zu dienen.

Dabei sollte man jene Dokumentationswerkzeuge auswählen, wo die Veränderung automatisch nachvollziehbar ist, und somit jegliche Diskussionen darüber auf die Seite legt.

Check #4: „Timeboxing Kultur etablieren“

Der wahre Enabler der Agilen Umsetzung ist eine Kultur des Timeboxings in der Analyse und der Umsetzung zu etablieren.

Wenn man schafft, die einzelnen Iterationen (Timeboxing) als die fixe Konstante zu etablieren, und Inhalt als Variable zu akzeptieren, dann bekommt man ein wichtiges Management-Werkzeug in die Hände: Die Möglichkeit daß man die Mitarbeiter ohne wenn und aber, zu festgelegten Zeitpunkten immer wieder neu ausrichten kann.

Liebe Kollegen,

wir haben am Contributor Workshop 24.1. eine Matrix erarbeitet, in der Typische Projektcharakteristika (Größe, Komplexität, uvm) agilen Requirements Praktiken zugeordnet werden.

V-ARC Projektkriterien-Praktiken Matrix

Das Ziel ist es in den nächsten Monaten ein gemeinsames Bild zu entwickeln welche Praktik in welchen Projektsituationen gut geeignet ist oder nicht. d.h. die relevanten Zellen sollen mit +++/++/+/0/-/–/— bewertet werden.

Im Anhang die unbefüllte Matrix (Version 0.1). Wir laden Dich ein die Zellen der Matrix aus Deiner Sicht zu befüllen und hier zu posten. Gut wäre auch wenn Du (wo relevant) Deine Bewertung mittels Excel „Kommentar einfügen“ Funktion kommentieren könntest.

Wir konsolidieren das dann im Laufe der nächsten Wochen.

Viele Grüße

Wolfgang Göbl

1 Einleitung

Das interdisziplinäre Zusammenspiel Requirements Management und Psychologie wurde vom Vienna Agile Requirements Circle als “mission critical” eingestuft. Es gibt allerdings kaum Literatur die sich mit diesem Zusammenspiel beschäftigt.

Dieser Beitrag führt Thesen zu psychologischen Aspekten des Requirements Management an.

Diese sollen als Grundlage für eine weitere Diskussion des Themas dienen. Wir würden uns über Eure zahlreichen Kommentare dazu freuen!

Annahmen:
In diesem Paper werden folgende Annahmen als Tatsachen gesehen:

Agile Methoden (wie z.B: Scrum) können die Software Entwicklung signifikant verbessern

Die Qualität der entwickelten Software hängt ab vom
Grad der Einbeziehung der Endbenutzer
“Qualität” der Kommunikation und Beziehung Enbenutzer/Fachbereich/Analytiker/Programmierer

2 Klassischer Wasserfallansatz

Insgesamt ergibt der Wasserfallansatz viel zu oft eine Situation wie folgt:

Fachbereichsvertreter formuliert Anforderungen unvollständig und unter zu wenig Einbeziehung der Endbenutzer
Analytiker versucht Anforderungen zu vervollständigen, allerdings nur mit dem Fachbereichsvertretern, selten mit den Endbenutzern
Konsens zwischen Fachbereichsmitarbeiter und Analytiker wird in schriftlicher Form an die Programmierer weitergeleitet
Programmierer machen kaum Rückfragen zum Analytiker und schon gar nicht zum Fachbereich
Treten dann (wie zu erwarten) Probleme beim Einsatz der Software auf (“das ist doch nicht das was ich brauche!!”), werden die “schuldigen” auf Seite des Software Lieferanten gesucht, spätestens hier verschlechtert sich die Beziehung Fachbereich-Analytiker

Wasserfallansatz Thesen:

1. IT ist meist nicht auf gleicher Augenhöhe wie Fachbereich
– “eh nur die Techniker/Programmierer die schlechte Software liefern”
– Verglichen mit “Star-Architekten” in der Bau-Branche haben IT-Analytiker einen vergleichsweise niedriges Ansehen :-)

2. Fachbereichsvertreter blockieren oftmals den direkten Kontakt Endbenutzer->Analytiker/ Entwicklungsteam Vermutung weil:
– Verlust von Einfluss und Macht
– Angst davor selbst obsolete zu werden

3. Fachbereichsvertreter ist meist zu weit weg von den Problemen im “echten Geschäft”

4. Der lange Kommunikationsweg Endbenutzer->Fachbereichsvertreter->Analytiker->Entwicklungsteam führt notwendigerweise dazu, dass Anforderungen nicht richtig erkannt und programmiert werden.

Anm. Vladimir: Die Augenhöhe Problematik ist in meinen agilen Projekten auch vorhanden, das hat meiner Ansicht nach nicht unbedingt was mit Wasserfall vs. Agil.

Die Problematik, bzw. Konflikt liegt meiner Meinung hat folgende Gründe:

IT der 80’er Jahre war in jenen Unternehmen wo IT als kein Core Business war oder betrachtet wurde, ein sog. “Rechenzentrum IT”. Für diese Art der IT waren folgende Aspekte spezifisch:
Keine Auseinandersetzung mit fachlichen Anforderungen, eher eine unidirektionale (von IT hin zu Fachbereich) Weitergabe der Tools/Software/Systeme.
Rechenzentrum-IT hat oft selbst entschieden was für Business geeignet und was nicht geegnet war, IT hat über meiste Geld selbst verfügt
Augenhöhe-Spiel war also eher umgekehrt

Sukzessive wurden die IT Organisation hin zu Dienstleister in dem Unternehmen transformiert, was an sich gut ist:
Budget für die IT Projekte kommt aus Business Projekten, Fachbereiche haben Geld, gehen dann auch teilw. An die eigene IT vorbei, kaufen selbst Lösungen auf dem Markt
Businessziele sollen mehr in Vordergrund stehen

Konflikte welche dabei entstehen sind folgende:

Nachdem Business nun Geld der IT in der Hand hat, führt es zu eine Umkehr der Augenhöge-Differenz. Die “alte IT” will sich wiederum mit der gezwungenen Transformation nicht abfinden, IT ist gemacht von den Technikern, und diese hinterfragen nicht die Businessziele, versuchen nicht neue Rolle wahrzunehmen, sondern tendieren in tiefe technische Diskussionen (WIE statt WAS).
In Fachbereichen wollen die Leute selbst auch nicht die eigenen Ziele hinterfragen, sondern denken auch gerne in Lösungen (WIE statt WAS), sehr oft ist also als Konfliktpotential ein Fachbereichslösungsansatz versus IT-Lösungsansatz, beide Gruppen sind also längst in WIE-Modus.

Ich denke es die Kommunikationsengpässe auch in Agilen Methoden durchaus gibt: daher ist z.B. die Rolle des “Product Owners” da, als der Sprachrohr der Endkunden. Agilität bietet eigentlich eher die Möglichkeit, dass man früher die Konsequenzen eigener Entscheidungen welche auch Konfliktpotential hatten, erfährt (z.B. bei Präsentation der entwickelten User Stories nach einem Sprint) und bietet einer Person/Gruppe dass sie daraus lernt und zu einem sinnvolleren Konsens für das Inhalt des nächsten Sprint kommt.

Diese Fähigkeit, die Zwischenergebnisse als Teil der Diskussions- und Entscheidungsgrundlage für die nächsten Schritte heranzunehmen, ist m.Meinung nach im Hinblick auf entstandene Gruppendynamik und soziale Verhältnisse zwischen den Parteien estentiell.

3 Scrum

Scrum bietet einen guten Lösungsansatz um einen direkten Kommunikationskanal zwischen Endbenutzer und Programmierern zu ermöglichen.
Voraussetzung: Product Owner schafft es sich zurückzunehmen und sich in einer Vermittlerrolle zu sehen.
Product Owner und Analytiker gestalten den Prozess der Anforderungserhebung und sorgen dafür dass die richtigen Leute über die richtigen Dinge reden und geeignet dokumentieren
Product Owner und Analytiker sind eher Consultants am Weg zur passenden Software

Abb. 2: Wünschenswerte Situation in Scrum Projekten
Thesen:
1. Scrum führt dazu, dass Fachbereich und IT “im selben Boot” rudert und somit zu einer Verbesserung in der Beziehung
2. Rolle des Product Owners ist problematisch, er formuliert Anforderungen meist unter zuwenig Einbeziehung der Endbenutzer
3. Fordert der Software-Lieferant ein frühzeitiges Einbeziehen der Endbenutzer so wird das häufig vom Product Owner abgeblockt. Vermutung weil:
– Verlust von Einfluss und Macht
– Angst davor selbst obsolete zu werden

4 Zu diskutierende Fragen:
Die vorherrschende organisatorische Trennung zwischen “Fachbereich” und “IT” wird durch Scrum aufgeweicht. Ist sie im Lichte agiler Methoden nicht eher ein Hindernis und mittelfristig abzubauen?
Wie bringt man eine Organisation dazu sich im Dienste der friktionsfreien Erstellung von Software mit Scrum neu aufzustellen?

Wie schafft man es als Software Lieferant eine Situation wie in Abbildung 2 gezeigt zu etablieren?
Vertrauen beim Kunden herstellen
“Gleiche Augenhöhe” frühzeitig etablieren (aber wie???)
Erfolge vorweisen
Aber was wenn ein “Machtmensch” als Product Owner eingesetzt wird und die Endbenutzer dennoch abschirmt?

Welche Moderations/Kommunikationstechniken brauchen wir um den breiten Kommunikationskanal zwischen Endbenutzern und Programmierern zu managen?

Psychologische Aspekte im RM – Thesen V0.2