Entstehung, Idee und Einordnung der Work-Feedback Loop

Seit der Veröffentlichung der Work-Feedback Loop habe ich ein paar Fragen bekommen. Zeit, diese in einem Artikel zu beantworten.

Wie ist die Work-Feedback Loop entstanden / Was ist der Anlass gewesen?

In Gesprächen online (vor allem auf Mastodon), aber auch auf der Arbeit, bin ich immer wieder an den Punkt gekommen, mir die Frage zu stellen, wie ich agiles Arbeiten definiere. Weiterhin hab ich vermehrt - auch für mich selber - festgestellt, dass der Begriff agil ziemlich verbrannt ist. 

Aus diesen beiden Blickwinkeln - was ist die Essenz von agilem Arbeiten und wie kann man sie erklären, ohne den Begriff agil zu benutzen - ist die Work-Feedback Loop entstanden. 

Schlussendlich geht es darum, dass wir nur erfolgreich in einem schnellen Markt arbeiten können, wenn Arbeit ("Work") mit Reaktion ("Feedback") eng gekoppelt ist. Es ist nötig, dass Feedback einen direkten Einfluss auf Arbeit hat. Zitat aus dem ersten Absatz der Work-Feedback Loop:

Die WorkFeedback Loop ist ein Denk- und Diagnosemodell, das zeigt, ob Arbeit in deiner Organisation realen Effekt erzeugt, sichtbar wird, Entscheidungen auslöst und dadurch zukünftige Arbeit tatsächlich verändert. So findest du schnell die strukturelle Engstelle, die eure Anpassungsfähigkeit begrenzt – ohne über Methoden oder „Agilität“ als Label zu diskutieren.

Dieses prägnante Bild ist die Basis und so ist die Work-Feedback Loop entstanden. Die Entwicklung hin zu einem Diagnose-Modell war dann der natürliche nächste Schritt.

Und der Begriff Modell ist mir hier wichtig. Die Work-Feedback Loop ist keine Methode. Sie ist kein Ersatz für Scrum oder Kanban. Sie will auch andere Methoden und Denkmodelle wie Flight Levels oder PDCA nicht ersetzen.

Und damit kommen wir zu der zweiten Frage, die ich so öfter bekommen habe.

Wie positioniert sich die Work-Feedback Loop in Relation zu anderen Methoden oder Modellen?

Ich denke, der beste Einstieg ist die folgende Grafik.

Ich teile hier die nahen Begriffe in die Dimensionen "Team Level" oder "System Level" sowie "Unterstützt Arbeit" oder "Erklärt Systeme" ein. 

Methoden oder Modelle, die eher operativ und nahe am Team sind, sind weiter unten angesiedelt. Sind sie eher für die tägliche Arbeit gedacht, befinden sie sich weiter rechts. 

Scrum als Methode ist in dieser Sicht unten links im Diagramm. Das Cynefin-Framework als Methode um Komplexität einzuordnen und daraus angemessene Entscheidungen und Handlungsweisen abzuleiten ist oben rechts.

Die Work-Feedback Loop versteht sich als Denkmodell für die Diagnose. Sie ist nicht als alltägliches Tool oder gar Methode zu verstehen. Daher steht sie relativ weit oben. Mit der Work-Feedback Loop lassen sich Systeme sehr gut diagnostizieren, daher steht sie relativ weit rechts.

Damit sind die beiden großen Fragen erst einmal erläutert. Natürlich freue ich mich auf weiteres Feedback - ihr erreicht mich hier.

Mastodon Diskussionen