![\"Produktentwicklung](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Agile-Produktentwicklung-mit-ux-design-2.jpg\")
<\/p>\n<\/p>\n
Software wird heutzutage agil entwickelt. Jeder wei\u00df das. Ergibt ja auch Sinn. In der heutigen Zeit \u00e4ndern sich Anforderungen so schnell, dass man anders gar nicht hinterher kommt. Und releasen m\u00f6chte 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\u00fcssen. 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!<\/p>\n
<\/p>\n
Was anf\u00e4nglich nach nicht viel klingt, entpuppt sich aber auch mehr als 20 Jahre nach dem Erscheinen des Agilen Manifesto<\/a> noch immer als gro\u00dfe Herausforderung. Auch wenn die agilen Software-Methodiken<\/a> der Herren der Agile Alliance<\/a> in den 90ern und fr\u00fchen 2000er Jahren nicht \u00fcberm\u00e4\u00dfig komplex wirken, so sind es doch gerade die simpel klingenden Grunds\u00e4tze und Werte, deren Verankerung in unserem analytischen und strukturierten Prozess-Denken nur sehr schwer gelingt. Viele Unternehmen f\u00fchren 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\u00e4sst sich eben nicht so schnell umsetzen, da es eines Kulturwandels bedarf. Und Kultur \u00e4ndert sich eben immer nur langsam.<\/p>\n Hinzu kommt, dass sich auch die Qualit\u00e4tsstandards von Software, vor allem in Bezug auf das User Interface und die User Experience, weiterentwickelt haben und Bed\u00fcrfnisse bei Kund:innen und Unternehmen wecken. Denn \u00fcber die Etablierung von UX Design freut sich nicht nur das Marketing, sondern man spart Geld, indem die Mitarbeiter effizienter und zufriedener werden<\/a>, indem an vielen anderen Stellen Kapazit\u00e4ten frei werden, die woanders sinnvoll eingesetzt werden k\u00f6nnen und die Kund:innen sind mit dem zu verkaufenden Produkt auch zufriedener. Aber wie soll man das alles bew\u00e4ltigen, wenn man nicht mal das agile Mindset effektiv etabliert bekommt?<\/p>\n Schaut man sich die Wikipedia-Artikel zu Agile software development<\/a> und User-centered design<\/a> 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\u00fctterlich behandelt. Dabei geht das eine heutzutage nicht mehr ohne das andere. Sind denn alle so sehr mit dem Versuch besch\u00e4ftigt, zumindest eins der beiden Themen in ihrem Unternehmen ans Laufen zu bringen, sodass niemand Zeit hat, die Wikipedia-Artikel auf die Jetztzeit anzupassen?<\/p>\n Wenn wir als Dienstleister f\u00fcr UX Design<\/a> zur Entwicklung eines Software-Produktes hinzugezogen werden, werden wir fast immer mit agilen Entwicklungsprozessen konfrontiert, deren Auspr\u00e4gung und Reife unterschiedlicher nicht sein k\u00f6nnen. Wir bekommen hautnah mit, welche Probleme sich aus der Etablierung der agilen Grunds\u00e4tze in ein Unternehmen ergeben und m\u00fcssen 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\u00e4hrt haben. Sie m\u00fcssen nur zusammengef\u00fchrt werden, auch wenn sie sich teilweise widersprechen. So gibt das allseits beliebte Prozess-Framework Scrum<\/a> etwa cross-funktionale Teams vor, um Abh\u00e4ngigkeiten innerhalb des Development-Teams zu minimieren. Ein absolut richtiger Grundgedanke der Risikominimierung durch Reduzierung von Abh\u00e4ngigkeiten – aber wer will ernsthaft von Software Engineers gestaltete User Interfaces sehen?<\/p>\n \u201eWir glauben an einen Ansatz, der Personen verschiedener Disziplinen in einem Team vereint und trotz etwaiger, daraus entstehender Abh\u00e4ngigkeiten, effektiv und effizient zusammen agieren l\u00e4sst, sodass der Mehrgewinn an Qualit\u00e4t f\u00fcr das Produkt durch die verschiedenen Expertisen das entstehende Risiko \u00fcberwiegt.\u201c<\/p><\/blockquote>\n Wir bei Centigrade glauben nicht daran, dass eine Person alle Prozess-Schritte des Produkt-Lebenszyklus beherrschen kann (vom Requirements Engineering \u00fcber 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\u00e4ngigkeiten, effektiv und effizient zusammen agieren l\u00e4sst, sodass der Mehrgewinn an Qualit\u00e4t f\u00fcr das Produkt durch die verschiedenen Expertisen das entstehende Risiko \u00fcberwiegt. Und diese interdisziplin\u00e4re Zusammensetzung von Teams hat sich in viele Bereichen als sinnvoll erwiesen, sei es bei Filmen, die auch dadurch besser werden \u2013 oder \u00fcberhaupt nur m\u00f6glich \u2013 indem viele verschiedene Disziplinen daran arbeiten, oder Fu\u00dfball-Teams, die auch nicht nur aus St\u00fcrmer:innen bestehen<\/a>.<\/p>\n Wenn wir in ein UX-Projekt kommen, wollen wir auch nicht bestehende Strukturen zerschlagen und den Scrum-Master-Finger heben, falls gar kein Scrum \u201eby-the-book\u201c gemacht wird. Wir wollen etablierte Methodiken und Tools aus der UX-Welt \u201elean\u201c in bestehende, agile Prozesse integrieren und dazu anhalten, die Zusammenarbeit zwischen allen an der Entwicklung beteiligten Disziplinen und Stakeholdern zu f\u00f6rdern und zu pflegen, um m\u00f6glichst schnell Mehrwert f\u00fcr die letztendlichen Nutzer:innen des Produktes vor dem Hintergrund eines definierten Business-Ziels zu erwirken. Das ist n\u00e4mlich gemeint mit den vier Grunds\u00e4tzen des Agilen Manifesto<\/a>: Menschen arbeiten kollaborativ zusammen, um m\u00f6glichst reaktiv funktionierende Software zu erzeugen. Und wenn wir diese Software auch noch so gestalten, dass sie gro\u00dfartige UX liefert und vom Markt gut angenommen wird, dann haben wir es geschafft.<\/p>\n \u201eDenn entscheidend f\u00fcr die Nutzer:innen ist, dass \u00fcber UX nicht nur zu Beginn eines Projektes gesprochen wird, sondern es auch w\u00e4hrenddessen seinen Weg ins Produkt findet.\u201c<\/p><\/blockquote>\n Herauskristallisiert hat sich so bei uns \u00fcber die Jahre ein flexibler Prozess-Baukasten, Continuous UX<\/a>, dessen Prozessbausteine es erm\u00f6glichen, einen agilen UX-Ansatz an die iterativen und inkrementellen Prozesse unserer Kund:innen anzupassen und \u00fcber die gesamte agile Produktentwicklung hinweg zu etablieren. Continuous UX eben, analog zu Continuous Integration und Continuous Delivery. Denn entscheidend f\u00fcr die Nutzer:innen ist, dass \u00fcber UX nicht nur zu Beginn eines Projektes gesprochen wird, sondern es auch w\u00e4hrenddessen seinen Weg ins Produkt findet.<\/p>\n Damit die Anwendung gelingt, bringen wir nicht nur unsere langj\u00e4hrige Erfahrung im UX Design<\/a> ein, sondern wenden genauso unsere Expertise in der agilen Produktentwicklung und dem agilen Projektmanagement<\/a> an. Daraus resultiert f\u00fcr uns die Rolle des Continuous UX Advis<\/strong>ors<\/strong>, deren wichtigsten Verantwortlichkeiten bei der Begleitung eines Projektes folgende sind:<\/p>\n Beim Project Scoping<\/a> wird der Grundstein f\u00fcr das Projekt gelegt. Wir beleuchten zun\u00e4chst ausschlie\u00dflich die im Kontext des zu entwickelnden Produktes vorherrschenden Potenziale aus Gesch\u00e4ftssicht, definieren gemeinsam f\u00fcr den aktuellen Projektabschnitt ein entsprechendes Business Ziel und schauen uns an, mit welchem minimalen Produktansatz (MVP) die wichtigsten Bed\u00fcrfnisse der wichtigsten Nutzer:innen in einem bestimmten Nutzungskontext erf\u00fcllt werden k\u00f6nnen. Wichtig dabei ist, dass man m\u00f6glichst klein denkt, um schnell wirkungsvolle Ergebnisse zu erzielen, ohne dabei das gro\u00dfe Ganze zu vergessen.<\/p>\n Validierte Nutzer:innen-Bed\u00fcrfnisse sind wichtig f\u00fcr einen Nutzer:innen-zentrierten Ansatz. Sie sind ma\u00dfgeblich f\u00fcr die Priorisierung der Funktionalit\u00e4ten des zu entwickelnden Produktes und geben damit eine Reihenfolge f\u00fcr die Entwicklung vor. Dabei ist es wichtig, sie immer wieder zu pr\u00fcfen, sie zu pflegen und auch mit anderen Anforderungen, wie etwa technischen Restriktionen oder organisatorischen Vorgaben, in Einklang zu bringen.<\/p>\n Neben der ersten Erkundung des L\u00f6sungsraums und der initialen Priorisierung von Nutzer:innen-Bed\u00fcrfnissen ist es wichtig, zu jeder Zeit die richtige Abstraktionsebene der Nutzer:innen-Bed\u00fcrfnissen zu w\u00e4hlen. Zu Beginn sollten sie so abstrakt sein, dass man einen guten \u00dcberblick \u00fcber die im Anwendungskontext der wichtigsten Nutzer:innen identifizierten Bed\u00fcrfnisse erlangt, um sie gegeneinander und gegen\u00fcber weiteren Anforderungen abzugrenzen und zu priorisieren sowie den meist frustrierenden Status Quo der Nutzer:innen und deren \u201eUser Journeys of Pain\u201c empathisch nachvollziehen zu k\u00f6nnen. Geht es aber in die konkrete L\u00f6sungs-Entwicklung, sei es in der Konzeption, im Visual Design als auch im Software Engineering, kann eine niedrigere Abstraktionsebene dabei helfen, L\u00f6sungen m\u00f6glichst vollst\u00e4ndig und genau zu kommunizieren und umzusetzen. Dabei ist die Wahl der richtigen Flugh\u00f6he eine Herausforderung und Entscheidung, die nur immer wieder \u00fcberpr\u00fcft und an den aktuellen Kontext angepasst werden muss.<\/p>\n Der Nutzer:innen-zentrierte Ansatz erscheint zun\u00e4chst sehr altruistisch. Aber nat\u00fcrlich muss man anerkennen, dass hinter jedem Projekt und Produkt wirtschaftliche Interessen stecken. Daher ist der ausschlie\u00dfliche Fokus auf Nutzer:innen nicht zielf\u00fchrend, vor allem eben nicht f\u00fcr 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\u00f6st. Daher ist es ratsam, Stakeholder nicht nur beim regelm\u00e4\u00dfigen Abstimmen von Anforderungen einzubinden, sondern ihnen die M\u00f6glichkeit zu geben, an der gesamten agilen Produktentwicklung teilzuhaben und mitwirken zu k\u00f6nnen.<\/p>\n Ist der Projektrahmen abgesteckt, geht es an die Umsetzung. Damit diese effektiv und effizient gelingt, braucht es ein f\u00e4higes und engagiertes Development-Team. Dieses kann mit den \u00fcblichen, agilen Praktiken bef\u00e4higt und gesteuert werden. Zu beachten ist allerdings, dass es sich um ein interdisziplin\u00e4res Team handelt, dessen Fokus sich bei der Erf\u00fcllung seiner Aufgaben stark unterscheidet. Auch hier empfiehlt es sich, den Grunds\u00e4tzen des Agilen Manifesto<\/a> treu zu bleiben und das Team als soziales Gef\u00fcge so zu unterst\u00fctzen, dass die vorhandenen Expertisen gemeinsam bei jedem Inkrement einen gro\u00dfen Wert f\u00fcr das Produkt erarbeiten.<\/p>\n 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\u00e4ndigen Wertsch\u00f6pfung f\u00fcr das Produkt arbeiten. Dadurch wird sichergestellt, dass die Entwicklung effektiver (vollst\u00e4ndiger und genauer), risiko\u00e4rmer (kontinuierliche Erf\u00fcllung von Nutzer:innen-Bed\u00fcrfnissen) und steuerbarer (Anpassung an Kontext\u00e4nderungen) ist, als bei traditionellen Arten Software zu entwickeln, wie etwa beim Wasserfallmodell<\/a>. Die Steuerung der Kapazit\u00e4ten ist dabei nicht immer einfach. Sie ist aber notwendig, um eine hohe Produktqualit\u00e4t sicherzustellen. Aus Continuous UX-Sicht bedeutet Continuous Delivery unter anderem, dass die Arbeit eines konzeptuellen Designers nicht mit der \u00dcbergabe an Software Engineers endet, sondern dass sie sich in Form von tiefgehenden Reviews des potentiellen, neuen Inkrements kontinuierlich fortsetzt.<\/p>\n \u201eDas Verinnerlichen und Beherzigen der Grunds\u00e4tze des Agilen Manifesto helfen dabei nicht nur, agil Software zu entwickeln, sondern f\u00f6rdern die Integration eines kontinuierlichen und ganzheitlichen UX-Ansatzes, der in der heutigen Zeit unabdingbar ist und ma\u00dfgeblich zum Produkterfolg beitr\u00e4gt.\u201c<\/p><\/blockquote>\n Werden diese Bausteine richtig angewendet, wie wir sie auch in unserem Academy Training „Scrum meets UX“<\/a> ganz praktisch schulen, gelingt das Zusammenspiel aus UX Design in einem Nutzer:innen-zentrierten Ansatz und der allgegenw\u00e4rtigen, agilen Produktentwicklung. Das Verinnerlichen und Beherzigen der Grunds\u00e4tze des Agilen Manifesto<\/a> helfen dabei nicht nur, agil Software zu entwickeln, sondern f\u00f6rdern die Integration eines kontinuierlichen und ganzheitlichen UX-Ansatzes, der in der heutigen Zeit unabdingbar ist und ma\u00dfgeblich zum Produkterfolg beitr\u00e4gt.<\/p>\n <\/p>\n Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen<\/a> an!<\/strong><\/p>\nZusammenf\u00fchren, was zusammengeh\u00f6rt<\/h2>\n
UX \u00fcber den gesamten agilen Produktentwicklungs-Zyklus etablieren<\/h2>\n
1. Project Scoping<\/a><\/h3>\n
2. User Requirements Management<\/a><\/h3>\n
3. Ideation und User Story Workshop<\/a><\/h3>\n
4. Stakeholder Management<\/h3>\n
5. Bef\u00e4higung des Development-Teams<\/h3>\n
6. Etablierung von Sprint-Zyklen<\/h3>\n