Agiles Anforderungsmanagement: die wesentlichen Kernelemente für erfolgreiche IT-Projekte

Immer häufiger werden IT-Lösungen nach dem Lean-Start-Up Prinzip realisiert. Beginnend mit der initialen Entwicklung eines, auf die Kernfunktionen fokussierten Produktes zum Markteinstieg („Minimal Viable Product – MVP“), wird das Produkt nach dem Go-Live durch direktes Marktfeedback, weiterentwickelt und optimiert.

Das erfordert ein entsprechendes Umdenken, auch im Anforderungsmanagement. Was sind die wesentlichen Kernelemente, die beim agilen Anforderungsmanagement über Erfolg und Misserfolg eines Softwareprojektes entscheiden?

Eine Frage auf die es vermutlich viele verschiedene Antworten gibt. In folgendem Blogbeitrag wollen wir uns dem Thema auf den drei Ebenen “Prozess”, “Tooling” und “Mindset” annähern und praxisnah darauf eingehen, wie agiles Anforderungsmanagement in diesen Bereichen jeweils Beachtung finden kann. Die Inhalte stammen größtenteils aus unserem Vortrag, den wir auf der ModernRE 2019 in Berlin gehalten haben.

Der Prozess: Von der Idee zur spezifizierten Anforderung

In einem Projekt liegt die thematische Verantwortung beim Fachbereich. Daher erstellt und aktualisiert dieser regelmäßig die Vision des Produkts – das Zielbild. Anhand dieser Vision werden viele Ideen abgeleitet um dieses Zielbild zu erreichen.

Die technische Verantwortung liegt wiederum beim IT Team. Das IT Team hat eine etwas andere Perspektive auf das Produkt und daher auch andere Ideen, als der Fachbereich, Im besten Falle ergänzen sich die Sichtweisen der IT mit der des Fachbereiches.

Von der Idee zur spezifizierten Anforderung
Abbildung: Von der Idee zur spezifizierten Anforderung

Eine Besonderheit ist es, dass alle Teammitglieder dazu aufgerufen sind ihre Ideen an einen eigens hierfür eingerichteten Bereich, dem sogenannten Ideen-Backlog, einzutragen und zu detaillieren. Ideen kommen dabei von einzelnen Teammitgliedern, die Verbesserungs- und Optimierungspotenziale erkannt haben, von externen Studien, in Form von direktem Feedback von Kunden, oder Dritten aus dem Markt.

In regelmäßigen Abständen findet durch den Fachbereich eine Begutachtung aller neuer Ideen aus dem Ideen-Backlog statt. Bei der inhaltlichen Prüfung der Ideen wird der bereits priorisierte Backlog betrachtet, sodass neue Ideen, die weiterverfolgt werden sollen, direkt priorisiert werden können. Auf diese Weise ist sichergestellt, dass immer die Idee als nächstes im Detail spezifiziert wird, die den größten Nutzen für Dritte und Kunden stiftet oder die größte Relevanz für das Produkt hat.

In der Spezifikation werden die Themen detailliert und im Sinne des Anforderungsmanagements spezifiziert. Es müssen beispielsweise Stakeholder ermittelt werden, die in einem Kick-off-Termin in das Vorhaben eingeweiht werden. Erste Erkenntnisse und Anforderungen werden notiert und grafisch in Form von Wireframes, Mockups oder mittels eines passenden Diagrammtyps aufbereitet. Ein Spezifikationstemplate hilft, wiederkehrende Fragen und Sachverhalte standardisiert zu betrachten und so keine wichtigen Aspekte zu vergessen. Klassische Ansätze kommen an dieser Stelle ebenfalls zum Tragen. Anforderungen müssen erhoben, analysiert, spezifiziert und validiert werden.

Nach jeder Spezifiaktionsphase steht das Review der fertigen Spezifikation an. Für das Review wird ein Teilnehmerkreis, bestehend aus dem Fachbereich und einem dedizierten IT-Ansprechpartner, dazu eingeladen, Feedback zur Spezifikation abzugeben. Um technische Risiken und die Umsetzbarkeit zu prüfen, sollte eng mit dem IT Team zusammen gearbeitet werden. Zusätzlich nehmen Kollegen aus der IT einen anderen Betrachtungswinkel ein und decken so zum Beispiel häufig noch nicht betrachtete Randfälle auf. Am Ende eines definierten Zeitraums ist es die Aufgabe des Autors, das Feedback zu konsolidieren, zu sichten und in die Spezifikation einzuarbeiten.

Am Ende steht eine finale Version der Spezifikation (v1.0), die sowohl vom Fachbereich, als auch vom IT Team gleichermaßen mitgetragen wird. Prozessual wird die fertige Fachspezifikation im IT-Refinement vom Fachbereich an das IT Team übergeben, Letzte Zusammenhänge werden betrachtet und ein einheitliches Verständnis hergestellt. Anschließend werden aus der Spezifikation User Stories für das Product Backlog der Software Entwicklung abgeleitet, definiert, priorisiert und detailliert.

Tooling in einer kollaborativen & verteilten Arbeitswelt

Ein toller Prozess allein reicht nicht aus! Es sind Tools notwendig, die diesen kollaborativen Ansatz ermöglichen und unterstützen. Zumeist werden zwei Tools in Kombination, beispielthaft JIRA und Confluence aus der Atlassian Suite, eingesetzt, um diesen Prozess abbilden zu können.

In einem Ticketingtool (Abbildung: Requirements Board im Ticketingtool) wird ein Kanban Board erstellt. Dort werden sämtliche Prozessschritte abgebildet, um den Überblick über alle Themen im Prozess zu behalten. Die Tickets im Status “Ready for Specification” stellen den bereits priorisierten Backlog dar, der aus dem Ideen-Backlog gespeist wird. Ideen, die keine Relevanz für das Produkt liefern, werden hier schon gar nicht mehr berücksichtigt. Themen, die sich momentan in der Bearbeitung befinden – sei es in der Erstellung der Spezifikation (“In Specification“) oder im Review (“In Review“) – werden per Drag-and-Drop in den entsprechenden Status gezogen. Durch die Verlinkung des Tickets zur Spezifikation besteht die Möglichkeit, in einem Klick vom Ticketingtool zum Kollaborationstool (Erklärung im nachfolgenden Absatz) zu springen. In die entgegengesetzte Richtung ist dies ebenso möglich. Auf diese Weise werden unnötige Tool- und Systembrüche vermieden und Arbeitsabläufe effizienter gestaltet. Aus Fachbereichssicht ist eine Spezifikation, nach dem das Review beendet wurde, mit der Übergabe an das IT Team (“Handover to IT“) fertiggestellt. Um eine vollständige Dokumentation zu gewährleisten, ist es notwendig, dass diese um die umgesetzten Funktionserweiterungen ergänzt wird (“Documentation done“). Erst jetzt ist der Zeitpunkt erreicht, an dem man guten Gewissens von einer umgesetzten Anforderung sprechen kann.

Requirements Board im Ticketingtool
Abbildung: Requirements Board im Ticketingtool

In einem Kollaborationstool findet die Dokumentation der Spezifikation und das Review statt. Zwischen den beiden Tools sind Verlinkungen der entsprechen Tickets und Spezifikationen möglich, um so direkt vom einen in den anderen Bereich springen zu können. Zusätzlich lassen sich Workshops ebenfalls im Kollaborationstool dokumentieren und als Entscheidungsprotokolle direkt in die Spezifikation verlinken. Durch zahlreiche Add-ons kann der Funktionsumfang eines Kollaborationstools sehr individuell auf die Bedürfnisse im Projekt und Prozess angepasst werden. So können beispielsweise Wireframes direkt im Kollaborationstool selbst erstellt und bearbeitet werden.

Der wohl größte Vorteil durch den Einsatz eines Kollaborationstools ergibt sich bei der Durchführung des Reviews einer Spezifikation. Vor dem Umzug in der Spezifikation in das Kollaborationstool wurde das Review anhand eines Word-Dokuments durchgeführt, wodurch je Review-Teilnehmer eine Version des Dokuments auf dem Fileserver abgelegt wurde. Die Aufgabe des Requirements Engineers bestand daraus, das Feedback zu konsolidieren und in die Spezifikation einzuarbeiten. Bei doppelten oder gar widersprüchlichen Kommentaren in den unterschiedlichen Review-Dokumenten führte das zu erhöhtem Abstimmungs- und Klärungsaufwand mit den entsprechenden Review-Teilnehmern. Durch den Umzug in das Kollaborationstool kann nun auf die vollen Funktionsumfänge zur Unterstützung und Verbesserung der Kollaboration unter den Review-Teilnehmern und des Requirements Engineers zurückgegriffen werden. Die Inline-Kommentarfunktion (Abbildung: Spezifikation und Review im Kollaborationstool) bietet die Möglichkeit, dass jeder Review-Teilnehmer durch Markieren einer Textstelle einen Kommentar platzieren kann, welcher für alle anderen Review-Teilnehmer sichtbar ist. Auf diese Weise werden Dopplungen vermieden, es entstehen Diskussionen, die neue Themen aufwerfen oder etwaige Rückfragen direkt klären. Für den Requirements Engineer verringert sich der Konsolidierungsaufwand des Review-Feedbacks signifikant, da nun mehr alle Kommentare in einem Dokument zu finden sind, Dopplungen und Widersprüche leichter zu identifizieren und aufzulösen sind.

Spezifikation und Review im Kollaborationstool

Abbildung: Spezifikation und Review im Kollaborationstool

Am Ende eines jeden Reviews sind alle Teilnehmer dazu aufgefordert, zu bestätigen, dass das Review beendet wurde und anzugeben, ob eine weitere Abstimmung mit dem Autor der Spezifikation gewünscht wird.

Review Log am Ende jeder Spezifikation

Abbildung: Review Log am Ende jeder Spezifikation

Mindset

Damit ein Projekt erfolgreich abgeschlossen werden kann, benötigt es mehr als funktionierende Prozesse und moderne Tools. Häufig wird ein wichtiges Kernelement übersehen: Das Mindset. Nur wenn die Menschen im Projekt kooperativ und auf das Projektziel ausgerichtet arbeiten, greifen die Prozesse und Tools effektiv ineinander. Heutzutage stoßen wir in Projekten jedoch häufig auf sogenannte Silos (z.B. bei verschiedenen Abteilungen innerhalb eines Konzerns), die das Zusammenarbeiten erschweren können. Silos verfolgen im schlechtesten Falle eigene Ziele, welche auf den ersten Blick nicht immer mit den Zielen des aktuellen Projekts übereinstimmen.

Georg Jocham, Coach für Projektmanager und Führungskräfte, greift in einem seiner Podcasts zum Thema „Silos“, auf eine im Jahre 2005 durchgeführte Studie zurück. Hier zeigte der Sozialpsychologe Mark Levin, welchen negativen Einfluss Silodenken auf das Kooperationsverhalten über die eigene Gruppe hinaus haben kann. Dazu werden Fußballfans von Manchester United zu Beginn des Versuchs Fragen im Themenumfeld rund um ihren Verein gestellt. Anschließend kann beobachtet werden, dass die Hilfsbereitschaft unter den Teilnehmern gegenüber anderen Manchester Fans um ein Vielfaches höher ist, als gegenüber Fans eines rivalisierenden Vereins. Beim zweiten Teil der Studie werden weitere Manchester United Fans eingeladen. Nun wird mit Hilfe einer anfänglichen Umfrage jedoch der Fokus nicht auf den Verein gelegt, sondern auf die gesamte englische Liga. Interessanterweise ist die im Anschluss beobachtete Hilfsbereitschaft gegenüber Menschen, die dem rivalisierenden Verein angehören massiv gestiegen ist. Sie erreicht dabei fast dasselbe Niveau wie die Kooperation den eigenen Vereinskollegen gegenüber.

Die Studie zeigt wie eklatant sich das Kooperationsverhalten unterscheidet: Je nachdem welcher Gruppe sich Menschen zum aktuellen Zeitpunkt zugehörig fühlen und ob deren Gegenüber ebenfalls Teil dieser Gruppe ist oder nicht. Die Studie zeigt neben den Gefahren die Silos bergen können, bereits eine mögliche Lösung, um aus dem Dilemma zu entkommen. Menschen, die in einem Projekt über verschiedene Abteilungen oder Firmen zusammenarbeiten, benötigen eine gemeinsame Projektidentität. Diese muss möglichst früh im Projekt etabliert werden, z. B. durch Vermittelung des gemeinsamen Projektziels im gemeinsamen Kick-off zu Beginn des Projekts.
Ist eine Projektidentität geschaffen muss sichergestellt werden, dass diese Bestand hat. Innerhalb dieses Projektteams haben sich zwei grundlegende Werte herausgeprägt die für den Zusammenhalt und eine funktionierende Zusammenarbeit innerhalb der Gruppe von großer Bedeutung sind: Wertschätzung und Vertrauen.

Ein wertschätzender Umgang im Projekt kann sich auf vielseitige Art und Weise äußern. So ist es zum Beispiel wertschätzend, andere nach Ihrer Meinung zu fragen oder sich für geleistete Arbeit zu bedanken. Eine hohe Wertschätzung im Projekt kann dazu führen, dass das Team eine höhere Loyalität dem Projekterfolg gegenüber zeigt.
Auch ein hohes Maß an Vertrauen spielt eine nicht unwesentliche Rolle, ob ein Team die gemeinsam etablierten Prozesse und Tools optimal nutzen kann. Dazu muss sichergestellt werden, dass jeder Beteiligte sich darauf verlassen kann, dass das gesamte Team auf den Projekterfolg ausgerichtet ist und somit auch das Ansprechen von Risiken, Fehlern und auch das Einbringen der eigenen Meinung als einen Beitrag zu diesem angesehen werden. In Projekten in denen ein hohes Maß an Vertrauen herrscht, steigt die Transparenz und die Berührungsängste in fachlichen Diskussionen und im schriftlichen Austausch nehmen stark ab. Es geht wieder mehr um die Sache. Insbesondere Transparenz ist in agilen Frameworks, wie zum Beispiel Scrum, eine wesentliche Grundvoraussetzung.

Wertschätzung und Vertrauen im Projekt

Abbildung: Wertschätzung und Vertrauen im Projekt

Fazit

Jedes der drei obigen Themen würde mehr als einen eigenen Vortrag füllen. Das hat sich unter anderem auch in der Agenda der diesjährigen ModernRE 2019 gezeigt. So wurden auf der Konferenz eigene Vorträge zum Einsatz einzelner Tools im Anforderungsprozess und zum Zusammenspiel von Ticketing- und Kollaborationstools gehalten. Auch auf das Thema Mindset wurde in einem spannenden Vortrag mit dem Titel “Wie Teams wirklich Stark werden” eingegangen.
Auch wenn die Rahmenbedingungen in IT-Projekten sehr unterschiedlich sind, so lohnt es sich doch von Zeit zu Zeit den eigenen agilen Anforderungsprozess unter die Lupe zu nehmen und bei Bedarf zu Überarbeiten. Besonders leicht fällt das, wenn man mit Tools arbeitet, die hier die notwendige Flexibilität mitbringen.

Wovon mit Sicherheit alle Projekte profitieren, unabhängig der Rahmenbedingung, ist ein wertschätzender und vertrauensvoller Umgang innerhalb eines gemeinsamen Projektziels.

Co-Autor Findan Eisenhut

 


Weiterführende Links

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Kundenzufriedenheit durch Erfüllung von Anforderungen – das Kano-Modell

 

Mehr zur Anforderungsanalyse für Softwareprojekte gibt’s hier

 

Agile Mixperience – die prickelnde Alternative zu Scrum Cooking

Mit Cocktails vermitteln, wie Scrum funktioniert

Nach jahrelanger Erfahrung mit dem Erfolgskonzept „Scrum Cooking“ inklusive optimierter Rezepte, zahlreichen neuen Koch-Skills und Kunden, die leckere Menüs genießen durften, wird es Zeit für ein wenig Abwechslung. Also warum die Methodik Scrum nicht bei einer Agile Mixperience erlernen? Statt 3-Gänge-Menüs werden hier Cocktails gemixt.

Es gibt zahlreiche Zertifizierungen, die sich mit den theoretischen Grundlagen der Projektmanagement-Methode Scrum beschäftigen. Wirklich nachhaltig lernt man am besten mit Praxisbezug und Spaß. Mit dem Workshop „Agile Mixperience“ vermitteln unsere Agile Coaches wie auch bei „Scrum Cooking“ die spezifischen Rollen, Prozesse und Artefakte der Methodik. Der eintägige Workshop wird entweder beim Kunden vor Ort oder in einer Location aus unserem Netzwerk durchgeführt. Die Teilnehmer lernen spielerisch die Grundprinzipien kennen, werden selbst aktiv und erleben unmittelbar die Effekte agiler Arbeitsmethoden. Sie schildern aus eigener Erfahrung:

„Es geht nur mit Kooperation.”
Für die Bearbeitung unserer strategischen und organisatorischen Aufgaben haben wir im Management Team agile Methoden schätzen gelernt. Die „Agile Mixperience“ hat uns ganz schnell wieder vor Augen geführt, dass eine reibungslose Kooperation im Team das A und O für den Erfolg des agilen Ansatzes ist.

 

„Raus aus der Falle „definition of (almost) done“
Seit Monaten arbeiten wir Product Owner mit unserem Entwicklungsteam agil zusammen und freuen uns über jede erfolgreiche Zwischenlieferung. Mit der Agile Mixperience wollten wir das Team nach einem Wechsel in verschiedenen Rollen neu zusammenschweißen. Wir haben aber noch mehr gelernt. Denn richtig lecker ist ein Cocktail erst, wenn er auch wirklich fertig ist und alle ihn genießen können.

 

„Agiles Arbeiten kann auch abseits der Software-Entwicklung sinnvoll sein.“
Wir standen vor der Frage, ob eine agile Arbeitsweise auch in unserem Vertriebsteam anwendbar ist. Nach dem Workshop steht fest: Wir werden nur gewisse Elemente aus dem Scrum Framework umsetzen können, diese jedoch konsequent bei uns etablieren. Nach der praktischen Anwendung zwischen Stößel, Shaker und Cocktails werden unsere Mitarbeiter jedenfalls nie wieder vergessen, was ein Scrum Master und ein Product Owner machen.

So funktioniert die Agile Mixperience:

  • Theoretische Einführung in das Scrum Framework, um bei den Teilnehmern ein gemeinsames Verständnis zu schaffen.
  • Team-Building und Verteilung der Rollen des Scrum Masters, Product Owners und der Teammitglieder.
  • Vorbereitung der Produktvision und des Product Backlog. Ziel ist es, dem „Kunden“ ansprechend dekorierte leckere Cocktails anbieten zu können – je nach Wunsch vom Virgin Cocktail bis zum Classic Cocktail.
  • Praktische Durchführung von drei Iterationen inklusive Sprint Planning, Sprint Review und Sprint Retrospektive, um das Erlernte zu festigen.
  • Gemeinsame Reflexion und Übertragung des Erlebten in die eigene Arbeitswelt.

 

Zusätzliche Herausforderungen entstehen durch Aktionskarten und veranschaulichen immer wieder, dass eine gute Planung, Transparenz und klare Kommunikation das A und O bei einer agilen Vorgehensweise sind. Auch die Zeit wird anfangs häufig unterschätzt. „Eine halbe Stunde für einen Cocktail? Das ist doch keine Herausforderung!“ Und doch geraten die Teams zu Beginn in Hektik. Mit jedem Sprint wird die zuvor besprochene Theorie verständlicher und besser angewendet – das Team schwingt sich ein, es lernt dazu und arbeitet in der nächsten Iteration produktiver.

doubleSlash Agile Mixperience Cocktails
Abbildung 1: Hanami-Cocktail bei einer Agile Mixperience mit doubleSlash im September 2019 in München

Während des gesamten Tages werden die Teilnehmer durch erfahrene Agile Coaches begleitet, die alle selbst in unterschiedlichen Rollen in agilen Projekten arbeiten.

Fazit: Agile Mixperience – für jedes agile Level und individuell nutzbar

Agile Mixperience schafft ein gemeinsames Verständnis im Projektteam und ist ideal für:

  • den Kick-off von anlaufenden agilen Projekten.
  • neue Projektmitglieder, die in laufende agile Projekte integriert werden.
  • erfahrene Projektmitglieder, die einen frischen Blick auf Ihre Scrum-Praxis werfen möchten.
  • Unternehmen, die sich eine Einführung von agilen Arbeits- und Entwicklungsmethoden überlegen.

 

Gemeinsam mit verschiedenen Kunden haben wir den Workshop „Agile Mixperience“ bereits erfolgreich verprobt. In lockerer Atmosphäre holen wir die Teilnehmer mit unterschiedlichsten Wissensständen ab – von Scrum Anfängern bis zum erfahrenen Scrum Master. Unser Ziel ist es, die Methodik verständlich zu vermitteln, den Teilnehmern die Scheu vor der praktischen Anwendung zu nehmen und die Essenz für die eigene Arbeitswelt mitzugeben.

Mehr Agile Workshops gibt es hier

 

Spring Boot: Webservice Integrationstest

Spring Boot bietet mit MockMvc einen Zwischenweg zwischen einem echten Integrationstest und einem Unit-Test und ermöglicht es, einfach Integrationsaspekte zu testen. So können sich Entwickler auf die Businesslogik konzentrieren und schnell Ergebnisse liefern. Der Artikel zeigt ein vollständiges Beispiel, wie man mit Spring MockMvc eine geschützte Webschnittstelle getestet werden kann.Mehr

Die fünf wichtigsten IT-Trends 2018

vernetzte TechnologienNein, die Blockchain gehört nicht zu den IT-Trends 2018, da wird sich vermutlich im kommenden Jahr erstmal – wie bei jeder Trendtechnologie – Ernüchterung einstellen. Zwar gibt es ohne Zweifel sinnvolle Szenarien für die Blockchain. Aber sie löst kein ernsthaftes Problem, sie erzeugt nicht den ganz großen Nutzen, den man sich erwartet. Unsere Infrastruktur, unsere etablierten Prozesse, unser ganzes Gemeinwesen basiert auf Vertrauen, auch wenn es zum Beispiel durch die Finanzkrise erschüttert worden ist. Hätten wir eine echte, weit reichende Vertrauenskrise, dann würde sich die Blockchain als Lösung anbieten. So aber glaube ich nicht, dass sich die Blockchain-Technologie die nächsten Jahre auf breiter Basis durchsetzen wird.

Mehr

DevOps, Microservices & Big Data: Drei Top IT-Themen, die Automobilhersteller künftig beschäftigen werden

Für einen fachlichen Austausch zwischen Mitarbeitern und ausgewählten Dienstleitern veranstaltete die BMW Group auch in diesem Jahr wieder ihre BMW IT Messe in der Münchner Zenith Halle. Im Fokus waren aktuelle Projekte und Innovationsthemen aus Business- und Fahrzeug-IT. Für das Fachpublikum gab es Informationen zu den aktuellen Trends in den IT-Projekten. Als langjähriger Partner der BMW AG waren wir mit dem 7er Pool [1] vor Ort und haben rückblickend drei Top IT-Themen identifiziert, die auf der Messe allgegenwärtig waren.

Mehr

Auf die API-Schnittstelle kommt es an

Schnittstellen TitelbildDurch zunehmende Digitalisierung und Automatisierung erhöht sich der Grad der Vernetzung zwischen Systemen. Das führt wiederum dazu, dass sich die Anzahl der Schnittstellen potenziert. Um die nötige Flexibilität zu bekommen, müssen moderne Softwaresysteme mit offenen Schnittstellen ausgestattet sein. Der Spagat zwischen Datenhoheit und der nötigen Offenheit für die Digitale Transformation stellt für Unternehmen eine Herausforderung dar.

Mehr

Agile Starthilfe für Konzern IT´s – Warum die agile Transformation im Unternehmen gar nicht so leicht ist

Agile Starthilfe für ProjekteStudien zur Verbreitung agiler Methoden[1] haben ergeben, dass sich agiles Projektmanagement in den Unternehmen immer mehr durchsetzt. Aus IT Abteilungen von Konzernen wird uns in letzter Zeit sogar berichtet, dass sie inzwischen alle IT-Projekte agil abwickeln müssen. Gleichzeitig tut sich die Konzern IT schwer, ihre Softwareprojekte flächendeckend auf agil umzustellen. Wir beobachten das mitunter daran, dass wir gerade jetzt vermehrt Anfragen nach „agilen Starterpaketen“ für Softwareprojekte erhalten. Warum ist das so?

 

Mehr