Product Backlog-Praxis — Hilfe, wir ertrinken…

3.547 (!) Einträge im Product Backlog [PBL]: beeindruckend – oder eher irritierend?! Das PBL als Problem-Indikator? Wie ist der Kontext?

Im Herbst 2010 wurde der Entschluss gefasst, dass das bisherige [ref]“CRM-System” eines Immobilien-Vertriebs schrittweise durch eine “richtige Programm-Entwicklung” abgelöst werden soll.

Das alte System ist eine noch vor dem Jahrtausend-Wechsel begonnene und durch einige Mitarbeiter selbst “gestrickte”, dennoch beeindruckende Word-, Excel- und Access-Snippet-Sammlung. In seiner gewachsenen Komplexität wird/ist es inzwischen unwartbar. Es unterstützt nach Angaben der beiden Geschäftsführer gut einhundert teils neben-berufliche Immobilien-Berater.

Zu meiner Überraschung wird die “IT” durch eine Handvoll technik-affiner Mitarbeiter betrieben, die den ein oder anderen Kontakt zu einem externen Dienstleister pflegen. Allerdings werden dessen Berater durch das interne IT-Team aus Kostengründen nur gelegentlich und “…maximal halb-tageweise…” zur Unterstützung angefordert. Im Wesentlichen wird alles in Eigenregie umgesetzt.

Werner…

Aus dem internen Mitarbeiter-Kreis hat mich ein Kollege über drei Ecken um Hilfestellung gebeten. Er interessiert sich nach eigener Aussage “besonders für’s Programmieren und agiles Projekt-Management…”. Nennen wir ihn Werner [1].

Werner treibt und koordiniert das gesamte Vorhaben. “Ich habe einen guten Draht zur Geschäftleitung”, erklärte er zu Beginn.

Seine “…Programmiersprache der Wahl ist PHP…weniger Java…”, als Application Server favorisiert er “…den Tomcat…”. Er möchte dringend seinen “Scrum Master machen” und ist von “Pichlers Scrum-Buch” begeistert [2], hat aber bisher keine Zeit und keine Budget-Freigabe erhalten. [guter Draht?]

Er ist in persona Programmierer, Archtitekt, Tester, ein bisschen Admin und – wie er freudig schildert – zu 20 % Product Owner. Außerdem “macht er noch ein wenig den Scrum Master”. [guter Draht?]

Unglaublich, gerade diese Personalunion?!
Ein sicherlich nicht einfacher Kontext, mit allerhand Herausforderungen, bei allen Beteiligten.

Product Backlog

“… Das Product Backlog ist eine geordnete Liste mit allem, was in dem Produkt benötigt werden könnte…”
[ref]Scrum Guide, Oktober 2011

Werner, mit ein wenig Stolz: “Hier ist meine Backlog-Liste.”

Eine Fleiß-Arbeit, unbenommen!

Dieses PBL springt als eines der Anzeichen für den dortigen erheblichen Optimierungsbedarf sofort in’s Auge. Ein fast 60 Seiten starker Blätter-Stapel einer Excel-Tabelle. Er erzählt – im Unterton etwas seufzend -, dass dieses Verzeichnis einmal pro 4-Wochen-Sprint ausgedruckt und vor dem nächsten Sprint-Start jeweils einen endlosen Tag lang durchgearbeitet wird.

“…Seitdem wir agil arbeiten, darf und kann in die Backlog-Liste jeder im Unternehmen seine Ideen, Wünsche und ‘Anforderungen’ eintragen…”, beschreibt er. [Hmmm?]

Einträge, die man zur Vorbereitung von “User Stories” nutzen könnte, haben geschätzt einen Anteil von 30 Prozent (ca. 1.000). Der große Rest sind “technische Stories”. Davon werden die Hälfte (1.200+) über die Excel-Spalte “Bugs” verwaltet. Weitere verteilen sich auf die Spalten “Technical Debt” und “Misc”. Nach meinem ersten groben Einblick könnten manche Fehler auch technische Schulden sein; und umgekehrt.

Nach einem Entwicklungsjahr (Werner: “… wir wollten erst einmal vorsichtig mit einer Version pro Jahr anfangen…”) wurde dann das erste Release zum Jahreswechsel in der zweiten Januar Woche verteilt.

Wenig erstaunlich, sein Hilferuf:

“Wir ertrinken …

… in der Liste …”

Nur in der Liste, nur in den PBL-Items?
Eindrücke über Eindrücke… Fragen über Fragen…

Lessons Learned ?

Habe ich schon etwas gelernt? Noch nicht wirklich…

Auch einige Tage nach meinen ersten beiden Gesprächen, in denen ich als Agile Coach – gefühlt eher als Seelsorger – ursprünglich von Werner um Unterstützung gebeten wurde, bin ich aufgrund des oben skizzierten Kontextes immer noch sehr verwundert, irritiert und bewegt [“bewegt” im Sinne von “berührt”, aber auch “Orientierung suchend”].

Es gibt viele [ref]Hebel, die man in Bewegung setzen muss bzw. könnte, um Werner und seinen Kollegen zu helfen. Zwei Mindmaps voll mit zu klärenden Punkten und zu prüfenden Maßnahmen quellen inzwischen über.

Nur, hier stellen sich mir unter anderem die Fragen, ob man eine realistische Chance hat, die Aufgabe rein auf der methodischen Ebene anzupacken. Oder ist es nachhaltiger bzw. ein unbedingtes Muss, die Problematik grundsätzlicher zu adressieren: nämlich bei der Geschäftsleitung.

Von dort werden die Mitarbeiter bis über die Grenzen gefordert (“Wochenend-Arbeit? Klar…”), aber leider nicht [ref]gefördert.

Obwohl unterschwellig eine Demotivation zu spüren ist – nicht nur bei ihm – ist das (Betriebs-) Ergebnis erstaunlich gut – zu gut? Der Leidensdruck der Geschäftleitung ist vermutlich deshalb kaum spürbar. Der Leidensweg der Mitarbeiter umso deutlicher:

Hilfe, wir ertrinken…

Bedenklich, traurig oder tragisch? Was meinst Du?

[cu]

[1] wie liest man so oft: “Richtiger Name der Redaktion bekannt” 😉 – und, der Name hat natürlich nichts mit dem [ref]“Werner-Syndrom” zu tun

[2] [ref]Scrum – Agiles Projektmanagement erfolgreich einsetzen, Roman Pichler, 2007

[thx]Carsten Grunwald / pixelio.de

6 Comments

  1.   

    Die Branche, das Unternehmen, „Werner“ sind austauschbar.
    Ich könnte sofort  vier Unternehmen
    eintragen, wo es ähnlich zugeht.

    Selbst in Unternehmen mit exzellenter Finanzausstattung will
    man die Rolle „Scrum Product Owner“ nicht einrichten. Product Owner, die  verbindlich pro Sprint priorisieren, die komplette
    User Stories mit Test- und Akzeptanzkriterien  schreiben, die von  Software so viel verstehen, dass Sie den
    Entwicklern jederzeit mit Rat zur Seite stehen.  Dann gibt es keine langen Backlogs die User
    Stories, Tasks, Bugs, technische Bringschulden, usw.  vermischen.

    Aber der Product Owner nimmt dem Produkt Managment und dem
    Senior Management Macht weg. Selbst wenn man Scrum mit Kanban unterlegt.  Dagegen wehren sie sich im Konsens.

    Sie können dann nicht mehr tagesaktuell die Teams mit neuen „ganz
    wichtigen“ Aufgaben beglücken, kommandieren, dirigieren.  Im Regelfall bevorzugen die zumeist auch „gedienten“
     Manager  „Command and Control“, so wie bei der
    Bundeswehr gelernt. Es funktioniert. Sie werden vom Top-Management belohnt.
    Warum sollen sie es ändern?

    Gelegentlich findet sich aber auch das neue Denken, „Management
    3.0“. Es sind häufig amerikanische Manager, die agiles Denken beim USMC gelernt
    haben. Freilich läuft es dann anders und Fälle wie da Endlos-Backlog gibt es
    dort wohl kaum.  

    Und was macht man mit dem Command-Control-Managern?

    Ken Schwaber empfiehlt: Bevor Scrum in einem Unternehmen
    eingeführt wird, sollten möglichst viele Manager im „Enterprise Transition Team“
    eingebunden werden. Agiles Denken  muss zuerst
    Top-Down in die Köpfe kommen.  Erst wenn im
    Senior Management Konsens über Agilität besteht, ist es erfolgsversprechend,
    die IT-Teams nach Scrum & Kanban arbeiten zu lassen.

    Ein wichtiges
    Hilfsmittel für die agile Überzeugung bildet dabei der untere Teil des Scrum
    Boards: Das Kanban Board. Den über die Steckkarten (jap. Kanban)  hält sich das Management die Option offen, letztendlich
    doch noch  „ganz wichtige Aufgaben“ direkt
    in die Teams hinein zu steuern.

    Aber damit lässt sich letztlich  agil leben.

    • Herzlichen Dank für die vielen – bedauerlicherweise sehr bekannten – Impulse.

      Ja, dieses Beispiel ist eines von vielen – leider.

      Unternehmen, die es sich leisten könnten, und jene, die es sich aufgrund angespannter Finanzen leisten müssten, verharren in ihren “alt-gedienten”, aber nicht “alt-bewährten” Strukturen.

      Zu viele Wörter in den Chef-Etagen verhindern einen Paradigmen-Wechsel:
      solange wir von “Führungsetage”, “Unternehmensführung”, “(Projekt-) Leitung” und Manager (lat. manus agere = „an der Hand führen“) wie selbstverständlich reden, solange werden Projekte und Mitarbeiter mit eng gefassten “Command-and-Control”-Zügeln “geführt” (interessant, wie “gut” das Wort “Zügeln” hier passt).

      Vor den zahllosen erfolgreichen (selbst-organisierenden) Teams hat man Angst, weil Verantwortung abgeben mit Kontroll- und (!) Status-Verlust gleichgesetzt wird [auch hierzu passt Ihr Satz “Dagegen wehren sie sich im Konsens.”]. Ausnahmen, die den Menschen in den Mittelpunkt stellen, sind einfach noch zu selten [z.B. Gore, GORE-TEX].

      Meine Erfahrung ist ebenfalls:
      solange die “oberen Etagen” gegeben sind, ist eine wirklich erfolgreiche “Agile Transition” nur mit(!) diesen, nie ohne diese möglich.

      Nur über Entwicklerteams als (subversive?) Keimzellen ein neues z.B. Scrum-Vorgehen zu versuchen, scheitert gewöhnlich sehr schnell am “non-agilen” Tellerrand – und führt leider auch sehr schnell zu falschen Interpretationen (“…Scrum ist Mist…”) oder zu alt-gewohnten Verhaltensweisen (“Scrum, but…”).

      Den Weg für einen gesamt-heitlichen, systemischen Ansatz sisyphus-artig zu erklären ist die Herausforderung von [uns] Agile Coaches…

      Nochmals “Danke!” für die Bestätigungen!

      CU
      Boeffi

  2. Hallo Boeffi,

    die Situation kommt mir bekannt vor. Ich glaube, manchmal ist es auch die Angst vor dem Anfang und die Angst vor Fehlern. Solange man Listen erstellt, könne man ja nicht so viel falsch machen.

    Einige Leute widerstrebt es irgendwie, mit einer Lösung anzufangen und diese dann weiter zu entwickeln. Wenn man diese Angst nimmt, kann man meist auch ein neues kurzes PBL erstellen.

    LG, Jan

Trackbacks/Pingbacks

  1. Scrum-Rollen "All in One" Product Owner, Scrum Master, Entwickler « cu @ Boeffi .net - [...] [2] » Cargo Cult – “Impediments haben wir (eigentlich) keine!” » Product Backlog-Praxis – Hilfe, wir ertrinken… [...]