Scrum bei alpha-board (Teil 1): Wir bauen uns einen Kunden

Ankunft Alexanderplatz im Herzen von Berlin. Im aktuellen Projekt geht es um das Schleifen der agilen Vorgehensweise bei einem Dienstleister für agile Hardware-Entwicklung - der alpha-board gmbh. Kennzeichnend für die Auftragsentwicklung von alpha-board ist ein stets hoher Termindruck, da Produktideen innerhalb kürzester Zeit umgesetzt werden müssen. Mir geht es bei alpha-board darum, Kinderkrankheiten zu beseitigen und mit dem Team gemeinsam neue Best Practices für die Branche  zu entwickeln. In dieser kleinen Blogreihe möchte ich davon erzählen und gerne auch Anregungen für Ihr eigenes agiles Projekt geben. In erster Linie wird es um das Generieren von und das Umgehen mit agilen Anforderungen gehen.

Startbedingungen

Die Voraussetzungen für Scrum bei alpha-board sind gut: Eigenverantwortlich und cross-funktional arbeitende Ingenieure, die Produkte von Anfang bis Ende entwickeln können, ein Prototypen-Labor, in dem designte Leiterplatten innerhalb von Stunden per Fräßtechnik erstellt werden können, eine Geschäftsleitung, die mir jeden gewünschten Ingenieur von anderen Projekten freistellt und eine komplexe Hardware-Neuentwicklung.Das erfordert kurze Feedback-Zyklen, was mich in der Rolle als ScrumMaster besonders freut. Denn unser Sprint wird lediglich eine Arbeitswoche dauern und jeweils einen Prototyp liefern. Das ist für viele Hardwareentwickler Utopie, aber in der Software-Branche war das vor ca. 20 Jahren ähnlich. Der Vorteil kurzer Sprints: Je kürzer die Iteration, desto agiler wird die Neuentwicklung an sich und desto schneller können wir User-Feedback erhalten. Zeitgleich erzeugen wir als Team selbst schnelles Methodenfeedback, das uns hilft, unsere Vorgehensweise zu verfeinern und Hindernisse schneller aufzudecken.

Ohne Produkt kein Nutzer, also bauen wir uns einen.

Wir sitzen im ersten Backlog Refinement, allerdings schreiben wir heute keine einzige User Story. Darum geht es uns auch nicht. Wir schreiben Personas. Unser Refinement könnte man heute auch einen "Persona Workshop“ nennen. Was ist eine Persona?Die Kurzantwort: Personas sind fiktive Charaktere mit allem, was dazu gehört. Zum Beispiel:

• Sabine Singvogel. Sie ist junge 19 Jahre alt, blond und kommt aus Stuttgart. Sie studiert BWL, feiert gerne und raucht zur Entspannung. Leider ist sie nicht besonders technikaffin oder wie mein Team es salopp formuliert: „Sie hat keinen Plan von Technik."
• Oder nehmen wir Max Müller. Der 30-Jährige fährt gerne Motorrad und Fahrrad, ist Naturliebhaber, wohnt mit seiner Freundin in Berlin-Pankow und mag Fußball nicht. Max putzt seine Sachen zwar regelmäßig, aber das Putzen selbst kann er absolut nicht ausstehen.

Was haben die beiden Charaktere gemeinsam? Sie haben beide einen Namen, ein gewisses Alter, authentische Charaktereigenschaften und ein produktrelevantes Nutzungsverhalten. Beide Personas sind also potenzielle Endanwender für unser zu entwickelndes Produkt. Mir geht es primär nicht darum, wie realitätsnah die beiden Personas tatsächlich sind, sondern wer die Personas baut: Das tun nämlich alle Abteilungen, die an der Produktentwicklung beteiligt sind, inklusive Entwicklungsteam. Bei alpha-board haben Team, Vertrieb und Management gemeinsam diese und zwei weitere Personas gebaut.

Aber warum eine Persona?

Namen erfinden, Profilbilder malen, das ist ein Anwender-Ratespiel. Man könnte meinen, es passt so gar nicht zur Agilität, die doch das empirische Vorgehen betont. Aber um empirisch vorgehen zu können, müssen wir bei mangelnder Informationslage (im komplexen Umfeld also quasi immer), zuerst verhandelbare Hypothesen aufstellen. Bei der Anforderungsgenerierung sind das User Stories, bei Endanwender-Gruppen bzw. einer Anwenderrolle sind es die besagten Personas. Ziel der Hypothese ist es immer, bewiesen oder widerlegt zu werden. Ein zweifellos gutes Mittel dafür ist die klassische Nutzeranalyse. In meinem aktuellen Projekt entwickeln wir Personas nicht nur, um Produktanforderungen zu verfeinern, sondern um in den Köpfen aller Teammitglieder Bilder von einem User entstehen zu lassen, für den das bestimmte Feature entwickelt werden soll.

Wir entwickeln nutzerorientiert

In der Konsequenz agilen Vorgehens entwickelt man idealerweise primär entlang des Endanwender und nur sekundär oder gar nicht entlang des eigentlichen Lastenhefts. Ein weiterer Bonus: Aus einer Persona erschließt sich, warum das Produkt gebraucht wird. In einem aktuellen Fall haben wir eine Produktidee verworfen, weil wir keine realistische Persona dafür bauen konnten. Wo es keine sinnvolle Hypothese gibt, ist ein Beweis hinfällig. Das Produkt muss entweder besser verstanden oder eingestellt werden. Dieses Vorgehen ist nicht nur empirisch, sondern auch nutzerorientiert.In diesem Sinne, euer Marcus.