Optimierst du noch oder wirkst du schon?
Zwei Wörter, eng verwandt, aber im Kern unterschiedlich: Eines vergeudet wertvolle Zeit, das andere schafft echten Nutzen. Dem Fractional Developer ist es klar: Effektivität ist der Schlüssel!
Uwe Friedrichsen schrieb vor kurzem in seinem Blog über Effizienz vs. Effektivität. Wunderbar! Seine Worte könnten nirgendwo mehr Zustimmung finden als bei mir. Vielleicht magst du hier kurz reinlesen!
Meine Beobachtung: Das Thema Effizienz vs. Effektivität hat eine riesige Auswirkung auf das ganze Purpose Thema. Heute spricht ja jeder und überall von Purpose. Klar, es ist eine andere Generation in der Mitte des Arbeitsmarktes und der aktuellen Generation ist das Thema Purpose sehr wichtig. Also Fragen wie “hat das was ich tagtäglich mache einen Sinn?”, “Stifte ich damit was gutes?” oder vielleicht eine Nummer kleiner “bekommt der Kunde denn überhaupt mit dass ich heute Code geschrieben habe?”
Man könnte jetzt argumentieren, “Blödsinn!” das muss doch nicht immer sein.
OK, aber wenn nicht immer, wieviel Purpose sollte es dann sein? Bzw. wieviel Sinnlosigkeit erträgt ein Entwickler? Aber in jedem Fall kann ich sagen, dass Entwickler sehr wohl mitbekommen wenn ihre Arbeit nicht effektiv ist. Wenn ihre Arbeit nicht beim Kunden ankommt.
Was darauf folgt, ist eine Negativspirale.
Entwickler entwickelt an Story X. Story X ist nichts effektives. Am Ende gibt es ein Button, der die Augen des Hundes der PM schont. Entwickler ist null motiviert. Entwickler hat bisher schon Buttons für alle Haustiere vom PM entwickelt und trödelt jetzt mit der Aufgabe. Daher kriegt Entwickler die Aufgabe zum Sprintende nicht fertig. Bei der Retrospektive heißt es dann natürlich “Wie können wir effizienter werden?” und damit geht die Spirale weiter.
Das Backlog - der Selbstzweck
In einem effizientem System gibt es ein Backlog. In diesem Backlog sind genügend Aufgaben für die nächsten drei Jahrzehnt. Viele von diesen Aufgaben sind auch ausdefiniert. Klar, muss ja effizient sein. Dazu gab es in der Vergangenheit Grooming 1-16 damit immer Arbeit vorbereitet ist.
Das Problem hier: Keine Aufgabe ist dringend. Denn ich würde argumentieren, dass wenn eine Aufgabe aus dem Backlog dringend wäre, entweder die Kunden “die Bude einrennen” würden oder die Aufgabe wäre schon längst erledigt.
Dieses Problem wird noch schlimmer, weil sich unsere Welt so schnell ändert.
Der nächste Punkt: Bis eine Aufgabe aus dem Backlog dran kommt um abgearbeitet zu werden, hat sich unsere aktuelle VUCA Welt ohnehin geändert oder der Kunde ist schon längst weitergezogen.
Also ist das Backlog per definition ein Parade Beispiel für Effizienz, jedoch nie für Effektivität. Weil das so ist, müssen wir anders über die Dinge nachdenken. Und es gibt schon ein paar gute Ideen dafür.
Es ist wahr. Irgendwo sind wir falsch abgebogen. Nicht Effizienz ist die Lösung, sondern Effektivität. Ja, so wie es auch Uwe sagt, es muss ein Umdenken stattfinden und ja, ich befürchte auch dass es ein weiter Weg ist. Aber es gibt Lösungsansätze.
z.B. spricht von “Burn the Backlog”. Wie ich finde, ein echt zielführender Ansatz. Weil man dann immer wieder “raus” gehen muss und mit den Kunden sprechen muss um etwas zu bauen, was dann wieder aktuell, dringlich und zielführend für den Kunden ist.Der Fractional Developer
Dann gibt es noch den "Fractional Developer". Der "FracDev" ist bis ins Mark effektiv.
Das fängt schon bei der Zielgruppe des "FracDev" an. Denn diese sind genau diejenigen, die Effektivität brauchen anstatt Effizienz. Der ideale Abonnent will die richtigen Ergebnisse, hat selbst keine Zeit, hat begrenzte Ressourcen und kann daher noch nicht wachsen. Ein Dienstleister kommt aber nicht in Frage, da zu teuer. Am liebsten würde der Abonnent die Aufgaben selbst erledigen.
Wenn dieser Abonnent und der "FracDev" erstmal zusammengekommen sind, geht die nächste Phase der Effektivität los. Denn der "FracDev" ist so unwissend wie möglich! Er macht keine Annahmen, um eine Zeile Code zu schreiben. Er erfindet nicht Anforderungen und er kann auch nicht ohne klare Anforderungen arbeiten, denn sonst müsste er ja wieder Annahmen treffen. Das heißt, der "FracDev" wird bei jeder Unklarheit wieder zum Abonnenten "laufen" und um Klarheit bitten. Das ist seine Stärke! Der "FracDev" erkennt Unklarheiten und weiß, dass das Ergebnis durch die kleinste Unklarheit völlig daneben gehen kann. Vor allem kann aber auch der Abonnent bei jeder Feedbackschleife nicht nur Unklarheiten lösen, sondern hat immer wieder die Möglichkeit, seine Kunden genauer kennenzulernen. Das löst der "Fractional Developer" aus. Bewusstsein über die Anforderungen und Wünsche des Kunden.
WIP=1
Was auf dem ersten Blick danach aussieht, dass sich da jemand Arbeit sparen will und nicht effizient ist, ist genau das, womit der "Fractional Developer" Effektivität erzwingt!
Denn mit WIP=1 kommt nicht nur weniger Arbeit, sondern auch zuallererst eine Priorisierung. Eine Priorisierung, bei der der Abonnent wieder an seine Kunden denken muss. Denn ist erstmal eine Aufgabe angefangen, wird sie auch zu Ende gebracht. Solange wird an nichts anderem gearbeitet bzw. an Effizienz geschraubt. Das erzwingt und erzielt Effektivität und genau das sind die Rahmenbedingungen, um mit dem "Fractional Developer" zu arbeiten.
Fazit
Es reicht nicht, nur an der Oberfläche zu kratzen. Vielleicht müssen wir die Rahmenbedingungen ändern, um wieder effektiv statt nur effizient zu sein. So finden wir Lösungen, die wirklich zeitgemäß sind.