Wir brauchen mehr Digital Design!
Wenn wir in 10.000 Meter Höhe in einem modernen A350 sitzen, vertrauen wir auf drei Dinge: dass die Pilotin einen guten Job macht, dass die Maschine von erfahrenen Fluggerätemechanikern gebaut wurde und dass die Konstruktion der Maschine auf einem tragfähigen Konzept fußt, das von Ingenieur:innen durchdacht wurde. Ein solides Konzept ist die Basis für alles. Das A und O. Und niemand würde das je bezweifeln.
Auf Konzepte vertrauen
Genau denselben Anspruch sollten wir im Zuge der Digitalisierung auch an den Bau moderner Softwareprodukte haben. Die Konzeption als Basis digitaler Produkte ist ein Muss – und kein Nice-to-have. Konzeption von Software ist eine eigene Profession – und keine Tätigkeit, die schnell nebenbei mitgemacht wird. Und: Konzeption in der agilen Welt ist bedeutend mehr als "ein paar User Stories schreiben". Das gilt grundsätzlich auch dann, wenn es sich um ein Digitalisierungsprojekt handelt, das weniger sicherheitskritisch ist als der Flugzeugbau.
Digital Design heißt: Fachlichkeit ready-to-code zu modellieren
Digital Design ist der neue Terminus, der – aus der angelsächsischen Welt kommend – nun auch allmählich im deutschsprachigen Raum Einzug hält [1]. Digital Design bezeichnet die Ingenieursleistung der Softwarekonzeption in der agilen Welt. Für uns bedeutet es, Fachlichkeit ready-to-code zu modellieren. Dabei geht es um den Weg, aus einer wolkigen Idee für ein digitales Produkt eine greifbare Vision zu schärfen, diese nach und nach zu durchdringen und auszugestalten, bis sie von einem Team von Programmierer:innen in Code gegossen werden kann.
Der Konzeption von Software als eigener Disziplin wird nach unserem Erleben beim Entwickeln digitaler Produkte aktuell zu wenig Platz eingeräumt. Oft macht es den Eindruck, als wären wir in der Wasserfall-Welt schon einmal weiter gewesen. Als hätte das agile Mindset die Softwarekonzeption in den Hintergrund gedrängt. Business-Analyse und Requirements Engineering – Softwarekonzeption ist mit einer Vielzahl an Bezeichnungen belegt – waren im Wasserfall gesetzte Tätigkeiten in der Softwareentwicklung.
Agil heißt NICHT: ohne Plan! Und schon gar nicht: ohne Konzept!
Die agile Welt erleben wir heute oft so: überlastete Product Owner. Scrum-Teams, die fast ausschließlich aus Programmier:innen bestehen. Kaum geplante Kapazität für Konzeption. Die Folge: Backlogs, die leerlaufen oder Features, die nie live gesetzt werden. Zu wenig Zeit und Raum für einen ganzheitlichen Blick auf die Konzeption des digitalen Produkts. So ist es nicht immer. Aber oft. Woran liegt das? Haben wir da etwas verlernt?
Missverständnisse bei der Interpretation des SCRUM Guide?
Im agilen Projektalltag erleben wir verschiedene Konstellationen mit Blick auf die Konzeption, die für erfolgreiche Softwareentwicklung ungünstig sind. Hier mal zwei Beispiele.
Auf der einen Seite sehen wir sehr viele agile Teams ohne explizite Konzeptionsprofession. Die Scrum-Teams bestehen aus einem Product Owner, einem Scrum Master, einer Handvoll Developern, womit Teammitglieder gemeint sind, die als Kernaufgabe codieren sollen und können, und vielleicht ein bis zwei Testspezialisten. Fragen wir nach Konzeption, kommt die Antwort: "Um die User Stories kümmert sich unsere Product Ownerin." Oder: "Die User Stories schreiben die Entwickler."
Ursache vermuten wir in einer Fehlinterpretation des Scrum Guide. Im neuen Scrum Guide von 2020 sind – neben den Rollen Product Owner und dem Scrum Master – die Developer benannt. Lange war von einem cross-funktionalen Developer-Team die Rede. So oder so: im deutschsprachigen Raum werden "Developer" meist als "Entwickler" übersetzt. Und Entwickler werden oft als reine Programmierer bzw. Codierer interpretiert, und nicht als "fachliche" Entwickler. Für die Modellierung von Fachlichkeit bleibt bei dieser Auslegung nicht viel Raum. Sie ist damit Aufgabe des Product Owners oder muss von den Entwickler:innen "mitgemacht" werden.
Auf der anderen Seite erleben wir in der Praxis Scrum-Teams mit einer sehr kleinteiligen oder diffusen Cross-funktionalität. Rund um den Product Owner versammelt sich eine Heerschar von "Konzeptions-Sub-Disziplinen": User Experience Researcher, User Experience-Designer, User Interface Designer, Interaktionsdesigner, Visual Designer, Service Designer, Business-Analysten, Agile Requirements Engineers und so weiter.
Die einzelnen Profile sind teils sehr spitz aufgestellt, andere Profile verstehen sich breiter. Dies gilt auch für den jeweiligen Kompetenzraum, was zu Verantwortungsdiffusion führt. Das Wirken der Einzelnen erscheint sehr silohaft und es gibt viele Hand-Overs. Ein solches Projektsetting wird schnell ineffizient und birgt jede Menge Gefahren für die Qualität des digitalen Produkts. Vor allem dann, wenn man die von Scrum geforderte Zusammenarbeit und den Austausch im Team nicht angemessen lebt.
Was beiden Ansätzen gemein ist – der ganzheitliche Blick für das Konzept des digitalen Produktes bleibt auf der Strecke!
Digital Designer wirken als konzeptionelle Brückenbauer
Für erfolgreiche und effektive Digitalisierungsvorhaben ist es daher ein Muss, ausreichend Digital-Design-Profession an Bord zu haben. Digital Designer:innen sind Teammitglieder, deren Leidenschaft das Gestalten digitaler Lösungen ist. Sie besitzen das zugrundeliegende technologische Know-how, das methodische Handwerkszeug und eine gute Portion Fingerspitzengefühl im Umgang mit Menschen.
Digital Designer:innen bilden in agilen Teams die Brücke von der zunächst oft "wolkigen Welt des Business" in die "technologische Welt der Nullen und Einsen".
Auf der einen Seite unterstützen und entlasten Digital Designer den Product Owner bei seinen zahlreichen Aufgaben. Gestaltend und kapazitativ. Der Product Owner ist und bleibt natürlich die Instanz, die über die Funktionalität letztlich entscheidet. Er kann aber Aufgaben an das Digital-Designer-Team delegieren. Die Digital Designer:innen geben mit ihrem technologischen und methodischen Wissen Rückhalt und denken mit.
Auf der anderen Seite arbeiten Digital Designer Hand in Hand mit denjenigen, die das Product in Code umsetzen, den Programmierer:innen und Systemarchitekten. Gemeinsam denken sie die Anforderungen zu Ende und modellieren die Fachlichkeit ready-to-code. Profundes technologisches Know-how der Digital Designer:innen sorgt für Akzeptanz und macht eine Kommunikation auf Augenhöhe mit dem Codierteam möglich.
Und wie läuft das in einem Projekt genau?
Digital Designer gestalten digitale Lösungen mit 3 Horizonten im Blick
Um die ineinandergreifenden Gestaltungsebenen der Digital Designer:innen aufzuzeigen, haben wir das "Modell der drei Horizonte" entworfen. Wir differenzieren das Digital Design in die drei Horizonte Shaping, Exploring und Implementing. In einem agilen Projekt ist es die Verantwortung der Digital Designer:innen, diese drei Horizonte stets im Blick zu halten. Unabhängig davon, wo sich gerade die Hauptaktivität der einzelnen Designer:in hin richtet.
Warum? Weil es darum geht, "das Richtige" zu bauen. Und Blindleistung zu vermeiden. Denn es gilt stets zu überprüfen, ob konzeptionelle Entscheidungen auf einem Horizont, Veränderungen auf einem anderen Horizont nach sich ziehen.
"Das Richtige bauen" bedeutet, geplante Anforderungen, die obsolet geworden sind, frühzeitig auszusortieren. Weil das Team dazu gelernt hat. Weil das Team Zusammenhänge erkannt hat. Damit gar nicht erst feinkonzipiert und codiert wird, was am Ende nicht live geschaltet wird. Denn in solchen Fällen wird sehr viel Zeit und Energie des Teams verbrannt. Und das kostet.
"Das Richtige bauen" bedeutet aber auch, neu aufpoppende Themen adäquat zu behandeln. Müssen neue, unerwartete Anforderungen berücksichtigt werden, weil sie eine hohe Relevanz haben? Oder müssen sie "abgewehrt" werden, weil sie nicht zum Scope des digitalen Produkts passen? Oder müssen etwa Scope und Vision angepasst werden, weil die neu geforderte Funktionalität das Produkt noch besser, noch gebrauchstauglicher macht?
Dies zu entscheiden, braucht es jede Menge Fingerspitzengefühl, Erfahrung und gegenseitiges Sparring von Product Owner und Digital Designern.
Und was bedeuten die einzelnen Horizonte? Und was passiert da jeweils?
Shaping – Digital Designer justieren das digitale Produkt langfristig
Der Horizont Shaping zeigt während des gesamten Vorhabens auf, wo die Reise für das digitale Produkt hingehen soll. Hier erarbeiten die Digital Designer:innen, technischen Spezialist:innen und Product Owner gemeinsam mit den Stakeholdern die Ziele, die mit dem digitalen Produkt erreicht werden sollen. Gemeinsam wird die Vision geschärft und der Rahmen für das Vorhaben gelegt. Fachlich, technisch und organisatorisch. Die Digital Designer:innen sorgen dafür, die Bilder aus den Köpfen zu holen und gemeinsam ein Big Picture des digitalen Produktes zu zeichnen. Und gleichzeitig helfen sie auf diesem Horizont, ein adäquates technisches und organisatorisches Projekt-Setup zu gestalten, das durch das Vorhaben trägt.
Der Shaping-Horizont dient als rahmenstiftendes Level für das digitale Vorhaben. Hier legen sich die die Projektbeteiligten die Karten. Initial zu Beginn des Vorhabens, und zwar bevor die Codierung begonnen hat.
Natürlich sind die Ergebnisse aus dem Horizont Shaping nicht in Stein gemeißelt. Sie begleiten das agile Vorhaben von Anfang bis Ende und sind immer wieder zu hinterfragen und zu justieren. Wenn Stakeholder und das agile Team dazu gelernt haben. Oder wenn die Rahmenbedingungen des Vorhabens sich einschneidend ändern.
Auf dem Shaping-Horizont nutzen Digital Designer:innen zur methodischen Unterstützung unter anderem Business Model Canvas, Design Thinking, Personas und Empathie-Maps.
Exploring – Digital Designer zerlegen den Elefanten
Auf dem Horizont Exploring geht es für Digital Designer darum, gemeinsam mit den Projektbeteiligten das digitale Produkt entlang unterschiedlicher Dimensionen zu erforschen und zu definieren. "Der Elefant" – also das digitale Produkt in seiner Gesamtheit – wird in kleinere Aspekte zerlegt und durchdacht.
Digital Designer erheben funktionale und nicht-funktionale Anforderungen des Produkts und erfassen diese beispielsweise als Sagas oder Epics und schneiden diese schließlich in User Stories. Frühzeitig gehen sie mit Pilotnutzer:innen in den Dialog, um Bedürfnisse und Wünsche aus Nutzersicht einzuholen und die Nutzer:innen an Lösungen aktiv mitwirken zu lassen.
Interaktive Workshopformate, co-kreatives Scribblen von Bedienoberflächen, Entwickeln einer Story Map helfen den Digital Designern methodisch dabei, mit Stakeholdern und Pilotnutzern gemeinsam die verschiedenen Perspektiven auf das digitale Vorhaben zu erarbeiten.
Wie im Shaping-Horizont ist es auch hier ein wichtiges Ziel, die Vorstellungen der Beteiligten aus den Köpfen zu holen und dabei Gemeinsamkeiten aufzuzeigen, Widersprüche aufzudecken, Entscheidungen herbeizuführen und Lösungen auf groben Level zu skizzieren.
Während das Digital Design auf dem Shaping-Level für die Stimmigkeit und Aktualität der Gesamtvision sorgt, geht es auf dem Exploring-Horizont um die gemeinsame Ausgestaltung einzelner Teilelemente und deren Zusammenspiel im digitalen Produkt.
Implementing – Digital Designer priorisieren und modellieren ready-to-code
Auf dem Implementing-Horizont geht es fachlich ins Detail. Die User Stories sind gemeinsam im Team zu priorisieren und fein zu konzipieren.
Bei der Priorisierung stellt sich das Team Fragen wie: Was bringt fachlich aktuell den meisten Nutzen? Welche Abhängigkeiten gibt es? Was ist fachlich-technologisch eine Voraussetzung für etwas, das erst danach implementiert werden kann? Und die oft wichtigste Frage – siehe oben: was muss gar nicht (mehr) gebaut werden?
Für die Feinspezifikation befassen sich die Digital Designer:innen mit Fragen wie: sind die User Stories adäquat geschnitten? Welche Beschreibung ist eine treffende Definition für die Story? Was sind die Akzeptanzkriterien? Dabei gilt das Augenmerk sowohl dem geradlinigen Standardfall (Happy Flow) als auch den Grenzfällen (Edge Cases).
Wie bereits oben erwähnt, arbeiten die Digital Designer:innen – analog zum Pair-Programming – Hand in Hand mit denen, die die User Stories in Code gießen, den Entwickler:innen und Systemarchitekten. Gemeinsam sind sie in der Lage, fachliche Anforderungen und technologische Grenzen und Möglichkeiten auszubalancieren und Nutzen und Aufwände frühzeitig richtig einzuschätzen. Gemeinsam modellieren sie die Fachlichkeit ready-to-code.
Wann ist eine User Story – aus Entwicklersicht – ready-to-code?
Oft reduziert sich die Modellierung von Fachlichkeit an der User Story, die aus der Perspektive des Users gezeichnet wird. Die Bedürfnisse und Wünsche des Users werden angemessen abgebildet. Aber dabei bleibt es dann auch. Alle weiteren Anforderungen, die aus der User Story resultieren, bleiben unberücksichtigt. Sie werden nicht explizit konzipiert, was für das Codierteam unbefriedigend ist.
Hier anhand einer Beispielanforderung "Fehlerbehandlung und User informieren":
- Als User möchte ich mit einer sprechenden Fehlermeldung darüber informiert werden, dass Services unerwartet nicht zur Verfügung stehen.
Aus dieser Perspektive lässt sich die Anforderung "Fehlerbehandlung und User informieren" durchaus umsetzen. Allerdings stecken hinter dieser User-Anforderung noch Anforderungen aus Systemarchitekt- und Entwickler-Perspektive:
- Als Systemarchitekt:in möchte ich, dass Fehler im System strukturiert behandelt werden. Nicht also nur an der einen Stelle, die besonders instabil ist, sondern kohärent im System auf eine gleichartige Art. Strukturierte Fehler haben eine vorgegebene Form, verwenden Fehler-ID´s, usw.
- Als Entwickler:in habe ich das Bedürfnis, dass die Fehlerbehandlung der Story aus dem letzten Sprint entsprechend angepasst wird an die nun strukturierte Art.
Das Digital Design ist gefordert, solche Anforderungen, die stillschweigend zwischen den Zeilen der user-zentrischen Anforderungen stehen, zu identifizieren, explizit zu machen und zu durchdenken, bevor es für die Entwickler:innen an das eigentliche Codieren geht.
Eine Story ist demnach erst dann ready-to-code, wenn auch diese Anforderungen durchdacht, diskutiert, abgeschätzt und spezifiziert sind. Fehlen sie, sind Entwickler:innen und Architekten oft im Blindflug unterwegs. Zum Beispiel bei der Schätzung von technischen Anforderungen. Außerdem bedeutet es Mehraufwand bei dem Codierteam, denn die Gedanken müssen sich ja gemacht werden.
Das Digital Design sollte also auch frühzeitig Fragen klären wie: Welche Regressionseffekte wird es absehbar geben? Welche Systemkomponenten sind betroffen und in welchem Zustand befinden sie sich? Gibt es Architekturkonzepte, die entworfen werden müssen? Und gibt es Best-Practice-Empfehlungen, mit denen vorausschauend gearbeitet werden kann?
Blickt man auf das oben Gesagte zurück, sind das schon eine ganze Menge Fertigkeiten, die Digital Designer:innen "drauf haben müssen". Wie sieht denn das Kompetenzprofil konkret aus? Und wie kommt man dazu?
Diese Pi-shaped Kompetenzen sollten Digital Designer aufbauen
Um all die genannten Aufgaben optimal zu meistern, brauchen Designer ein umfassendes Skillset. Der Bitkom bezeichnet das Rollenbild des Digital Design als "PI-shaped" [2] und untergliedert es in Gestaltungskompetenz, Digitale Materialkunde und Methoden und Vorgehensweisen:
- Gestaltungskompetenz: Digital Designer:innen müssen gestalten können – und wollen. Tools und Methoden für das Requirements Engineering und Usability Engineering gehören zum grundlegenden Handwerkszeug. Gleichzeitig sollten Digital Designer:innen davon angetrieben sein, den Menschen in den Mittelpunkt stellen.
- Digitale Materialkunde: Um den fachlichen Herausforderungen mit den optimalen technologischen Lösungen zu begegnen und den Entwicklern und Systemarchitekten auf Augenhöhe begegnen zu können, brauchen Digital Designer:innen vor allem Kenntnisse von Technologien in der Breite. Sie müssen die Möglichkeiten und Grenzen von Software und Hardware kennen, ein solides Verständnis von IT-Architektur haben und aktuelle Endgeräte und Interaktionsformen überblicken.
- Methodik und Vorgehensweisen: Das Skill-Profil der Digital Designer:innen wird abgerundet durch querschnittliche Kompetenzen im Projektmanagement, Dos und Don’ts des agiles Vorgehens und einen Blick auf wirtschaftliche Aspekte im Rahmen eines Digitalisierungsvorhabens.
Bei all diesen Fähigkeiten hilft eine gesunde Portion Neugier: Neugier auf Fachlichkeit, Neugier auf Menschen und Interesse an zukunftsträchtigen Trends und Methoden.
Der Bitkom ist aktuell dabei, das Rollenbild Digital Design mit einer entsprechenden Ausbildungsinitiative zu belegen und als Profession im deutschsprachigen Raum zu etablieren.
Fazit: Nimm 30 Prozent Digital-Design-Kapazität an Bord!
Zusammengefasst verstehen wir Digital Design als eine übergeordnete Profession. Diese Profession vereint in der agilen Welt, was bislang synonym oder als Teildisziplin mit Requirements Engineering, UX-Design, Service-Design und UI-Design bezeichnet wird. Auf Basis ihres Technologieverständnisses gestalten Digital Designer:innen Lösungen mit drei Horizonten im Blick. Sie bilden die Brücke von Fachlichkeit zu Programmcode – die Brücke zwischen Stakeholdern, Usern und Product Owner einerseits und Codierteam bestehend aus Entwicker:innen und Systemarchitekten andererseits.
Wir empfehlen, bei einem agilen Projekt 30 Prozent Digital-Design-Profession an Bord zu nehmen. Diese Prozentzahl ist nicht gewürfelt. Sie entstammt unserer Erfahrung aus dem klassischen Vorgehen. Wir beobachten über Jahre, dass in erfolgreichen Digitalisierungsvorhaben die Konzeptionsarbeit zirka ein Drittel der Software-Engineering-Leistung ausmachen.
Was sich anfänglich – zum Beispiel aus Managementperspektive – wie ein großer Invest anfühlt ("Da wird ja gar nichts codiert!"), entpuppt sich im Laufe des digitalen Vorhabens als Katalysator für das digitale Produkt: ein Rahmen ist geschaffen, der ganzheitliche Blick der Digital Designer:innen sorgt dafür, dass das Richtige gebaut wird und Überflüssiges oder Unpassendes für das Produkt frühzeitig aussortiert wird.
Die Velocity des Teams steigt. Die Qualität und Gebrauchstauglichkeit des Produktes werden besser. Und am Ende sind Aufwände reduziert und Kosten gespart.
Wir brauchen mehr Digital Design!
