Kommentierte Links (XXVI)
Ein weiser alter Mann blickt zurück und erklärt, was unter zwei der zentralen Begriffe von Scrum zu verstehen ist. Das Besondere: Ron Jeffries ist einer der Pioniere agiler Softwareentwicklung, gehört zu den initialen Unterzeichnern des agilen Manifests und kennt die Erfinder von Scrum persönlich. Man kann also davon ausgehen, dass er weiss wovon er spricht. Besonders seine Interpretation von "Done" gefällt mir:
"in every regard, in good enough condition to be shipped to customers". Eben nicht perfekt, eben nicht "zu Ende entwickelt", sondern gerade gut genug um zum Kunden gebracht zu werden, damit aus dessen Feedback gelernt werden kann.
Apropos Erfinder von Scrum. Ken Schwaber (einer der beiden) erklärt warum nicht viel mehr von den good practices und best practices in den Scrum Guide aufgenommen wurden. Seine Antwort: damit er nicht zu spezifisch wird. Je spezifischer, desto größer die Gefahr, dass er für manche Teams zu einengend wird und für andere gar nicht mehr anwendbar. Tatsächlich sehe ich in einigen von mir gecoachten Teams, dass die Frage "
Ist das noch Scrum oder kann das weg?" sehr unterschiedlich beantwortet wird. Warum sollte man hier durch eine einheitliche Zwangslösung funktionierende Vielfalt beschneiden? Ich wüsste keinen Grund.
Eine Frage die ich mit meinen Kunden seit Jahren diskutiere ist:
"Was machen die Manager wenn hier alles agil ist?" Eine einfache Antwort darauf gibt es nicht (warum müssten wir sonst jahrelang diskutieren) aber viele gute Ansätze. Ron Eringa sammelt einige davon und ordnet sie in ein Phasenmodell ein, das dem jeweiligen Manager eine schrittweise Evolution ermöglicht. Für mich wichtig ist dabei der systemische Ansatz. In Eringas Worten:
"Each of the stages has a relation to the maturity-level of the Scrum team. An Agile Manager cannot grow when the Scrum Master, Product Owner and Development Team are not growing along."
Ein weiteres Dauerbrennerthema. Und das Problem wird durch Tranter gleich zu Beginn auf den Punkt gebracht:
"The wrong people are doing the measuring, and the wrong things are being measured". Mit anderen Worten, es wird erneut versucht command & control auf Ebene einzelner Arbeitsschritte zu machen. Die Folgen dessen sind seit über 20 Jahren bekannt - am Ende wird nur noch für Zahlen gearbeitet, nicht mehr für Ergebnisse. Die Alternative besteht darin, sich bewusst zu machen welchem Geschäftszweck das Produkt überhaupt dient und die Messung hier anzusetzen.
Ursprünglich stand hier ein Link zum t3n-Artikel
Der Weg ist das Ziel. Eine nett geschriebene Einführung, nichts Spezifisches. Der TechBeacon-Artikel von Matthew Heusser ist sehr spezifisch und sehr wichtig, da er um Probleme kreist an denen viele agile Transitionen scheitern: fehlende Einbeziehung und fehlendes Verständnis des Managements. Er arbeitet sehr gut die Hintergründe und Ursachen heraus, wird aber leider gegen Ende etwas dünn. Sein Lösungsansatz lautet nämlich (vereinfacht gesagt), dass man die erkannten Probleme einfach lösen soll. Wenn es so einfach wäre. Allerdings ist alleine die Erkenntnis der Probleme schon viel, viel wert.
