Agile Produktentwicklung heute
Software wird heutzutage agil entwickelt. Jeder weiß das. Ergibt ja auch Sinn. In der heutigen Zeit ändern sich Anforderungen so schnell, dass man anders gar nicht hinterher kommt. Und releasen möchte man auch alle zwei Monate. Neue Features, gefixte Bugs. Das ist, was die Kund:innen wollen. Den aktuellen Technologien sei dank geht das auch. Das ist auch in den oberen Etagen der vielen Unternehmen angekommen, die sich aufgrund der Digitalisierung in allen Branchen mehr und mehr zu Software-Herstellern entwickeln müssen. Und die Konkurrenz macht das ja auch. Also Scrum-Master einkaufen, Produktmanager zu Product Owner umschulen, 1-2 Blogs lesen, die Software-Abteilung ein wenig restrukturieren und schon geht’s los!
Was anfänglich nach nicht viel klingt, entpuppt sich aber auch mehr als 20 Jahre nach dem Erscheinen des Agilen Manifesto noch immer als große Herausforderung. Auch wenn die agilen Software-Methodiken der Herren der Agile Alliance in den 90ern und frühen 2000er Jahren nicht übermäßig komplex wirken, so sind es doch gerade die simpel klingenden Grundsätze und Werte, deren Verankerung in unserem analytischen und strukturierten Prozess-Denken nur sehr schwer gelingt. Viele Unternehmen führen schnell agile Methodiken und Tools ein, die ab dann jede:r Mitarbeiter:in einzusetzen hat („doing agile“), vergessen aber, dass das Wichtigste ist, agil zu denken („being agile“). Und das lässt sich eben nicht so schnell umsetzen, da es eines Kulturwandels bedarf. Und Kultur ändert sich eben immer nur langsam.
Hinzu kommt, dass sich auch die Qualitätsstandards von Software, vor allem in Bezug auf das User Interface und die User Experience, weiterentwickelt haben und Bedürfnisse bei Kund:innen und Unternehmen wecken. Denn über die Etablierung von UX Design freut sich nicht nur das Marketing, sondern man spart Geld, indem die Mitarbeiter effizienter und zufriedener werden, indem an vielen anderen Stellen Kapazitäten frei werden, die woanders sinnvoll eingesetzt werden können und die Kund:innen sind mit dem zu verkaufenden Produkt auch zufriedener. Aber wie soll man das alles bewältigen, wenn man nicht mal das agile Mindset effektiv etabliert bekommt?
Zusammenführen, was zusammengehört
Schaut man sich die Wikipedia-Artikel zu Agile software development und User-centered design an, bemerkt man schnell, dass es sich um zwei getrennte Welten handelt: Es gibt keine direkten Verweise aufeinander und die UI-Gestaltung auf der einen und die agile Entwicklung auf der anderen Seite werden jeweils nur stiefmütterlich behandelt. Dabei geht das eine heutzutage nicht mehr ohne das andere. Sind denn alle so sehr mit dem Versuch beschäftigt, zumindest eins der beiden Themen in ihrem Unternehmen ans Laufen zu bringen, sodass niemand Zeit hat, die Wikipedia-Artikel auf die Jetztzeit anzupassen?
Wenn wir als Dienstleister für UX Design zur Entwicklung eines Software-Produktes hinzugezogen werden, werden wir fast immer mit agilen Entwicklungsprozessen konfrontiert, deren Ausprägung und Reife unterschiedlicher nicht sein können. Wir bekommen hautnah mit, welche Probleme sich aus der Etablierung der agilen Grundsätze in ein Unternehmen ergeben und müssen in diese komplexe, vom Umbruch gezeichnete Situation unseren Nutzer:innen-zentrierten Ansatz einbringen. Dabei sollten wir das Rad aber auch nicht neu erfinden, denn in beiden Welten gibt es Methoden und Praktiken, die sich bewährt haben. Sie müssen nur zusammengeführt werden, auch wenn sie sich teilweise widersprechen. So gibt das allseits beliebte Prozess-Framework Scrum etwa cross-funktionale Teams vor, um Abhängigkeiten innerhalb des Development-Teams zu minimieren. Ein absolut richtiger Grundgedanke der Risikominimierung durch Reduzierung von Abhängigkeiten – aber wer will ernsthaft von Software Engineers gestaltete User Interfaces sehen?
„Wir glauben an einen Ansatz, der Personen verschiedener Disziplinen in einem Team vereint und trotz etwaiger, daraus entstehender Abhängigkeiten, effektiv und effizient zusammen agieren lässt, sodass der Mehrgewinn an Qualität für das Produkt durch die verschiedenen Expertisen das entstehende Risiko überwiegt.“
Wir bei Centigrade glauben nicht daran, dass eine Person alle Prozess-Schritte des Produkt-Lebenszyklus beherrschen kann (vom Requirements Engineering über UI Design bis zur Umsetzung und Pflege). Wir glauben an einen Ansatz, der Personen verschiedener Disziplinen in einem Team vereint und trotz etwaiger, daraus entstehender Abhängigkeiten, effektiv und effizient zusammen agieren lässt, sodass der Mehrgewinn an Qualität für das Produkt durch die verschiedenen Expertisen das entstehende Risiko überwiegt. Und diese interdisziplinäre Zusammensetzung von Teams hat sich in viele Bereichen als sinnvoll erwiesen, sei es bei Filmen, die auch dadurch besser werden – oder überhaupt nur möglich – indem viele verschiedene Disziplinen daran arbeiten, oder Fußball-Teams, die auch nicht nur aus Stürmer:innen bestehen.
Wenn wir in ein UX-Projekt kommen, wollen wir auch nicht bestehende Strukturen zerschlagen und den Scrum-Master-Finger heben, falls gar kein Scrum „by-the-book“ gemacht wird. Wir wollen etablierte Methodiken und Tools aus der UX-Welt „lean“ in bestehende, agile Prozesse integrieren und dazu anhalten, die Zusammenarbeit zwischen allen an der Entwicklung beteiligten Disziplinen und Stakeholdern zu fördern und zu pflegen, um möglichst schnell Mehrwert für die letztendlichen Nutzer:innen des Produktes vor dem Hintergrund eines definierten Business-Ziels zu erwirken. Das ist nämlich gemeint mit den vier Grundsätzen des Agilen Manifesto: Menschen arbeiten kollaborativ zusammen, um möglichst reaktiv funktionierende Software zu erzeugen. Und wenn wir diese Software auch noch so gestalten, dass sie großartige UX liefert und vom Markt gut angenommen wird, dann haben wir es geschafft.
UX über den gesamten agilen Produktentwicklungs-Zyklus etablieren
„Denn entscheidend für die Nutzer:innen ist, dass über UX nicht nur zu Beginn eines Projektes gesprochen wird, sondern es auch währenddessen seinen Weg ins Produkt findet.“
Herauskristallisiert hat sich so bei uns über die Jahre ein flexibler Prozess-Baukasten, Continuous UX, dessen Prozessbausteine es ermöglichen, einen agilen UX-Ansatz an die iterativen und inkrementellen Prozesse unserer Kund:innen anzupassen und über die gesamte agile Produktentwicklung hinweg zu etablieren. Continuous UX eben, analog zu Continuous Integration und Continuous Delivery. Denn entscheidend für die Nutzer:innen ist, dass über UX nicht nur zu Beginn eines Projektes gesprochen wird, sondern es auch währenddessen seinen Weg ins Produkt findet.
Damit die Anwendung gelingt, bringen wir nicht nur unsere langjährige Erfahrung im UX Design ein, sondern wenden genauso unsere Expertise in der agilen Produktentwicklung und dem agilen Projektmanagement an. Daraus resultiert für uns die Rolle des Continuous UX Advisors, deren wichtigsten Verantwortlichkeiten bei der Begleitung eines Projektes folgende sind:
1. Project Scoping
Beim Project Scoping wird der Grundstein für das Projekt gelegt. Wir beleuchten zunächst ausschließlich die im Kontext des zu entwickelnden Produktes vorherrschenden Potenziale aus Geschäftssicht, definieren gemeinsam für den aktuellen Projektabschnitt ein entsprechendes Business Ziel und schauen uns an, mit welchem minimalen Produktansatz (MVP) die wichtigsten Bedürfnisse der wichtigsten Nutzer:innen in einem bestimmten Nutzungskontext erfüllt werden können. Wichtig dabei ist, dass man möglichst klein denkt, um schnell wirkungsvolle Ergebnisse zu erzielen, ohne dabei das große Ganze zu vergessen.
2. User Requirements Management
Validierte Nutzer:innen-Bedürfnisse sind wichtig für einen Nutzer:innen-zentrierten Ansatz. Sie sind maßgeblich für die Priorisierung der Funktionalitäten des zu entwickelnden Produktes und geben damit eine Reihenfolge für die Entwicklung vor. Dabei ist es wichtig, sie immer wieder zu prüfen, sie zu pflegen und auch mit anderen Anforderungen, wie etwa technischen Restriktionen oder organisatorischen Vorgaben, in Einklang zu bringen.
3. Ideation und User Story Workshop
Neben der ersten Erkundung des Lösungsraums und der initialen Priorisierung von Nutzer:innen-Bedürfnissen ist es wichtig, zu jeder Zeit die richtige Abstraktionsebene der Nutzer:innen-Bedürfnissen zu wählen. Zu Beginn sollten sie so abstrakt sein, dass man einen guten Überblick über die im Anwendungskontext der wichtigsten Nutzer:innen identifizierten Bedürfnisse erlangt, um sie gegeneinander und gegenüber weiteren Anforderungen abzugrenzen und zu priorisieren sowie den meist frustrierenden Status Quo der Nutzer:innen und deren „User Journeys of Pain“ empathisch nachvollziehen zu können. Geht es aber in die konkrete Lösungs-Entwicklung, sei es in der Konzeption, im Visual Design als auch im Software Engineering, kann eine niedrigere Abstraktionsebene dabei helfen, Lösungen möglichst vollständig und genau zu kommunizieren und umzusetzen. Dabei ist die Wahl der richtigen Flughöhe eine Herausforderung und Entscheidung, die nur immer wieder überprüft und an den aktuellen Kontext angepasst werden muss.
4. Stakeholder Management
Der Nutzer:innen-zentrierte Ansatz erscheint zunächst sehr altruistisch. Aber natürlich muss man anerkennen, dass hinter jedem Projekt und Produkt wirtschaftliche Interessen stecken. Daher ist der ausschließliche Fokus auf Nutzer:innen nicht zielführend, vor allem eben nicht für die Nutzer:innen selbst. Ohne beispielsweise geldgebende Interessensvertreter gibt es eben auch kein Projekt und kein Produkt, welches irgendwann mal ein Problem der Nutzer:innen löst. Daher ist es ratsam, Stakeholder nicht nur beim regelmäßigen Abstimmen von Anforderungen einzubinden, sondern ihnen die Möglichkeit zu geben, an der gesamten agilen Produktentwicklung teilzuhaben und mitwirken zu können.
5. Befähigung des Development-Teams
Ist der Projektrahmen abgesteckt, geht es an die Umsetzung. Damit diese effektiv und effizient gelingt, braucht es ein fähiges und engagiertes Development-Team. Dieses kann mit den üblichen, agilen Praktiken befähigt und gesteuert werden. Zu beachten ist allerdings, dass es sich um ein interdisziplinäres Team handelt, dessen Fokus sich bei der Erfüllung seiner Aufgaben stark unterscheidet. Auch hier empfiehlt es sich, den Grundsätzen des Agilen Manifesto treu zu bleiben und das Team als soziales Gefüge so zu unterstützen, dass die vorhandenen Expertisen gemeinsam bei jedem Inkrement einen großen Wert für das Produkt erarbeiten.
6. Etablierung von Sprint-Zyklen
Die Organisation der Arbeit und notwendigen Abstimmungen in kurzen, effektiven Sprints hilft bei der Motivation des Development-Teams, beim Einbinden der Stakeholder und bei der Risikominimierung durch fortlaufende Auslieferung von funktionierender Software (Continuous Delivery). Dabei ist es ausschlaggebend, dass alle Disziplinen parallel und in enger Abstimmung miteinander an der ständigen Wertschöpfung für das Produkt arbeiten. Dadurch wird sichergestellt, dass die Entwicklung effektiver (vollständiger und genauer), risikoärmer (kontinuierliche Erfüllung von Nutzer:innen-Bedürfnissen) und steuerbarer (Anpassung an Kontextänderungen) ist, als bei traditionellen Arten Software zu entwickeln, wie etwa beim Wasserfallmodell. Die Steuerung der Kapazitäten ist dabei nicht immer einfach. Sie ist aber notwendig, um eine hohe Produktqualität sicherzustellen. Aus Continuous UX-Sicht bedeutet Continuous Delivery unter anderem, dass die Arbeit eines konzeptuellen Designers nicht mit der Übergabe an Software Engineers endet, sondern dass sie sich in Form von tiefgehenden Reviews des potentiellen, neuen Inkrements kontinuierlich fortsetzt.
„Das Verinnerlichen und Beherzigen der Grundsätze des Agilen Manifesto helfen dabei nicht nur, agil Software zu entwickeln, sondern fördern die Integration eines kontinuierlichen und ganzheitlichen UX-Ansatzes, der in der heutigen Zeit unabdingbar ist und maßgeblich zum Produkterfolg beiträgt.“
Werden diese Bausteine richtig angewendet, wie wir sie auch in unserem Academy Training „Scrum meets UX“ ganz praktisch schulen, gelingt das Zusammenspiel aus UX Design in einem Nutzer:innen-zentrierten Ansatz und der allgegenwärtigen, agilen Produktentwicklung. Das Verinnerlichen und Beherzigen der Grundsätze des Agilen Manifesto helfen dabei nicht nur, agil Software zu entwickeln, sondern fördern die Integration eines kontinuierlichen und ganzheitlichen UX-Ansatzes, der in der heutigen Zeit unabdingbar ist und maßgeblich zum Produkterfolg beiträgt.
Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen an!
