Projektmanagement: PRINCE2 - Zertifizierung

[Clawmens]

Ich habe PMP-ACPI + PMP + wertlose Scrum Zertifikate. In der Praxis brauche ich nicht mehr. Evtl. für Projekte >100mio.

 

[Clawmens]

Mag sein, habe ich auch schon öfters gedacht. Aber wir sind halt nicht soooo klein (im Konzern ~10.000 Mitarbeiter), wir haben massig Externe in div. Projekten und mir kommt es so vor, als wäre das, was ich hier erzähle, Standard in der IT. Grundsätzlich läuft es, wir gewinnen Kunde auf Kunde dazu, alle sind happy, alle sind glücklich. Nur sehe ich verschenktes Potential. Aber vielleicht durchdringe ich diese ganze agile Projektmethodik einfach auch noch nicht...

Ich war mal bei einem Unternehmen mit >50.000 Mitarbeiter und die haben es nicht verstanden. Lag nicht an mir, ich hatte damals die Prozesse nur dokumentiert

 

[Shihatsu]

Morph, du machst hier glaube ich den selben Fehler wie so ziemlich alle Manager:
Ein Vorgehensmodel wird mit einem Prozess verwechselt. Das ist ein feiner aber immens wichtiger Unterschied. Man kann Scrum ohne Probleme nicht-agil machen. Man kann ohne Probleme Wasserfall und Scrum vereinen. Was dabei jedoch mal wieder klar wird ist etwas anderes das ich hier auch schon im topic plaziert habe: Manager stehen auf den Scheiss - aber sie verstehen ihn nicht. Ist ganz ähnlich wie SAP-Einführungen: Die wollen krampfhaft die Methodik oder das Toll an ihre Prozesse anpassen, dabei kann es nur anders herum gehen - die eigenen Prozesse müssen auf den Prüfstand, und vieles davon muss weggeworfen werden. Da das meist ohne Human Change Management und ohne Mut auch mal Mitarbeiter zu verändern passiert wird daraus in der Regel nichts. Je größer der Konzern desto mehr Schrott kommt bei agile raus. Ich kotze mitlerweile bei dem Wort "agile" genauso wie bei "cloud" - verstanden hat das keiner von den "Entscheidern". Aber ich verdien gutes Geld damit das sie genau das auch nie merken, so what...
So, agile und Mitbesteimmungspflicht: Tjaja, im ifb-Forum wird man IMMER eine solche Antwort kriegen. Die Jungs machen grossartige Schulungen, aber sind noch roter als die IGM - und das zieht sich auch durchs Forum. Aus Scrum ergibt sich keine Mitbestimmungspflicht.
Wenn Rollen jedoch auf einzelne Personen runtergebrochen werden (wer das tut hat Scrum nicht verstanden) und die einzelnen Sprints rollengerecht aufgezeichnet und verarbeitet werden und im selben Verarbeitungstool das Rollenverzeichn is hinterlegt wird dann ist der BR nicht mitbestimmungspflichtig, dann ist der BR entweder als ganzes anfechtbar oder lässt dieses Verhalten sofort einstellen. Denn ja, das ist dann Verarbeitung Personenbezogener Daten zur Leistungskontrolle ohne Kontrollmechanismuss durch den BR. So kann man wunderbar Lowperformer identifizieren... Und btw, Entscheider LIEBEN so etwas.

 

[Clawmens]

Ja, auch meine Eindruck. Der Manager hat mich ganz entgeistert angeschaut als ich ihm erklären hab versuchen, dass es bei Scrum nicht um Kontrolle von Programmierern geht und er hat mich dann gleichmal fristlos entlassen

 

[Zweifeuerkraut]

Scrum ist der absolute Hype momentan. Jeder will es, kaum einer versteht es (siehe Claw: Programmierer besser kontrollieren). Und in den meisten Fällen schlägt es (imho) komplett fehl. So jedenfalls mein Eindruck unserer Kunden. Der grösste Schweizer Telecom Anbieter stellt grad seinen gesamten IT Betrieb(!) auf Agile um. Sogar das HR dort ist jetzt agil
Zu der jährlichen Führungs- und Abteilungs-reorg kommt jetzt halt auch noch eine jährliche Arbeitsweise-reorg.

 

[parats']

Momentan ist gut, eigentlich schon seit bestimmt 5 Jahren. Wir entwickeln seit jeher in Iterationen von zwei Wochen um releasezyklen kurz zu halten. Funktioniert an sich problemlos, sofern es keine xxx Manager möchte Wünsche gibt..

 

[Clawmens]

Meist ersetzt agile Entwicklung nicht Wasserfall oder V-Modell, sondern ad-hoc Management. In den Fällen ist Agile natürlich ein Geschenk des Himmels, also dass man sich zumindest hin und wieder trifft und Dinge zuende bringt anstatt lauter neue Projekte zu starten. Mit Agilität an sich hat das natürlich eher wenig zu tun und Wasserfall wäre in dem Fall wahrscheinlich besser---fehlt halt an einem guten Manager der das durchziehen könnte.

 

[deleted_24196]

Das Problem mit der Agilität @ heise.de
weiterlesen...

Die Kommentare stimmen teilweise genau mit meinen Erfahrungen überein, z.B.

Unser Kunden sind auf Festpreisprojekte aus mit detaillierten "Lastenheften" und Meilensteinplänen im Vertrag, bestehen aber auf SCRUM, was gar nicht zusammen passt.

Dann liefern sie entweder gar kein Feedback oder ändern alle 2-4 Wochen die GUI und "behaupten": Wir machen doch agil und verstehen darunter so viel Änderungen wie sie wollen. Wenn dann aber ein Meilenstein deswegen nicht erreicht wird, dann ist es natürlich unsere Schuld.

 

[Gelöschtes Mitglied 683020]

Ich kotze mitlerweile bei dem Wort "agile" genauso wie bei "cloud" - verstanden hat das keiner von den "Entscheidern". Aber ich verdien gutes Geld damit das sie genau das auch nie merken, so what...

Ohne dir persönlich einen Vorwurf zu machen, ich verweise auf den ersten Post, den ich im Urtopic (diesem hier) gemacht habe. Mich deucht, auch die Anbieter der Schulungen haben wenig bis kein gesteigertes Interesse an Erklärungen, stattdessen wird in bester Autokäufermanier mit den üblichen Buzzwörtern Werbung gemacht. Aktuell ist meine Firma total begeistert von der Idee alles AGIL zu machen, am besten auch den Postboten und die Putzkräfte. Erklären, was es eigentlich soll, kann trotzdem keiner, "aber die Experten haben uns gesagt" und "die anderen ja auch"

 

[Shihatsu]

Was willst du mir damit sagen? Erst einmal was didaktisches: "Ich will dir ja nicht zu nahe treten aber" oder ähnliches funktioniert nicht. Nicht in RL und nicht im Internet. Danach kommt IMMER das was einem zu Nahe tritt.
Desweiteren: Was hat dein Post mit meinem zu tun? Du redest von Schulungsanbietern (da gibt es gute und schlechte - und bei agile transformation kannst du die guten eigentlich daran erkennen das sie onsite support für mindestens ein projekt verbilligt nach Schulung anbieten), ich rede von realen Erfahrungen von mitleren und grossen Kunden.

Meine Definition von Agil: Projektschritte so klein wie möglich machen, solange sie ein messbares Ergebnis liefern können das den Gesamtfortschritt auf größer 1% vorranbringt (bei Riesenprojekten natürlich dann Teilprojekte basteln, da brauch man dann aber schon ne wirklich gute PM-Sau). Nach jedem einzelnen Projektschritt: test. bewertung. repeat or next. Eigentlich ist das recht einfach zu erklären, und die Vorteile in komplexen Systemen liegen auf der Hand...

 

[HellAngel]

In meiner ehemaligen Firma haben wir nur 'Agil' gearbeitet und ich habe es mit der Zeit schätzen gelernt, auch wenn natürlich am Anfang nicht alles so reibungslos lief wie man es sich vorgestellt hatte. Der Hauptvorteil ist dass es die Leute zum kommunizieren 'zwingt' und durch die dauernde Iteration diese Kommunikation auch in strukturierte Bahnen gelenkt wird (Backlog Items, User Stories etc). Vorher war das mehr so 'wir treffen uns mal zu nem Meeting, labern zwei Stunden und haben dann kein Ergebnis'.

Für die Stakeholder (Kunden, interne Anforderer, wer auch immer) hat es natürlich den Vorteil schon relativ bald was von der Software zu sehen zu bekommen und entsprechend noch die Möglichkeit zu haben einzugreifen bevor totaler Murks abgeliefert wird. Wie schon angesprochen besteht da natürlich die Gefahr, dass sie selbst nicht so wirklich wissen was sie wollen und man sich im Kreis dreht. Aber ein guter Product Owner oder Scrum Master weiß mit sowas umzugehen.
Solche Anforderungen sind normalerweise nicht 'Ready for Backlog' -> sowas darf von der Entwicklung nicht angenommen werden.

Steht und fällt natürlich immer damit wie viel Druck der Kunde macht. Wenn der halt kein Plan hat was er will aber alles am besten gleich Morgen - da geht jedes 'Modell' in die Knie.

 

[Scorn4]

 

[Clawmens]

Yoah, so wird Agile häufig gelebt, obwohl Agile vorgibt, eine Roadmap und ein gefülltes Backlog zu haben