E-Health: Agile Methoden & Use Cases [Meetup Q&A]

Bei unserem gemeinsamen E-Health Meetup mit MAERA blieben einige Fragen aus Zeitgründen unbeantwortet. Hier stehen euch unsere Expert:innen Rede und Antwort!

Q: Habt ihr mit Design Sprints gearbeitet ?

A: In diesem Projekt haben wir nicht mit Design Sprints gearbeitet, da sie für uns nicht in allen Situationen die beste Wahl sind. In unserem konkreten Fall war die Problemstellung zwar technisch komplex, fachlich war die Lösung jedoch bereits grob abgesteckt (Terminbuchungsportal im Web).

Grundsätzlich führen wir für unsere Kund:innen nach Bedarf Design Sprints durch und unterstützen hierbei mit Moderator:innen sowie mit unserer technologischen und UI/UX-Expertise.

Q: Hatten die Beteiligten bereits Erfahrung mit agilen Vorgehensweisen?

A: Nicht alle Beteiligten hatten schon Erfahrung in der Arbeit mit agilen Methoden. Auf Kundenseite war die agile Welt sowohl für die Product Owner als auch die Endanwender:innen neu. Für unsere inovex-Entwickler:innen, UI/UX-Expert:innen und Scrum Master war es jedoch das gewohnte Umfeld. Nach einer Agile-Grundlagenschulung, engem Coaching und dem Vorleben des agilen Mindsets im Team fand die agile Arbeitsweise beim Kunden sehr schnell Anklang.

Q: Habt ihr die internen User asynchron eingebunden? Hintergrund der Frage: Personal im Krankenhaus ist oft sehr eng getaktet und gleichzeitig „nicht entbehrlich“, ohne dass der Praxisbetrieb lahm gelegt wird …

A: Sowohl als auch. Synchrone Meetings umfassten z. B. die Sprint Reviews, User Interviews und User Shadowing. Asynchrone Abstimmungen wurden für fachliche Detail-Besprechungen verwendet.

Synchrone Meetings wurden durch Lücken im Alltag, aber vor allem durch den Willen der Beteiligten ermöglicht, Innovation voranzutreiben. Auch die Beteiligung wechselnder Ansprechpartner aus demselben Tätigkeitsbereich konnten dabei helfen, die individuelle Belastung zu senken.

Q: Wie habt ihr die Fragen für das Interview gestaltet?

A: Wir haben uns an die gängigen Methoden der Gestaltung von Interviewleitfäden gehalten. Hierzu gehören mitunter eine Zielsetzung, offene Fragen (W-Fragen, keine fragen, die Ja/Nein-antworten erlauben), keine leitenden Fragen (z. B. rhetorische Fragen, Suggestivfragen) und vorwiegend Fragen über vergangenes Verhalten. Inhaltlich haben wir sichergestellt, dass wir die wichtigsten Aufgaben abfragen, die das Portal erfüllen soll. Hierzu haben die Teilnehmer:innen beispielsweise die Aufgabe erhalten, sich einen bestimmten Termin zu buchen. Weiterführende Informationen zu qualitativen Interviews vermitteln wir in unserem Discovery Training.

Q: Welche Personen hattet ihr im Blick und welche waren überraschend neu dabei?

A: Die für uns wichtigsten Zielgruppen hatten wir in einem User Story Mapping Workshop mit Hilfe von Personas erarbeitet. Beispielsweise haben wir bereits früh im Projekt die Unterscheidung zwischen sehr jungen (U30) und älteren Patient:innen (Ü60) getroffen, da diese sich maßgeblich in ihrer digitalen Affinität unterscheiden. Jedoch ist im Verlauf des Projektes deutlich geworden, dass auch die Ärzte ein Mitspracherecht bei der Terminplanung und -vergabe hatten. Das kristallisierte sich erst nach den ersten Feedbackrunden zum Patientenportal heraus, wurde aber dann fortan berücksichtigt.

Q: Wie lange habt ihr gebraucht von Kick-Off bis erstem Release?

A: Vom Kick-Off bis zum ersten Release waren es ca. 5 Monate, bei einer cross-funktionalen Teamzusammensetzung von 3x DEV, 1x Infra, 1x UX/UI, 1x SM, 2x PO.

Q: Sind nicht Elemente vom Design Thinking mit drin?

A: Für uns ist Design Thinking wie auch andere Modelle (z. B. User-Centered Design, IBM Loop) primär ein Mindset. Es geht vor allem darum, nutzerzentriert zu handeln und in iterativen Zyklen ein Problem zunächst zu verstehen, eine Lösung zu erarbeiten und diese dann zu testen, bevor man zur Implementierung übergeht. Mit dem Dual-Track-Scrum-Ansatz sind wir dieser Logik ebenfalls gefolgt. Die angewandten Methoden aus dem Design Thinking und der Product Discovery überschneiden sich stark. Beispielsweise haben wir Empathy Interviews durchgeführt (Design-Thinking-Methode), was in der Product Discovery oft unter der Flagge Problem Interviews geführt wird.

Q: Warum habt ihr Scrum als Dual Track mit zwei abgegrenzten Teams/Abteilungen umgesetzt anstatt mit einem gemeinsames cross-funktionales Team?

A: Wir haben mit einem cross-funktionalen Team sowohl im Discovery als auch im Delivery Track gearbeitet. Jedoch haben wir zwei unterschiedliche Backlogs geführt. Unsere Product Owner, Entwickler:innen, Scrum Master und Designer:innen waren in unterschiedlichen User-Research-Aktivitäten involviert. Um einen Vorsprung mit der Anforderungsanalyse zu erhalten, ist der Design & Discovery Track vor dem Delivery Track gestartet: erst verstehen, dann implementieren.

Q: Zu der Folie, auf der die zwei Tracks gezeigt wurden: War der Design-Prozess komplett vom Entwicklungsprozess getrennt, da man in unterschiedlichen Sprints gearbeitet hat? Waren die Designs für die Entwickler:innen immer komplett fertig, bevor angefangen wurde, ein Use Case zu implementieren?

A: Vom Grundgedanken her war unser Bestreben, dass das Design fertig ist, bevor die Entwickler:innen mit der Implementierung starten. „Fertig“ bedeutet in diesem Fall, dass die Endanwender:innen und die Entwickler:innen die Gelegenheit hatten, Feedback zum Design zu geben und dieses eingearbeitet wurde. Dieses Vorgehen spart Zeit, weil wir erst herausfinden, was einen Mehrwert stiftet, bevor wir es implementieren.

In der Realität haben wir dieses Zielbild nicht immer erreicht, was aber einen recht simplen Grund hatte: sich schnell ändernde Prioritäten. Mit jeder Iteration steigt der Erkenntnisgewinn über die Bedürfnisse unserer Nutzer:innen, was häufig eine Re-Priorisierung des Backlogs zur Folge hat. Da unser UX-Experte integraler Bestandteil unseres Scrum Teams war (d.h. in allen Scrum Meetings dabei), war ein sehr enger Austausch gegeben, wodurch es möglich war, Features auch ohne Designvorlage zu implementieren.

Q: Wie genau habt ihr die Patient:innen als User einbezogen?

A: Wir haben zunächst unsere Zielgruppe definiert: orthopädische Patient:innen U30 und Ü60, die sich operieren lassen wollen oder bereits operiert wurden. Im Anschluss haben wir in unserem Netzwerk nach passenden Kandidat:innen gesucht und Usability Tests mit Prototypen durchgeführt sowie Interviewfragen zum Problem und Kontext gestellt.

Q: Es wurde von einer PO-Schulung für Scrum Basics gesprochen. Haben Endkunden eine Product-Owner-Rolle eingenommen? Wer war für die Übertragung von Anforderungen zu Use Cases und Erstellung von Akzeptanzkriterien verantwortlich?

A: Unsere Product Owner waren zwar nicht die Endnutzer:innen, aber sie waren im konstanten Austausch mit ihnen. Die Product Owner waren verantwortlich für die inhaltliche Gestaltung des Produkts (d. h. Inhalte der Product Backlog Items, Priorisierung des Product Backlogs), wurden aber durch das Team bei Bedarf unterstützt (z. B. Formulierung von Stories und Akzeptanzkriterien).

Q: Könnt ihr noch ein Beispiel teilen, wie ihr Use Cases eingesetzt habt?

A: Wenn ihr Interesse an weiteren Einsatzgebieten und Beispielen habt, dann schaut gerne bei unseren Case Studies und auf inovex.design vorbei.

Die Präsentationen und weiterführende Informationen findet ihr bei MAERA als Download.