Kapitel 4: Das potentiell nicht vorhandene Produktinkrement und meine erste Mission

Der Scrum Master: Das potentiell (nicht) auslieferbare Produktinkrement
Keine Kommentare

Scrum ist doof, so beginnt die Geschichte „Der Scrum Master“ von Jürgen Knuplesch, selbst Scrum Master, agiler Berater, Autor, Mathematiker, Trainer, Theologe und vor allem Mensch. Als agiler Enthusiast und Pragmatiker versucht er jeden Tag die Welt ein wenig zu verbessern, was ihm aber nur selten gelingt. In unserer Fortsetzungsgeschichte gibt er einen Einblick in seinen umfangreichen Erfahrungsschatz.

(Diese Geschichte ist sehr real und doch erfunden)

Das potentiell (nicht) auslieferbare Produktinkrement

Eine der schönsten Wortschöpfungen, die Scrum hervorgebracht hat, ist das „potentiell auslieferbare Produktinkrement“. Es klingt wie das aus der Biologie bekannte endoplasmatische Retikulum, hat aber damit nichts gemeinsam. Es erscheint im Scrum Guide 2017 genau einmal, wird aber an vielen Stellen einfach als „Inkrement“ bezeichnet.

Eigentlich sagt das Wort „potentiell auslieferbares Produktinkrement“ alles Wichtige aus. Es enthält aber auch drei Fremdwörter, und es ist kurz. Als Menschen besitzen wir die zweifelhafte Begabung, aus Wörtern Worthülsen zu machen. Eine Hülse ist eine des Inhalts beraubte Hülle. Scrum selbst ist eine der beliebtesten Worthülsen in Software-Firmen und wird im agilen Sektor nur noch durch das Schlüsselwort „agil“ getoppt. Weil vieles nur Worthülse ist, kann man am Ende fast alles als „agil“ verkaufen, auch wenn es das Gegenteil davon ist, weil erschreckend wenige eine Ahnung vom Thema haben. Wer aber jemals die Bedeutung des „potentiell auslieferbaren Produktinkrements“ verstanden hat, ist in der Regel von dessen Bedeutung begeistert. Das „Inkrement“ ist fester Bestandteil von Scrum und im Scrum Guide als eines der Artefakte definiert. Und zudem sagt der Scrum Guide, dass man, sobald man vom Scrum Guide abweicht, nicht mehr Scrum hat.

Das potentiell auslieferbare Produktinkrement entsteht am Ende des Sprints, und es ist „done“, das heißt „fertig“. Also nicht „eigentlich fertig“, auch nicht „fast fertig“ oder „so gut wie fertig“, auch nicht „fertig, aber noch nicht getestet“, und auch nicht „fertig programmiert, aber noch nicht gebaut.“ Das Produkt ist so fertig, dass man es dem Kunden in die Hand drücken kann. Und genau das passiert heutzutage bei tausenden von Apps und Anwendungen.

Der Scrum Master

Teil 1: Wie alles begann
Teil 2: Die Offenbarung
Teil 3: Re-Entry in die Realität
Teil 4: Das potentiell nicht vorhandene Produktinkrement und meine erste Mission

Alle paar Wochen kommt eine neue und funktionierende Version, und meistens funktioniert sie wirklich. Man muss heute nicht mehr ein Jahr auf die nächste Version warten, sondern die Software wird kontinuierlich weiterentwickelt und ausgeliefert. Und das passiert nach jedem einzelnen Sprint. Hat man also einen Sprintzyklus von zwei Wochen, entstehen jedes Jahr 26 neue Versionen eines Produkts. Darum ist das „potentiell auslieferbare Produktinkrement“ eines der geilsten Wörter in der agilen Software-Entwicklung.

Leider hatte sich das bei WabelTech noch nicht herumgesprochen. Das, was wir „Scrum“ nannten, produzierte kein „potentiell auslieferbares Produktinkrement“. Stattdessen entstand Code, der nicht von einem Tester getestet wurde und der nicht zu einem fertigen Produkt zusammengebaut wurde. Der Code wurde stattdessen dem ProductOwner im Review aus einer Entwicklungsumgebung gezeigt. Bei WabelTech gab es nur das „potentiell nicht vorhandene Produktinkrement“. Schade!

Ein guter Scrum Master spürt auch, was momentan möglich ist und was nicht. Die Mission „potentiell auslieferbares Produktinkrement“ war für den Anfang definitiv zu groß und landete darum in meinem persönlichen Scrum Master Backlog. Dafür wollte ich wenigstens an einer anderen Stelle für eine Verbesserung sorgen. Meine Mission lautete nun…

Meine Mission: Ein Tester für jedes Team

Ich begann also, bei jedem Kaffee und bei jeder anderen Gelegenheit davon zu reden, dass wir die Software bereits in den Entwicklungsteams testen sollten, denn „done“ heiße schließlich, dass die Software auch getestet wurde. Ich war so erfolgreich, dass das auch unser Bereichsleiter zu verstehen begann. WabelTech kam uns etwas unfreiwillig entgegen, weil sie einen an sich gut funktionierenden Bereich einfach als „ineffizient“ bezeichneten und von einem Tag auf den anderen auflösten. Ein Teil der freiwerdenden Mitarbeiter sollten „Tester“ in den Entwicklungsteams werden. Auch solche Gelegenheiten gibt es in der realen Welt: Es passieren weniger agile Dinge, und trotzdem kann daraus auch noch etwas Gutes entstehen. Da gilt es, nicht in einer Opferhaltung und im Frust zu verharren, sondern auch die Chancen zu nutzen.

So kamen Saskia und ein paar andere zu unseren Entwicklungsteams. Zudem wurde Nadja als Qualitätsmanagerin und Testerin eingestellt. Qualität war, wie alle paar Monate, wieder einmal Chefsache, weil sich Kunden beschwert hatten. Auf einmal hatte jedes Entwicklungsteam mindestens einen Tester. Ich war so glücklich darüber, dass es mich fast nicht geärgert hatte, dass mein Chef behauptete, dass die Idee von Erwin stammte (Sie erinnern sich…?). Na ja, das war eben Künstlerpech. Und mir ging es auch mehr um die Sache, als um meine Ehre.

Nadja legt los

Nadja wird also als Testerin meinen beiden Scrum-Teams zugeteilt. Auch die anderen Teams bekommen ihre Tester. Als Scrum Master ist es mir wichtig, neue Teammitglieder ins Team zu integrieren. Darum wird Nadja auch in einem von mir anberaumten Meeting dem Team vorgestellt.

Sofort fällt mir ihr starkes Qualitätsbewusstsein auf. Das können wir hier gebrauchen, denke ich, denn so mancher Entwickler gibt sich allzu schnell mit seinem Ergebnis zufrieden. Nadja passt auch menschlich gut zum Team. Das ist zumindest mein Eindruck. Sie weiß sich zu behaupten und hat auch im Daily Standup etwas zu sagen. Sie nimmt gleich mehrere wichtige Rollen ein. Nadja entpuppt sich immer mehr zu einer idealen Ergänzung für meine Teams.

Heute hat sich Nadja mit einem Entwickler gestritten. Offen, kontrovers und respektvoll. Wow! Das gefällt mir. Sie knickt nicht gleich ein, ist aber auch offen für die Argumente der Entwickler. Ja! Solche Diskussionen brauchen wir im Team.

Das Thema war natürlich, ob eine Story fertig ist oder nicht. Der Entwickler sagt ja, Nadja sagt nein. Bei ihren Tests hat sie Legionen von Bugs zu Tage gefördert. Der Entwickler meint aber, dass das nicht Teil der Aufgabe war, diese zu fixen, und dass diese Bugs schon davor im Produkt waren. Davon lässt sich Nadja aber nicht beeindrucken, denn wie soll der Kunde ein so defektes Modul nutzen, fragt sie. Hier muss natürlich der Product Owner entscheiden, denn ihm gehört das Produkt. Er hat die Vision, und er muss alles vor den Kunden und den Steak-Holdern, Verzeihung, den Stake-Holdern vertreten.

Zum Glück ist Udo einer, der auch abweichende Meinungen ertragen kann. Und so entscheidet er und gibt im Grunde beiden Recht. Die Story wird abgeschlossen, und die schlimmsten gefundenen Bugs müssen bis zur Freigabe des Features auch noch gefixt werden. Zwar nicht in diesem, aber dafür in einem der nächsten Sprints.

Nadja hat die vakante Rolle der Verteidigerin der Qualität im Team angenommen. Das war bitter nötig. Die Idee, Tester in das Team zu holen, war agil, logisch und zeigt Früchte. Ich habe zwar kein potentiell auslieferbares Produktinkrement, dafür aber eine Verbündete für die Qualität unseres Produkts gefunden. Es fühlt sich gut an, etwas zu bewirken und zu sehen, dass es Menschen wie Nadja gibt, die ihre Aufgabe mit Leidenschaft erfüllen. So kann es weitergehen!

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -