Product Backlog Praxis    Hilfe, wir ertrinken... via boeffi.net Rettungsring 266x400x24 compressed 199x300 scrum kanban books agile  Systems Thinking SoftwareDevelopment Scrum ProjectManagement Kanban Change Agile 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?

Product Backlog Praxis    Hilfe, wir ertrinken... via boeffi.net 9c0665ecc42f4622d57899fb98f6da11 scrum kanban books agile  Systems Thinking SoftwareDevelopment Scrum ProjectManagement Kanban Change Agile CU
@ Boeffi  .net     aktualisiert am 28.06.2012

 

[1] wie liest man so oft: “Richtiger Name der Redaktion bekannt” Product Backlog Praxis    Hilfe, wir ertrinken... via boeffi.net icon wink scrum kanban books agile  Systems Thinking SoftwareDevelopment Scrum ProjectManagement Kanban Change Agile – 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


... in diesem Zusammenhang empfehle ich außerdem ...

Product Backlog — “Priorisierung” – Wie ?   Ein häufig ungenutztes Potenzial liegt in der aktiven Priorisierung des Product Backlogs. Vor allem unter dem Aspekt eines seriösen Risiko-Managements. Erfahrungen und Beispiele aus einigen Scrum-Projekten … Üblicherweise werden die Einträge...

Anregungen aus und für die Praxis — Product Backlog “Priorisierungen”   Versäumnisse in der aktiven Priorisierung des Product Backlogs lassen häufig erhebliches Potenzial ungenutzt liegen. Einige Projekte scheitern sogar. Erfahrungen und Beispiele aus einigen Scrum-Projekten … Üblicherweise werden die Einträge eines Product...

clevere Metapher — Tasks, User Stories und Epics   "Dinge vereinfachen" hilft Komplexität beherrschen. Dies lässt sich auch über Metaphern, also Sinnbilder unterstützen. Wird - mal wieder - eine neue Vorgehens-Optimierung versucht, führt dies nicht selten zu Widerständen, da...

Transparenz — “Agile” macht ja nur Probleme – oder…?   Die einschneidende Wirkung einer öffentlichen Impediment-Liste. … neulich in einem mir bekannten Projekt … (ein komprimierter Rückblick auf einen Projekt-Start mit Scrum [1] …) Hintergrund: In einem Finance Profit Center arbeiten in...

Projekt- oder Produkt-Entwicklungen — Erfolgreich mit agilen Methoden   Gibt es Probleme mit Deinen Projekten oder Produkt-Entwicklungen ? Natürlich nicht ! Hand auf’s Herz: vielleicht doch, ein wenig … ? Als Agile-Wegbereiter, -Förderer und -Anwender kennen mich viele seit langem. In diesem Zusammenhang...

#1/5 – Perspektiven-Wechsel — Was hat Scrum mit Fröschen zu tun?   „Wer einen Sumpf trockenlegen will, darf nicht die Frösche fragen.“ - Volksmund Während des letzten sehr munteren “agilen Stammtisches” kam das Dauerthema nach der besten “Verkaufsmethode für Scrum” auf. Aus...

Scrum-Projekte — Warum scheitern diese immer öfter ?   Ist die jüngst zu beobachtende Heransgehensweise, Projekte mittels “Scrum” durchzuführen, optimal ? Impuls für diesen Beitrag sind die in letzter Zeit unzähligen Projekt-Ausschreibungen, die mich als AgileCoach in dieser Form erreichen:...

  7 Responses to “Product Backlog-Praxis — Hilfe, wir ertrinken…”

  1. [...] [2] » Cargo Cult – “Impediments haben wir (eigentlich) keine!” » Product Backlog-Praxis – Hilfe, wir ertrinken… [...]

  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

  3. Top story: Product Backlog Chaos bei Scrum oder Kanban ? « cu @ Boeffi .net http://t.co/ME3MOEvawl, see more http://t.co/QbEIFOQiu4

  4. Top story: Product Backlog Chaos bei Scrum oder Kanban ? « cu @ Boeffi .net http://t.co/455QPQI5, see more http://t.co/FpnmRaOk

  5. RT @Boeffi: Product Backlog-Praxis — Hilfe, wir ertrinken… – 3.547 (!) Einträge… http://t.co/Q0XReWau
    #Change #Kanban #ProjectManagement

  6.   

    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

 Leave a Reply

(required)

(required)


nine − 9 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

   
Made with Much Love, these Pages are © 2009 - 2014 by cu @ Boeffi .net Impressum / Imprint Suffusion theme by Sayontan Sinha