bor!sgloger » Marc Bless

Wie viel bin ich wert? Die Geschichte einer User Story

Marc Bless — Thu, 28 Feb 2013 06:33:55 +0000

Am Anfang war das Nichts und es war dunkel. Und mit einem Mal blitzte es kurz auf, es ward Licht im Geiste und ich entstand als eine assoziierte Idee. Und meine Erzeugerin sprach: „Ja, jetzt hab ich‘s“ und schuf mich auf einer kleinen, weißen Welt. Ich glaube, meine Welt war eine Scheibe. Jedenfalls war sie äußerst flach. Im Laufe der Zeit veränderte mich meine Erzeugerin noch an der einen und anderen Stelle. Teile von mir wurden durchgestrichen, Teile von mir wuchsen neu aus mir heraus.

Meine Erzeugerin war stolz auf mich und zeigte mich den anderen Göttern. Diese begannen sofort, über mich zu sprechen, meine Sinnhaftigkeit zu hinterfragen. Wie groß und komplex ich sei. Und dass ich in meiner jetzigen Form gar nicht umzusetzen sei. Zu aufgebläht sei ich und viel zu viele Abhängigkeiten hätte ich an mir haften. Die anderen Götter wollten mich halbieren und in kleine Stücke zerschneiden, denn ich sei eine Dreizehn!

Meine Erzeugerin gebot Einhalt und sprach:
„Nur im Ganzen kann ich sie brauchen. In kleinen Teilen nützt sie mir nichts!”

Die Götter aber ermahnten meine Erzeugerin und sprachen: „Dann sag uns, wie wertvoll sie für dich ist!“

Meine Erzeugerin antwortete beschämt: „Das kann ich nicht. Ich weiß nicht, wie viel sie wert ist. Aber sie ist wichtig, wir müssen sie umsetzen.“

Die Götter aber riefen voller Zorn: „Alles, was du uns bringt, ist wichtig und muss umgesetzt werden! Nenne uns ihren Wert, sonst werden wir sie in kleine Stücke hacken und einzeln umsetzen!“

Meine Erzeugerin nahm mich mit zu ihren Brüdern und Schwestern und fragte diese nach meinem Wert. Die anderen Erzeuger aber sprachen: „Wir wissen nichts über ihren Wert. Alles, was wir erzeugen, ist wichtig und dringend und muss umgesetzt werden.“

So wurde ich schließlich in einen Stapel gesteckt und zwischen anderen Welten meiner Art eingequetscht. Ich verlor das Bewusstsein kurz nachdem ich die Götter sagen hörte, ich sei wohl doch eher eine Vierzig. Als ich nach langer Zeit wieder erwachte, fand ich mich selbst wieder – gewandelt in eine Funktionalität. Seit langer Zeit warte ich nun darauf, dass ich endlich von jemandem benötigt und ausgeführt werde. Ich gebe die Hoffnung nicht auf, schließlich war ich doch so wichtig …

Die Moral dieser Geschichte ist ganz einfach. Product Owner dieser Welt, denkt über Business Value nach und gebt Euren User Stories einen ernsthaften, echten Wert mit auf den Weg!

Stories mit Business Value werden Euch helfen, Euer Backlog in eine priorisierte Ordnung zu bringen. Und sie werden die Kommunikation zwischen dem Team und Euch auf eine neue, ganz andere Ebene heben!

Das mag vielversprechend und beinahe zu schön klingen. Auf die Spitze getrieben möchte ich es folgendermaßen formulieren: Macht Euch und Eurem Team ein schönes und bequemes Leben, denn ohne Business Value habt Ihr die völlige Freiheit, tun und lassen zu können, was Ihr gerade gerne möchtet.

“Ich mache mir immer wieder Vorwürfe, dass meine Malerei nicht wert ist, was sie kostet.”

Vincent van Gogh

“Meist belehrt erst der Verlust über den Wert der Dinge.”

Arthur Schopenhauer

Es geht nicht um Software-Entwicklung!

Marc Bless — Wed, 06 Feb 2013 07:14:51 +0000

Kurz nachdem ich meinen neuen Job als Management Consultant bei bor!sgloger angetreten hatte, gratulierte mir ein ehemaliger Kollege mit den Worten: „Have fun making software teams productive!“

Geht es bei Scrum wirklich um Software-Entwicklung? Kann es das richtige Ziel sein, ein einzelnes Entwicklungs-Team produktiv zu machen? Dreht sich die Einführung eines agilen Mindsets in einem Unternehmen tatsächlich um technische Praktiken und Management-Frameworks?

Nein! Das alles greift viel zu kurz.

Immer wieder höre ich von Managern den Wunsch: „Wir müssen effizienter werden.“ Dahinter steckt oft der klassische Ansatz der lokalen Optimierung. Wenn nur jeder Bereich, jede Abteilung, jedes Team und jeder Mitarbeiter maximal ausgelastet sei, dann würden unsere Projekte auch schneller fertig.

Immer wieder höre ich von Managern die Aussage: „Die Entwicklung muss eine bessere Qualität liefern. Das Anforderungsmanagement muss bei uns vorgelagert sein. Der Betrieb ist sowieso voll ausgelastet, da die Software nie richtig funktioniert.“ Auch hier wird die Software-Entwicklung als zentraler Schuldiger gesehen, durch den die Probleme in der restlichen Organisation verursacht würden.

Was geschieht nun im Regelfall nach einer erfolgreichen Einführung von Scrum und agilen Entwicklungsmethoden? Die beteiligten Manager erkennen nach kürzester Zeit, dass die Probleme in der restlichen Organisation nicht verschwinden, obwohl die Entwicklung funktionierende Software schneller und in besserer Qualität liefert.

Scrum hat die Macht, die wahren Probleme einer Organisation sehr schnell offenzulegen! Und diese Offenlegung geschieht eben auch an den Schnittstellen der Entwicklungsteams in andere Bereiche. Damit erkennen wir die Kommunikationsschwierigkeiten zwischen allen Beteiligten am Produktentstehungsprozess. Produktmanager haben vielleicht noch nie mit Administratoren gesprochen, Verkäufer noch nie mit Testern, Entwickler noch nie wirklich mit dem Support. Aber all diese Mitarbeiter mit ihren unterschiedlichen Verantwortungen müssen gemeinsam daran arbeiten, den „Wow!“-Effekt für Kunden und Anwender zu erzeugen!

Durch die reine Optimierung unserer Entwicklungsmannschaft werden wir es nicht schaffen, den Anwender signifikant zu begeistern. Nur durch das Zusammenspiel aller Beteiligten können wir ein Produkt, eine Dienstleistung erzeugen, die der Anwender wirklich haben möchte.

Was müssen wir also tun, um ein erfolgreiches Scrum-Unternehmen zu transformieren?

Eigentlich ganz einfach: die Scrum-Teams müssen cross-funktional mit Beteiligten aus allen Unternehmensbereichen besetzt werden, die zur Erschaffung des Produktes benötigt werden!

So einfach dies klingt, so schwierig ist die Umsetzung der dafür notwendigen Grundlage: Veränderung der Unternehmensstruktur und vor allem der Unternehmenskultur. Das bedeutet, das agile Mindset, also die agilen Werte und Prinzipien, im Unternehmen auf allen Ebenen zu etablieren. Dies ist die eigentliche Herausforderung, mit der wir es zu tun haben. Und ich freue mich jeden Tag darüber, wenn ich sehe, wie Mitarbeiter und Manager sich von ihren traditionellen Vorstellungen Stück für Stück trennen, weil sie erkannt und erfahren haben, dass es andere, vielleicht erfolgreichere Wege gibt, mit Menschen gemeinsam ein funktionierendes Produkt zu bauen.

Wenn ich meinen alten Kollegen das nächste Mal treffe, werde ich ihm also antworten: „I have fun changing product development organizations. And sometimes that even may have something to do with making software teams productive.“

Die Dilemmafrage: A oder B?

Marc Bless — Tue, 29 Jan 2013 07:22:57 +0000

Beinahe täglich quäle ich mich damit, welche Wahl ich auf der Speisekarte treffen soll. Fisch oder Fleisch? Kohlenhydrate oder Proteine? Was ist besser? Ist eines gesünder als das andere? Ach, ich kann mich wieder mal nicht entscheiden …

Auch Teams müssen täglich Entscheidungen treffen, die herrliche Konfliktpotentiale innerhalb des Teams an die Oberfläche bringen können.

Jim: „Wie sollen wir die Themen auf unserer Liste bearbeiten? Ich bin der Meinung, durch Arbeit in kleinen Gruppen bekommen wir die besten Ergebnisse.“

John: „Nein, Gruppenarbeit hilft uns da überhaupt nicht weiter. Wir haben wichtige Fragen zu klären, das können wir nur mit allen aus dem Team bearbeiten.“

Jack: „Nein, wenn wir alle beteiligt sind, kommen wir wieder zu keinem sinnvollen Resultat. Ich bin für Gruppenarbeit.“

Joe: „Gruppen kommen für mich nicht in Frage, dafür sind mir die einzelnen Themen viel zu wichtig.“

Jennifer: „Wenn eine Arbeitsgruppe ein Ergebnis erarbeitet, dann ist das für mich in Ordnung.“

Jessica: „Ich will aber auf jeden Fall überall dabei sein.“

Und so weiter und so fort.

Wie soll sich das Team in so einer Situation entscheiden, in der es auf den ersten Blick keine richtige Entscheidung gibt? Das Team steckt in einem Dilemma und jetzt ist der ScrumMaster gefragt, um das Team aus diesem Dilemma zu befreien. Ein guter ScrumMaster erkennt diese Situation und hilft dem Team, kreativ und neu zu denken, weitere Optionen und Alternativen zu finden, sowie aus festgefahrenen Denkmustern auszubrechen. Wir können weder vor noch zurück? Was ist mit links und rechts? Oben und unten? Raumkrümmung, höhere Dimensionen oder Beamen?

Falls er eine eigene Antwort auf die Dilemmafrage hat, muss sich der ScrumMaster inhaltlich zurücknehmen und seine ganze Energie darauf verwenden, den kreativen Raum für das Team zu schaffen und alle möglichen Ergebnisse des Teams als Moderator festzuhalten.

„Nehmt an, wir könnten weder A noch B durchführen. Welche Möglichkeiten hätten wir noch?“
„Nehmt an, wir könnten sowohl A als auch B durchführen. Wie würde die Kombination aussehen?“
„Was würde passieren, wenn wir nur A durchführten? Was müssten wir tun, um dies auszugleichen?“

Das Team wird Lösungen finden und gemeinsam die sinnvollste Variante herausarbeiten, mit der alle Teammitglieder gut leben können. Die Frage bezüglich Gruppenarbeit oder Teamentscheidung besitzt auch mindestens eine Antwort. Was spricht dagegen, erste Zwischenergebnisse in Arbeitsgruppen zu erzeugen und diese im Anschluss mit dem ganzen Team zu diskutieren? Ebenso gut könnten Ergebnisse von Einzelnen erarbeitet werden. Selbst die Entscheidung, überhaupt niemanden daran arbeiten zu lassen, kann in bestimmten Situationen sinnvoll sein. Ich überlasse die Beantwortung dieser konkreten Dilemmafrage der einzelnen Leserin und ihrer spezifischen Situation als Hausaufgabe.

Ich selbst entscheide mich dann übrigens für die vegetarische Pasta. Obwohl ja Steak mit Salat auch immer eine gute Alternative bietet. Nein, heute mal Nulldiät, ich esse einfach nichts. Also gut, wenigstens ein kleines Dessert … oder zwei.