Komm mir nicht mit Fachlichkeit

Wir müssen der Wahrheit ins Auge blicken: Scrum funktioniert nicht immer, besonders wenn es um die Bewältigung der Herausforderungen unzureichender Anforderungen geht.

Dabei gewinnt das Verständnis der Fachlichkeit unserer Kunden zunehmend an Bedeutung, was an der aktuellen Domain-driven Design - Bewegung zu erkennen ist. Hier wird die enge Zusammenarbeit zwischen Entwicklungsteams und fachlichen Experten betont. Dennoch scheitern viele Softwareprojekte aufgrund unzureichender Anforderungen.

Aber keine Sorge, es gibt Alternativen!

In diesem Vortrag werfe ich einen kritischen Blick auf Scrum und präsentiere verschiedene Tools und Methoden, mit denen unsere Entwicklungsteams tief in die Fachlichkeit eintauchen. User Story Mapping, Event Storming und Domain Storytelling sind nur einige der Werkzeuge, die wir erkunden werden. Sie helfen dabei, die Fachlichkeit besser zu verstehen, Lücken in den Anforderungen aufzudecken und eine gemeinsame Sprache zwischen dem Entwicklungsteam und den fachlichen Experten zu etablieren.

Dieser Vortrag ermutigt die Teilnehmer, das veraltete Scrum-Paradigma zu überdenken und sich stattdessen auf wirkungsvollere Methoden zu konzentrieren. Nur so können wir hochwertige Produkte entwickeln, die den Bedürfnissen unserer Kunden gerecht werden.

Transcript

1. ina.einemann@openknowledge.de Ina Einemann @ieinemann
2. Scrum Sprint Planning Backlog Backlog Sprint Backlog Backlog acklog Backlog Backlog g Product Backlog Refinement Product Review Retrospective Sprint Daily Scrum
3. Scrum Sprint Planning Backlog Backlog Sprint Backlog Backlog acklog Backlog Backlog g Product Backlog Refinement Product Review Retrospective Sprint Daily Scrum
4. Scrum Delievery Discovery • Ideen generieren • Problemen und Kundenwünsche verstehen • Validieren • Umsetzung der Produktideen • Output ist potenziell auslieferbar
5. 4-5 Risiken der Produktentwicklung (Marty Cagan) Usability Risk Business Viability Risk Ethical Risk Value Risk Feasibility Risk
6. Was? Wie? Fokus bei Scrum Wofür? PO Developer Stakeholder
7. Domain Driven Design „For most software projects, the primary focus should be on the domain and domain logic“ Eric Evans, Domain-Driven Design, Addison-Wesley, © Eric Evans, 2004
8. Was? Wie? DDD Wofür?
9. Was? Wie? DDD Wofür?
10. Domänen- modell
11. Ubiquitous Language
12. Und womit schaffen wir das?
13. User Story Mapping
14. User Story Mapping
15. User Story Mapping
16. Event Storming
17. Event Storming Morgen:
18. Domain Storytelling
19. Domain Storytelling
20. Discovery Domain Storytelling Delievery User Story Mapping Event Storming
21. Discovery vs. Delievery • Ideen generieren • Problemen und Kundenwünsche verstehen • Validieren Fokus: Schneller Erkenntnisgewinn • Umsetzung der Produktideen • Output ist potenziell auslieferbar Fokus: Planbarkeit und Qualität
22. Dual-Track-Agile-Methode
23. Dicovery Workshops Domain Storytelling User Story Mapping Event Storming
24. Dicovery Sprint
25. Methoden • Stakeholder Orientierung
26. Stakeholderorientierung Identifizieren Analysieren Integrieren
27. Identifizieren Bank Lehrende Lernende Pot. Projekt- partner Lehr- mittel- hersteller Lernhaus GmbH (Wett- bewerber) Bildungs- träger Investor (Einebeck- EDV) Marketing Medien / Presse Vertrieb
28. Einfluss gering hoch Interesse gering hoch Lehrende Lernende Investor (Einebeck- EDV) Marketing Bank Pot. Projekt- partner Lehr- mittel- hersteller Lernhaus GmbH (Wett- bewerber) Bildungs- träger Medien / Presse Vertrieb Analysieren
29. Methoden • Stakeholder Orientierung • Personas • Interviews
30. Persona Workshop Interviews Einfluss gering hoch Interesse gering hoch Lehrende Lernende Investor (Einebeck- EDV) Marketing Bank Pot. Projekt- partner Lehr- mittel- hersteller Lernhaus GmbH (Wett- bewerber) Bildungs- träger Medien / Presse Vertrieb Analysieren
31. Methoden • Stakeholder Orientierung • Personas • Interviews • Gemba Walk • Jobs to be Done • Business Story
32. Business Story
33. Methoden • Stakeholder Orientierung • Personas • Interviews • Gemba Walk • Jobs to be Done • Business Story • Impact Mapping
34. Impact Mapping
35. Methoden • Stakeholder Orientierung • Personas • Interviews • Gemba Walk • Jobs to be Done • Business Story • Impact Mapping • Hack Days
37. „Discovery isn’t a one-time activity“ Teresa Tores, Continuous Discovery Habits
38. Was kann ich in meinem Scrum Setting konkret machen?
39. Überlegungen • Verständnis im Team schaffen • Was passt im eigenen Kontext • Kontinuierliche Kundeninteraktion • Visualisierung der Discovery-Arbeit • Meetings anpassen
40. Sprint Planning
41. Sprint Review
42. https://www.planetgeek.ch/2023/06/13/the-caretaker-model-our-way-of-working/
45. ina.einemann@openknowledge.de Ina Einemann @ieinemann