Agiles Projektmanagement – PM Camp München 2017

Projektleiter, Coaches, Führungskräfte, Trainer und Interessierte tauschen sich darüber aus, wie Projekte besser laufen können – das ist das  PM Camp München.

Das PM Camp München – wobei PM für Projektmanagement steht – ist einer die vielen Abkömmlinge des PM Camp Dornbirn, das vergangenen November zum letzten Mal stattfand – siehe dazu auch der Artikel hier. In den Räumen der Ludwig-Maximilian-Universität München fanden wir uns zusammen, um über Wasserfall, Cynefin und Agil zu sprechen, über Hindernisse und Menschliches, über Prozesse und Entscheidungen. Die Teilnehmerschaft empfand ich als eine sehr angenehme Mischung aus Konzernmitarbeitern, Projektleitern aus Mittelstand, Beratern, Trainern und Coaches.

Hat Spaß gemacht. Super Orga, nette Leute!
Hier schonmal das Gruppenhüpfen#PMCampMUC @wowolek @dimjon @melmel2701 @bildwerck @aigner_martin pic.twitter.com/toLPFCXfwx

— Ali Malak (@alimalak) July 1, 2017

Das PM Camp ist eine „Unkonferenz“ im Format eines Barcamp. Das bedeutet, dass die Agenda erst am jeweiligen Tag entsteht. Die Teilnehmer kommen mit Ideen für eine „Session“, egal ob Vortrag, Diskussion, oder auch ganz andere Formate. Fest in einstündigen Zeitscheiben durchgetaktet finden sich Menschen zu einem Thema zusammen, mehr oder weniger. Wer eine Session anbieten möchte, tut das eben. So ist denn auch ein Teil der Begrüßung dafür reserviert, den Sessionplan aufzustellen.

Ein nettes Gimmick der Münchner fand ich, den Session kleine Sofortbilder anzuheften, damit man mit dem Namen des Sessiongebers auch gleich ein Gesicht verknüpfen kann.

Aus der Vielzahl an Themen möchte ich nur einige exemplarisch herausgreifen. Die offizielle Session-Dokumentation wird bei PM Camps auf der OpenPM Plattform abgelegt, so auch für das PM Camp München 2017.

Feedback geben in kritischen Situationen

In eine Art von Session stellt der Themengeber ein ganz konkretes Problem vor, mit dem er oder sie sich gerade beschäftigt. Das spannende daran ist, dass man vorher nicht weiß, wohin die Reise führt, wenn es eben nicht nur ein Lern-Beispiel ist, sondern ein tatsächliches Problem, bei dem man selbst bislang auf keine gute Lösung kam.

Im konkreten Fall ging es um ein Problem in einem Projekt, bei dem ein Projektmitarbeiter sich mit ihren Vorschlägen nicht gehört fühlte und fragte, was denn nun zu tun sei.

Ganz exzellent ist es, wenn bei einer solchen Session jemand mitzeichnet, wie die Jungs von Visual Braindump. Auf diese Weise haben die Teilnehmer und auch Du ein grafisches Ergebnis der Diskussion:

Gut gemeint… toll geteilt @BarbaraBucksch und gutes #Feedback bis zur letzten Minute #pmcampmuc pic.twitter.com/imHxwC2Uax

— Visual Braindump (@VisualBraindump) June 30, 2017

Die Session-Doku zum Thema Feedback.

Visuelles Projektmanagement

Mehr zu den Grundlagen ging es für mich in der nächsten Session: Was für grafische Möglichkeiten habe ich denn, ein Projekt zu führen? Wie visualisiere ich Besprechungen, Ergebnisse und Artefakte? Bernhard Schloß und Christian Botta plauderten aus der Erfahrung.

Die Kollegen zum Thema #Visuelles #Projektmanagement. Wenig Zeit – viel Inhalt #pmcampmuc @pottasson @schlossblog pic.twitter.com/2IxsSJcei3

— Visual Braindump (@VisualBraindump) June 30, 2017

Schon allein die Auflistung der angesprochenen Arten der Visualisierung ruft einige ins Gedächtnis, die ich gar nicht mehr als besonders grafisch wahrgenommen hatte

• Mind Map
• Gantt Charts
• Organigramme
• Story Mapping
• User Story Diagramme
• Canvas (z.B. Business Model Canvas)
• Visual Facilitation / Graphic Recording
• Ishikawa (Fischgrätendiagramm)
• Ampeln (meist schlecht ausgeführt)
• Die Insel auf dem Bierfilz
• Projektmetapher – ein Bild für das Projekt
• Zeichnen im Allgemeinen

Agilität messen

Marcus Raitner fragte, wie man denn Agilität in einer Organisation messen könne, und bekam reichlich Material.

Konkret ging es in dieser Session darum, den Fortschritt einer Transformation hin zum agilen Vorgehen zu messen und zu bewerten. Ideen und Hinweise gab es derer viele, was man denn messen könne:

• Aufwand für Reporting, manuell und automatisiert
• Durchlaufzeit von Idee zu Nutzung
• Kundenzufriedenheit (im konkreten Kontext der interne Kunde der IT)
• Mitarbeiterzufriedenheit, Fluktuation
• Messen beim Team beginnen und autark lassen
• Frequenz von Lieferung
• Business Value pro Zeit
• Depriorisierte Features, also die Anzahl dessen, was nicht gemacht wird
• Kosten
• Qualität oder auch Technical Debt
• Agiler Reifegrad, die Kultur
• Dedication pro Mitarbeiter – wie viele Projekte/Produkte bedient jemand gleichzeitig
• Lernen vs. Liefern
• Work in Progress – angefangene Arbeit
• Agility Health Radar

Dabei wurde betont, dass auf keinen Fall eine Incentivierung, also ein Bonussystem an irgendeine der potentiellen Messgrößen gekoppelt werden dürfe, weil das unweigerlich zur Topimierung führt.

Die Sessiondokumenation zu Agilität messen.

Menschen und Interaktionen über Prozesse und Tools

Meine These, die mich zu dieser Session anstiftete: Aus dem agilen Wert „People and Interactions over Processes and Tools“ folgt, wenn man das ganze so aufmalt, dass Prozesse und Tools die Basis für Menschen und Interaktionen bilden.

Obgleich wir uns einig sind, dass im agilen Arbeiten die Menschen zählen, schrieben wir Tools und Prozesse auf, die wir aus unserer täglichen Arbeit als nützlich erachten.

Aus den vielen Dimensionen, in die sich Prozesse und Tools einteilen lassen, griffen wir zwei heraus:

• Grad der Automatisierung: Wie stark läuft der Prozess bzw. das Tool automatisch, also ohne dauernden händischen Eingriff?
• Wirkung (“Impact”): Wie weit reicht die Wirkung, auf wie viele Projektmitglieder, auf das Projektergebnis oder wie strategisch?

Die elektronifizierte Fassung des Ergebnisses:

Aus der Diskussion entstanden einige notierenswerte weitere Thesen:

1. Agil ≠ Chaos. Wird gerne verwechselt, oder das eigene Chaos wird als agiles Vorgehen schön geredet. Chaos bleibt aber Chaos.
2. Prozesse und Tools erlauben Teams, sich auf die wesentlichen Arbeitsinhalte zu konzentrieren. Ein Prozess entbindet mich davon, jedes Mal aufs neue eine Entscheidung zu treffen, die sich ohnehin ergibt. Ein Tool automatisiert Vorgänge und dokumentiert Ergebnisse, so dass ich später darauf zurückgreifen kann.
3. Jedes Team braucht Prozesse. Siehe auch 1. Die Art der Prozesse hängt ab vom gewünschten Arbeitsergebnis, von der Teamzusammensetzung, von der Teamgröße und vielen weiteren Faktoren. Aber jedes Team braucht Prozesse.
4. Wenn ein Team sich einen Prozess nicht gibt, ist es in Ordnung, eine Prozessvorgabe zu machen. In der reinen Lehre werden von außen nur Qualitäts-, Inhalts- und Zeitanforderungen gestellt und das Team gibt sich selbst Prozesse. Damit nicht jedes Team wieder bei Null anfangen muss, können von außen Prozesse und Tools angeboten werden. Ein Team, das keine Notwendigkeit sieht, davon abzuweichen, übernimmt einfach bestehendes.
5. Lemma aus 4: Standardprozesse vorsehen, Abweichung erlauben. Standardprozesse erlauben, flotter loszulegen. Um die Anpassungsfähigkeit des Teams – die Agilität – sicherzustellen, darf das Team aber von den Standards abweichen.
6. Prozess-Autarkie von Teams bedingt informierte Teammitglieder. Sich selbst Prozesse zu geben erfordert, dass das Team einen guten Überblick über Möglichkeiten an Prozessen und Tools hat, und die Fähigkeit, beides für sich umzusetzen.
7. Große Entwicklungsprojekte benötigen Prozess/Tool-Abstimmung und ggf. Synchronisation. Damit größere Organisationen nicht im Prozessdschungel und Tool-Zoo versinken, braucht es eine Runde, die sich über Prozesse und Tools austauscht. Eine regelmäßige Konsolidierung hilft, die organisatorische Komplexität zu reduzieren.

Die Session Doku zu People, Processes, Tools.

Lesestoff

Zu lesen habe ich auch wieder einige Empfehlungen mitgenommen, und manche auch gegeben.

• Greg Brougham: The Cynefin MiniBook (Englisch)
• Mike Hoogveld, John M. D. Koster: Measuring the Agility of Omnichannel Operations: an Agile Marketing Maturity Model (Paper)
• Svenja Hofert: Agiler führen: Einfache Maßnahmen für bessere Teamarbeit, mehr Leistung und höhere Kreativität
• Jeff Sutherland: Scrum: The Art of Doing Twice the Work in Half the Time (auch in deutsch). Siehe dazu auch meine Buchbesprechung.
• Martin Haussmann: UZMO – Denken mit dem Stift: Visuell präsentieren, dokumentieren und erkunden
• Tim Themann: Die Computermaler: IT visualisieren – ganz spontan

Danke für die Buchempfehlungen, da schau ich, was ich davon lese. (Stay tuned)

Menschen

Ein PM Camp lebt von den Menschen, die es gestalten. Deshalb fotografiere ich gerne auf diesen Unkonferenzen: Weil es die Menschen sind.

Wenn in Deiner Nähe auch ein PM Camp stattfindet, dann empfehle ich, dort selbst einmal teilzunehmen. Jeder ist Professional, und jeder kann hier etwas mitbringen und etwas lernen. Das Beste daran für mich ist, dass ich vorher nie genau weiß, was ich lerne, aber immer zuversichtlich bin, etwas zu lernen.

Alle Fotos: www.joachimschlosser.de
Offenlegung: Am PM Camp München nahm ich für Elektrobit Automotive Consulting teil.  

MerkenMerken

MerkenMerken

MerkenMerken

MerkenMerken

MerkenMerkenMerkenMerken

MerkenMerken

MerkenMerken