Visual RE – Was ist das? & Wozu ist das gut?

Visual RE – Was ist das? & Wozu ist das gut?

Visuel RE ist ein Set an Denkweisen und Methoden, die in der Produktentwicklung helfen, schneller ein gemeinsames Verständnis zu erreichen.

Der Begriff Visual RE steht zunächst mal für
Requirements Engineering mit visuellen Methoden“.
Visual RE steht aber auch für
Requirements Exploration, also einen iterativen Prozess, in dem wir mit Hilfe schneller Feedbackzyklen herausfinden, was der Anwender wirklich braucht.

Requirements Engineering wird ja nun schon seit Jahren erfolgreich eingesetzt. Wozu braucht es jetzt eigentlich Visual RE?

Visual RE adressiert im Wesentlichen die folgenden zwei Punkte:

  1. Das Gesamtbild ständig vor Augen zu haben.
  2. Unterstützen eines kontinuierlichen Dialogs mit dem Ziel des gegenseitigen Verständisses.

Informationen, die irgendwo abgelegt werden, sind nicht mehr präsent.
Aus den Augen aus dem Sinn. Visuell arbeiten bedeutet also, das Gesamtbild ständig vor Augen zu haben und aktiv damit zu arbeiten.

Das fördert zielgerichtetes Arbeiten, weil man den Kontext besser einsortieren kann. Außerdem wird kooperatives Arbeiten optimal unterstützt.

Beispiel dafür ist ein Kanban-Board, in dem die Arbeit eines Team visuell abgebildet ist und jeder im Team sehen kann, welche Arbeit gerade von wem in welchem Schritt bearbeitet wird. Sehr hilfreich z.B., wenn mehrere Personen (Product Owner, Requirements Engineers, UX-Experten, etc.) gemeinsam an Anforderungen zu einem Produkt arbeiten. Ein weiteres Beispiel, welches noch näher am Kontext des Anforderungsmanagement ist, wäre die Story Map. Dieses visuelle Arbeitsmittel stellt auf sehr übersichtliche Art und Weise die Zusammenhänge von Anforderungen und Releases gleichzeitig mit den Arbeitsschritten des Anwenders in einem Bild dar. Ein großer Wert ist hier die Präsenz der Story Map im Teamraum. Hier haben wir schon oft erlebt, wie sich am Board ein lebhafter Dialog um fehlende und ggf. auch überflüssige Features entwickelt hat.
Visual RE stellt alle bekannten Methoden, die solche Art von Vorgehensweisen unterstützen in einen Gesamtzusammenhang.

Im RE geht es des weiteren darum, gegenseitiges Verständis zwischen dem, der ein Produkt wünscht und dem, der das Produkt herstellen soll zu erreichen. Also viel Kommunikation. Erwiesenermaßen ist die Verwendung von bildhaften und optisch strukturierten Informationen deutlich effektiver, als rein sprachlich oder textuell präsentierte Information.

Die Erfahrung hat gezeigt, dass leider viel zu viele Requirements-Prozesse darauf abzielen, Information zuerst möglichst vollständig zu sammeln und dann zur Entwicklung oder Weiterverarbeitung über den Zaun zu werfen.
Ein typisches Antipattern dokumentenzentrierter Vorgehensweisen.
Dies dient eben nicht dem gegenseitigen Verständis, sondern eher nur der eigenen Absicherung.
Visuelle Methoden fokussieren von Anfang an auf einen gemeinsamen Entstehungsprozess. Bilder und visuell unterstützende Techniken wie z.B. MindMaps, Canvas oder z.B. auch Papier-Prototypen beschleunigen dabei -direkt im Dialog- die Feedbackschleifen und reduzieren so Missverständnisse. Durch die Verwendung explizit unvollständiger und erklärungsbedürftiger Bilder ensteht im Dialog nach und nach ein gemeinsames Bild. Dieses Prinzip, welches zunächst paradox erscheint, lässt sich sowohl im phasenorientierten, als auch im agilen Vorgehen einsetzen, um gegenseitiges Verständis zu erzeugen.

Um es klarzustellen: Die hier beschriebenen Techniken sind nicht von Grund auf neu, sondern stellen die Prinzipien visuellen Arbeitens im Kontext der Ermittlung, des Managements und des Erkunden von Anforderungen in den Vordergrund. Außerdem bringt es existierende Methoden und Techniken in einen größeren Gesamtzusammenhang.
Kurz: Visual RE

Technical Debt Game

Technical Debt Game

Let’s talk about technical debt.

Was ist los…

… wenn die Velocity sinkt?

… wenn es immer länger dauert neue Features in die Software zu bringen?

… wenn die Anzahl der gemeldeten Fehler nicht weniger wird, sondern eher noch mehr?

… wenn alle danach schreien, das Produkt lieber neu zu entwickeln, als dass man weiterhin daran arbeiten möchte?

Entwicklungsteams reden dann oft von technischer Schuld oder englisch: Technical debt.

In diesem Beitrag möchten wir das „Technical debt game- for non technical people“ vorstellen, welches auf der play4agile 2019 entstanden ist und das Thema erlebbar macht. Die Simulation ist eine gute Grundlage und Anschauliche Demonstration für eine Diskussion über die eigene Lage in der Produktentwicklung.

Die Simulation wurde schon in mehrere Community Events und Traings eingesetzt.

Anleitung, Material und eine passende Präsentation sind im Download enthalten. Statt der Zahlenkarten könnt Ihr auch 2 Sets von dem Spiel The Mind dazu verwenden.

Wenn wir die Simulation bei Euch durchführen sollen oder Ihr Starthilfe braucht, sprecht uns einfach an…

Viel Spass beim ausprobieren!

Digitalisierung ist Wandel

Digitalisierung ist Wandel

Digitalisierung in einem Unternehmen ist nicht einfach eine Reformation der IT oder der Einsatz von ein paar neuen digitalen Technologien.

Digitalisierung ermöglicht und zwingt -aufgrund des Wettbewerbs- Unternehmen neue Geschäftsfelder zu erschließen. Mittel- und langfristig bedeutet dies einen Wandel des Business-Modells. Auf der einen Seite erschafft dies neue Chancen durch Innovationen. Auf der anderen Seite bedeutet dies einen Wandel der Aufgaben für Mitarbeiter. Arbeitsplätze sind in Gefahr, wenn die Mitarbeiter nicht bereit sind, Neues dazu zu lernen. Die Arbeit wird nicht weniger, kann sich aber eben radikal verändern. Digitalisierung bedeutet also immer auch eine Verunsicherung der Mitarbeiter, auf die eine Organisation eingehen muss.

Die neuen digitalen Technologien bringen die Kunden und Anwender deutlich näher an das Unternehmen als früher, oder erhöhen die Frequenz des Kontaktes bzw., des Informationsaustauschs. Dies ermöglicht eine viel konkretere Erfüllung der Kundenbedürfnisse, da durch schnelles Feedback (z.B. unmittelbare Nutzungsstatistiken o.ä.) besser der Kundenwunsch erkannt werden kann. Auch hier gibt es eine Kehrseite: Die Nutzer erwarten viel häufiger eine Änderung oder Anpassung auf ihre individuellen Bedürfnisse.

Dies erfordert einen Wandel der Arbeitsweise des Unternehmens, da damit eine höhere Flexibilität erforderlich wird. Agile Produktentwicklungsmethoden sind daher seit Jahren auf dem Vormarsch. Letztendlich werden agilere Unternehmen als Gewinner aus der Digitalisierung hervorgehen.

Um nun mit diesen Herausforderungen umzugehen, bedarf es einen Wandel der Führung. Selbstorganisation in Teams, mehr Eigenverantwortung bei den Mitarbeitern heißt auch, dass Führungskräfte oder sogar ganze Führungsmodelle neu gedacht werden müssen. Die Themen, die heutzutage heiß diskutiert werden, sind: Loslassen und stetiges Übertragen von Verantwortung an Mitarbeiter/Teams (Empowerment), Unterstützung & Coaching der Mitarbeiter (Servant Leadership) und Führen am System. Führen am System bedeutet Veränderung von Strukturen, statt qualifizierte Mitarbeiter zu (micro-)managen.

Um auf die sich schnell ändernden Anforderungen reagieren zu können, sind lange hierarchische Entscheidungswege oft nicht mehr geeignet. Die neue Arbeitsweise benötigt zudem auch andere Strukturen. Digitalisierung bedeutet also auch einen Wandel der Strukturen hin zu flacheren Hierarchien, mehr Vernetzung von kleinen operativen Teams, oder gar eine Abschaffung der klassischen Organisationsstruktur (z.B. Soziokratie 3.0).

Da diese verschiedenen Wandel niemals komplett abzuschließen sind, ist eine Organisation im Zeitalter der Digitalisierung stetig im Fluss. Dies erfordert ein Umdenken bei allen Beteiligten. Also nicht nur ein Wandel von Analog auf Digital, sondern ebenfalls und insbesondere ein Wandel des Mindsets. (Stichwort Fixed Mindset vs. Growth Mindset).

Das macht eine Digitalisierungs-Transformation so schwierig, aber auch immer wieder spannend.


Hier noch die Sketchnote zum Artikel:

Modern RE 2019

Modern RE 2019

Wir waren in diesem Jahr auf der Modern Requirements Engineering (#MRE19,#modernRE)

Sehr interessante Vorträge…
Weiter unten meine Sketchnotes zu den von mir besuchten Vorträgen.

Außerdem haben wir unser Lieblingsthema visuelles Requirements Engineering vorgestellt, zu dem wir im Dezember ein Training anbieten.

Hier die visuellen Notizen, die direkt live während der Vorträge entstanden sind:

Mythen und Polemik

Mythen und Polemik

„Wir müssen agiler werden!“

Jeder kennt es: In der Kaffeeküche geht es mal wieder hoch her. Jemand hat eine Behauptung rausgehauen und jetzt prallen die Meinungen aufeinander. Wir haben uns mal 5 dieser Behauptungen herausgegriffen, die wir in letzter Zeit immer wieder mal gehört haben – und mit unserem gesammelten Wissen eine Antwort formuliert.

„Agilen Methoden sind besser“

Wortwörtlich genau so oft gehört. Gemeint ist meist, „sind besser, als der aktuell gelebte (Wasserfall-)Prozess“.

Manchmal.

Aber das hängt im Wesentlichen davon ab, mit welcher Art Anforderungen man es zu tun hat. Weiß man ziemlich sicher und genau, wie eine Lösung aussehen soll, bringt agiles Vorgehen u.U. keinen Vorteil.

Sind die Anforderungen jedoch eher unklar, man weiß nicht, ob der Kunde bestimmte Funktionen wirklich braucht und wie diese zu implementieren sind – dann muss man mit höherer Unsicherheit und mehr Risiken im Projekt umgehen. Dann muss man akzeptieren, dass ein Plan sich ändern wird, dann benötigt man Anpassungsfähigkeit und die Möglichkeit, schnell und leichtgewichtig Entscheidungen zu treffen und die Richtung zu justieren.

Bottom Line: Agil zu arbeiten empfiehlt sich bei manchen Aufgabenstellungen mehr, bei anderen weniger.

Und nicht jedes Unternehmen kann agil arbeiten. Ein Unternehmen benötigt einen gewissen Reifegrad, um Selbstorganisation zuzulassen und effektiv und effizient agil zu arbeiten. Manchmal passen die organisatorischen Strukturen (noch) nicht zum agilen Denken. Bevor dann irgendeine neue Methode eingeführt wird, scheitert, zu Frust führt und verflucht wird, ist es manchmal besser, bei den bekannten klassischen Methoden zu bleiben und sich Stück für Stück weiter zu entwickeln. Aber: Einfach ist das nicht.

Was auf jeden Fall nicht funktioniert: Das Management ordnet an, „Wir sind jetzt agil“, und versteht nicht, was wirklich dahintersteckt. Und dann werden blind irgendwelche Berater engagiert und „Agile Methoden“ eingeführt. Am Besten noch mit vielen Schulungen und Zertifizierungen. Das ist teuer, aber im besten Fall unwirksam.

„Agil bedeutet, nach zu Scrum arbeiten“

Oft wiederholt und trotzdem falsch. Scrum kann der Rahmen sein, der mir dabei hilft, Agilität zu leben. Kann, muss aber nicht.

Ich kann mit Scrum herrlich un-agil sein, genauso kann ich sehr agil sein, ohne Scrum zu nutzen.

Agil zu arbeiten heißt, anpassungsfähig zu sein und die agilen Werte und Prinzipien zu leben. Die Methode ist dabei nicht so wichtig – so lange sie uns nicht behindert.

„Wir brauchen agiles Projektmanagement“

Genaugenommen gibt es weder Wasserfall-Projektmanagement, noch agiles Projektmanagement – und schon gar kein hybrides Projektmanagement.

Es gibt sehr viele unterschiedliche Techniken und Praktiken im professionellen Projektmanagement. Diese sind für bestimmte Projekte mehr oder weniger sinnvoll und Projektmanager sollten das Können und die Freiheit haben, diese pragmatisch und (hoffentlich) passend zu den Gegebenheiten im Projekt anzuwenden.

Denn natürlich brauchen wir auch bei agilen Vorhaben eine funktionierende Planung und Vorhersagbarkeit. Ja, wir planen vielleicht leichtgewichtiger und vor allem nur das, was sinnvoll geplant werden kann, soll, oder muss. Wir machen kein Projektmanagement des Projektmanagements willen – aber war das nicht eigentlich schon immer so?

Unser Projektmanagement muss also agiles Arbeiten unterstützen und darf es nicht behindern. Manchmal muss ich ausprobieren, lernen und mich anpassen. Aber manchmal muss ich auch etwas längerfristig planen und den Überblick über Termine behalten. Das hängt davon ab, wie gut der Kunde schon weiß, was er braucht – und von der Klarheit, wie er diesen Bedarf ausdrücken kann. Es hängt nicht von den Werkzeugen ab, die ich im Projektmanagement verwende.

Manchmal sind die klassischen Tools hilfreich, manchmal sind sie zu schwergewichtig. Manchmal sind neue Techniken sinnvoll, manchmal reichen sie nicht aus. Wir nutzen, was sinnvoll ist.

„Agil bedeutet, nicht planen zu können und nicht zu wissen, was wann geliefert werden wird“

Im Gegenteil. Denn: Gibt mir die klassische Planung wirklich Sicherheit? Ich kenne kein klassisch abgewickeltes Projekt, das am Ende so geliefert wurde, wie zu Beginn gedacht. Projekte sind nun einmal neuartig, risikoreich, dynamisch und häufig komplex.

Agil sein heißt, dies zu akzeptieren und Schritt für Schritt vorzugehen – und regelmäßig zu validieren, ob wir noch auf dem richtigen Weg zum richtigen Ziel sind. Um mit Hilfe dessen, was wir aus den bereits erzeugten, sicht- und anfassbaren Teilergebnisse gelernt haben, die bestmöglichen Entscheidungen für unsere weitere Arbeit zu treffen.

Letztendlich ist das magische Dreieck, das Kosten, Inhalt und Zeit in Beziehung bringt, immer gültig. Und die Aussage, dass man Kosten, Inhalt und Zeit vorhersagen und festzurren kann, war noch nie richtig und wurde auch von wirklich professionellen Projektmanagern nie behauptet. Eigentlich logisch, denn dann bräuchte man ja auch kein Projekt-Management mehr, dann würde eine Projekt-Verwaltung vollkommen ausreichen.

„Das Projekt ist zu groß für Agil“

Große Projekte heißt, viele Beteiligte. Viele Beteiligte benötigen viel Interaktion. Je komplexer die Aufgaben, desto mehr Interaktion ist notwendig. Agiles Vorgehen erhöht die Anforderungen an die Häufigkeit der Interaktion.

Sind die Möglichkeiten und Fähigkeiten zur Interaktion und die notwendigen Freiheitsgrade für ausreichend schnelle Entscheidungen vorhanden, dann funktionieren Vorhaben. Wenn nicht, dann nicht.

Mit klassischen Methoden kann Komplexität und die Notwendigkeit für späte und schnelle Entscheidungen reduziert werden – das funktioniert jedoch nur, wenn die Anforderungen bekannt sind. Sind die Anforderungen, auch teilweise, unklar, bleibt keine Wahl: Viele Entscheidungen können nicht gleich zu Beginn eines Vorhabens endgültig getroffen werden. Und dann sind die Projekte vielleicht zu groß für die Fähigkeiten einer Organisation – bzw. vielleicht kann die Organisation nicht agil genug sein. Das liegt dann aber nicht an der Methode.