Covid war und ist der Katalysator für die Digitalisierung. Durch die Pandemie stieg die Digitalisierungsrate in Unternehmen und vor allem für die Konsumenten sprunghaft an.
Ob es gefällt oder nicht, aber Amazon’s Umsatz stieg im 1. Quartal 2021 um 60,4%.
Physikalische Produkte wurden digital wo es nur ging. Von dem Autoschlüssel bis zur Briefmarke gibt es mehr digitale Produkte als je zuvor. Produkte bei denen wir uns in der Vergangenheit nur schwer vorstellen konnten sie digital zu nutzen, sind jetzt Teil unserer täglichen Routinen.
Supermärkte liefern jetzt Ihre Ware direkt zum Kunden oder bieten einen schnelle Pickup an nachdem online bestellt, beworben und bezahlt worden ist.
Für viele kleine Unternehmen war die Digitalisierung aber auch die einzige Möglichkeit zu überleben. Warum und wie fragen Sie sich jetzt? Naja, weil es keine Raketenwissenschaft mehr ist, einen online Store auf einer der zahlreichen Cloud Plattformen zu eröffnen und schnelle Ergebnisse zu sehen. Weil es Social Media möglich macht schnell im eigenen Netzwerk auf sich aufmerksam zu machen und nicht zuletzt, weil die Endkunden genau danach gesucht haben.
In der Vergangenheit hat die Angst zur Veränderung oft die digitale Revolution gebremst. Die weltweite Krise hat dazu geführt, dass vor allem Ihre Kunden, wir alle als Konsumenten, digitale Lösungen für unsere täglichen Probleme gesucht und gefunden haben.
Außerdem kommen neue Herausforderungen hinzu. Sicherheit ist eine davon. Denn wenn wir über Digitalisierung von Produkten und Services sprechen, müssen wir zwangsläufig auch über IT Sicherheit sprechen und Investieren. – Was habe ich letztens auf einem Social Network gelesen: Das ganze Jurassic Park Fiasko wäre nicht passiert wenn der alte Milliardär mal mehr als nur einen IT Spezialisten eingestellt hätte. Kleiner Spaß. Der Film ist 29 Jahre her. Aber, mal ehrlich, hier fällt wahrscheinlich jedem von uns ein Beispiel ein, was zum Thema IT Sicherheit verbessert werden könnte, aber nicht so hoch auf der Prio Liste steht.
Jedes Unternehmen und jede Abteilung kann die Digitalisierung als Chance nutzen. Die Herausforderung dabei die Herangehensweise. Denn wenn man sich dem Thema Digitalisierung nähert, müssen wir erstmal alles auf den Kopf stellen. Wir hinterfragen alles. Und das endet nicht oft darin, dass wir ganz viele Puzzelteile vor uns haben. Das ist so ein bisschen wie wenn ich meine kleiner Sohn sage er soll sein Zimmer aufräumen und er steht vor dem Chaos und hat keine Ahnung wo er anfangen soll. Er sucht eine Struktur oder Anleitung der er folgen kann.
Die gute Nachricht ist, dass es Projektmodele gibt sich dieser Herausforderung im Business geordnet zu stellen.
Design Thinking ist eine bewährte Möglichkeit sich aus dem Chaos heraus zubewegen und die Anforderungen sowie Umsetzung in kleine Teile, unser Produkte, zu spezifizieren.
Es ist eine Methode, neue und innovative Ideen zu entwickeln. Die verschiedenen Phasen dabei helfen zuerst einmal das Problem zu verstehen, dann mögliche Lösungen zu generieren und diese mithilfe von Scrum in Prototypen zu entwickeln.
Dabei steht immer der Benutzer im Vordergrund. Er bildet bei allem das Herz des Prozesses ab.
Design Thinking bedeutet, aber auch dass es konstantes Feedback zwischen den Entwicklern und den Benutzern geben muss. Auch hierbei hilft Scrum mit Daily Scrum Calls und natürlich den obligatorischen Reviews und Retrospektiven zum Ende eines jeden Sprints. Aber zu Scrum, Begrifflichkeiten und den Prozessen später etwas mehr.
Der Design Thinking Ansatz hilft also das große Ganze in kleine Teile, unsere Produkte, zu zerlegen, sie zu ordnen und zu strukturieren um sie danach kontinuierlich abzuarbeiten. Hierbei erhalten wir in sehr kurzer Zeit die ersten praktische Ergebnisse und können diese bewerten.
Das Agile Framework ist kein Hexenwerk was nur verrückte Startups in Berlin Kreuzberg in einem CoWorking space benutzen. Nein. Ganz im Gegenteil. Sehr traditionelle Unternehmen benutzen Agile Ansätze um sich der Transformation zu stellen. Denn agile Transformation bedeutet eine komplexe Veränderung zu vollziehen, die nicht nur die IT-Organisation betrifft, sondern das gesamte Unternehmen ja, im besten Fall kommt die Anforderung zur Veränderung aus dem Business und nicht der IT. Ein Commitment des Managements ist somit eine notwendige Voraussetzung für das Gelingen einer jeden Veränderung.
Erwarten Sie vom Agile Framework eine Sammlung von Methoden und Tools, die die Projekte steuern und immer wieder hinterfragen. Nicht jede der Methoden ist für jeden Einsatz geeignet und selbst unser bewährtes Wasserfall Model kann und wird an der ein oder anderen Stelle integriert.
Die Methoden und Tools unterscheiden sich in Daily Use, Project Use oder Product use. Je nachdem was wir erreichen wollen und was der Anwendungszweck ist.
Im Daily use finden wir Methoden und Tools, die wir unabhängig vom Projekt alle täglich einsetzen können. Hierunter finden sich Kanban Boards, User Storys, Canvas und viele mehr.
Ich benutze diese täglich, denn sie dienen allesamt der Kollaboration. Der Zusammenarbeit im Team. Der Dokumentation des Fortschrittes und der Erwartungshaltungen. Sie helfen also, gerade in Zeiten der Pandemie, in denen wir nicht oft zusammensitzen können, jedem Einzelnen dabei die täglichen Arbeitspakete zu bewältigen und zu managen.
Aber in diesem Blog heute liegt unser Fokus in dem Projekt- und Produkt Use. Denn das ist es was ich machen. Customized Products mit und für meine Kunden entwickeln und umsetzen.
Deshalb liegt unser Fokus heute auf Scrum und den Use Cases. Und jetzt, sollte auch klar sein, warum wir den Blog „Bridgeing the Gap“ genannt haben, denn Use Cases helfen dabei eine Brücke zu bauen zwischen dem Benutzer und dem Ziel welches dieser erreichen möchte und der IT.
Scrum ist eine der bekanntesten agilen Ansätze und schon vielfach bewährt. Die fundamentalen Ansätze stammen aus der physischen Produktentwicklung. Aber Scrum, so wie wir es heute kennen und nutzen, ist dazu ausgerichtet Software zu entwickeln bzw. diese zu customizen. Ausgangspunkt für die Entwicklung von Scrum in den 1980er und 1990er Jahren war, dass eine Software-Entwicklung nicht von Anfang bis Ende präzise durchgeplant werden konnte. Daran hat sich auch bis heute nichts verändert. Es ist schlichtweg nicht möglich bei komplexen Softwarelösungen mit einem Rutsch alle Anforderungen 1:1 in der gegebenen Zeit umzusetzen. Wer das probiert, wird schnell feststellen, dass die Zeit davonläuft und wenn das Produkt dann endlich zu fertig ist, ist es bereits veraltet.
Deshalb erfolgt die Produktentwicklung bei Scrum iterativ in Feedback-Schleifen von maximal 4 Wochen, den sog. Sprints. Bei jedem Sprint soll eine verwendbare Produktversion entstehen, das Inkrement – Inkrement deshalb, weil mit jedem Sprint ein Teil zum finalen Produkt hinzukommt. Hierdurch bekommt man schnelles Feedback über die neue Funktion. Es ist wichtig bereits zu jedem Use Case den man sich überlegt hinzuzufügen, wie man dessen Erfolg messen möchte. Denn wenn er nicht erfolgreich ist, kann er wieder verschwinden oder muss verändert werden.
Scrum sieht keine Projekte, im eigentlichen Sinne vor. Mit der Projektbrille könnte man Scrum so interpretiert werden, dass jeder Sprint ein in sich abgeschlossenes kleines Vorhaben ist. Es gibt Anforderungen, eine Planung, die Arbeit im Sprint, eine gemeinsame Begutachtung der Ergebnisse und ein “Lessons-Learned” bzw. Reviews.
Im wesentlichen gibt es drei Rollen im Scrum. Den Product Owner, den Scrum Master und die Entwickler.
Der Product Owner arbeitet auf Basis der Vision des Firmen Managements oder den Anforderungen der Benutzer aus den jeweiligen Abteilungen zusammen und versucht so herauszufinden, wie das gewünschte Produkt aussehen könnte und was, für die Benutzer die wertvollsten Eigenschaften sein werden. Die zu entwickelnden Funktionalitäten beschreibt der Product Owner im Product Backlog als Use Case. Dieses ist der Arbeitsvorrat für das Entwicklungsteam und wird von diesem konsequent in der vorgegebenen Reihenfolge und Priorität abgearbeitet. Diese Abarbeitungen sind die Sprints. Hierbei ist natürlich darauf zu achten, dass zuerst einmal Grundlangen der Software zur Verfügung stehen. Vielleicht muss auch erstmal, in einem klassischen Wasserfall Projekt die ein oder andere Voraussetzung implementiert werden. Als Beispiel das bereitstellen von HW, SW oder Datenbanken.
Der Product Backlog wird nicht vollständig sein, wenn mit dem Vorhaben gestartet wird. Also nicht wie bisher, den kompletten Umfang enthalten. Ein Arbeitsvorrat für ein bis drei Sprints ist ausreichend. Der Product Owner füllt den Product Backlog nach und nach anhand des Feedbacks und neuen Anforderungen auf.
Zu Beginn eines Sprints findet das Sprint-Planning statt. Dabei präsentiert der Product Owner dem Entwicklungsteam den priorisierte Product Backlog. Das Entwicklungsteam entscheidet eigenständig, wie viele der am höchsten priorisierten Anforderungen es im anstehenden Sprint umsetzen kann, übernimmt diese in das Sprint Backlog und plant die Tätigkeiten im Sprint.
Das Sprint Backlog stellt einen für die Sprintlänge weitgehend stabilen Arbeitsvorrat dar, während das Product Backlog die Dynamik des Umfelds auffängt und diese vom Entwicklungsteam fernhält. Das Product Backlog kann jederzeit vom Product Owner verändert werden.
Im Sprint-Review,, am Ende des Sprints präsentiert das Entwicklungsteam dem Product Owner und ggf. anderen Entscheidern das Inkrement, d.h. den Zuwachs der Funktionalität. Diese begutachten das Inkrement und erstellen bei Bedarf neue Einträge für das Product Backlog. Eine aus Projekten bekannte formale Abnahme gibt es nicht. Der Sprint wird auf keinen Fall verlängert. Was nicht fertig geworden ist, kommt wieder in den Produkt Backlog und steht damit wieder als Arbeitsvorrat zur Verfügung.
Abschließend erfolgt die Sprint-Retrospektive, in der das gesamte Scrum-Team den Entwicklungsprozess sowie die Zusammenarbeit im vorangegangenen Sprint analysiert und ggf. Maßnahmen für die Verbesserungen der Arbeitsorganisation beschließt. Der Sprint endet mit dem Ende der Retrospektive. Direkt danach startet der nächste Sprint, wieder mit dem Sprint-Planning oft wird dies also in einem ganztages Meeting zusammengefasst.
Puh.. das war viel ich weiß. Aber wir müssen grundlegend verstehen wozu ein Use Case führt, damit wir verstehen wofür wir ihn brauchen und warum er so wichtig ist. Denn auch hier gilt die alte Regel: „Garbage in – Garbage out“.
Kommen wir also zu den Use Cases. Ein Use Case beschriebt das Vorhaben und seine Auswirkung. Eine Interaktion eines Aktors mit einem System und seinem Owner und zwar ganz einfach und bildlich. Der Use Case hilft dem Product Owner “smate” Fragen zu stellen. So kann er sicherstellen, dass er die Anforderung auf eine einfache Weise klar verstanden hat.
Aber wie macht man das am einfachsten? Es gibt ein paar grundlegende Themen zu jedem UseCase. Die Groundwork. Diese folgt in der Regel einer einfachen Tabelle mit den wichtigsten Informationen zu dem Case. Dazu gehört: Ein Titel, eine einfache Beschreibung des Ziel, eine Bereich und ggf. Sub Bereiche die es betrifft, einen Verantwortlichen aus dem Bereich, ggf. andere Use Cases die dazugehören, die Nachverfolgbarkeit und, last but not least, die Möglichkeiten den Erfolg zu messen und wie das passieren soll. Also die Key Performace Indicators. Das sollte bei einer Idee die Grundlage bilden und sollte nicht allzu schwer sein. – Im übrigen, muss das nicht direkt als erstes ausgefüllt und besprochen werden. Einige Punkte werden vielleicht erst nach der Visualisierung klar und können verschriftlicht werden. Andere müssen vielleicht im Use Case mit entwickelt werden. Wie z.B. die KPI’s.
Erst jetzt geht es an die eigentliche Erfassung der Essentials. Der wichtiger Teil der Essentials, und damit des gesamten Use Cases, ist das Visualisierungsmodel. Und jetzt aufpassen, denn das ist das wichtigste des ganzen Vortrages.
In dem Visualisierungsmodel gibt es nur drei wesentliche Kernelemente. Beginnen wir mit den Aktoren. Als Aktoren bezeichnen wir alle Personen, Organisationen, Geräte oder andere Systeme, die Einfluss auf unser System nehmen. – Wir habe unser, zu entwickelnde, System. Das ist unser Fokusbereich und als letztes haben wir die Beziehung, Relationships dazwischen.
Gehen wir das mal an einem Beispiel durch. Wir wollen eine einfache Web-Applikation erstellen und in unserem Beispiel geht es um den Login eines Users.
Wir haben also einen Kunden als Aktor. Dieser macht einen Seitenaufruf in unserem System. Da es ein geschütztes System ist, wird er als erstes nach einem User und Passwort gefragt. Wir sehen also den Seitenaufruf mit einer sogenannten Standard Relationship. Dieser gelangt zu dem Base Use Case Seitenaufruf. Von Hier geht es weiter in einer include Relationship zur Passworteingabe, was ein eigener Use Case ist. Soweit so gut. Nun ist das nur soweit gut, als dass der Kunde vielleicht noch ein bisschen mehr machen muss. Z.B. erstmal einen Account bekommen. Also haben wir hier einen weiteren Use Case. Und schon kommt ein zweiter Aktor ins Spiel. Nämlich der Admin, der einen Use Case braucht um einen Account zu erstellen. Soweit das, was wir den Happy Way bezeichnen. Also alles läuft wie erwartet und glatt. Der Kunde kann einen Account und kann sich einloggen. Applikation fertig. – Nun ja, wir wissen alle, dass das nicht der Realität entspricht und Menschen Ihr Passwort vergessen. Wir schauen uns also nochmal den Usecase case „Passwort eingeben an“ denn der bekommt jetzt eine Extension. Nämlich genau dann, wenn der User sein Passwort falsch eingibt. Wir nennen es mal Authentifizierung. Die Folge ist ein neuer Use Case nämlich „Lock Account“. Dieser tritt dann in Kraft, wenn der Benutzer 3x sein falsches Passwort eingegeben hat. Diesen Prozess muss ein Admin bearbeiten. Deswegen bekommt er auch die direkte Relationship dazu. Um das zu tun, bekommt er einen neuen Use Case nämlich Unlock Account.
Soweit zu dem Visualisierungsmodel. Zu den Essentials gehören aber noch ein paar weitere wichtige Punkte, die beschrieben werden wollen. Als erstes, die Requierments. Also alles das, was wir brauchen um den Use Case zu bedienen. Das kann SW, Datenbanken usw. sein. Zweitens, eine Beschreibung des „happy ways“ also eine Verschriftlichung dessen, was im besten Fall passiert. Sie kann aber auch farblich in das Visualisierungsmodel eingezeichnet werden. Hierdurch wird nochmal deutlich, was eigentlich passieren soll. Außerdem darf ein alternativer Prozess nicht fehlen. In unserem Beispiel könnte ein alternativer Prozess zur Authentifizierung sein, dass der Kunde das telefonisch mit einem Admin bespricht und sich dort authentifiziert.
Jetzt habe ich zwar viel geredet, aber eigentlich ist das Bild nun für jeden klar, was mit unserem Use Case passieren soll. Egal ob Entwickler, Admin oder Kunde. Jeder versteht was passieren soll. Und zwar auf Anhieb. Natürlich ist das ein recht einfacherer Use Case, aber es verdeutlicht, wie wir mit Use Cases die Brücke bauen können zwischen den Anforderungen und dem Entwickler, der den Code schreibt und im Zweifel genau das tut, was ihm aufgetragen wird. Nicht mehr und nicht weniger.
Die Digitalisierung ist nicht aufzuhalten. Nutzen Sie die Chance. Denn es ist Eine. Für jedes Unternehmen.
Schauen Sie nicht nach einer Referenz, sondern seien sie Eine.
Benutzen sie Agile Methoden, die zu schnellen Ergebnissen führen und einen völlig neuen Blick auf Ihre Kunden Kontakte liefern.
Denn der Design Thinking Ansatz stellt Ihre Kunden und Mitarbeiter in den Mittelpunkt.
Mit Use Cases stellen sie zusammen mit den Verantwortlichen smarte Fragen.
Den es geht nicht um ein Produkt, oder ein Feature. Es geht darum, was wir gemeinsam daraus machen.