Best of PM 2 go

Projektmanagement wird ein zunehmend wichtigerer Erfolgsfaktor fr Unternehmen im Wettbewerb. In dieser Ausgabe von PM 2 go lesen Sie die besten Kurzartikel aus dem Blog Unlocking Potential von Projekt Management Beratung. folgende Risiko deren Nicht-Umsetzung Auftraggeber nicht ausreichen bewusst. wird dem Antwort: Transparenz ist einer der wichtigsten Werte von Scrum und wieder ist es der Job des Product Owners dies zu managen. Dass einem klassischen Projektleiter dies durch einen Change Request aufgezwungen wird ist nicht schlecht, allerdings sollte der gesunde Menschenverstand in der agilen Welt fr ein erfolgreiches Management solcher Situationen ausreichen. Unvollstndige Konzepte Schwachpunkt: Testen wrde frhzeitig konzeptionelle Fehler aufzeigen. Antwort: In jedem Sprint sollten die User Stories so wie sie fertig sind abgenommen werden. Somit werden unvollstndige oder fehlende Anforderungen mglichst frh erkannt. Darber hinaus werden Anforderungen meist ber rollierende Planung schrittweise verfeinert, d.h. der komplette Scope eines Projektes existiert in grober Form im Backlog und wird dann verfeinert. Die Anforderungen werden zum letzten verantwortbaren Zeitpunkt verfeinert und somit viel Aufwand fr Change Management gespart ohne schwerwiegende Beeintrchtigung aufgrund vollstndiger Vorab-Konzeption. Burndown-Chart unvollstndig Schwachpunkt: Zeit- und Budgetvorgaben knnen aufgrund der Krze von Burndown-Charts aus dem Blickfeld geraten. Antwort: Wieder ist es der Job des Product Owners die Einhaltung oder Verletzung von Randbedingungen transparent zu machen. ber die Releaseplanung in Scrum sind das notwendige Werkzeug vorhanden. Die meisten Projektreportings sind so komplex, dass sich jede Nachricht erfolgreich vermitteln lsst unabhngig von den Fakten. Bei Burndown Charts liegt der Charme in der Einfachheit und der Reduzierung auf die wenigen wirklich wichtigen Fakten. Dieses Reporting wird dann auch gerne gelesen, wie Ken Schwaber immer wieder gerne mit Anekdoten in seinen Trainings belegt. Qualittsrisiken Schwachpunkt: Risiken da das Development Team ggf. Qualittskompromisse eingeht, um fertige Features zeigen zu knnen. Antwort: Lt. deutschem Recht sind Ergebnisse nach dem Stand der Technik abzuliefern, d.h. Nachbesserungen sind bei Bedarf ohne Mehrkosten einforderbar. Darber hinaus ist wieder Transparenz gefordert. Das Risiko der Technical Debt besteht auerdem bei klassischen Projekten genau so wie bei agilen Projekten. Technologierisiken Schwachpunkt: Neue Technologien werden dank niedriger Hrden zu schnell genutzt. Antwort: Wieder eine Transparenz- und Abstimmungsfrage und damit keine Schwche agiler Methoden.

Scrum mit ein bisschen Wasserfall? Klar, und Popeye wird stark dank Spinat
By Andreas Heilwagen on April 23rd, 2012

Scherz beseite, Popeye knnte wirklich dank Spinat effizienter sein. Nur rettet das Wasserfall-Modell noch lange keine Projekte mit schlechten Product Ownern! Diesmal hat mir das Projekt Magazin mit dem Artikel Risiken der Agilen Software-Entwicklung reduzieren Ein bisschen Wasserfall muss sein eine Steilvorlage geliefert. Aber fangen wir mit einem starken Argument an und schauen dann, wo der Artikel zu Recht mgliche Schwchen agiler Methoden anspricht und wie die Lsung in der agilen Welt ohne Anleihen aussieht. Zuerst: Das Wasserfallmodell hat noch nie funktioniert! Zumindest wenn man dem Autor Winston Royce glaubt, der das Modell aufgebracht hat. Wie Eberhard Huber vor zwei Jahren gebloggt hat, zerlegt Royce das Wassermodell gleich in dem Artikel, in dem er es aufgebracht hat: In my experience, however the simpler method [Wasserfallmodell] has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process [Iteratives Modell] listed.. Dank Eberhard grinse ich seit zwei Jahren jedesmal, wenn jemand Wasserfallmodell sagt. Die einzigen erfolgreichen reinen Wasserfallprojekte die ich kenne sind Projekte, die in 2 Arbeitspaketen ( 2 Wochen gedacht) oder weniger abgewickelt sind und damit eigentlich kaum auf dem Radar der Methodikdiskussionen erscheinen sollten.

6 Grnde fr agilen Wasserfall?

Hier sind die aus meiner Sicht 6 relevanten Grnde des Artikels fr das Aufmotzen von Scrum mit Wasserfallelementen oder um prziser zu sein, Elementen des klassischen Projektmanagements denn mit Wasserfall hat der Artikel berhaupt nichts zu tun: Abhngigkeiten schlecht gemanaged Schwachpunkt: Abhngigkeiten, z.B. zu einer Produktivumgebung werden in agilen Projekten mangels technischem Projektleiter ggf. vernachlssigt. Antwort: Es ist der Job des Product Owners, die Konzeption und Weiterentwicklung eines Produkts zu treiben. Er ist der Nachfolger des Projektmanagers als Kommunikator in Scrum. Ob am Ende das Development Team die Abhngigkeiten klrt kann gewhlt werden. Anforderungen werden depriorisiert Schwachpunkt: Die Depriorisierung von Anforderungen durch neue wichtigere Anforderungen und das daraus

Fazit
Der Artikel endet mit: Bei aller Begeisterung fr agile Vorgehensweisen ist es gerade fr unerfahrene Teams wichtig zu verstehen, dass bewhrte Prozesse zur Einhaltung von Zeit und Budget konomisch sinnvoll sind. So kann ein agiles Projekt mit etwas Wasserfall nicht nur zur Zufriedenheit der Anwender, sondern auch in Zeit-, Budget- und Qualittszielen umgesetzt werden. Den Satz wrde
1

ich so komplett streichen. Unerfahrene Teams werden bei jeder Methodik mit besonderen Risiken konfrontiert. Strenge Prozesse sind an der Stelle weniger die Heilung als Begleitung = Coaching, was wiederum der Job eines Scrum Masters ist. Bei agilen Projekten wird als Rahmenbedingung das Sponsoring verwendet, d.h. nur noch eine von den frher verwendeten Randbedingungen Scope, Zeit und Budget wird eingeschrnkt. Anstatt z.B. eine Scope in unmglicher Zeit bei mglicherweise passendem Budget umsetzen zu wollen werden die unwichtigsten Features eben nicht mehr umgesetzt. Insbesondere werden 80% der Features von Softwareprodukten typischerweise von Kunden nicht genutzt. Grund dafr ist insbesondere die up-front-Spezifikation ohne angemessene Iterationen und Inkremente mit Einarbeitung von Kundenfeedback, d.h. genau die Medizin, die die Autoren der agilen Welt verabreichen wollen. Sehr gut an dem Artikel ist der Hinweis auf das von Mike Cohn modifizierte Burn-Down-Chart , welches u.a. die Aufwnde fr Change Requests transparent macht. Die genannten Schwchen der agilen Welt beruhen aus meiner Sicht darauf, dass die Product Owner-Rolle unterschtzt wird und unabhngig von der Methodik bzw. vom Framework immer noch Kommunikation der wesentlichste Erfolgsfaktor fr Projekte ist. Wie einleitend erwhnt hat der Artikel auch keinen Bezug zum Wasserfallmodell, sondern bezieht sich auf agile Methoden mit einer Ergnzung durch klassisches Projektmanagement. Insgesamt kann ich mich dem Artikel nicht anschlieen und vermisse die notwendigen Primrquellen wie beispielsweise den Scrum Guide. Ich hoffe mit diesem Posting Lsungen fr die genannten Schwachpunkte angeboten zu haben und freue mich auf eine heie Diskussion.

Fertige Karten werden rechtsum weitergereicht und vom Nchsten ggf. ergnzt bis sie wieder beim Autor ankommen. Wenn man gerade keine Zeit hat knnen Karten durchgereicht werden. Wenn man gerade keine Idee hat, kann man sich durchgesehene Karten nehmen, ergnzen und wieder in Umlauf bringen.

Irgendwann ebbt die Aktivitt ab und man hat seinen Ideenstapel fr die Bewertung. Galeriemethode
o

Einfhrungsphase Der Gruppenleiter stellt das Problem dar. Ideenbildungsphase Lsungsskizze. I Jeder entwirft eine

Assoziationsphase Die Skizzen werden aufgehngt und von allen diskutiert. Ideenbildungsphase II Die Ergebnisse werden eingearbeitet. Selektionsphase Vorauswahl der besten Lsungen.

Kartenabfrage Kartenabfrage und Pinnwandmoderation nutzen hnliche Mittel wie Brainwriting-Pool und Galeriemethode. Diese beiden Methoden gefallen wir auf Anhieb am Beste. Wenn ich eine aus Ihrer Sicht wichtige Methode ergnzen soll bitte ich um Hinweis.

Erfolgreiches Brainstorming ist Zufall Parallelisierung hebt das Potential wirklich

By Andreas Heilwagen on April 23rd, 2012

Ein Artikel in der Sddeutschen hat mich animiniert, das Thema Brainstorming einmal umzugraben. Angefangen hat alles 1948 im Buch Your Creative Power von Alex Osborne mit der Idee, einen Sturm der Ideen in den Gehirnen einer Gruppe zu entfachen und damit die besten Ideen zu produzieren. Immerhin ca. 80% der Menschen glauben das Mrchen dass Experten seit 50 Jahren mit immer mehr Forschungsergebnissen widerlegt haben. In der Basisform werden nacheinander in der Gruppe Ideen genannt, aber erst in einer spteren Phase bewertet. Darin liegt auch genau die Schwche von Brainstorming: Whrend man versucht seine eigene Idee nicht zu vergessen hrt man den Anderen auch nicht richtig zu. Trotzdem fhlen sich alle danach gut, denn in der Gruppe fhlen sich Menschen wohl und somit sieht man die Technik auch eher durch die rosarote Brille. Eine Lsung liegt in der Lsung der durch Sequentialitt bedingten Blockade durch Einfhrung von Parallelisierung, d.h. auf die Teilnehmer entwickeln ihre Ideen unabhngig voneinander und gleichzeitig. Die Forschung zeigt dass so durchweg mehr und bessere Idee entstehen. Ohne schriftliche Niederlegung der Ideen funktioniert es nicht und so kommt man bei den verschiedenen Spielarten des Brainwritings an: Brainwriting ist die Basisform verschiedener Methoden und fordert lediglich die schriftliche Niederlegung von Ideen und die Abtrennung der Bewertung in eine zweite Phase. Brainwriting-Pool
o

Ideen werden auf Karten notiert.

2