Das Management glaubt auch gerne daran, dass es bei klassisch geplanten Projekten am Ende das geplante bekommt. Das ist aber nie der Fall. Abstriche und Änderungen sind genauso an der Tagesordnung wie Terminverschiebungen und mangelhafte Anforderungen. Bei agilem Vorgehen akzeptiert man das von vornherein und priorisiert vor jedem Sprint neu.

Wie gesagt: Leider spricht dieses „Schneller, besser, effektiver mit Scrum“ gerade die Entscheider an … 

Guter Einwand das Beispiel der Migration. Ist in letzter Konsequenz tatsächlich 0 oder 1. Wobei man auch bei Migrationen vorher durchaus iterativ vorgeht und ganz viele Trockenläufe in möglichst realistischer Umgebung hat bevor man den Umstellungstermin ankündigt. Insofern ist man bis zu dieser Ankündigung beim Termin schon flexibel und das ist auch gut so.

Hi,

vom Ansatz her ein guter Kommentar. Leider fehlt mir etwas der Inhalt, weshalb er auch mehr oder weniger zu Recht dem Spamfilter zum Opfer fiel. Wie ich schon an anderer Stelle hier im Blog mehrfach ausgeführt habe und hier nochmals vertieft habe, hat agiles Vorgehen für mich den großen Charme, flexibel auf Veränderungen reagieren zu können. Wie man die agilen Grundsätze dann in der Praxis umsetzt und ob das dann Scrum heißen muss (und nur darauf zielt ihre Aufzählung) ist eine ganz andere Frage, die nur im Kontext der konkreten Projektsituation entschieden werden kann.

Und nein: schnell mal agil in dem Sinne wie ich es in dem Artikel beschreibe, geht nicht.

von der Einleitung her ein guter Artikel. Leider fehlt mir etwas der Inhalt. Agiles Projektmanagment bedeutet mehr als Projekte flexibel zu gestalten. Ich sehe da Planning Meeting, das Daily Planning Meeting, Retrospektiven, Schätzen mit Story Points… mehr dazu: http://www.agile-is-limit.de/its-agile-woran-erkennst-du-ein-agiles-team-10-punkte/

und zur Überschrift: Schnell mal agil – doch geht :)

Ab sofort, ab heute – Go for it! :P

Natürlich muss das neue System nicht gleich nach der Migration alle 100 Funktionen komplett verfügbar haben. Da kann man getrost eine nach der anderen der weniger wichtigen Funktionen aufschalten. Aber die Migration muss als Ganzes so klappen, dass danach keine betriebsverhindernden Issues auftauchen. Ist das nicht gegeben, kommt ein Rollbackszenario zum Zug und man ist wieder auf dem alten System. Alles oder nichts, keine Iterationen.

Der Rollback wäre ziemlich schlimm, denn solche Systeme stellen meistens Netzdienste zur Verfügung, die von 10’000, 100’000 oder gar Millionen Endusern genutzt werden. Einmal musste ich z.B. die Netzsoftware für bundesweit alle Bankomatsysteme migrieren. Wenn danach auch nur ein Bankomat wegen der Migration ausgefallen wäre, hätte man mit Klagen rechnen müssen. Die Unmengen an Enduser erhalten in der Regel ein paar Wochen vor dem geplanten Wechsel eine Information. Daher ist auch der Endtermin von Migrationsprojekten ziemlich unverrückbar.

Davon abgesehen stimme ich Dir vollständig zu. Der Satz gefällt mir besonders:

„Jedoch nicht um schneller den gesamten Umfang umzusetzen, sondern um zum unverrückbaren Endtermin einen brauchbaren Umfang zu bekommen.“

Danke für Deine Zustimmung. Leider ist es oft aber auch so, dass das höhere Management genau das agil = schneller hören will bzw. genau darauf anspringt.