Der Weg zur agilen Anforderungsanalyse (Lean Business Analysis)

Wir brauchen keine Business-Analysten

Ich weiß nicht, wie oft ich die Aussage „Wir brauchen keine Business Analysten in Agile“ oder „Business Analysten bringen keinen wirklichen Mehrwert“ schon gelesen oder gehört habe.

In Anlehnung an Churchills „Diejenigen, die es versäumen, aus der Geschichte zu lernen, sind dazu verurteilt, sie zu wiederholen“, denke ich, wir sollten einen kurzen Blick auf die Geschichte der Informationstechnologie (IT) werfen, um die Prämisse zu testen.

Der Grund, warum ich mich gut mit Computern identifizieren kann, ist, dass wir denselben Weg eingeschlagen haben. Geboren in den 40er Jahren, aufgewachsen in den 50er Jahren, volljährig in den 60er Jahren, produktiv in den 70er Jahren, erfolgreich in den 80er Jahren, vernetzt in den 90er Jahren, downsized in den 00er Jahren und in diesem Jahrzehnt viral geworden. (OK, vielleicht bin ich noch nicht ganz auf der viralen Ebene angekommen, aber hey, ich habe noch ein wenig Zeit übrig! Wenn ich 2020 zu diesem Jahrzehnt zähle, habe ich noch über ein Jahr Zeit).

Die Geburtsstunde der Business Analyse

Im Laufe dieser Zeit hat sich auch der Prozess, herauszufinden, was wir mit diesen „denkenden“ Maschinen, den Computern, tun sollen, gewandelt. Natürlich sind die Techniken zur Definition von Geschäftsbedürfnissen und zur Validierung von Geschäftsanforderungen immer hinter der Technologie zurückgeblieben, aber so gehört es sich nun einmal. Wir müssen beweisen, dass ein Computer zuverlässig 1 und 1 addieren kann, um 2 zu erhalten, bevor wir Zeit damit verbringen, herauszufinden, warum wir diese Fähigkeit brauchen.

Wie immer muss man etwas schaffen, bevor man es verbessern kann. Während die Entwickler lernten, WIE sie dem Computer sagen, was er tun soll, mussten die Benutzer den Entwicklern sagen, WAS der Computer tun soll. Ich denke, das fasst den Sinn der Business-Analyse ziemlich gut zusammen.

Technologie-getriebene Geschäftsanalyse

Am Anfang versteckten sich die Entwickler unter dem Titel „Programmierer“. Dieser Titel verwandelte sich in „Programmier-Analytiker“, als sie erkannten, dass es nicht ausreichte, den Computer dazu zu bringen, etwas zu tun – er musste etwas tun, was die Geschäftsbereich wirklich brauchte.

Als Computer immer leistungsfähiger wurden, wurde das Leben immer komplexer. Mit dem technologischen Wandel Schritt zu halten wurde zu einer Vollzeitbeschäftigung, also teilten wir den Programmierer-Analytiker in zwei Rollen auf. Diejenigen, die „die Sprache der Computer sprachen“, wurden zu Entwicklern und diejenigen, die „die Sprache der Menschen sprachen“, zu Analytikern.

Die Rolle der Analyse wurde Leuten zugewiesen, die mehr Spaß an der Arbeit mit Menschen hatten, als Bits und Bytes für ihren Lebensunterhalt zu twiddlen. Die IT-Abteilung behielt jedoch stets die Oberhand und nannte sie Systemanalytiker, um sicherzustellen, dass sie mit ihren Wurzeln verbunden blieben. Die Theorie war, dass man, wenn man nicht wusste, wie man einen Computer programmiert, unmöglich wissen konnte, wie man Anforderungen für eine Anwendung entwickelt.

Anwender übernehmen die Kontrolle über ihr Anwendungen

Die 80er Jahre brachten uns den PC mit der weit verbreiteten Verwendung von GUIs. Diese Entwicklungen halfen uns zu erkennen, dass Computerexperten nicht immer die besten Kandidaten für die Definition dessen waren, was die Business-Community benötigte. Zu diesem Zeitpunkt stand unsere Firma vorderster Front einer Bewegung, die darauf abzielte, Geschäftsfachleuten zu lehren, wie sie ihre eigenen Anforderungen in ihrer eigenen Sprache definieren können. Das war die Geburtsstunde der Business Analyse als Beruf. Wir fanden endlich ein Zuhause.

In der ersten Hälfte der 90er Jahre lehrten wir (damals als Hathaway & Associates, Inc.) Nicht-IT-Mitarbeitern, wie man Geschäftsanforderungen erstellt und Business-Analyst wird (damals oft noch System Analyst genannt). Diejenigen, die diese „schmutzige Arbeit“ machten, waren dafür verantwortlich, die Interessen der Business-Community zu vertreten. Zu ihren Aufgaben gehörte das Elizitieren, Schreiben, Analysieren, Schätzen, Kommunizieren und Validieren von Anforderungen. Zum ersten Mal hatten die Geschäftsbereiche ihre eigenen IT-Anwendungen einigermaßen unter Kontrolle.

Der Jahr-2000-Hickser

In der zweiten Hälfte der 90er Jahre machte sich jeder, der auch nur ein bisschen Ahnung von Computern hatte, daran, den gefürchteten Jahr-2000-Bug zu eliminieren. Für diejenigen, die später geboren wurden und glauben Y2K war ein Scam; das war wirklich kein Schwindel, sondern ein existenzieller und geradezu heroischer Versuch, das Risiko katastrophaler Systemausfälle zur Jahrhundertwende zu verringern.

Offensichtlich hatte keiner von uns, der sich des Schreibens von Code schuldig gemacht hatte, erwartet, dass unsere Programme das Jahr 2000 überleben würden. (OK, das ist defamierend und eine glatte Lüge, aber das hat keinen Einfluss auf meine Story, also lasse ich es dabei). Ich behaupte, daß das Jahr-2000-Problem nur aufgrund des außerordentlichen Engagements und der Hingabe von Millionen von IT-Fachleuten auf der ganzen Welt als DOA eingestuft wurde. Gute Arbeit, liebe Leute, gute Arbeit und vielen Dank.

Es entsteht eine neue Rolle: Der Product Owner

Nun, zurück zur Timeline. Die 2000er läuteten eine neue, agile Ära ein, in der sich der Fokus für Software wieder auf die Entwickler verlagerte. Die Agile Philosophie legte fest, dass die Aufgabe des Entwicklers darin bestand, funktionierende Software zu liefern. Bei agilenAnsätzen wie z.B. „Extreme Programming“ sollten die Entwickler die Anforderungsgespräche (User Story Meetings) direkt mit ihren Kunden führen, so dass viele die Rolle des Business Analysten für überflüssig hielten. Wir wurden fast zum kurzlebigsten Beruf überhaupt.

Agile Methoden schufen die Rolle des Product Owner, um die Interessen der Business-Community zu vertreten. Indem dem Product Owner die Verantwortung für das agile Team (bestehend aus Entwicklern und Testern) übertragen wurde, wurde gewährleistet, dass die Geschäftsseite die Aufsicht über den Fortschritt hatte. Der IT wurde zu Recht die unterstützende Rolle zugewiesen.

Erfahrungen und Erkenntnissen

Agile ist eine äußerst wertvolle und effektive Methode zur Entwicklung von Software-Anwendungen, die die Anforderungen und Wünsche der Business-Community erfüllen. Agile liefert kleine Stücke funktionierender Software auf einmal. Jedes Release demonstriert Funktionalität für den Product Owner, der sicherstellt, dass es den Endbenutzern einen Mehrwert bietet und das repräsentiert, was das Unternehmen wirklich braucht. Was die Ideen betrifft, absolut brillant.  Erstklassiges Konzept, das viele Probleme anspricht, die die IT von Anfang an geplagt haben.

Wir haben gelernt, dass erfolgreiche Agile Initiativen davon abhängen, dass der Product Owner einen Großteil dessen tut, wofür Business-Analysten ausgebildet werden. Die Terminologie hat sich geändert. Wir sprechen jetzt von User Stories, Epics und Feature-Listen statt von Business-, Stakeholder- und Solution Requirements. hat sich dahingehend geändert, dass sie nicht mehr ein einmaliger, erster Schritt in einem Projekt ist, sondern ein ständiges, fortlaufendes Arbeitsverfahren. Die Detailtiefe, die für jede Anforderung erfasst wird, wurde auf das Wesentliche reduziert, um die Entwickler nur für die bevorstehende Arbeit anzuleiten.

Titel ändern sich, notwendige Arbeitsergebnisse bleiben

Aber vergessen wir nicht, dass Product Owner auch Menschen sind (zumindest solange, bis die künstliche Intelligenz das Sagen hat). Einige sind großartig darin, zu bestimmen, was das Geschäftsumfeld braucht, andere brauchen Hilfe. Ausgehend von meiner kurzen Reise in die Vergangenheit sehe ich eine strahlende Zukunft für diejenigen unter uns, die es lieben gelernt haben, Business-Analysten zu sein. Wir können den Hut wechseln und Product Owner werden (unsere Fähigkeiten sind ideal) ODER wir unterstützen unseren Product Owner vor Ort mit unseren umfangreichen Fähigkeiten im Bereich der Anforderungserhebung und -Analyse. So oder so ist es ein zukunftsorientierter Weg für diejenigen, die sich gerne zwischen realen Menschen und IT bewegen. Wir müssen nur den Wandel annehmen, anstatt an der Berufsbezeichnung festzuhalten. Wir haben die Wahl.