Nach 3 Tagen rings um Medien und Kommunikation, nun die Case Study diese Woche – Scrum bei den Experten für (Marken)Kommunikation.
Die Münchner Agentur P//MOD – ein Ableger der renomierten Agentur Publicis, die sich vor allem mit digitalen Medien befasst, arbeitet seit nunmehr fast einem Jahr mit Scrum.
Klar, nicht so einfach, schliesslich kennt man Anwendungsbeispiele von Scrum viel eher aus der Softwarebranche. Dennoch funktioniert Scrum auch hier sehr erfolgreich. General Manager Joel Flammann hat sich trotz dichtem Terminplans auf einer morgendlichen Autofahrt viel Zeit für ein ausführliches Gespräch genommen – wie ich finde, wirklich aufschlussreich. Ein Muss für alle, die glauben, Scrum ist eben “bloß” der Gegensatz zu Waterfall in der Softwareentwicklung. Irrtum. Lesen! 100721_casestudy_pmod münchen
Nochmal herzlichen Dank!
Katrin Dietze
Hands on Design. Webteam
Related posts:
Schöne Case Study. Was mich allerdings im speziellen interessieren würde – und hier geht der Artikel nicht drauf ein – ist, wie mit diesen kurzfristigen und daher beim Sprint Planning nicht planbaren Anfragen/Aufträgen umgegangen wird.
Sagt man da dem Kunden wirklich: “Nein, machen wir erst im nächsten Sprint”? Das kann ich mir ja nicht vorstellen, weil das ja dann einen Wettbewerbsnachteil bringt. Kannst du das vielleicht erläutern?
Hallo Thomas, das ist die immer gleiche Frage, die auch immer gleich beantwortet wird: “Das kommt darauf an!”
Wichtig ist, nur das Team entscheidet! Denn deren Sprint wird verändert.
Es kommt darauf an:
Wann kam die Änderung? Anfang, Ende Sprint
Wie groß ist die Anfrage? Simple und es dauert länger zu diskutieren, das wir das nicht machen, als klar, machen wir und 2 Minuten später ist es getan. So groß, dass sie tatsächlich ein Problem erzeugt.
Wieso kommt die Änderung, welcher Business Impact ist es?
und und und.
Es ist einfach entscheidend, dass wir uns in Scrum-Unternehmen klar machen: Die Hoheit darüber, was ich täglich tue liegt bei mir.
Scrum soll den Menschen helfen zu mündigen Talenten am Arbeitsplatz zu werden.
Danke für die Antwort, Boris.
Bei den kleinen unwichtigen Aufgaben ist es klar, dass das Team das einfach ablehnt und an den SM/PO verweist.
Ich rede aber von Aufgaben, die möglicherweise einen hohen Wert haben und nicht darauf warten können, erst im nächsten Sprint gemacht zu werden.
Und was ist mit Aufgaben (auch eingeplante), deren Resultat noch vor dem eigentlichen Sprintende “geliefert” werden muss?
Hier finde ich im Grunde in keiner bisher gelesenen Literatur Hinweise auf ein gutes Vorgehen. Auch im SM-Kurs wurden diese Fragen unbefriedigend beantwortet und ich kann mir beim besten Willen nicht vorstellen, dass derlei Störungen/Aufgaben in der Welt ein unrealistisches Szenario darstellen, als dass dafür kein ordentliches Vorgehen in Scrum definiert werden könnte. Die Gefahr, die ich sehe ist, dass man einerseits nicht immer “nein” sagen kann, weil Geld auf dem Spiel steht. Andererseits verwässert der SCRUM-Prozess, wenn man das häufiger praktiziert und das Team kann sich letztendlich nicht auf das eigentliche Ziel der ursprünglichen Stories fokussieren.
Als input für eine Idee, was man machen könnte: Joel hat mir im Interview erzählt, p//mod hatte genau solche Probleme: Zwischenanfragen, ganz eiliges, Pitches etc. Sie haben dann mal analysiert, was das genau ist, welche Bereiche betroffen sind und was wirklich Dinge sind, wo man aus Businesssicht nicht “nein” sagen möchte. Wenn man das ehrlich betrachtet blieben zwei Sachen übrig: Support und Pitches. Jetzt ist die Frage wieviel Zeit beansprucht das wirklich? Was ist der BV?
Ergebnis ist, die Agentur hat ein dezidiertes Support Team und ein dezidiertes Team für New Business, was kurzfristige Wettbewerbsanfragen/Pitches macht.
Wenn euer Business aus schnellstens reagieren besteht – ok, tuts doch.
Hallo Thomas,
tatsächlich stellt genau das in unserer täglichen Arbeit eine permanente Herausforderung dar. Ich glaube nicht, dass sich die Frage durch Prinzipien oder eine absolute Haltung beantworten lässt. Meiner Meinung/ Erfahrung nach teilen sich die Möglichkeiten in folgende Szenarien:
1) Der PO kann mit dem Kunden beim Eintreffen der AdHoc Anfrage klären, ob die Anfrage im nächsten Sprint laufen kann – und erklärt ihm die damit verbundenen Vorteile für die aktuell in Arbeit befindlichen Dinge (auch für diesen Kunden) und für die Aufgabe an sich, wie z.B. Zeit für Abklärung im Vorfeld, Ausräumen von offenen Fragen etc. Natürlich ist das auch ein wenig abhängig davon, wo im Sprint (Anfang, Mitte, Ende) man gerade steht. Im besten Fall einigen sich Agentur und Kunde auf den Start im nächsten Sprint.
2) Es führt kein Weg daran vorbei, sofort damit zu beginnen. In diesem Fall funktionieren 2 Wege:
2.1) Die Aufgabe wird sofort begonnen, nach Absprache mit z.B. Management. Das wird bei uns durch eine “rote” Story/Task-Karte dargestellt. In diesem Fall ist die Priorisierung der Stories wirklich anzupassen. –> das ist eigentlich nicht wirklich nach Lehrbuch gedacht. Wir achten allerdings darauf, die aktuell in Arbeit befindliche Story trotzdem abzuschliessen.
2.2) Es ist eine Aufgabe, die von unserem Support-Team geleistet werden kann. Dort sitzt ein Team, was auch mit Scrum arbeitet, aber im Wesentlichen kaum planbare Dinge hat (20-30%). Die Haupttätigkeit ist das erledigen von kurzfristigen Anfragen.
In der Praxis hat sich bewährt, von Fall zu Fall den besten Kompromiss zu finden. Es zeigt sich aber, dass Kunden – wenn sie auch Ihre Vorteile der Scrum Methode erkennen – ein Verständnis für das Beibehalten von Planung entwickeln und somit die Frequenz von AdHoc Themen zurück gehen kann.
Welche Wege habt ihr ausprobiert?
Viele Grüße
Joel
Hallo Thomas,
tatsächlich stellt genau das in unserer täglichen Arbeit eine permanente Herausforderung dar. Ich glaube nicht, dass sich die Frage durch Prinzipien oder eine absolute Haltung beantworten lässt. Meiner Meinung/ Erfahrung nach teilen sich die Möglichkeiten in folgende Szenarien:
1) Der PO kann mit dem Kunden beim Eintreffen der AdHoc Anfrage klären, ob die Anfrage im nächsten Sprint laufen kann – und erklärt ihm die damit verbundenen Vorteile für die aktuell in Arbeit befindlichen Dinge (auch für diesen Kunden) und für die Aufgabe an sich, wie z.B. Zeit für Abklärung im Vorfeld, Ausräumen von offenen Fragen etc. Natürlich ist das auch ein wenig abhängig davon, wo im Sprint (Anfang, Mitte, Ende) man gerade steht. Im besten Fall einigen sich Agentur und Kunde auf den Start im nächsten Sprint.
2) Es führt kein Weg daran vorbei, sofort damit zu beginnen. In diesem Fall funktionieren 2 Wege:
2.1) Die Aufgabe wird sofort begonnen, nach Absprache mit z.B. Management. Das wird bei uns durch eine “rote” Story/Task-Karte dargestellt. In diesem Fall ist die Priorisierung der Stories wirklich anzupassen. –> das ist eigentlich nicht wirklich nach Lehrbuch gedacht. Wir achten allerdings darauf, die aktuell in Arbeit befindliche Story trotzdem abzuschliessen.
2.2) Es ist eine Aufgabe, die von unserem Support-Team geleistet werden kann. Dort sitzt ein Team, was auch mit Scrum arbeitet, aber im Wesentlichen kaum planbare Dinge hat (20-30%). Die Haupttätigkeit ist das erledigen von kurzfristigen Anfragen.
In der Praxis hat sich bewährt, von Fall zu Fall den besten Kompromiss zu finden. Es zeigt sich aber, dass Kunden – wenn sie auch Ihre Vorteile der Scrum Methode erkennen – ein Verständnis für das Beibehalten von Planung entwickeln und somit die Frequenz von AdHoc Themen zurück gehen kann.
Welche Wege habt ihr ausprobiert? Viele Grüße, Joel
Vielen Dank für die ausführlichen Antworten. Sie bieten mir doch interessante Ansätze, die ich evaluieren werden.
Da wir nur ein Team haben und uns vom ersten Sprint an bewusst waren, dass diese wichtigen Störungen auftreten werden, haben wir direkt die Verfügbarkeit der Leute im Sprint um einen gewissen prozentuellen Anteil reduziert und haben praktisch etwa 20% der Zeit nicht verplant.
Problematisch hierbei ist meiner Meinung nach, dass man damit eine gewisse Ausnahme schafft und die “Anderen” immer versuchen ihre gerade absolut wichtigen Aufgaben in eben diese 20% zu schieben.
Damit kann sich das Team im Grude nur darauf verlassen, 80% ihrer Zeit (im Idealfall) dem Sprint und damit dem fokussierten Arbeiten zu widmen. Oft brauchen die “wichtigen Aufgaben” der “Anderen” auch mehr Zeit. Damit sind die eigentlichen Vorteile der Sprints irgendwie ad absurdum geführt.
Natürlich kann ich sagen, dass die Störungen sich durch Scrum schon ein wenig reduziert haben im Vergleich zu der Vor-Scrum-Zeit. Dennoch bin ich mit diesem Umstand unglücklich.
Ich suche daher immer noch nach einer besseren Lösung. Mir schwebt es vor, die 20% der Zeit wirklich zu timeboxen und nach Überschreitung der Zeit die ungeplante Aufgaben liegen zu lassen und das für den Sprint einzuplanen, weil sie doch mehr Zeit benötigen. Allerdings ist es schwer das den Kundenbetreuern zu kommunizieren, weil hier ein wenig die Einsicht fehlt.
Daher bin ich für weitere Vorschläge und Erfahrungen sehr offen!
Hi Thomas,
wir haben solche “Störungen” zum Glück selten. Wenn sie auftreten und in den laufenden Sprint kommen, dann werfen wir eine Anzahl an Stories aus dem Sprint, die der Störung gleich kommen. Natürlich die, mit der geringsten Prio.
Ansonsten versucht doch, die Sprintlänge zu verkürzen. Für gewöhnlich brauchen ja auch dringende Aufgaben etwas Vorlaufzeit beim Business. Und da ist eine stetige Kommunikation wichtig, so dass man frühzeitig weiß, dass eine “wichtige Aufgabe” bald an die Tür klopft.
Hallo Susanne!
Die Sprintlänge haben wir schon – in weiser Voraussicht – auf eine Woche angelegt. Aber wenn ihr dann wirklich Stories aus dem Sprint schmeißt, so ist es ja doch irgendwo eine Rückkehr zum pre-Scrum, wo es in gewisser Weise keine richtige Commitments auf das Sprintziel gibt. Das sind halt so Sachen, die mir Sorgen machen, weil ich dann die Verwässerung von Scrum sehe und das ganze dann eher zu einem “Scrum, but…” verkommt.
Hast du nicht den gleichen Eindruck?
Hallo Thomas,
zunächst einmal hast Du mMn richtig erkannt, dass derartige definierte Ausnahmen im Sprint insbesondere bei Teams, die Scrum noch nicht so lange kennen mit erheblichen Problemen einhergehen.
Die Grundzüge mit Deinem Problem umzugehen, haben ja meine Vorredner schon beschrieben. Sollte allerdings ein großes und wichtiges Thema kurzfristig bearbeitet werden und nicht mehr bis zum nächsten Sprint warten können (kurze Sprints helfen hier, aber kürzer als 2 Wochen ist mMn auch die hohe Schule und alles andere als einfach), so muss der Sprint abgebrochen werden.
Insbesondere zu Beginn der Scrum-Einführung kann und sollte dem zuständigen PO und/oder dem Management klar gemacht werden, dass ein Sprintabbruch mit Aufwand und damit Kosten und Waste verbunden ist und dass das neue Thema gegen die alten priorisiert werden muss (fängt man das neue an, dauern die alten Themen länger).
Durch schmerzvolle Sprint-Abbrüche werden POs, Key Accounter, Kundenberater, die mit der Methode noch ungeübt sind, mit den Schmerzen derartig kurzfristiger Themen für die Organisation konfrontiert und denken vor jedem angestrebten Sprint-Abbruch sehr genau über die Notwendigkeit dessen nach.
Wichtig ist, dass es hierbei nicht um eine drakonische Maßnahme zum Lernen oder gar eine Art Strafe geht, sondern darum die Nöte anderer Beteiligter transparent zu machen.
Ich hoffe ich habe meine Gedanken auf verständliche Weise in Worte fassen können.
Vielen Dank für die zahlreichen Ideen und Berichte.
Ich habe mir ein Konzept überlegt, wie zukünftig mit Störungen effektiv umgegangen wird. Die nächsten Sprints werden daher spannend. In ein paar Wochen weiss ich mehr :)
Grüße
Eine Anmerkung noch zur 20%-Nicht-Verplanungs-Variante: ich orte hier einen Widerspruch. Wenn Du sagst, es kommen Aufgaben herein, die nicht planbar sind, ist es imho nicht sinnvoll sie mit 20% der Zeit zu verplanen. Sollten solche Anfragen eine gewisse Regelmäßigkeit haben und der Erfahrungswert bei 20% liegen, ist es OK. Dann sind es aber auch planbare Aufgaben.
Mein Team ist von solchen Aufgaben ganz gut verschont. In der Theorie haben wir uns allerdings beim Einführen von Scrum dazu überlegt eine “Task Force” einzurichten, die sich genau um solche Themen kümmert. Das dürfte dasselbe sein, wie das Support-Team, das schon weiter oben erwähnt wurde. Die Task Force ist bisher allerdings ein theoretisches Konstrukt geblieben.
Sehr interessant finde ich das Thema der Berater, die in Beratungsgruppen organisiert sind. Vielleicht kannst Du, Joel, das noch näher ausführen.
Bei uns ist es ganz ähnlich: wir bearbeiten ein fachlich äußerst umfangreiches Gebiet und haben Fachexperten, die Kontakt zum Kunden haben und Anforderungen entgegennehmen, Details klären, etc. Ich, als Product Owner, habe dann das Vergnügen, die Anforderungen gemeinsam mit den Fachexperten gegeneinander abzuwiegen. Das ist nicht einfach.
Wie sammelt Ihr alle Anforderungen? Wer bewertet die Priorität? Werden Anforderungen auch mal mit einem einfachen “Nein” abgelehnt, um ein Ausufern des Backlogs zu vermeiden?
Gibt es nur einen Berater für einen Kunden, oder vertreten sich die Berater gegenseitig (als Kundenschnittstelle wie auch als Informationsquelle)?
Hi Thomas, ich bin gespannt auf das Konzept. Vielleicht kannst Du uns ja ein paar Wochen davon berichten :) Das Thema scheint insgesamt für viele Scrum-Teams eine Herausforderung zu sein – natürlich auch in unterschiedlicher Intensität. Daher würde mich Eure Erfahrung mit Deinem neuen Konzept interessieren. Grüße, Joel
Das werde ich natürlich gerne machen. Denn ich sehe hier wirklich ein ernsthaftes Problem bei der Implementierung von Scrum in kleineren Firmen.
@Mathias:
Das Modell mit der Berater-Gruppe ist noch relativ jung. Die ersten Monate hatten wir alle Personen, die kein PO oder SM waren, automatisch in ein Team gesteckt. Das war aber suboptimal. Die Erfahrungen, die wir mit dem Beratungs-Team haben ist, dass natürlich hier eine gewisse Abstimmung, Wissens-Austausch aber auch eine gemeinsame Priorisierung des Company Backlogs stattfinden muss. Der “Schiedsrichter” ist in diesem Fall der C3PO, sprich der Company PO, der in unserem Fall aus dem Management besteht. Der Manager hat im Zweifel das Recht, aus eine Priorisierung bei Uneinigkeit des Beratungs-Teams zu klären. Natürlich handelt er auch nach der Devise, den bestmöglichen ROI für Kunde und Agentur zu erzielen.
Wir haben teilweise verschiedene Berater/Ansprechpartner für einen Kunden. Hier wird die interne Abstimmung und der Dialog sehr wichtig. Eigentlich aber auch ein Scrum-unabhängiger Prozess, denn der Kunde erwartet i.d.R. schon, dass wir uns intern abstimmen. Das galt es schon vor Scrum zu managen.
Gruß,
Joel
Tolle Antworten und jede einzelne Variante halte ich im jeweiligen Kontext für sinnvoll.
Ich hätte noch gerne einen Denkanstoss zu eurer Diskussion hinzugefügt.
Ich sehe, wie ihr auch, dass die Realität immer anders ist, als wir es gerne hätten. Pläne, und sogar sehr kurze Pläne, im Grunde immer versagen.
Spannend finde ich jedoch, dass wir implizit bei der Diskussion immer davon ausgehen, dass das Aussen, die Störung, einen höheres RECHT auf Erfüllung hat als das bereits jemand anderem Versprochene. Das hatte ja im Sprint Planning auch ein RECHT auf Erfüllung und wurde vom Team auch offiziell als Selbst-Verpflichtung akzeptiert.
Die Störung wird als von JEMANDEM als so wichtig erachtet, dass man es dem TEAM, mit welchem Argument auch immer, “aufzwingt”. Wieso darf denn das Team nicht selbst entscheiden? Wieso muss denn der PO kraft seiner Autorität dem Team dann doch im Sprint sagen, dass die Befugnis zu entscheiden, wie viel sie schaffen können, doch nicht echt ist und im Fall des Falles einfach untergraben wird.
Wäre ein Vorgehen in dieser Art nicht sinnvoller:
1. PO oder Kunde oder Manager sagen im Sprintverlauf, dass sie ein super wichtiges Ding haben, dass sehr dringend ist.
2. Team entscheidet, ob sie es noch hinein nehmen können.
3. Im Fall des Nein wird das akzeptiert, und der Initiator der Störung kann natürlich einen Handel vorschlagen. Der PO nimmt dann etwas aus dem Sprint als mögliches Angebot heraus.
Dieses Vorgehen wäre dem Team gegenüber respektvoll und würde die Autorität des Teams anerkennen.
Was meint ihr?
Boris
Die “wichtigen” Störungen von Aussen sind in sofern planbar, als dass mein sich sicher sein kann, dass wahrscheinlich etwas kommen wird. Es ist meistens so, dass der Kunde lange Zeit nichts von sich hören lässt und dann kommt irgendwann die Antwort und alles muss “ganz schnell” gehen. Ich denke, dass viele hier diese Situation kennen. Und weil das Geld von eben diesem Kunden schneller kommt, als das Geld, was durch die Weiterentwicklung hereinkommen soll, entsteht schnell der Eindruck, der kurzzeitige Auftrag sei wichtiger.
Ich stimme zu, dass man hier vielleicht etwas besser im Vorfeld klären musste, ob mit einer Kundenantwort für den nächsten Sprint zu rechnen ist, um es entsprechend einzuplanen.
Auch mache ich die Erfahrung, dass die Kundenberater dem Kunden nicht erklären wollen, dass man selber einen bestimmten Prozess fährt. In meinen Augen wirkt sich das doch professioneller aus. Aber das scheinen die Kundenberater (noch?) nicht so zu sehen.
Natürlich ist dem PO klar, dass durch den ultra-wichtigen Auftrag die Arbeiten am Produkt nicht weiter gehen können. Aber das scheint ja noch in einer gewissen “Ferne” zu sein, so dass das kurzfristige Einkommen vielleicht greifbarer und daher wichtiger erscheint.
Wie man es nun dreht und wendet: Kommen diese Aufgaben ständig, so wird Scrum ad absurdum geführt, weil eben die Kernkomponente – das fokussierte Arbeiten am Sprintziel – nicht möglich ist und weil die Aufgaben für den Sprint tatsächlich nicht fest sind.
Boris, ich würde Deinen Vorschlag noch etwas verschärfen (so praktizieren wir es aktuell):
1. PO und/oder Kunde kommen im Sprintverlauf mit einem dringlichen Anliegen.
2. Team entscheidet, ob es noch zusätzlich mit erledigt werden kann.
3. Falls nein, sagt das Team, wie viel aus dem ursprünglichen Sprint-Backlog erledigt werden kann und was evtl. rausfallen müsste – sprich: es zeigt die Konsequenzen des “Reindrückens” auf.
4. PO und/oder Kunde entscheiden, ob die Konsequenz den Nutzen der drängenden Aufgabe wert ist.
Damit liegt die Verantwortung für das, was das Team schaffen kann, immer beim Team. Und der Respekt dem Team gegenüber bleibt ebenfalls gewahrt.
Grüße
@Boris & Elke:
Ich finde Eure Vorschläge wirklich interessant. Was mir in unserem Dienstleistungsgeschäft allerdings schwer fällt, ist ein Weg, dies in die Praxis umzusetzen. Unsere Kunden setzen einfach voraus, dass ihr Anliegen in diesem Moment immer oberste Priorität hat. Das kann ich aus Kundensicht auch verstehen.
Also wie kann man das Problem lösen – zwei Fliegen mit einer Klappe schlagen. SCRUM machen ohne Kunden zu enttäuschen, weil man Sie vertrösten muss?
Es liegt nahe, ein weiteres Team zu etablieren, was eben NUR diese ADHOC Dinge macht. Leider hat man dadurch keine Planbarkeit: weder sind die Stories, die Tasks, aber auch nicht die Auslastung, die Revenues und auch nicht der wirtschaftliche Erfolg eines solchen Teams planbar – denn es würde ja NUR AdHoc Themen leisten. Mal ist es zu viel auf einmal, mal zu wenig.
ich muss zugeben: ich sehe noch keine wirkliche Lösung dafür.
Wenn jeder Kunde sein eigenes Team hätte, dann wäre natürlich ein “aushandeln” möglich, weil dann der PO mit dem Kunden eine gemeinsame Priorisierung vornehmen könnte – denn beide haben das gleiche Ziel, bzw. sind zum Kompromiss “gezwungen”.
Im Agentur-Alltag gibt es aber viele Kunden und Ansprechpartner, welche von einem Team “bedient” werden. Und somit muss die Agentur “mit sich selbst” handeln. Denn grundsätzlich ist es Kunde A doch egal, ob Kunde B jetzt gerade etwas mit höherer Priorität braucht. Das ist in diesem Moment eine subjektive Meinung jedes einzelnen.
Und hier unterscheidet sich m.M.n. Scrum im reinen Software-Entwicklungsbereich (Produktentwicklung) zu Scrum im Agentur-Umfeld. Oder?
Du triffst den Nagel auf den Kopf, Joel. Genau das ist der Punkt. Wobei ich aus der Produktentwicklung (Software) komme und wir tatsächlich die gleichen Probleme haben. Weiterentwicklung vs. Kundenaufträge.
bor!sgloger — Teamführung in Projekten – vorgesetzt oder selbst gewählt? // Jul 26, 2010 at 07:02
[...] Case Study über P/Mod in München hat eine tolle Diskussion über Störungen, während des Sprints ergeben. Es freut uns, [...]
@Joel: In dem Unternehmen, in dem ich bis vor kurzem als Scrum Master tätig war, war genau das der Fall: Als Application Service Provider haben wir eine Plattform für viele verschiedene Kunden weiterentwickelt, die alle unterschiedliche Ideen oder Probleme hatten und zuerst bedient werden wollten.
Mit zunehmender Erfahrung im Scrum und im Zusammenspiel zwischen den einzelnen Akteuren (aus PO-Sicht: Welche Nöte erzeuge ich beim Team, wenn ich bestimmte Dinge verlange? Und umgekehrt.) haben sich die Probleme deutlich verlagert. Generell wachsen die Beteiligten mit der Zeit zu einem Team zusammen. Und wenn man es schafft möglichst viel Transparenz in das Zusammenspiel zu bringen, kommt das gegenseitige Verständnis von selbst.
Ein guter PO kann so auch mit einem Kunden herausfinden, ob die Arbeit an einer Anforderung tatsächlich unbedingt sofort begonnen werden muss (meist muss vorher zumindest etwas Zeit fürs Abstecken der Eckdaten und die Analyse des Kunden-Problems eingeplant werden) oder ob das nicht doch noch eine oder zwei Wochen Zeit hat, da sich dann das gesamte Team vollständig auf das Problem konzentrieren und eine qualitativ bessere Lösung insgesamt in einer kürzeren Zeit liefern kann.
Als Lektüre für POs kann ich nur diesen Artikel empfehlen (@Boris: ich hoffe des Verlinken eines Artikels aus einem anderen Blog ist hier in Ordnung): http://www.agileproductdesign.com/blog/2009/product_owner_and_problem_shaped_hole.html
Interessante Probleme. Wir (TNG Technology Consulting in Unterföhring bei München) haben inzwischen ganz gute Erfahrungen gemacht, Scrum und Kanban *parallel* zu benutzen. Die kleinen, wichtigen/dringenden Themen im Kanban-Board (ohne Schätzen etc.), die größeren Themen komplett ohne Störungen per Scrum. Ein gemeinsamer Product Owner. Retrospektiven und Sprint Planning I gemeinsam, Daily Standups jeweils mit gegenseitigen Vertretern. Rotation der Mitglieder möglich zu Sprint-Grenzen. Interessantweise macht wegen den schnellen Erfolgen den Leuten Kanban fast mehr Spaß ;-).