Methoden

DISCUS Framework

Wir haben unserem Beratungs-Framework „DISCUS“ eine eigene Seite gewidmet. Klicken Sie bitte auf den nachfolgenden Link, um mehr über diesen Beratungsansatz zu erfahren: Zum DISCUS Framework

Lean Startup

Build, Measure, Learn

Der Lean Startup Ansatz verfolgt einen ebenso einfachen wie wirkungsvollen Ansatz. Durch ein frühes Kundenfeedback soll eine Verschwendung von Ressourcen in der Entwicklung neuer Services und Produkte bestmöglich vermieden werden. Die Methodik ist in enger Anlehnung an die Arbeit von Taiichi Ohno, der das Lean Manufacturing des Toyota Production System (TPS / 1948-1975) maßgeblich entwickelt hat, entstanden.

Eric Ries hat diese Philosophie auf die Startup Welt übertragen und mit seinem Bestseller „The Lean Startup“ (2011) populär gemacht. Er selbst schreibt zu seinem Ansatz:

The Lean Startup asks people to start measuring their productivity differently. Because startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build – the thing customers want and will pay for – as quickly as possible. (Ries, 2011).

Wir adaptieren diese Philosophie in unserer Beratung und suchen frühstmöglich das oft schonungslose Feedback des Marktes. Dies erfordert eine klare Fokussierung auf jene Tätigkeiten, die uns dabei unterstützen, eine bloße Idee in klare und belastbare Fakten zu überführen. Eric Ries schreibt hierzu:

Most startups lack a structures process for testing their business models’ hypotheses – markets, customers, channels, pricing – and for turning those guesses into facts. The traditional new product introduction model offers no customer feedback until beta, when it‘s too late. (…) Validated learning means nothing less than that “effort that is not absolutely necessary for learning what customers want should be eliminated“ (Ries, 2011).

Während Ries seine Ausführungen primär auf Startups bezieht, verwenden wir große Teile seiner Philosophie in der Verprobung neuer Konzepte und Ideen – auch in großen Unternehmen.

Das Konzept des frühen und konstanten Kundenfeedbacks ist in einem dreistufigen Kreislauf (Build, Measure, Learn) verankert. Neue Ideen werden so lange getestet und überarbeitet, bis ein positives Feedback vorliegt (Beginn der Umsetzung) oder die Idee als nicht zielführend eingestellt wird. Größere Anpassungen innerhalb dieses Kreislaufes werden als „Pivot“ bezeichnet.

Design Thinking

Innovation aus Anwenderperspektive

Design Thinking zielt darauf ab, die Bedürfnisse von Benutzern oder Kunden besser zu verstehen, um innovative und passgenaue Lösungen zu entwickeln. Es handelt sich um einen iterativen Prozess, der sich auf die menschliche Perspektive konzentriert und großen Wert auf eine intensive Zusammenarbeit und systematisches Experimentieren legt.

Design Thinking besteht aus fünf Phasen: Empathie, Definition, Ideenfindung, Prototyping und Testen.

• In der Empathiephase geht es darum, die Bedürfnisse und Herausforderungen von Benutzern oder Kunden zu verstehen, indem man sich in ihre Lage versetzt und ihre Perspektive einnimmt.
• Die Definitionphase beinhaltet die Definition des Problems und die Formulierung einer klaren Fragestellung.
• In der Ideenfindungsphase werden verschiedene Lösungen generiert und bewertet, um schließlich eine auszuwählen, die am besten geeignet ist.
• In der Prototypingphase wird ein Prototyp der Lösung erstellt, der getestet und verbessert wird.
• In der Testphase wird der Prototyp von den Benutzern oder Kunden getestet, um Feedback zu erhalten und die Lösung weiter zu optimieren.

Ein Beispiel für die Anwendung von Design Thinking ist die Entwicklung eines neuen Produkts oder einer neuen Dienstleistung. Ein Unternehmen kann den Design Thinking-Ansatz verwenden, um das Produkt oder die Dienstleistung aus der Perspektive eines Benutzers oder Kunden zu betrachten und dessen Bedürfnisse und Herausforderungen zu verstehen. Ziel ist es, das Unternehmen in die Lage zu versetzen, innovative Lösungen entwickelt, die den Bedürfnissen des Benutzers oder Kunden besser gerecht werden und das Produkt oder die Dienstleistung erfolgreicher machen.

Ein weiteres Beispiel für die Anwendung von Design Thinking ist die Verbesserung von Prozessen in einem Unternehmen. Indem man die Perspektive der Benutzer oder Kunden einnimmt und deren Bedürfnisse und Herausforderungen genau versteht, können ineffiziente Prozesse identifiziert und verbessert werden. Dies kann dazu beitragen, die Produktivität und Effizienz des Unternehmens zu steigern und gleichzeitig die Benutzer- oder Kundenzufriedenheit zu verbessern.

Insgesamt bietet Design Thinking einen strukturierten Ansatz zur Problemlösung, der darauf abzielt, innovative Lösungen zu entwickeln, die den Bedürfnissen von Benutzern oder Kunden entsprechen. Durch den Fokus auf Zusammenarbeit, Experimentieren und die menschliche Perspektive können Unternehmen erfolgreicher sein, indem sie bessere Produkte und Dienstleistungen entwickeln.

Business Model Canvas

Ihr Geschäftsmodell auf einen Blick

Das Business Model Canvas von Alexander Osterwalder ist ein populäres Tool zur Entwicklung, Dokumentation und Visualisierung von Geschäftsmodellen. Die wesentlichen Aspekte des Geschäftsmodells werden dabei in die unterschiedlichen Felder des Canvas überführt und zueinander in Verbindung gesetzt. Vor allem in einer frühen Phase der Konzeptentwicklung kann so eine Vollständigkeit aller wesentlichen Elemente sichergestellt werden. Gleichzeitig lassen sich die Wechselwirkungen von Anpassungen einzelner Elemente besser einschätzen, beispielsweise bei Business Innovation Projekten.

SCRUM

Planvoll Agil

SCRUM ist ein Framework, das im Kontext der agilen Softwareentwicklung entstanden ist, inzwischen jedoch in Projekten unterschiedlichster Art und Größe Anwendung findet. Seine Philosophie ist eng mit dem „Manifest für agile Softwareentwicklung“ verknüpft, das 2001 von einigen Softwareentwicklern publiziert wurde. Das Manifest definiert zentrale Werte einer zielführenden Softwareentwicklung und stellt diese in Gegensatz zur sonst üblichen Vorgehensweise. Im Manifest heißt es:

• Individuen und Interaktion mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Diese Werte stellen nicht weniger als einen vollständigen Paradigmenwechsel zur bisherigen Form der Softwareentwicklung und des Projektmanagements dar. Das spontane Reagieren auf Veränderung wird für wichtiger erachtet als das dogmatische Abarbeiten eines detaillierten Planes. In vielen Organisationen stößt diese Philosophie auch heute noch auf große Skepsis. Zu groß ist die Versuchung, komplexe Projekte im Vorfeld bis ins Detail durchdenken zu wollen. Jede Eventualität und Abhängigkeit soll idealerweise vorab erkannt und berücksichtigt werden. Die hohe Zahl an gescheiterten IT-Großprojekten, die Kosten in Milliardenhöhe verursachen und dann ergebnislos eingestellt werden, sprechen nicht unbedingt für die Leistungsfähigkeit dieser Vorgehensweise.

Zu den Gründungsvätern dieser Bewegung gehörten auch Jeff Sutherland und Ken Schwaber, die heute als Erfinder der SCRUM-Methodik angesehen werden. Bereits 1995 schrieb Schwaber in einem Konferenzbeitrag:

„Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität“ (Schwaber, 1995).

Scrum kennt drei wesentliche Rollen in der Softwareentwicklung und im Projektmanagement. Dies sind der Product Owner, der Scum Master und der Developer. Jede dieser drei Rollen hat klare Zuständigkeiten und Aufgaben, die erst im engen Zusammenspiel miteinander Sinn ergeben.

Rollen im SCRUM Framework

Product Owner

Die Aufgabe dieser Rolle liegt darin, die Anforderungen des Produktes zu definieren, zu priorisieren und mit anderen Stakeholder abzustimmen. Der Product Owner ist häufig auch für den wirtschaftlichen Erfolg des Produktes sowie dessen Budget verantwortlich. Die Anforderungen des Produktes werden üblicherweise als separate Punkte in einem Backlog dokumentiert und gemäß ihrer Priorität in den Entwicklungsprozess (Sprint) überführt. Im Gegensatz zu einem klassischen Projektleiter, der Aufgaben an andere Abteilungen delegiert, ist der Product Owner selbst Teil des Scrum-Teams und kann stärker Einfluss auf den Erfolg des Projektes nehmen.

Scrum Master

Diese Rolle hat einen starken Coaching-Charakter. Der Scrum Master ist als Befähiger des Teams zu betrachten. Er verfügt über keinerlei (disziplinarische) Befugnisse, sondern unterstützt das Team bei der Einführung und Anwendung des SCRUM Frameworks. Er kennt sich bestens mit dem Regelwerk aus, schult und moderiert die Scrum-Events oder vermittelt bei Unstimmigkeiten. Er sorgt auch gegenüber der Organisation dafür, dass das Team ungestört seiner Arbeit nachgehen kann.

Developer

Diese Rolle ist für die tatsächliche Umsetzung der Anforderungen in ein Produkt bzw. eine Funktionalität zuständig. Üblicherweise handelt es sich um ein ganzes Team von Developern, deren Bezeichnung nicht zwangsläufig für „Softwareentwickler“ stehen muss. In der Softwareentwicklung beinhaltet dieses Team üblicherweise auch Tester, Datenbankexperten, etc. Das Development Team schätzt den Entwicklungsaufwand für einzelne Funktionalitäten und plant diese gemäß ihrer Priorität in die kommenden Sprints ein.

Das Konzept des „Sprint“

Die Entwicklung von Funktionalitäten erfolgt im SCRUM innerhalb eines festgelegten Zeitabschnittes, der als Sprint bezeichnet wird. In dieser Zeit wird ein sogenanntes „Inkrement“ entwickelt, eine eigenständig verwendbare Funktionalität, die nach dem Sprint in die produktive Nutzung überführt werden kann.

Üblicherweise dauert ein Sprint vier bis sechs Wochen. Die Dauer wird vom Voraus festgelegt und nicht mehr verändert. Die Aufgaben für den jeweiligen Sprint werden ebenfalls im Voraus festgelegt und anschließend nicht mehr verändert. Der Sprint kann vom Product Owner abgebrochen werden, wenn wichtige Ereignisse die Erreichung des Sprint Zieles nicht länger ermöglichen.

Ereignisse im SCRUM Framework

Sprint Planning

Das Sprint Planning findet im Vorfeld eines neuen Sprints statt. In diesem Event stellt der Product Owner seine priorisiere Anforderungen aus dem Product Backlog vor. Anschließend werden diese vom Development Team in den Sprint Backlog überführt und hinsichtlich ihrer Komplexität geschätzt. Am Ende wird eine gewissen Anzahl an Anforderungen zur Umsetzung im kommenden Sprint verabschiedet und durch den Sprint Backlog dokumentiert. Das Development Team entscheidet hierbei, wie ein realistisches Ziel für den kommenden Sprint aussieht und wie viel Funktionalität tatsächlich umgesetzt werden kann.

Daily SCRUM

Das daily SCRUM findet als kurzes tägliches Meeting, gerne auch Standup genannt, statt. Es dient dem gegenseitigen Informationsaustausch. Die Mitglieder des Development Teams informieren sich gegenseitig, was seit dem letzten Daily erreicht wurde und was man sich bis zum nächsten Daily vorgenommen hat. Unerwartete Ereignisse, Verzögerungen und Abhängigkeiten etc. werden so schnell für alle Beteiligten transparent.

Sprint Review

Das Sprint Review findet am Ende eines Sprints statt. Das Development Team präsentiert das Inkrement des Sprints und gleicht dieses gemeinsam mit dem Product Owner gegen die initiale Planung und Zielsetzung ab. Der Product Owner begutachtet die entstandenen Funktionalität und überprüft, ob diese seinen Anforderungen und Qualitätskriterien entspricht.

Retrospektive

Die Retrospektive ist eine offene Aussprache am Ende des Sprints. Diese findet in einem geschützten Raum unter Ausschluss der übrigen Stakeholder statt. Sie zielt darauf ab, die künftige Zusammenarbeit zu verbessern und aufgetretene Probleme offen und ehrlich zu klären. Der Scrum Master moderiert dieses Meeting und unterstützt das Team bei der Definition von Verbesserungsmaßnahmen.

Artefakte im SCRUM Framework

Product Backlog

Das Product Backlog stellt eine Auflistung der künftigen Anforderungen und Funktionalitäten dar. Das Dokument wird ständig überarbeitet und angepasst, die enthaltenen Elemente werden (neu) periodisiert und ergänzt.

Sprint Backlog

Das Sprint Backlog enthält Anforderungen und Funktionalitäten, die als Inkrement im nächsten Sprint erarbeitet werden sollen. Es ist daher meist deutlich weniger umfangreich als das Product Backlog.

OKR

Messbare Ziele setzen

Das Konzept der „Objectives and Key Results“, kurz OKR, geht auf die Arbeit von John Doerr zurück. Ziel der Methodik ist es, ein klares Framework zur Zielsetzung (Objectives) zu etablieren und die Erreichung dieser Ziele (Key Results) anhand klar definierter und gut messbarer Metriken zu ermöglichen.