Hans-Thoma-Str.33, Heidelberg
+491702415877

Anders arbeiten

Anders arbeiten

Die Digitalisierung macht bessere Methoden möglich, um Produkte zu entwickeln. Digitalisierung macht „agil“ und benötigt agile Prozesse. Doch was ist Agilität konkret?

Wie schon mehrfach angesprochen: Wir befinden uns mitten in einer Zeit des technologischen und damit kulturellen Umbruchs, der digitalen und demographischen Transformation, der unzähligen kleinen und größeren Disruptionen. „Viele Märkte verändern sich heute so schnell, dass Unternehmen mit klassischen Strukturen nur noch schwer darauf reagieren können.“, schreibt Valentin Nowotny vom Upload-Magazin und leitet damit seine Kapitel zur „Agilität“ ein. „Wandel wird zur Norm und Teams bekommen wieder die Verantwortung für ihr eigenes Tun. Das kann zugleich den positiven Nebeneffekt haben, gerade die leistungsstärksten und fähigsten Mitarbeiterinnen und Mitarbeiter zu motivieren.“

Die digitale Welt verändert sich per definitionem rasanter als die alte analoge. Wir haben schnelleren und umfassenderen Zugang zu Wissen und Daten, schaffen durch virtuelle Teams größeren und besseren Output und können mit skalierbaren Tools schnellere Ergebnisse erzielen. Mit Projektmanagement aus der analogen Zeit können wir gegen die Innovationsgeschwindigkeit der kleinen Start-ups nicht ankommen.

Auch Agilität hat ein Manifest

Aha, schon wieder ein Manifest. Diesmal von einer ganzen Gruppe von Software. Entwicklern, die schon 2001 die Grundprinzipien agiler Softwareentwicklung in ein bindendes Manifest geschrieben haben – und damit eine Revolution auslösten in eine Branche, die bisher ausschließlich auf lineare Methoden wie beispielsweise den „Wasserfall“ gesetzt hat.

Manifest für agile Softwareentwicklung

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionenmehr alsProzesse und Werkzeuge
Funktionierende Softwaremehr alsumfassende Dokumentation
Zusammenarbeit mit dem Kundenmehr alsVertragsverhandlung
Reagieren auf Veränderungmehr alsdas Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.“

Was Agilität bedeutet, erläutert Mark Shead in seinem animierten Erklärvideo.

Mark Shead: What is Agile?

Die Prinzipien

Das „Agile Manifesto“ definiert zwölf Prinzipien, die die Kundenzentriertheit sehr deutlich machen.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Einfachheit –– die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell. .

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Heiße Anforderungs-änderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Agile Methoden ersetzen mehr und mehr klassische Projektmanagement-Methoden – schauen wir uns eines dieser linearen Modelle an.

Wasserfall-Modell

Das Wasserfall-Modell kommt vor allem in sehr hierarchisch organisierten Unternehmen zum Einsatz: Große Projekte werden in mehrere Stufen bzw. Phasen unterteilt, die aufeinander aufbauen und in einer festgelegten Reihenfolge durchgeführt werden. Ein Internet-Relaunch beispielsweise wird in die fünf abgeschlossenen Phasen Konzeption, Design, technische Umsetzung, Roll-out und Support eingeteilt. Einmal getroffene Entscheidung sollen und können nicht mehr rückgängig gemacht werden.

Das Wasserfall-Modell bedeutet hohe Planungssicherheit, auch umfangreiche Projekte können durch die klare Struktur präzise geplant werden. „Wasserfall“ eignet sich daher besonders für Projekte, für die bereits konzeptionelle Geschwister existieren und die daher ohne konzeptionelle Korrekturschleifen auskommen. Ist das Projekt aber völlig neu und existieren keine solchen „Vorbilder“, können die einzelnen Planungsschritte weder präzise vorhergesagt noch Aufwände abgeschätzt werden. In solchen Fällen ist das Wasserfall-Modell ungeeignet: Fehler in der Konzeption häufen sich gegen Ende des Projekts. Sie dann zu korrigieren ist entweder nicht mehr möglich oder sehr, sehr aufwändig. entsprechend teurer als es eine frühzeitige Überarbeitung gewesen wäre. Zudem sieht man das Ergebnis erst ganz zum Schluss. Das dauert oft einfach zu lange und macht das ganze Projekt dann obsolet. Besser – das wird deutlich – sind also „agile Techniken, die schneller zu ersten Ergebnissen führen, mit denen man dann besser weiterarbeiten kann.

SCRUM

Eine der bekanntesten agilen Methoden ist „SCRUM“, zu Deutsch: „Gedränge“. SCRUM geht davon aus, dass viele Projekte einfach viel zu komplex sind, als dass sie in einen festen Plan gegossen werden könnten. Vieles an solchen Projekten ist im Vorfeld unklar. Daher macht SCRUM aus diesem Faktum eine Tugend und schafft schnell Zwischenergebnisse, die diese Unklarheiten zu beseitigen helfen. Hat man erstmal ein Zwischenergebnis, kann man die nächsten Schritte effizienter und bewusster angehen, sieht bereits Fallstricke und Sackgassen und kann das Projekt rechtzeitig modifizieren. Weil langfristige Pläne hier nicht funktionieren, wird das Projekt in „Sprints“ aufgeteilt. Das sind kurze Bearbeitungszyklen, in denen klar definierte Aufgaben bearbeitet, getestet und abgeschlossen werden. Optimalerweise dauert ein Sprint zwischen einer und vier Wochen. Neben dem Produkt wird so auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Sprint erstellt. Damit fokussiert sich die Projektplanung auf das Wesentliche.

Der Entwicklungszyklus in Scrum kann durch drei Begriffe zusammengefasst werden: Apply, Inspect, Adapt.

  1. Apply: Anwenden
    • endlich mal anfangen(!)
    • etwas entwickeln
    • aktiv eine Idee umsetzen
    • überprüfbare Fakten schaffen
  2. Inspect: Prüfen
    • kritische Erfolgskontrolle
    • Fehler in Produkt und Prozess analysieren
  3. Adapt: Anpassen
    • Spezifikation präzisieren
    • Prozess verbessern
    • ggf. alternativ vorgehen
    • auch mal (rechtzeitig!) etwas „wegwerfen“

Ziel von SCRUM ist es, hochwertige Produkte schnell und kostengünstig entsprechend einer vorher formulierten Vision zu entwickeln. Oft nutzt man dazu User Stories, also Produktanforderungen in Form von Eigenschaften aus Anwendersicht. Diese Anforderungen werden im Product Backlog dokumentiert und in den Sprints umgesetzt. Am Ende eines Sprints steht ein auslieferungsfertiges Teilprodukt, das Product Increment. Zum Schluss dieses Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.

User Storys

User Storys bringen die Vision und damit das Ziel der Entwicklung auf einen Satz

Die User Story hat einen Titel, eine kurze Beschreibung und einige Akzeptanz-Kriterien.

  • Tipp 1: Focus on the User!
    Klar, die User Story konzentriert sich auf die Benutzer des Produkts. Daher: Schreibt die Stories ausschließlich aus der Perspektive der unterschiedlichen Benutzer des Produktes: Endbenutzer, Firmenbenutzer, Administratoren, usw.
  • Tipp 2: User Stories zu schreiben ist Teamwork!
    Die User Story muss den Dialog des Teams mit Kunden, Benutzern und anderen Stakeholdern fördern! Sie ist Diskussionsgrundlage und nicht Ersatz für den Dialog! Profitiert von der Kreativität und dem Wissen des Teams und den Stakeholdern und verfeinert die User Stories im Teamwork für das nächste Sprint Planning Meeting.
  • Tipp 3: Akzeptanz-Kriterien nicht vergessen!
    Akzeptanz-Kriterien machen erst die User Story! Wann die User Story fertig ist, hängt von den definierten Akzeptanz-Kriterien ab! Nach diesen Kriterien wird die User Story getestet und gilt erst dann für komplett verwirklicht und akzeptiert! 3 bis 5 Akzeptanz-Kriterien sind eine gute Grundlage für die Überprüfung jeder Produkt-Funktion!
  • Tipp 4: Macht Eure User Stories einfach, knapp, präzise und sichtbar
    Haltet Eure User Story einfach, knapp und präzise! Und macht sie sichtbar: Schreibt sie auf eine Karte und klebt sie an den Bildschirm, damit ihr sie immer vor Augen habt.
    Hier verbindet sich die User Story schön mit der Persona:
    • Was benötigen die „User“,
    • was ist ihnen wichtig?
    • Warum könnte dieses oder jenes Feature ein Problem der User lösen?
  • Tipp 5: Es gibt nicht nur User Stories!
    Nicht alles kann und soll in eine User Story gepackt werden. Es ist ohnehin nicht möglich, jeden einzelnen Aspekt des Produkts in einer User Story zu formulieren – also fühlt Euch nicht dazu verpflichtet. Oft sind Mockups oder andere Visualisierung besser geeignet. Benutzt Eure Kreativität, um die Aufgabe auf beste Art und Weise zu lösen.

Design Thinking

Design Thinking geht davon aus, dass Probleme besser gelöst werden können, wenn Menschen unterschiedlicher Disziplinen

Das Verfahren orientiert sich an der Arbeit von Designern, die als eine Kombination aus Verstehen, Beobachtung, Ideenfindung, Verfeinerung, Ausführung und Lernen verstanden wird.

Design Thinking ist sehr stark interdisziplinär und aufs praktische „Machen“ ausgerichtet. Schon sehr früh baut man Prototypen, an denen man die wesentlichen Funktionen ablesen kann und in einer folgenden Iteration verbessert, verfeinert oder verwirft.

Dieser iterative Prozess besteht in der Regel aus sechs Schritten:

  1. Verstehen: Im ersten Schritt geht es um das Verständnis des Problems, was in der Wahl einer geeigneten Fragestellung mündet, welche die Bedürfnisse und Herausforderungen des Projekts definiert.
  2. Beobachten: Es folgt eine intensive Recherche und Feldbeobachtung, um wichtige Einsichten und Erkenntnisse zu gewinnen und die Rahmenbedingungen des Status Quo zu definieren.
  3. Point-of-View: Die gemachten Beobachtungen werden dann auf einen einzelnen, prototypischen Nutzer heruntergebrochen, dessen Bedürfnisse in einer klar definierten Brainstorming-Frage kondensiert werden.
  4. Ideenfindung: Dieser Schritt ist eines der Kernelemente des Design Thinkings und besteht vor allem aus dem Brainstorming, welches der Entwicklung und Visualisierung unterschiedlicher Konzepte dient.
  5. Prototyping: Zum Testen und Veranschaulichen der Ideen werden erste, aufwandsarme Prototypen entwickelt und an der Zielgruppe getestet.
  6. Verfeinerung: Auf Basis der durch Prototypen gewonnenen Einsichten wird das Konzept weiter verbessert und solange verfeinert, bis ein optimales, nutzerorientiertes Produkt entstanden ist. Dieser Iterationsschritt kann sich auf alle bisherigen Schritte beziehen.

Zu den wichtigen Methoden des Design Thinking, die vor allem im Marketing eingesetzt werden, zählt das Customer Journey Mapping. Also: Was wollen die Kunden, welche Erlebnisse und Emotionen haben sie an den verschiedenen Touchpoints (Kundenschnittstellen und Vertriebskanäle wie Shop, Telefon, Email, Web, App usw.), wie läuft der Kaufvorgang ab, was passiert „after Sales“? Wie ist der Kundenservice? Was passiert am Ende der Produktlebenszeit?

Als zweite wichtige Methode können Nutzermodelle einer Gruppe von Menschen mit konkreten Merkmalen und Verhaltensweisen in der Mensch-Computer-Interaktion erstellt werden – die bereits bekannte Persona.

Mit der Digitalisierung der Kundenkommunikation auf immer mehr verfügbaren Kommunikationskanälen und zunehmender Diversifizierung der Absatzwege werden derartige Verfahren immer wichtiger für Kundenbindung und Vertriebserfolg.
aus: Wikipedia

https://www.youtube.com/watch?v=pXtN4y3O35M

Kanban – die „Karte“

Das ursprüngliche Kanban-System wurde 1947 von Taiichi Ohno bei Toyota entwickelt. Das Unternehmen war amerikanischen Autobauern deutlich unterlegen und deutlich unproduktiver. Ohno beschrieb seine Idee so: „Es müsste doch möglich sein, den Materialfluss in der Produktion nach dem Supermarkt-Prinzip zu organisieren, das heißt, ein Verbraucher entnimmt aus dem Regal eine Ware bestimmter Spezifikation und Menge; die Lücke wird bemerkt und wieder aufgefüllt“. Ungefähr so wie in einem Cola-Automaten, in dem die Flaschen so lange nachrutschen, bis zum Schluss eine Bestellkarte im Fach liegt. In traditionellen, zentral gesteuerten Planungssystemen wird der gesamte Materialbedarf an einer zentralen Stelle bis ins kleinste Detail vorausgeplant. Das ist unflexibel und führt zu einer hohen Vorratshaltung. Kanban dreht die Verantwortlichkeiten herum: Nicht die Zentrale plant die Vorräte, sondern der Verbraucher bestellt kurzfristig nach. Im Projektmanagement heißt das: Nicht ein zentraler Vorabreiter verteilt die Arbeit und das nötige Material, sondern die Mitarbeiter ziehen sich, was sie brauchen, selbsttätig. Dieses agile Prinzip wird im Projektmanagement von Start-ups entweder über physische Kanban-Boards oder über virtuelle Boards wie etwa mit Trello nachgeahmt.

Agiles Projektmanagement mit Trello

 In Trello erhält jedes Projekt ein eigenes Board. Dieses Board kann beliebig viele Listen aufnehmen – jede Liste kann beispielsweise ein „Milestone“ des Projektes sein. Innerhalb der Listen erstellt man dann einzelne Kanban-Karten – jede Karte ist eine Aufgabe, die verschiedene Eigenschaften haben kann. An die Karte können Materialien wie Fotos oder Word-Dokumente angeheftet werden, sie kann als Aufgabe einer Person zugewiesen werden, erhält ein Ablaufdatum – und kann intuitiv mit der Maus zwischen den Listen (und auch den Boards) hin- und hergeschoben werden. Daraus entsteht ein Workflow: Aufgaben können so von einer Liste, bspw. „To do“, in eine andere („Erledigt!“) verschoben werden. Die Karten können mit farbigen Labels unterschiedlichen Kategorien zugeordnet werden und helfen so, den Stand aller Aufgaben inkl. aller Materialien und Teammitglieder im Blick zu behalten.