IREB RE@Agile Primer

Disziplinen und Teams: Agile Methoden, arbeiten mit cross-funktionalen Teams. Abgesehen von den Expertenrollen (PO und Scrum Master) decken die Teammitglieder unterschiedlichen Kompetenzbereiche ab und unterstützen gemeinsam die RE- oder Testaktivitäten. Ziel des Teams ist es, Kundenanforderungen vollständig zu liefern, unabhängig von technologischen oder organisatorischen Elementen.

IT-Manager: Streben in  Organisationen ein Gleichgewicht zwischen Spezialisten und Generalisten an. Die Teamstruktur spielt die Produkt- resp. Systemstruktur. Wenn ein Unternehmen seine Teams nach Komponenten / Systemen organisiert, ist eine Skalierung durch Steigerung der Anzahl von Teams nicht hilfreich (= erzeugt mehr Abhängigkeit). Skalierung ist nur bei Anz. Teammitgliedern möglich (= erzeugt Kommunikationsaufwand). Cross-funktionale Teams, die alle Fähigkeiten zur Auslieferung vollständiger Inkremente übernehmen, lassen sich leicht skalieren (aber Aufbau ist schwierig und zeitintensiv).

Product Owner vs. Projektmanager: POs tragen aufgrund der Priorisierung mehr Verantwortung als REs. Müssen aber dazu ermächtigt sein, Geschäftsentscheidungen zu treffen. Einige PM Tasks, sind in agilen Ansätzen nicht mehr erforderlich, da die Entwicklungsteams sich selbst organisieren (Anforderungen detailieren, aufgliedern und innerhalb des Teams zuweisen). In einem agilen Umfeld müssen IT-Manager ein klares Setting der Vision für die agile Entwicklung entwerfen und die kulturellen Voraussetzungen klar kommunizieren, damit dieser Ansatz erfolgreich sein kann.

Requirements Engineering: RE kann Teil des Entwicklungsteams sein oder ein eigenes Team bilden, welches den PO unterstützt. Beide Ansätze haben Vorteile und verletzten keine agilen Prinzipien.

Die agilen Werte direkter, täglicher, nicht-hierarchischer Kommunikation spiegeln sich typischerweise in kleinen, fest miteinander verwachsenen Teams wider. Empfehlung: Scrum Teams mit 5 bis 11 Mitglieder (3 bis 9 Entwicklungsteammitglieder + Product Owner + Scrum Master). Die Teammitglieder sollten sich im Idealfall physisch am selben Standort befinden und in Bezug auf betriebswirtschaftliche und technische Kompetenzen cross-funktional aufgestellt sein.

Faktoren welche das in grösseren Organisationen verhindern sind:

• Bei komplexen Problemen kann die Einbeziehung von Stakeholdern und Wissen aus verschiedenen Unternehmensbereichen erforderlich sein, die sich in einem einzigen Team nicht so einfach vereinen lassen.
• Bei komplexen Problemen kann zudem die Einbeziehung einer Reihe von technischen Experten und Wissen erforderlich sein, die sich in einem einzigen Team nicht so einfach vereinen lassen.
• Der bis zu einem festgelegten Einführungstermin erforderliche Umfang geht über das mit der erreichbaren Geschwindigkeit eines einzelnen Teams Mögliche hinaus.
• Mitarbeiter in globalen Unternehmen arbeiten unter Umständen an verschiedenen geografischen Standorten.

Der Begriff „Scaled Agile" (skalierte Agilität), wird verwendet wenn mehrere Teams zusammen an einem Produkt/einer Lösung mit gemeinsamen Zielen arbeiten. Bei Scaled-Agile-Ansätzen müssen Entscheidungen zur Organisation von Scrum-Teams getroffen werden und dazu, wie die Kommunikation unter den Teams koordiniert werden soll. Ziel dabei ist es, einen effizienten Ansatz für den Umgang mit komplexen Problemen zu erreichen und dabei möglichst viele Vorteile agiler Methoden beizubehalten.

Nach welchen Dimensionen lassen sich Teams organisieren, dass eine cross-funktionale Zusammensetzung (Mindestgrösse) erlaubt und gleichzeitig eine effiziente (maximale Grösse) Kommunikation und Abstimmung ermöglicht?

• Das Organisieren nach funktionalen Linien (z. B. Geschäftsbereich, Funktion) hat den Vorteil, dass sich das betriebswirtschaftliche Wissen in einem einzigen Team konzentriert. Das kann die Ermittlung von Anforderungen erleichtern (Reduktion der Anzahl der zu berücksichtigenden Stakeholder). Ein Nachteil ist, dass die Bereitstellung von umfassenden Funktionalitäten in einem Geschäftsbereich unterschiedliche technische Besonderheiten involviert, wie UI-Design, Datenbanken und zentrale Plattformen wie ein ERP System, durch die man leicht an die Grenzen der maximalen Grösse eines effizienten Teams stösst.
• Alternativ liesse sich die Entwicklung auch nach technischen Linien (d. h. in Teams, die sich etwa auf technische Komponenten oder Plattformen) organisieren. Der Vorteil dieser Teams sind die tiefgehenden Kenntnisse in ihren jeweiligen technologischen Gebieten. Ein Nachteil sind die Abhängigkeiten, die zwischen den Teams entstehen, die zusammenarbeiten, um das gesamte Produktinkrement termingerecht zu liefern.

Die Skalierungs-Frameworks zeigen, wie man mit dieser Situation umgehen kann. Requirements-Engineering-Aktivitäten müssen auf das Framework ausgerichtet werden, um eine gemeinsame Sicht auf die lieferbaren Ergebnisse zu erreichen.  In diesem Szenario spielt das RE eine besonders wichtige Rolle: zuerst bei der Aufgliederung der Geschäftsziele und Anforderungen in einzelne Untersystemanforderungen, die dann Teams zugewiesen werden können, und zweitens bei der Begleitung der Entwicklung, um sicherzustellen, dass das Ergebnis einer integrierten Lösung erreicht und damit der betriebswirtschaftliche Nutzen geliefert wird.

Die beste Lösung kann eine Mischung aus allen Arten von Teams darstellen, um von den Ideen sog. Feature-Teams zu profitieren und gleichzeitig unternehmensspezifische Einschränkungen zu berücksichtigen.

Für die effiziente Teams Zusammenarbeit gibt es zwei Ansätze:

1. Methoden aus dem Vorgehen mit einem Team verwenden

2. Zusätzliche Konzepte zur Organisation der Kommunikation und Verantwortlichkeiten einführen

1. Methoden aus dem Vorgehen mit einem Team verwenden: Zusätzliche Rollen und Artefakte widersprechen der agilen Denkweise, erhöhen die Komplexität und führen zu mehr Verwaltungsaufwand. Die Kommunikation und Koordination zwischen den Teams wird gewöhnlich durch die Product Owner der Teams initiiert, dann jedoch von den Teamvertretern ausgeführt. Über Konstruktionen wie „Communities of Practice" können die Teammitglieder über die Teams hinweg Erfahrungen austauschen und Gesamtprozesse koordinieren.

2. Zusätzliche Konzepte einführen:  Bei diesem Ansatz werden grössere Probleme in kleinere Probleme unterteilt. Diese werden durch unterschiedliche Rollen für verschiedene Abstraktionsebenen gemanagt. Durch das Unterteilen müssen weitere Artefakte für die unterschiedlichen Abstraktionsebenen eingeführt werden (z. B. Business Epics, Architectural Epics, Investment-Themen, Features, User-Storys).

Abhängig von dem verwendeten Framework werden auch noch weitere Rollen mit Verantwortung für die unterschiedlichen Abstraktionsebenen eingeführt (z. B. PortfolioManager, Produktmanager, Product Owner). Aufgrund der steigenden Komplexität sind ausserdem zusätzliche Artefakte und Rollen erforderlich, um die Planung und Kommunikation unter den verschiedenen Teams zu managen und integrierte Ergebnisse für jede Iteration zu erzielen (z. B. Roadmaps und Release-Manager). Darüber hinaus müssen spezielle Meetings organisiert werden, um die Kommunikation zwischen neuen und bereits etablierten Rollen zu fördern. Das RE bietet zahlreiche Techniken, die dabei helfen könnten, grössere Probleme zu unterteilen und die neuen Rollen auf den unterschiedlichen Abstraktionsebenen zu unterstützen (z. B. Kontextmodellierung, Zielmodellierung).

Beide Ansätze haben ihre Vor- und Nachteile; die Anwendbarkeit ist individuell und unternehmensabhängig.

Es gibt zahlreiche Frameworks, welche eine Skalierung von Scrum und agilen Entwicklungsprozessen unterstützen:  

• Scaled Agile Framework (SAFe): SAFe ist eine Wissensdatenbank mit bewährten Erfolgsmustern für die Implementierung von Lean-Agile-Software- und -Systementwicklungen für Unternehmen.
• Large-Scale Scrum (LeSS): LeSS ist die Anwendung von Scrum auf zahlreiche Teams, die zusammen an einem Produkt arbeiten.
• Large Nexus: Nexus ist ein Framework, das auf das Zentrum der Skalierung abzielt: Cross-Team Abhängigkeiten und Integrationsprobleme.  
• Scrum@Scale: Das Scrum-at-Scale-Framework ist eine minimale Erweiterung des zentralen Scrum Frameworks, das die modulare Struktur im Kern des Scrum-Frameworks beibehält und zudem erlaubt, dass sich Scrum-Implementierungen massgeschneidert auf die einzigartigen Bedürfnisse des Unternehmens skalieren lassen.
• Scrum Disciplined Agile Delivery (DAD): Disciplined Agile AD ist ein Framework für Prozessentscheidungen für Unternehmen, die sich an Lean-Prinzipien orientieren. Es ist taktisch auf Teamebene und strategisch über das gesamte Unternehmen hinweg skalierbar.

Die zusätzlichen Abstraktionsschichten bedeuten, dass es mehr Rollen für das Management der RE-Aktivitäten gibt (Product Owner, Produktmanager, PortfolioManager oder Business-Analyst). Jede Rolle erstellt für ihren jeweiligen Problembereich entsprechende RE-Artefakte (Epics, Features, User-Storys und die Verfolgbarkeit zwischen diesen). Es sind zusätzliche Meetings für RE-Aktivitäten erforderlich (z. B. Story-Times, FeatureTimes, Systemdemos), und die Kommunikation mit Stakeholdern wird von den unterschiedlichen Rollen auf den verschiedenen Ebenen in der Organisation ausgeführt.

Durch die Skalierung werden umfassende Anforderungen zerlegt und angemessen unter den zahlreichen agilen Teams verteilt. Die RE-Techniken helfen bei der Strukturierung von Problemanalysen und bei der Verfeinerung von groben in detailliertere Anforderungen (z.B. Features und User-Storys für einzelne Teams). Durch diesen strukturierten Ansatz können teilweise autonome, agile Entwicklungsteam die Anforderungen teamintern weiter verfeinern.

Wenn Teams an unterschiedlichen Standorten arbeiten, kommt eine weitere Herausforderung hinzu. Die Komplexität beim Management der Kommunikation nimmt aufgrund möglicher Zeitverschiebungen oder sprachlicher Unterschiede zu. Die grösste Herausforderung liegt meist in den kulturellen Unterschieden. Da Kommunikation eine der Hauptaufgaben von Product Ownern und Produktmanagern ist, hat dies einen erheblichen Einfluss auf die erforderlichen Kompetenzen der RE-relevanten Rollen.

Agile Methoden lassen sich als ein kontinuierlicher, iterativer Prozess charakterisieren, in dem ein System basierend auf den Backlog Items inkrementell entwickelt wird. Aus Requirements-Engineering-Perspektive lassen sich fünf Parameter identifizieren, die diesen Prozess prägen:

• Definition erster Anforderungen
• Detaillierungsgrad für Backlog Items
• Validität von Backlog Items
• Feedback zum Backlog und dessen Aktualisierung
• Zeitplan für den Entwicklungszyklus

Vorab-RE vs. kontinuierlichem RE

Die erste Definition des Backlogs wird benötigt, um den iterativen Prozess zu starten. Dieses wird als «Vorabdefinition» verstanden. Ob diese Vorabdefinition eine vollständige und detaillierte Spezifikation aller Anforderungen ist hängt von den vorhandenen Informationen ab, die für die erste ersten Iteration benötigt wird. Abhängig von System und Kontext können Anforderungsunsicherheiten zu Prozessbeginn zu Verzögerungen, Kosten oder zum Scheitern des Projekts führen (=Vorteil Vorab-RE). Im Gegenzug kann sich ein zu später Start negativ auf die Markteinführungszeit oder auf Kundennutzenbefriedigung auswirken (= Nachteil Vorab-RE).

Lösung: Anforderungen welche grosse Auswirkungen auf die Architektur, auf die Realisierbarkeit der Lösung insgesamt oder auf zentrale Entscheidungen in Bezug auf Infrastruktur und Hardware haben, müssen zu einem früheren Zeitpunkt ermittelt und detailliert erfasst werden sollten (= Vorab-RE). Anforderungen mit geringeren Auswirkungen können dann im Verlauf der Iterationen in einem kontinuierlichen Prozess verfeinert werden (= kontinuierlichem RE).

In den iterativen und inkrementellen Prozessen agiler Entwicklung wird das Requirements Engineering zu einem kontinuierlichen Prozess, der Anforderungen just in time liefert und verfeinert, und zwar genau in der für den Entwicklungszyklus erforderlichen Detailtiefe.

Der Detaillierungsgrad eines Backlog Items beschränkt die Freiheit des Entwicklungsteams bei dessen Realisierung. Alle Aspekte eines Backlog Items, die nicht definiert worden sind, liegen in der Entscheidungsgewalt des Teams, was dem Team - innerhalb der definierten Geschäftsgrenzen - mehr Kreativität erlaubt.

Faustregel: Wenn das Entwicklungsteam über ausreichende Kompetenz für die Entscheidung über die Details eines Backlog Items verfügt (z. B. wenn ein Experte für Authentifizierungen und Berechtigungen im Team ist), dann sollte diese Entscheidung dem Team überlassen werden.

Die Bestimmung der Validität (= Gütekriterium) eines Backlog Items ist eng mit seinem Detaillierungsgrad verbunden. Der Aufwand für die Ausarbeitung und Validierung einer Anforderung vor der Implementierung muss dem Aufwand der Anforderungsimplementierung mit anschliessender Validierung in der ausgelieferten Software gegenüberstellt werden.

Kann eine Backlog Item mit tragbarem Aufwand vor der Implementierung durch die Stakeholder Präferenzen validiert werden, sollte die Validierung vorgelagert stattfinden.

Ebenfalls sollten Backlog Items mit hohem Risiko (z. B. kritische Geschäftsfunktionen, sicherheitsrelevante Funktionen, innovative Funktionalitäten) oder mit hohen Testkosten für die Implementierung (z. B. wenn die Software in einem teuren Prototyp getestet werden muss) vor der Implementierung validiert werden.

Typische Beispiele für diese Art von Anforderungen (inkl. Validierungsansatzes): das Benutzeroberflächendesign (= UI-Mock-ups), Berechtigungs- und Authentifizierungsmechanismen (= Reviews von Anwendungsfällen), in dem System zu speichernde Datenstrukturen (= Reviews von Datenmodellen) und Schnittstellenanforderungen zu vorhandenen Systemen (= Reviews von Aktivitätsdiagrammen).

Der «richtige» Aktualisierungszyklus für das Product Backlog ist abhängig von der Skalierung und Detailierung der Anforderungen, deren Komplexität/Abhängigkeiten sowie von der Anzahl involvierter Entwicklungsteams. Zudem muss der Entscheidungsfindungsprozess der Organisation beachtet werden. In Organisationen in denen z.B. Entscheidungsgremien selten stattfinden, muss das Prinzip kontinuierlicher Verfeinerung konkret in Meetings umgesetzt werden, an denen alle betroffenen Stakeholder teilnehmen. Das RE dient zur Vorbereitung und als Entscheidungshilfe für solche Meetings.

Generell: Die Backlog Aktualisierung aufgrund des Sprint Review Feedback ist bei geringer Skalierung und bei detaillierten Anforderungen möglich, für die Auswirkungen einer Änderung schnell analysiert und erfasst werden können, und zwar in einer Umgebung mit ein oder zwei kleinen Entwicklungsteams. Anforderungen in komplexen Umgebungen mit vielen Abhängigkeiten können nicht kurzfristig geändert werden (Analysebedarf und Abhängigkeit der Stakeholder Verfügbarkeit für Wissenstransfer).

Kürzere Iterationszeiten steigern das Arbeitspensum für die Stakeholder:

1. Stakeholder müssen während der gesamten Iteration verfügbar sein, um am Backlog mitzuarbeiten und Informationen für die nächste Iteration zu liefern.

 2. Stakeholder müssen die vom Team erarbeiteten Ergebnisse durchsehen und Feedback abgeben.

3. Stakeholder müssen immer wieder den Arbeitskontext wechseln (Tagesgeschäft vs.Projektarbeit).

Längere Iterationszeiten verringern den Druck, reduzieren aber auch die Möglichkeiten für die Produktentwicklung, das Backlog zu beeinflussen.

Die Iterationsdauer muss unter Berücksichtigung der Verfügbarkeit der Stakeholder festgelegt werden. Stakeholder sind in der Regel nicht zu 100 % für Entwicklungsaktivitäten verfügbar, da sie noch andere Verpflichtungen haben.

Faustregel: Eine kürzere Iterationsdauer ermöglicht häufiges Feedback und mehr Möglichkeiten, Fehler frühzeitig zu erkennen; daher beschleunigen kürzere Iterationszeiten die Entwicklungsaktivitäten tendenziell. Wenn eine kurze Zykluszeit ein inakzeptables Pensum für die Stakeholder darstellt, sollte für die Iterationsdauer ein Kompromiss gefunden werden.

Ein weiterer Faktor ist der durchschnittliche Umfang und die Komplexität von Backlog Items. Grössere oder komplexere Backlog Items erfordern mehr Zeit zum Verständnis und für die Analyse. Daher kann die Zykluszeit verlängert werden, um diese Backlog Items innerhalb einer einzigen Iteration abzuwickeln.

Die Entscheidung für längere oder kürzere Zykluszeiten muss gemeinsam im Team getroffen werden, unter Abwägung der Zeit, die für die Analyse benötigt wird, mit dem Ziel, frühzeitig Feedback zu erhalten. Veränderte Zykluszeiten beruhen immer auf dem Prinzip „Inspect and Adapt" (wobei bisherige Erfahrungen nicht immer eine Zukunftsgarantie sind). Die Änderung der Zykluszeit sollte vor, aber niemals während eines Sprints stattfinden. 

A set of conditions (typically associated with a ➔user story) that must be fulfilled by any implementation. Such conditions may be, for example, expected outcomes for sample input data or expected speed or volume to be achieved.

1. (General) Able to move quickly and easily.

2. (General) Quick, smart, and clever.

3. (In software development) A (software) ➔product development approach which builds a product ➔incrementally by dividing work into ➔iterations of fixed duration (➔timeboxes). Agile development is characterized by focusing on delivering a working product in each iteration, collaboration with stakeholders with frequent feedback and adaptation of plans after each iteration based on feedback and changed requirements. 

A diagram plotting the units of work that remain to accomplish on a time scale.

A team of people whose members have expertise in various functions of a task (for example, architecting, coding, testing, designing databases and user interfaces, etc.) 

A daily ceremony to discuss the current state of work within a ➔sprint. The Daily Scrum is an element of ➔Scrum.

A list of criteria which must be met before a product ➔increment is considered to be completed. Typically, the Definition of Done is created by the ➔development team and displayed prominently in the team room.

Criteria that a Product Backlog item must meet prior to being accepted into an upcoming ➔iteration

1. A plan or drawing produced to show how something will look, function or be structured before it is made.

2. A decorative pattern [This meaning does not apply in the software engineering domain].

3. The activity of creating a design.

In software product development, we distinguish between creative design which determines the functions as well as the look and feel of the product, and technical design (also called software design) which determines the inner structure of the product, in particular the software architecture.

A group of professionals who develop a (software) ➔product. ➔Agile development aims at working with ➔cross-functional teams. 

1. (General) A long book that tells a story about a hero’s adventures or other exciting events.

2. (In Agile) A high-level, abstract description of a stakeholder need which has to be addressed in the ➔product being developed. Epics are typically larger than what can be implemented in a single ➔iteration. 

The activity of coding and testing a piece of software.

An addition to a system under development that extends, enhances or refactors (➔Refactoring) the existing parts of the system. In ➔Agile development, every ➔iteration produces an increment.

A basic principle of ➔Scrum: After each ➔sprint, both the developed results and the development practices are inspected. Then, the product goals and development practices are adapted accordingly.

1. (General) The repetition of something, for example, a procedure, a process or a piece of program code.

2. (In Agile) A ➔timeboxed unit of work in which a ➔development team implements an ➔increment to the ➔product under development. In ➔ Scrum, the requirements to be implemented are given in the ➔Sprint Backlog.

The systematic application of one or more coherent ➔techniques to achieve a certain objective and/or to create an artifact. 

1. The systematic study of ➔methods in a particular field, in particular, how to select, apply or evaluate methods systematically in a given situation.

2. A set of methods being applied in some combination.

A product with the smallest possible feature set that has a market value and can be shipped to customers / end users. 

A minimal version of a new ➔product that allows the ➔development team to learn about customer acceptance of the product.

A MVP tries to maximize the return on investment in terms of customer feedback while minimizing the risk (in terms of development cost). 

In user-centered design and marketing, personas are fictional characters created to represent the different user types that might use a site, brand, or product in a similar way.

An agile estimation technique 

An ➔ increment that has sufficient maturity to be released to the customer

A software-based system or service which is developed and marketed by a supplier and used by customers. 

An ordered, typically prioritized collection of work items that a ➔development team has to work on when developing or evolving a ➔product. Items include requirements, bugs to be fixed, or ➔refactorings to be done.