Hypothesis-Driven Development

tl;dr

Ein gutes Werkzeug um Personen und Organisationen in der Softwareentwicklung (Teams, Management, etc) effektiver zu machen, ist sich auf die Dinge zu konzentrieren, die am meisten Wert für den Kunden haben. Um schnell Feedback zu bekommen etabliert man Continuous Delivery und damit man besser mit Unsicherheit umgehen kann hilft Hypothesis-Driven Development.

Man formuliert die Hypothesen nach folgendem Muster (Siehe auch: Quellen unten):

Wir glauben das <wenn wir diese Funktion bauen> 
für <diese Personen>
liefert es  <dieses Ergebnis>
Wir haben das Vertrauen fortzufahren, wenn wir (bis <Datum>) folgendes <messbare Signal sehen>.

In den letzten Jahren habe ich mich sehr intensiv mit dem Thema Continuous Delivery, DevOps, Lean usw. beschäftigt und bin bei meinen Kunden immer wieder auf ähnliche Muster gestoßen.

Allen ist klar, dass man an den richtigen und wichtigsten Aufgaben arbeiten soll. Aber wie findet man heraus, ob das was man sich da überlegt richtig und wichtig ist? Ein Instrument ist das Verkürzen der Feedback-Zyklen und darauf zu schauen wie die Kunden reagieren. Implementieren kann man dies in der Organisation in dem man u.a. konsequent eine Testpyramide – zusammen mit Continuous Delivery – aufbaut.

Zu den Anforderungen gelangen prozessorientierte Ansätze mit einer entsprechenden Analyse des Problems und wenn die Anforderung gut genug formuliert ist, dann muss man sie “nur” noch umsetzen. Man macht eine Liste von Diesen und hat alles was man für einen Sprint (Siehe Scrum) braucht. Dies ist stark vereinfacht, soll aber an dieser Stelle als Grundüberlegung ausreichen. Das Problem an dieser Stelle ist, dass sich nicht alles analysieren lässt bzw. man mit einem Versuch schneller eine Frage beantworten kann bzw die Relevanz einer Anforderung herausfindet.

Ein Problem entsteht, wenn die Vision, bzw. die daraus abgeleiteten Anforderungen und Prioritäten als Fakt fest im Raum stehen. Dies äussert sich z.B. in Sätzen wie “Der Kunde hat gesagt, dass …”, “Der Chef hat gesagt, dass …”. Viele Personen getrauen sich in einer solchen Situation nicht zu intervenieren, wenn sie beobachten das etwas nicht stimmt und erledigen einfach die Arbeiten, die Ihnen übertragen wurden. Andere wiederum geben nach mehreren Anläufen auf, ihre Beobachtungen mitzuteilen und an Verbesserungen zu arbeiten. Obwohl das Wissen in der Organisation vorhanden ist, wird es nicht genutzt.

Um dieser Situation Rechnung zu tragen und die Leute zu ermutigen solche Situationen aufzudecken, spricht man häufig davon “autonome Teams” zu bilden,  “Experimente” zu fördern und “Fehler zuzulassen” – eine lernende Organisation aufzubauen. 

Die Schwierigkeit besteht darin die alten Gewohnheiten zu durchbrechen und die Menschen dazu zu bringen, die “harten” Anforderungen und Visionen zu hinterfragen bzw zu verwerfen, wenn sie nicht korrekt sind. Oft werde ich gefragt, “Oliver, wir kennen das Agile Manifesto, Lean, Continuous Delivery, Squads and Guilds… aber wie konkret macht man den ersten Schritt bei uns hier im Unternehmen? Wie fange ich an die Veränderung in Gang zu bringen, mit genau diesen Leuten, diesem Team?”

Ich habe mit den Hypothesen gute Erfahrungen gemacht Teams und Personen zu ermutigen mehr zu experimentieren, schneller zu werden und mehr Sicherheit bei ihren Entscheidungen zu bekommen.

Dies liegt daran, dass dies im Grunde einer wissenschaftlichen Vorgehensweise entspricht:

• Mache Beobachtungen/Denke über Fragestellungen nach
• Erstelle eine Hypothese
• Designe ein Experiment um die Hypothese zu prüfen
• Benenne die Indikatoren die zu finden sind, damit die Hypothese als “erfolgreich”/”richtig” bezeichnet werden kann
• Führe das Experiment aus
• Werte die Ergebnisse des Experimentes aus
• Akzeptiere oder verwerfe die Hypothese
• wenn notwendig, erstelle und teste neue Hypothesen

Wenn man die Fragestellungen und Hypothesen daran ausrichtet, was den grössten Wert für den Kunden oder dem Unternehmen erbringt, arbeitet man auf den grössten Nutzen hin. Das eine Hypothese verworfen werden kann, ist implizit enthalten. Viele nennen dies vereinfacht: “Fehler zulassen”. Aber eigentlich sind dies ja gar keine Fehler, sondern “nur” verworfene Hypothesen.

Ich benutze folgendes Schema (siehe auch unten in den Quellen) um Dinge wie Anforderungen, Stories oder Verbesserungsmaßnahmen, als Hypothesen zu formulieren:

Wir glauben das <wenn wir diese Funktion bauen> 
für <diese Personen>
liefert es  <dieses Ergebnis>
Wir haben das Vertrauen fortzufahren, wenn wir (bis <Datum>) folgendes <messbare Signal sehen>.

Das Datum ist dabei optional und spiegelt den praktischen Gesichtspunkt wieder, dass unter betriebswirtschaftlichen Rahmenbedingungen eine zu lange Untersuchung unwirtschaftlich sein kann.

Offensichtliche Dinge braucht man natürlich nicht auf diese Weise angehen. Wenn ein Bug verhindert, dass die Applikation startet, dann braucht man keine Hypothese aufstellen, dass der Kunde die Applikation mehr benutzt, wenn man den Bug beseitigt. Auch in Bereichen wo man ein grosses Wissen hat und die Effekte schon kennt, ist es nicht notwendig. Sobald man aber unter Unsicherheit oder hoher Komplexität arbeitet – und das trifft man in der Softwareentwicklung sehr häufig an – hilft dieser Ansatz sehr. 

Für mich persönlich war es sehr interessant zu sehen, wie problemlos sich dieser Ansatz in die bestehenden Prozesse von Teams integrieren lässt. Der Widerstand ist meist gering und trotzdem ändert sich die Sichtweise und das Handeln der einzelnen Personen. Kulturelle Änderungen in Teams zu etablieren sind meist sehr schwer, insbesondere wenn es um die Übernahme von Verantwortung geht. Das ein Verwerfen der Hypothese explizit eingebaut ist, hilft schneller Entscheidungen zu fällen und ermutigt die Teams unter Unsicherheit zu arbeiten und nicht paralysiert schwierige Entscheidungen vor sich herzuschieben. 

Quellen:

• How to implement hyposis-driven development
  
• GOTO 2015 • Why Scaling Agile Doesn’t Work • Jez Humble
• Scientific method. (2017, March 21). In Wikipedia, The Free Encyclopedia. Retrieved 10:28, March 22, 2017, from https://en.wikipedia.org/w/index.php?title=Scientific_method&oldid=771369971