Regeln brechen

Regeln brechen (FFD, Folge 39)

Kommen wir jetzt zum dritten Teil. Sie haben es gerade schon gesogen, wir sind jetzt also im Pull-Modus. Wie geht man denn nun mit Disruptionen um, wie geht man mit Veränderungen auf der Kundenebene um. Da ist das Thema Regeln brechen ganz wichtig. Jetzt kommen wir eben aus einem Bereich wo es hieß: Regeln einhalten, schnelles Feedback holen, frühes Scheitern – also sehr sicherheitsorientiert. Das ist jetzt also der Bereich, der den ganzen Lösungsraum auch wieder sehr weit aufmacht.

Weiter >>>

[…]

Veröffentlicht in Rede

Wer genau ist unser Kunde?

Wer genau ist unser Kunde? (FFD, Folge 38)

(Das ist ja interessant, weil da hat sich Jemand wirklich Gedanken darüber gemacht, wer ist denn eigentlich unser Kunde? Und er oder sie hat wahrscheinlich eine Entscheidung getroffen: Der Kunde ist vielleicht nicht der High-Sophisticated Professor in der Klinik, sondern dass ist Jemand der vielleicht auf der Straße zufällig bei einem Autounfall vorbei kommt und der einfach Angst davor hat, einen schwerwiegenden Fehler zu machen. Da hat man dann plötzlich komplett andere Anforderungen. Das ist wirklich auch ein sehr interessanter Punkt, wie kann man das runterdeklinieren von der Kundensicht und dafür muss man erst einmal Klarheit haben darüber, wer überhaupt der Kunde ist.

Weiter >>>

[…]

Veröffentlicht in Rede

Verbotenes Feedback

Verbotenes Feedback (FFD, Folge 37)

((Ich habe noch eine kleine Frage und zwar: Kundenfeedback, Fail fast, extrem wichtig, keine Frage. Nur ist das in der Medizintechnik wahrscheinlich oftmals ein Problem, dass oft nicht alle Dinge immer am Kunden ausprobiert werden können. Also bei so einem Herzschrittmacher stelle ich mir das schwierig vor. Wie gehen Sie mit solchen Sachen um, wie gehen Sie auch mit gesetzlichen Regularien um, die Ihnen verbieten Kundenfeedback früh einzuholen?))

(Das ist eine persönliche Antwort die ich Ihnen darauf geben möchte. Da wo die Regulatorien klar etwas einfordern, da halte ich mich dran. Ich werde natürlich schauen – also bleiben wir mal bei dem Beispiel Herzschrittmacher, in der Notfallmedizin kenne ich mich ein bisschen aus. Defibrilatoren habe ich mitentwickelt, das geht ja so in Ihre Richtung. Da kann man nicht einfach mal sagen im Testteam: Wer hat Lust heute zu testen. (LACHEN) Das ist dann tatsächlich auch schwierig, wo holt man sich dann das Feedback. Ich glaube, dass es viele Bereiche gibt wo es einfacher ist, zum Beispiel alles wo es um Usability geht, um Fragestellungen was genau die Anforderungen sind, wo man etwas in genauen Zahlen darstellen kann. Aber gerade wenn es in disruptive Bereiche reingeht, wo man wirklich etwas komplett Neues machen will und es gleichzeitig nicht testen darf, dann befindet man sich in einem Dilemma von dem ich ehrlich sagen muss: Das habe ich noch nicht gelöst. ((Wir auch noch nicht.)) Das finde ich dann allerdings das interessante hier auf der Konferenz auch ins Gespräch zu kommen über die Fragen: Wer hat denn so etwas schon einmal gelöst? Wer hat denn Ideen? Und wie können wir es gemeinsam lösen? Ich glaube nicht, dass das etwas ist was ein Unternehmen alleine lösen wird.

Weiter >>>

[…]

Veröffentlicht in Rede

Radikales Feedback

Radikales Feedback (FFD, Folge 36)

((Ich habe noch eine andere, etwas disruptive Idee. Das wird noch nicht angewendet aber dass versuchen wir einzuführen. Das man wirklich eben auch Kundenfeedback sich zu holen und danach auch entlohnt zu werden. Also fragen: Fandest Du das jetzt gut? zwischen 0 und 10. Und bei den Zulagen kriegt man dann eben nur 80% des vereinfachten Preises. Das ist ein bisschen radikal, aber letztendlich ist es genau das wo wir hinwollen.))

(Da müssen wir uns dann nachher noch drüber unterhalten, superspannendes Konzept. Das ist letztendlich auch ein Feedback über solche Themen wie Vertrauen über Unternehmensgrenzen hinweg. Und das ist eine superspannende Sache zu der wir jetzt noch kommen. Nämlich: Regeln brechen.)

Weiter >>>

[…]

Veröffentlicht in Rede

Agile Verträge

Agile Verträge (FFD, Folge 35)

((Darf ich eine Frage stellen? (Ja immer) Ich erlebe das immer wieder, das ist alles richtig und so, aber das Problem ist irgendwo muss zwischen Auftraggeber und Auftragnehmer ein Vertrag geschlossen werden. Gibt es irgendwelche Erfahrungen darüber wie man dieses Ändern von Anforderungen vertraglich auf die Reihe kriegen könnte, so dass jeder davon einen Gewinn hat. Weil Auftragnehmer versuchen ja zu verhindern, dass sie überlastet werden durch ständig wechselnde Anforderungen.))

(Boris Gloger beschäftigt sich sehr stark mit genau dieser Fragestellung. Agiler Festpreis geht in diese Richtung. Ich glaube auch nicht, dass es ein Fehler ist zu dokumentieren, was man gemeinsam mit dem Kunden erreichen will. Aber noch wichtiger ist das Vertrauensverhältnis, dass man nachher auch ein richtiges Ergebnis bekommt und das man die Dokumente die dafür notwendig sind so spät wie möglich erzeugt. Wenn ich mir zum Beispiel die AAMI TIR 45 anschaue oder auch die entsprechenden europäischen Normen die sagen ja nicht, dass ein Pflichtenheft schon ein halbes Jahr vor der Implementierung vorhanden sein muss. Die Normen sagen lediglich „vor der Entwicklung“. Im Extremfall mache ich das also eine halbe Stunde vorher. Dann ist das Dokument da, dann arbeite ich danach, mache direkt danach einen Feedbackzyklus – passt! Es geht nicht darum die Normen auszuhebeln, sondern es geht darum sie richtig zu interpretieren und sowohl die Normen zu erfüllen als auch schnell zu sein. Die Normen müssen wir erfüllen, dafür sind wir in der Medizintechnik oder im Automotiv-Bereich. Sonst könnten wir dort nicht bestehen.)

Weiter >>>

[…]

Veröffentlicht in Rede

Moving Targets

Moving Targets (FFD, Folge 34)

Wie sieht das Ganze win der Praxis aus, an einem Bild visualisiert? Man kann entweder hingehen und sagen: So, der Projektstart ist links, dort beginnen wir mit dem V-Modell, müssen uns überlegen wo wir eigentlich hinwollen, schreiben ein schönes Pflichtenheft, das dauert zwar ein halbes Jahr, aber da steht dann genau drin: Da, dieser grüne Punkt, da müssen wir hin. Das wird dann dem Team verkündet und ab da wird es so gemacht.Und dann läuft das eine ganze Weile und man schaut nicht hin und ehe man sich versieht ist das Ganze an einer Stelle gelandet wo es gar keinen Sinn mehr macht. Weil die Wolke, die ursprünglich auch der Kunde im Kopf hatte, die ist fuzzy. Und die hat sich bewegt und ist auf einmal irgendwo hier unten, und das Produkt was entwickelt wurde hat auf einmal gar nicht mehr viel zu tun mit dem was der Kunde eigentlich wollte. Ich habe mal Zahlen gesehen, dass der Change der Anforderungen in vielen Projekten so um die 1-3% pro Monat ist. Und jetzt rechnen Sie das mal hoch auf so ein typisches Medizinprodukt mit 2, 3, 5 Jahren Laufzeit. Da steht am Ende kein einziger Satz mehr aus dem Ursprungsdokument mehr drin. Und deswegen funktioniert das Ganze auch nicht.

Weiter >>>

[…]

Veröffentlicht in Rede

Usability

Usability (FFD, Folge 33)

Verstehen ist unwahrscheinlich. Das ist etwas was ich häufig auch erlebt habe, auch dazu wieder ein kleines Beispiel aus der Praxis: Ich war in den letzten 10 Jahren sehr stark im Bereich Schlafmedizin unterwegs. In einem der letzten Projekte die ich dort gemacht habe haben wir ein Produkt entwickelt, das dafür da ist um Schlafapnoe-Patienten nachts beim Atmen zu unterstützen. Diese Patienten können nachts schlecht schlafen, die schnarchen, denen fällt der Rachenraum zu. Eine Möglichkeit diese Erkrankung zu beheben ist es, den Patienten nachts eine Atemmaske aufzusetzen, einen Überdruck darin zu erzeugen und dadurch wird der Rachenraum „geschient“ und die Patienten können wieder frei atmen. In der Literatur liest man dann wer die typischen Patienten sind und da stehen immer 3 Schlagworte: 1) Männer 2) alt 3) adipös. Adipös heißt einfach: Die sind dick. Mit dieser Prägung bin ich hingegangen und habe mir gesagt: Ich muss jetzt zum Ende eines Projekts noch einen Usability-Workshop durchführen. Da bin ich reingegangen mit der Ansicht: Komm, ich hole mir nur noch schnell den Haken ab für die Norm IEC 62366 und mache einfach einen schnellen Workshop mit Endanwendern. Ich bin dann in den Workshop reingekommen und direkt zu Beginn kam ein rüstiger Rentner auf mich zu. Der war schlank. Der war agil. Und er stellt mir die Frage „Herr Lange, wie lang wird eigentlich dieser Spaß hier heute dauern? Weil: In 1,5 Stunden möchte ich mit meinem alten Schulfreund hier in ein Taxi steigen, wir haben einen Flieger gebucht, wir machen eine Studienreise nach Moskau, nach Kiev und danach weiter nach Sibirien.“ Da viel mir erst einmal die Kinnlade runter weil das war etwas komplett anderes Bild als das was ich im Kopf hatte. Als nächstes sagte er: „Und übrigens dieses Gerät, was ich da ja nicht verstehe: Sie haben da so ein superschönes Touch-Display vorne, warum werden denn da nur diese komischen Fachwerte angezeigt? Ich habe das doch bei mir zu Hause auf dem Nachttisch stehen. Wäre das viel Aufwand gewesen, da ein Radiowecker reinzubauen? Und wieso ist denn der Ein-Aus-Schalter an der Seite, bei meinem Radiowecker ist der doch oben, damit ich mit dem Snoozer den Alarm einfacher aushauen kann.“ Dieser Anwender hat das komplette Produkt innerhalb von 5 Minuten komplett auf den Kopf gestellt. Daher meine Bitte, mein Appell: Holen Sie sich frühes Feedback. Frühes Scheitern erlaubt es schnell zu reagieren.

Weiter >>>

[…]

Veröffentlicht in Rede

Continous Feedback

Continous Feedback (FFD, Folge 32)

Continous Feedback. Das ist jetzt quasi die höchste Ebene. Wir kommen vom persönlichen über die Teams bis hin zu einer Ebene wo sogar die Unternehmensgrenze überschritten wird. Hier gehen wir zum Kunden und holen uns das Feedback und müssen auch auf dieser Ebene scheitern.

Weiter >>>

[…]

Veröffentlicht in Rede

Agilität & die gläserne Decke

Agilität & die gläserne Decke (FFD, Folge 31)

((Herr Lange, darf ich vielleicht noch eine Beobachtung machen? Ich habe das auch erlebt, dass in einer Struktur auch crossfunktionale Teams gibt, die dann auch total gelobt und gepriesen werden, die aber eben gar nicht funktionieren. Weil sie eben diese funktionalen Zwischenräume gar nicht überspringen können, also die Impediments sind so hoch, dass sie eigentlich gar nichts mehr leisten können und es wird trotzdem immer gesagt: Ja, super, ihr seid ja crossfunktional im Team – jaja, wir sind ja super Teamplayer. Und dann bleibt man da auch oft stecken weil man eigentlich das untere denkt und das obere aber macht. Und dann bleibt man einfach hängen: Man denkt, man macht es richtig, aber es passiert eigentlich gar nichts. Das ist eigentlich fast noch viel schlimmer. So etwas wie eine nicht erkannte Krankheit.))

( Und was ist Ihre Erfahrung, wo so etwas herkommt? Also wo dann auch die Grenzen herkommen? So wie ich es verstanden habe möchte das Team das ja gerne machen diese Zusammenarbeit aber irgendetwas hindert dieses Team daran es zu tun.)

((Genau. Im Grunde war es das was Sie erzählt haben: Diese Lieferstrecke muss klar sein. Die Eigenverantwortung der Lieferkette klären. Erst einmal gucken: Was muss ich denn überhaupt liefern? Und dann sitze ich mit einem crossfunktional so zusammen der durch seinem Chef so geprägt ist, dass er immer nein sagt. Dann muss ich also irgendwie versuchen, dass Team zu verändern und auch die Entscheidungsstrukturen in dem Team.))

(Lieferketten ist übrigens auch noch ein ganz wichtiger Punkt. Die Thematik kommt ein klein bisschen später.)

Weiter >>>

[…]

Veröffentlicht in Rede

Silodenken überwinden

Silodenken überwinden (FFD, Folge 30)

Hier das Ganze auch noch mal als Grafik aufgezeichnet. Vorher herrschte die Abteilungsdenke vor, die ja auch im Teufelskreis links unten sehr stark dafür gesorgt hat, dass eigentlich keine abteilungsübergreifende Zusammenarbeit möglich war und unten – das kennen Sie auch aus dem agilen Bereich -funktionale Teams schaffen, die in sich völlig autark leistungsfähig sind, die in sich einen Austausch haben, und die dann gf. noch einmal auf einer Ebene darüber wieder integrieren.

Weiter >>>

[…]

Veröffentlicht in Rede