Sonntag, 30. August 2015
Seite auswählen

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 → „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…“
→ 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 → 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 → 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?

about "Boeffi" ...CU
@ Boeffi  .net     aktualisiert am 20.06.2015

 

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

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

Medien- / Artikelbilder-Nachweis: Danke an und © siehe » 
Carsten Grunwald / pixelio.de