Arbeiten mit Hypothesen 
Fragen statt Geschichten erzählen 
Lydia Grawunder @lllyyyddd
Hallo
Out
Story
Fail
Hypothesen
Und es war gut
Was ist anders?
Wissen
Cynefin
Ausprobieren
Warum Hypothesen?
Building the thing RIGHT!
Building the RIGHT thing!
Offene Diskussion
Wie?
Template
Versuchsaufbau
Nur für StartUps?
Probiert‘s
ENDE
Picture: IMG_2202 / Jaume Jornet / 
Picture: Lydia Grawunder 
Picture: Lydia Grawunder 
Picture: Lydia Grawunder 
Picture:...
• Replacing Requirements with Hypotheses by Josh Seiden 
• Hypothesis-Driven Development by Abby Fichtner 
• How to implem...
Nächste SlideShare
Wird geladen in …5
×

Arbeiten mit Hypothesen (Pecha Kucha)

695 Aufrufe

Veröffentlicht am

Die Folien von meiner Pecha Kucha auf den XP Days 2014.

Danke noch mal für das tolle Feedback.

Veröffentlicht in: Business
0 Kommentare
4 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
695
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
53
Aktionen
Geteilt
0
Downloads
14
Kommentare
0
Gefällt mir
4
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Hi,

    ich werde euch in den nächsten 6 min 40 was über meine Erfahrungen mit Hypothesen erzählen.

    Ich hab vor 4 Jahren bei einer großen deutschen Immobilienplatform als 2ter Fulltime ScrumMaster angefangen.
  • Wir hatten mit einem Team gerade Scrum ausprobiert und beschlossen das für die anderen Teams auch einzusetzen. Als ich in März dort aufgehört habe, hatten wir bei über 25 Teams, die mit agilen Methoden arbeiteten und sogar welche außerhalb der IT.
  • Ich hab also schon einmal diese ganze Scalinggeschichte gesehen und begleitet und auch das ein oder andere Team aufgebaut. Und ich dachte mir, mit den Erfahrungen kann ich doch überall was gutes bewirkten. Spring über dein Schatten, verlasse deine Komfortzone und die ganzen tollen Kollegen und starte von Vorne. Und so hab bei einem StartUp angefangen.
  • Und dann saß ich mit dem PO zusammen und wir versuchten die ersten Stories zu schreiben.

    Natürlich bin total selbstbewusst rein und fing an mit „As a mmmm I like to bla so that blub.“

    Und was soll ich sagen…
  • …es hat überhaupt nicht funktioniert.

    Wir haben nämlich noch keine Ahnung was die User möchte. Oder wer die User überhaupt sind. Und manchmal wissen wir auch nicht was wir von ihnen wollen.

    Ihr ahnt vielleicht schon in welche Richtung das Problem geht…
  • Eric Ries schlägt für so einen Fall Hypothesen vor.

    Damit wollten wir versuchen heraus zu finden, ob unsere Produktidee tatsächlich so geil ist wie wir uns das denken.

    Der PO war am Anfang skeptisch, aber mit dem alten „Lass es uns wenigstens ausprobieren und wenn es nicht funktioniert lassen wir es wieder“ Trick gings dann los.
  • Und es hat funktioniert.

    Backlog Items schreiben ging plötzlich leicht von der Hand. In Meetings wurde weniger über Standpunkte gestritten, dafür über die Frage „ Wie können wir das herausfinden?“ „Wie können wir das beweisen?“ diskutiert.
  • Das hat meine Neugier geweckt. Und die erste Frage, die ich mir gestellt hab war:

    Warum ist das bisher nie ein Thema für mich gewesen? Warum hab ich die Stories bisher nie in Frage gestellt?

    Irgendwas muss sich verändert haben. Aber was?
  • In meiner alten Firma kannten wir unsere Kunden, wir hatten ein User Lab, überall Tracking und KPIs, d.h. wir konnten analysieren und dann reagieren. Es war ein Stück weit berechenbar.
  • Alles hatte vorhersehbare Ergebnisse und was sogar gewünscht war. Und das ist definitiv Story Land.

    Das ist es jetzt nicht mehr.

    Jetzt sind wir hier in einer komplexen, unbekannten Situation. Da ist es einfacher…
  • … Fragen zu stellen als Antworten zu geben. Vor allem weil es viele Ideen gibt die alle irgendwie zum Ziel führen können.

    Wir müssen Dinge ausprobieren. Wir müssen versuchen daraus Muster zu erkennen. Dafür sind Aussagen nicht geeignet. Hypothesen schon.
  • Das heißt Hypothesen helfen uns einer komplexen Situation.

    Weil wir aus ihnen etwas lernen und das Learning ist momentan für uns wertvoller als running Software.

    Und das ist ja das Ziel für User Stories. Das ist gut zu erkennen wenn man sich ansieht, wann eine Story als erfolgreich angesehen wird.
  • Wenn sie in Qualität, Zeit und Scope abgeliefert wird. Also dem DoD entspricht, vom PO abgenommen und im Sprint geliefert wird.

    Leider fehlt ein entscheidender Teil: nämlich der Sinn der Story.
  • Wir haben noch gar kein Produkt, Qualität ist noch nicht relevant.

    Was unsere Idee voran bringt, ist Erkenntisgewinn, weil alles was wir bisher haben sind Probleme.

    Die wir irgendwie lösen müssen. Deswegen steht MVP bei uns auch für minimal validatable Problem.
  • Außerdem macht es einen großen unterschied ob jemand behauptet er weiß was User wollen

    oder aber ob die Aufgabe als Experiment gestellt wird.

    Ein Versuch kann scheitern, eine Story nicht, weil sie als Tatsache dargestellt wird.
  • Ich hab mir also überlegt wo Menschen schon mit Hypothesen arbeiten und hab einige Wissenschaftler gefragt ob sie eine Art Schema für Hypothesen verwenden. Das fand ich so charmant an den Stories.

    Tun sie nicht. Weil sie Hypothesen als Arbeitsmittel sehr ernst nehmen und nicht als Hilfsmittel um Diskussionen anzustoßen.
  • Aber ich hab mich an einen Vortrag erinnert, den ich auf der ALE 2013 von Barry O’Reilly, und Kate Logan gesehen hab. Dabei haben das Template vorgestellt, das dann so klingt:

    „Wir glauben daran das diese Änderung dazu führen wird, dass mehr Kunden den Vorgang abschließen und wir werden wissen das wir Erfolg haben, wenn die Abbruchrate um 10% sinkt“
  • Damit verschiebt sich die Diskussion von „Wie machen wir das?“ zu „Warum machen wir das?“.

    Und im besten Fall wird ein Feature ohne Value gar nicht erst implementiert.

    Man braucht immer noch ein Art Beschreibung, quasi das Setup für den Versuchsaufbau.
  • Ist das jetzt nur was für StartUps?

    Nein, ich glaube nicht. Unsichere Situationen gibt es bei jedem Produkt.

    Und wenn ich das früher gewusst hätte, dann hätte sich mein PO nicht so verbiegen müssen.
  • Hypothesen helfen, dass sich das Team zusammen setzt, miteinander redet und ein gemeinsames Ziel verfolgt. Ja das die gleiche Intension von Stories.

    Aber eine Frage, als Hypothese verpackt, ist dafür oft besser geeignet.

    Also: Arbeitet mit Hypothesen

    und fragt lieber als das ihr Geschichten erzählt.
  • Arbeiten mit Hypothesen (Pecha Kucha)

    1. 1. Arbeiten mit Hypothesen Fragen statt Geschichten erzählen Lydia Grawunder @lllyyyddd
    2. 2. Hallo
    3. 3. Out
    4. 4. Story
    5. 5. Fail
    6. 6. Hypothesen
    7. 7. Und es war gut
    8. 8. Was ist anders?
    9. 9. Wissen
    10. 10. Cynefin
    11. 11. Ausprobieren
    12. 12. Warum Hypothesen?
    13. 13. Building the thing RIGHT!
    14. 14. Building the RIGHT thing!
    15. 15. Offene Diskussion
    16. 16. Wie?
    17. 17. Template
    18. 18. Versuchsaufbau
    19. 19. Nur für StartUps?
    20. 20. Probiert‘s
    21. 21. ENDE
    22. 22. Picture: IMG_2202 / Jaume Jornet / Picture: Lydia Grawunder Picture: Lydia Grawunder Picture: Lydia Grawunder Picture: Eric Ries - The Lean Startup, London Edition / Betsy Weber / Creative Commons Picture: Post-it time! / Ignacio Palomo Duarte / Creative Commons Picture: Curiosity Did What to the Cat? / pmeidinger / Creative Commons Picture: Lydia Grawunder Picture: Lydia Grawunder Picture: Lydia Grawunder Picture: Lydia Grawunder Picture: wtf - code quality measurement / smitty42 / Creative Commons Picture: Lydia Grawunder Picture: Facts Not Opinions / John Lord / Creative Commons Picture: Scientists / Craig Anderson / Creative Commons Picture: Lydia Grawunder Picture: Tiny Breadboard Power Supply: LEDs! / Adam Greig / Creative Commons Picture: Lydia Grawunder Picture: CEO - Tiare - Board Meeting - Franklin Canyon / tiarescott / Creative Commons Picture: the audience is shaking (CC) / Martin Fisch / Creative Commons Bilder
    23. 23. • Replacing Requirements with Hypotheses by Josh Seiden • Hypothesis-Driven Development by Abby Fichtner • How to implement Hypothesis-Driven Development by Barry O’Reilly • Cynefin and Story Splitting by Richard Lawrence Quellen

    ×