Agile Saxony
Posts 1-10 of 11
- Back
- Next
-
Jens Korte Premium Member Group moderatorThe company name is only visible to registered members.Wie gehe ich mit dem Rollout / Troubleshooting in Produktion um?19 Jun 2009, 5:37 pmRelease alle 2 - 4 Wochen
Wenige Kunden akzeptieren das Risiko eines Rollouts aller 2 - 4 Wochen.
(siehe:
https://www.xing.com/app/forum?op=showarticles;id=21760518)
-
Post visible to registered members
-
Jens Korte Premium Member Group moderatorThe company name is only visible to registered members.JensG schreibt:01 Jul 2009, 11:00 amRe^2: Release alle 2 - 4 Wochen
Praxis: Kunde nickt verständnisvoll, sagt "Ja" und "Amen" ... und kommt dann trotzdem mit 1000 Sonderwünschen, die "unbedingt noch in dieses Release mit 'rein müssen, sonst ist das für uns völlig nutzlos".
Was ist zu tun?
Iterations- und Releasezyklen sollten voneinander losgelöst sein. Das könnte so aussehen:
|---Iteration---|---Iteration---|---Iteration---|
|--------------------Release---------------------|
Iterationslänge ist z.B. 4 Wochen, dann ist für alle 3 Monate ein Release geplant.
Vor jeder Iteration hat der Kunde die Gelegenheit, neue Anforderungen oder Sonderwünsche einzubringen und so zu priorisieren, dass sie in der kommenden Iteration in die Umsetzung gelangen. Wenn der Kunde während der letzten Iteration mit Sonderwünschen kommt, die UNBEDINGT noch mit ins Release müssen, dann gibt es folgende Optionen:
1. Das Release verschiebt sich um eine Iteration (Empfehlung)
|---Iteration---|---Iteration---|---Iteration---|---Iteration---|
|----------------------------Release-------------------------------|
Der Kunde bekommt alle bisher gewünschten Anforderungen UND seine Sonderwünsche der letzten Minute.
2. Die letzte Iteration wird abgebrochen und neu geplant. (Nur im wirklichen Notfall)
|---Iteration---|---Iteration---|---Iter.|--Iter--|
|--------------------Release---------------------|
Die letzte Iteration könnte dann kürzer geplant werden, um das Releasedatum zu erreichen. Das macht aber keinen Sinn, wenn er in der letzten Woche vor dem Relase kommt. Dann ist Variante 1. zu bevorzugen.
Aber ganz klare Message an den Kunden: Wenn er die Sonderwünsche will, fallen andere Wünsche raus.
Was ginge noch?
Sonderwünsche werden in die letzte Iteration "reingepresst". Entwickler machen Überstunden, die Qualität sinkt, das Release ist gefährdet, "Agile Softwareentwicklung ist SchXXXe und auch nicht besser als füher", die Entwickler sind (wiedermal) frustriert und verlieren den Glauben...
-
Post visible to registered members
-
Ralf Lippold Premium Member Group moderatorThe company name is only visible to registered members......und alles nur wegen mangelnder Transparenz02 Jul 2009, 3:33 pmRe^4: Release alle 2 - 4 Wochen
der Ursachen (kurzfristige Änderung von Anforderungen
in letzter Iteration).
Möglicherweise wird SRUM in solchen Fällen vom Auftrag-
geber als "Killer" von Projekten verwendet ;-(
Beste Grüße
Ralf
-
Post visible to registered members
-
Post visible to registered members
-
Ralf Lippold Premium Member Group moderatorThe company name is only visible to registered members.in den oben beschriebenen Problemgemengelagen helfen gemeinschaftliche Gespräche und Nutzung von System Dynamics "Sprache": Causal Loop Diagrammen!04 Jul 2009, 12:29 amRe^7: Release alle 2 - 4 Wochen
Diese zeigen auch den Verhinderen (unbewusstes oder auch bewusstes Verhindern) recht deutlich, wo das Projekt hinführt wenn so oder so gehandelt (oder auch nicht) wird.
Nicht ganz üblicher Weg, denn Eskalationen spielen ja bislang in Unternehmen doch eine entscheidende Rolle - nur dass sich damit langfristig überhaupt nichts ändert, nur noch schlimmer wird:-(
Wie sind Eure Erfahrungen mit dem Ansatz (wenn denn schon gemacht)? Wer hat davon noch nichts gehört?
(für mich kam dies auch 2006 überraschend;-))
Beste Grüße
Ralf
-
Jens Korte Premium Member Group moderatorThe company name is only visible to registered members.Richtig: Beim Product Owner sitzt das Problem. Oder vor dem Product Owner...04 Jul 2009, 11:01 pmRe^8: Release alle 2 - 4 Wochen
Was hilft, deutet Ralf an: Die Ursachen suchen. Gemeinsam mit dem Kunden! Der Kunde muss verstehen, was Scrum ist, warum ihr Scrum einsetzt und was passiert, wenn er das System (sprich: Must-have-Anforderungen in letzter Minute einkippen) immer wieder aus dem Gleichgewicht bringt.
Der ScrumMaster muss für die Einhaltung der Regeln sorgen und das Entwicklerteam vor solchen Störungen schützen! Falls der ScrumMaster nicht in der Lage ist, das Problem der immer wiederkehrenden Störungen zu beseitigen, muss er es eskalieren. Wenn ihn jetzt die Organisation und das Management im Stick lassen, dann hat er ein echtes Problem (er ist nicht genügend "befähigt") und es könnte sein, das Scrum scheitert. Aber es liegt nicht an Scrum!
-
Post visible to registered members
- Back
- Next
