Auf der Webseite der Scrum Alliance habe ich eine interessante Übersicht der wichtigsten Scrum Prozesse, Rollen und Artefakte gefunden, die ich Ihnen nicht vorenthalten möchte.

“The Scrum Framework in a SIPOC Nutshell” (doc), erstellt von Madhu Laulin.

Warum ich die Übersicht gut finde:

• Der Autor hat die wichtigsten Scrum Prozesse und Regeln auf der ersten Seite des Dokuments sehr übersichtlich und verständlich dargestellt.
• Zudem gefällt mir auch die Beschreibung in Form des SIPOC Diagramms, einer Methode aus Six Sigma. Insbesondere die verschiedenen Rollen werden durch diese Form der Ausarbeitung sehr klar.

Ähnliche Beiträge:

1. Zen of SCRUM (by Jurgen Appelo)
2. SCRUM Plakat
3. SCRUM Day in München – Vorträge zum Herunterladen

Zusätzlich zu den Videos, die natürlich rund um die Uhr abgerufen werden können, besteht die Möglichkeit, mit den Referent/innen über das “WorkNet” direkt in Verbindung zu treten und offene Punkte zu diskutieren. Ein gutes und innovatives Konzept, wie ich finde.

Und das Beste ist: SIE KÖNNEN NUN EINE VON 3 FREIKARTEN GEWINNEN!

Schreiben Sie einfach eine e-Mail an info@pionierbasis.com und geben Sie in der Betreffzeile “PM-Blog.com” an. Patrick Fritz von der Pionierbasis wird alle Einsendungen, die bis zum 24.1.2011 eintreffen, sammeln und daraus den/die Gewinner/in ziehen. Wert eines Konferenz-Tickets: EUR 300.

Ähnliche Beiträge:

1. Virtuelle SCRUM Konferenz
2. SCRUM im Unternehmen implementieren
3. SCRUM: Den strategischen Geschäftsnutzen im Fokus

Klassische vs. Agile PM-Ansätze

Internationale Standard und Rahmenwerke wie das PMBOK von PMI, die ICB von IPMA, PRINCE2 oder auch die DIN 69901 können den klassischen PM Ansätzen zugeordnet werden. Die oben genannten agilen Vorgehensmodelle, die bislang größtenteils in der Softwareentwickung Verwendung finden, sind hingegen Ansätze des Agilen Projektmanagements (APM). Ich persönlich bin davon überzeugt, dass wir in vielen Bereichen Wissen und Fähigkeiten aus “beiden Welten” benötigen werden (= Integriertes Projektmanagement).

Buchtipp

Neulich habe ich ein Rezensionsexemplar des Buches “Pragmatisches IT-Projektmanagement” von N. von Briniski und G. Vollmer erhalten.  Der Untertitel des Buches gibt Aufschluss über die Besonderheit dieses Buches: “Softwareentwicklungsprojekte auf Basis des PMBOK® Guide führen”. Die Autoren haben damit ein Werk geschaffen, das in einer sehr systematischen und gleichzeitig praxisorientierten Art und Weise eines der wichtigsten “klassischen” Rahmenwerke, nämlich das PMBOK, mit agilen Prinzipien und Vorgehensmodellen verbindet und daraus das PITPM Vorgehensmodell ableitet.

Das Buch ist meines Erachtens ein großer Wurf in dem Thema. Denn gerade mittelständische IT Unternehmen oder IT-Abteilungen in Unternehmen stehen häufig vor dem Problem der Entwicklung einer PM Methodik für die Planung und Steuerung der IT Projekte. In diesem Zusammenhang kommt man in der Regel auch zu der Frage, ob agile oder klassische Methoden Anwendung finden sollen. Das Buch “Pragmatisches IT-Projektmanagement” kann in diesem Zusammenhang schlüssige Antworten und eine individuell anpassbare Vorlage für eine spezifische PM-Methodik bieten.

Ein weiteres Highlight: Auf der Seite www.PITPM.net können (vorausgesetzt, Sie legen einen Benutzer an) kostenlos zum Buch passende Vorlagen und Templates herunter geladen werden. Ein echter Mehrwert!

Weitere Buchempfehlungen:

• Oestereich/Weiss: APM – Agiles Projektmanagement
• Wirdemann: SCRUM mit User Stories
• Gloger: SCRUM

Ähnliche Beiträge:

1. Buchtipp: Agile Softwareentwicklung
2. SCRUM – dem agilen Projektmanagement gehört die Zukunft!
3. PMTV004: Agiles Projektmanagement

Mein Kollege Patrick Fritz hat kürzlich das Unternehmen “Pionierbasis – Plattform für überbetrieblichen Austausch” gegründet. Pionierbasis ist direkt aus dem Projekt “Jahooda” entstanden, mit dem in den letzten Jahren erfolgreich der überbetriebliche Wissens- und Erfahrungsaustausch in den Themenfeldern Projektmanagement, Softwareentwicklung, Logistik und Produktentwicklung in der Bodenseeregion “angekurbelt” wurde.

Eines der ersten Projekte von Pionierbasis ist die SCRUM Konferenz. Ziel ist es, das Thema SCRUM mit erfahrenen Expert/innen in einer “virtuellen Konferenz” zu besprechen und zu vertiefen. Mit 8 Personen – ich war eine davon – wurden Videointerviews zu unterschiedlichen Themen geführt.

Eine gute Idee und ein wirklich spannendes Projekt – ich bin schon gespannt.

Download “Scrum Konferenz” Flyer (PDF)

Ähnliche Beiträge:

1. 3 Freikarten für virtuelle SCRUM-Konferenz
2. SCRUM – dem agilen Projektmanagement gehört die Zukunft!
3. ScrumBut – “We use Scrum, but…”

Wenig überraschend sind die meisten Leser/innen (nämlich 68%) der Ansicht, dass Zertifzierungen zwar karrieretechnisch einen Vorteil bringen können, dass sie aber wenig darüber aussagen, ob jemand ein/e gute/r Projektleiter/in ist. 22 % der Rückmeldungen erachten PM Zertifizierungen für wichtig und sinnvoll, lediglich 6 % halten gar nichts davon.

Meine Meinung zu dem Thema:

• Es ist unbestritten, dass man sich einiges an Wissen aneignen muss, um die verschiedenen PM Zertifikate zu erwerben.
• Es ist weiters unbestritten, dass zertifizierte Projektleiter/innen ein gemeinsames Verständnis und eine gemeinsame Sprache entwickeln, was für die Praxis sehr wichtig ist.
• Eine generelle Bewertung der Zertifikate ist natürlich nicht zulässig oder möglich, da inhaltliche, konzeptionelle und auch qualitative Unterschiede zwischen den einzelnen Zertifizierungen und Zertifizierungsstufen bestehen.
• Für mich ist eine der Kernfragen, ob man mit einer Zertifizierung erworbenes Wissen auch in KÖNNEN umwandeln kann. Wenn dies nicht gelingt, sind Zertifizierungen nutzlos (oder sogar schädlich, denn dann werden vermeintliche “Könner” auf Projekte angesetzt, mit denen sie faktisch überfordert sind). Denn dann weiß jemand zwar viel, er/sie kann es aber nicht umsetzen.
• Eine weitere wichtige Frage besteht darin, welche Konzepte, Inhalte und Theorien die Grundlagen für die Zertifizierungen darstellen. Denn teilweise hat man den Eindruck, dass die Praxis des Projektmanagements schon weiter ist als die Theorien und Modelle der PM Standards.
• Ob der Aufwand für eine Zertifizierung in einem guten Verhältnis zum jeweils individuellen Nutzen steht, muss jede/r für sich selbst beurteilen.

Ich für meinen Teil kann sagen, dass ich in den nächsten 1-2 Jahren wahrscheinlich eine Scrum Zertifizierung angehen werde. Mit den Zertifzierungen der großen Verbände habe ich abgeschlossen, da sie für mich zu wenig praktischen Nutzen haben. Die Zeit, die ich für eine erfolgreiche Zertifizierung aufwenden müsste, verwende ich lieber für selbstgesteuertes Lernen in anderen Bereichen.

Über Ihre Meinungen zu diesem Thema würde ich mich sehr freuen.

Ähnliche Beiträge:

1. Projektmanagement Zertifizierung – IPMA oder PMI?
2. PM Software: Zwischenergebnis
3. Zwischenergebnis Blitzumfrage: PM und Social Media

Neulich hielt Jurgen eine Keynote bei LINEAS in Braunschweig. Seine Präsentation”Zen of SCRUM” gibt einen hervorragenden Überblick über agile PM-Ansätze, mit Schwerpunkt auf SCRUM.

Ähnliche Beiträge:

1. Management 3.0 Course with Jurgen Appelo
2. SCRUM verstehen
3. Buchtipp: Management 3.0 (Jurgen Appelo)

SCRUM ist eine agile PM Methodik und gleichzeitig ein Vorgehensmodell, das in den letzten Jahren stark an Bedeutung zugenommen hat. Gleichzeitig fällt es vielen Unternehmen schwer, die Scrum Prinzipien 1:1 umzusetzen. Diese sind beispielsweise (siehe hierzu auch die Grafik unten):

• Daily Scrum Meeting (15 Min.)
• Sprints (ca. 30 Tage)
• Scrum Roles “Product Owner”, “Scrum Master”, “Team”, “Scrum Team”
• Sprint Planning Meeting
• Sprint Review Meeting
• Sprint Retrospective
• etc.

Ken Schwaber ist einer der Begründer von Scrum. Er erläutert im obigen Video, dass es unter gewissen Umständen legitim ist, von den definierten Scrum Prinzipien abzurücken und diese anzupassen. Schwaber nennt dies “ScrumBut”. Diese Bezeichnung kommt von der Aussage “Yes, we use Scrum, but…”.

Blogger-Kollege Jurgen Appelo geht sogar noch weiter und behauptet, dass das volle Potenzial von Scrum erst dann entfaltet werden kann, wenn ScrumBut angewendet wird, sprich wenn das Konzept den jeweiligen Rahmenbedingungen und vor allem dem jeweiligen Team angepasst wird.

Auch der von mir sehr geschätzte Kollege Pawel Brodzinski plädiert inständig für eine sinnvolle Anpassung von methodischen Ansätzen und Vorgehensmodellen. Sein Beitrag ist allerdings etwas ironisch geschrieben – ich musste ihn 2 mal lesen, um die Argumentation zu verstehen.

Verhältnismäßig wenige Expert/innen sehen ScrumBut kritisch und raten strikt davon ab, das Scrum-Konzept zu “verbiegen”. Es scheint sich die Meinung durchzusetzen, dass ScrumBut legitim oder sogar zwingend notwendig ist.

FAZIT: Ich denke, ScrumBut ist in den meisten Fällen sinnvoll und notwendig. Allerdings sollte man es sich in der Praxis nicht zu leicht machen. Denn das “Herz” von Scrum – so wie es auch im agilen Manifest beschrieben ist – sollte niemals verloren gehen. Für ein differenziertes ScrumBut tritt auch Scrum-Experte Boris Gloger ein: “ScrumBut – Eine genauere Betrachtung“.

Nachtrag vom 19.11.2010: Boris Gloger hat recht. Die Formulierung “ScrumBut ist in den meisten Fällen sinnvoll und notwendig” ist so nicht richtig. Ich stimme ihm zu, dass man die Implementierung von SCRUM als Entwicklungsprozess betrachten sollte. Natürlich ist das Ziel, agile Prinzipien so weit wie möglich bzw. soweit es Sinn macht zu implementieren.

Ähnliche Beiträge:

1. SCRUM – dem agilen Projektmanagement gehört die Zukunft!
2. Agiles Projektmanagement mit SCRUM
3. SCRUM – Agile for everyone

Boris beschreibt in der Präsentation zu recht, dass im traditionellen Projektmanagement der Projektstrukturplan (Work Breakdown Structure) ein zentrales Planungsinstrument ist. Die kleinste Planungseinheit sind Arbeitspakete oder einzelne Aufgaben. Dies kann dazu führen, dass das Projekt “aufgaben-getrieben” abläuft und die eigentlichen Anforderungen und Ziele im Extremfall vernachlässigt werden. Taktisches anstatt strategisch sinnvolles Arbeiten kann die Folge sein.

In SCRUM ist das zentrale Planungsinstrument der Product Backlog. Boris bezeichnet diesen zurecht als “Feature Breakdown Structure”. In SCRUM orientiert sich das Projektteam an den jeweiligen Features, die unmittelbar aus den definierten Anforderungen des Kunden (bzw. Product Owner) resultieren. Der Fokus auf den strategischen Geschäftsnutzen ist fast die unausweichliche Folge dieses Vorgehen.

Gut, ganz schwarz und weiß malen darf man die Sache sicher nicht. Auch mit traditionellen Methoden kann man den Geschäftsnutzen sicher stellen, und auch mit agilen Methoden können Projekte völlig am Geschäftsnutzen vorbei laufen. Von der Tendenz her stimme ich Boris Gloger aber vollkommen zu: Ein wesentlicher Vorteil der SCRUM Methode besteht darin, dass die Ziele (in IT Projekten Features) im Planungs- und Umsetzungsfokus stehen. Und diese resultieren in der Regel unmittelbar aus den Anforderungen und der Produktvision des Kunden (bzw. Product Owner).

Oder aus der anderen Perspektive gedacht: Im traditionellen Projektmanagement wird der Projektauftraggeber in den Initiierungs- und Planungsprozessen verstärkt eingebunden. Während der Durchführungsprozesse ist die Einbindung häufig nur noch sporadisch. Dies birgt die Gefahr, dass das Projektteam (teilweise) an den Bedürfnissen und Anforderungen des Auftraggebers vorbei arbeitet.

Was meint Ihr? Seid Ihr anderer Meinung?

Ähnliche Beiträge:

1. SCRUM – dem agilen Projektmanagement gehört die Zukunft!
2. ScrumBut – “We use Scrum, but…”
3. SCRUM Day in München – Vorträge zum Herunterladen

Denn das “klassische Projektmanagement” (der Begriff ist übrigens in der Theorie noch nicht klar definiert), das seinen Ursprung in den 50-er Jahren des letzten Jahrhunderts hat, ist auf unsere dynamische Wirtschaftswelt nicht mehr 1:1 anwendbar. Auf der anderen Seite sind agile Methodiken, wie sie hauptsächlich im IT Projektmanagement und der Softwareentwicklung angewendet wurden, für diverse andere Anwendungsbereiche (wie z.B. Anlagenbauprojekte, Bauprojekte, Produktentwicklungsprojekte) nicht 1:1 übertragbar. Fazit: Wir brauchen in vielen Bereichen eine sinnvolle Integration und Kombination aus beiden “Welten”.

In den letzten Monaten wurde einiges über dieses Thema geschrieben und publiziert, wie beispielsweise hier, hier, hier, hier oder hier. Trotzdem glaube ich, dass wir mit der Entwicklung noch ziemlich am Anfang stehen. Ähnlich wie in der gesamten Führungs- und Managementlehre, wo Ansätze zwischen Stabilität und Dynamik bzw. zwischen Hierarchie und Heterarchie von Experten intensiv diskutiert werden. Meine Überzeugung: Die “Wahrheit”, wenn man in diesem Zusammenhang diesen Begriff überhaupt verwenden darf, liegt häufig in der Mitte. Differenzierung, Diversität und ganzheitlich-systemisches Denken werden unsere Zukunft bestimmen.

Zurück zum Thema: Auch in dieser Präsentation wird ein weiteres Mal die Frage ins Zentrum gerückt, wie traditionelle mit agilen PM Ansätzen kombiniert werden können. Besonders interessant ist diese Präsentation auch darum, weil die Zentrierung auf MENSCHEN (human-centered design) zusätzlich noch propagiert wird. Der einzig sinnvolle Weg!

Ähnliche Beiträge:

1. PM Blitzumfrage 9: Agiles Projektmanagement
2. Agiles Projektmanagement mit SCRUM
3. Agiles Management: Delegation und Authorität

Oliver Fischer (Bild, Software Engineering Blog) hat mich auf eine Projektmanagement Studie von “oose. Innovative Informatik” aufmerksam gemacht. Ich kenne oose schon länger und bin davon überzeugt, dass es sich hier um ein überaus innovatives, erfolgreiches und gut geführtes Unternehmen handelt. Aber das nur nebenbei…

Einleitend möchte ich festhalten, dass die Unsitte seit einiger Zeit um sich gegriffen hat, in jeder zweiten Pressemeldung eine ach so wichtige und aussagekräftige “Studie” anzukündigen. Ein großer Teil dieser “Studien” wurde aber auch nicht annähernd nach den Qualitätskriterien einer empirischen Untersuchung erstellt. NICHT SO IN DIESEM FALL.

Für die Qualität und Aussagekraft der vorliegenden Untersuchung spricht aus meiner Sicht, dass

• die Studie von einem sehr professionellen und vertrauenswürdigen Unternehmen erstellt wurde,
• das empirische Vorgehen transparent dargelegt wird,
• dieses Vorgehen fundiert und gut durchdacht erscheint und
• dass aufgrund der Unterstützung durch große PM Institutionen vermutet werden kann, dass der Zugang zu Unternehmen gelegt werden konnte, die zu dem Thema “auch wirklich etwas zu sagen haben”.

Darüber hinaus wurde aus den 212 eingereichten Fragebögen nach einer durchlaufenen Plausibilitätsprüfung nur 130 für die Ergebnisauswertung heran gezogen.

Nun aber zu den Zielen und Ergebnissen der Studie. Folgende Zielsetzungen wurden am Beginn formuliert:

1) Gibt es signifikante Unterschiede darin, wie klassische und agile Projekte arbeiten?

2) Was können agile und klassische Projekte voneinander lernen?

3) Welche Verfahren tragen zum Projekterfolg bei?

Das zentrale Ergebnis, das in der Fachwelt gerne ausgiebig diskutiert und kritisch hinterfragt werden darf und soll: AGILE PROJEKTE SIND SIGNIFIKANT ERFOLGREICHER ALS KLASSISCHE PROJEKTE!

Mir erscheint wesentlich, dass laut oose nicht das gewählte agile Vorgehensmodell erfolgsentscheidend ist, sondern die Art und Intensität der Kommunikation zwischen Kunden und Entwickler-Teams. Ich persönlich bin davon überzeugt, dass hier der wirkliche Schlüssel zu hocheffektiven und selbstorganisierten Projektteams liegt. Oder in der Terminologie des agilen Manifests:

INDIVIDUALS AND INTERACTIONS over processes and tools.

That’s the key. For sure!

DOWNLOAD: Hier könnt Ihr die Studienergebnisse direkt bei oose herunter laden.

Ähnliche Beiträge:

1. Klassisches oder agiles PM bei Softwareprojekten?
2. Menschen-zentriertes Design trifft agiles Projektmanagement
3. Klassisches vs. agiles Projektmanagement