PM 2 go Praxis

Projektmanagement wird ein zunehmend wichtigerer Erfolgsfaktor fr Unternehmen im Wettbewerb. In dieser Ausgabe von PM 2 go Standards lesen Sie die praxisorientierten Kurzartikel aus dem Blog von Projekt Management Beratung. in Ihren Zustndigkeitsbereich fallen und welche in die Zustndigkeitsbereiche der Kollegen. Letztlich war die Prsentation ein best-of der Publikationen von Peter Hruschka und seinen Kollegen rund um das Thema Softwareentwicklung im agilen Bereich, was aber der Qualitt des Inhalts keinen Abbruch getan hat. Dieses Posting Manage Agile Mit Risiken Agiler Methoden umgehen Peter Hruschka wurde verffentlicht auf Unlocking Potential.

Manage Agile Mit Risiken Agiler Methoden umgehen Peter Hruschka

By Andreas Heilwagen on October 22nd, 2012

Manage Agile Panel zu agilen KPIs, verbindlichen Roadmaps und der Suche nach den TopLeuten
By Andreas Heilwagen on October 22nd, 2012

Der zweite Tag der Manage Agile begann mit Peter Hruschka von der Atlantic Systems Guild, einem Beraterverbund dem auch Tom DeMarco angehrt (vgl. sein Interview im PM Podcast). Seine Sicht aus 30 Jahren Softwareprojekten ordnet agile Vorgehensweisen letztlich als eine von drei groen Strmungen ein (strukturiert, objektorientiert, agil). Vor diesem Hintergrund gab er den Teilnehmern einige Empfehlungen auf den Weg: 1. Scrum ist aus seiner Sicht ein sehr gutes ManagementFramework, das aber durch gute Engineering Skills ergnzt werden muss in den Bereichen Architektur, Design und Anforderungsmanagement. 2. Anforderungsmanagement macht erfahrungsgem 25% des Gesamtaufwands des Projekts aus, deshalb ist es illusorisch daran zu glauben, dass ein Product Owner mehr als ein Team alleine betreuen kann. 3. POs brauchen neben der Scrum-Grundsausbildung Kenntnisse agilen Requirements Engineerings. 4. Iterationen sollten zwischen 2 und 12 Wochen dauern und er empfiehlt mit verschiedenen Lngen zu experimentieren. 5. Iteration 0 darf nicht vergessen werden (clean project start) als Vorlauf des Product Owners und Aufgaben wie Ziele SMART festlegen, Scope abgrenzen und Architektur planen. 6. Es ist notwendig eine Architektur-Dokumentation bereitzustellen und sich damit auch fr die nchste Runde aufzustellen und nicht allein lauffhige Software zu liefern in der ersten Runde. 7. disciplined agile mit einer Abwgung von Risiko und Business Value, d.h. Design-Entscheidungen richtig treffen damit das Produkt auch lngerfristig berlebt, wartbar ist, erweitert werden kann, wiederverwendet werden kann etc. 8. Es sollte einen Verantwortlichen fr Architektur im Team geben da sonst Architektur gem dem Motto TEAM=Toll Ein Anderer Machts luft. Allgemeiner: Jeder Projektaufgabe ist eindeutig eine zustndige Person zugeordnet und jede Person wei genau, welche Aufgaben

Spannend war das Expert Panel, da man herausfinden knnen was eigentlich die aktuellen Fragen aus der Praxis sind. Auf der Bhne saen von links nach rechts Boris Gloger, bor!sgloger consulting GmbH Susanne Mhlbauer, HOOD GmbH Moderator Rainer Grau, Zhlke Engineering AG Dr. Andrea Tomasini, agile42 GmbH Bernd Schiffer, it-agile GmbH Hier einige spannende Insights: 1. KPIs fr agile Teams Mitarbeiter optimieren ihr Verhalten auf extern gesetzte KPIs, sogar gegen ihre eigene berzeugung. Besser sind mit dem Team vereinbarte KPIs, allerdings bleibt jedes KPIs zunchst eine Hypothese, deren gewnschte Wirkung sich erst beweisen muss. 2. Verbindliche Roadmap Der Wunsch nach einer solchen Roadmap luft kontrr zu den Grundstzen agiler Vorgehensweisen. Die Frage Wann bin ich fertig? ist falsch gestellt und beruht auf einem Misstrauensverhltnis. Vielmehr muss gefragt werden was das Risiko ist wenn man seinen Plan nicht erreicht. Diese Einsicht dem Management zu vermitteln ist die Herausforderung. 3. Braucht man Top-Leute fr Scrum? Grundstzlich muss man die Mitarbeiter weiterbilden, um in einer Scrum-Umgebung erfolgreich zu sein. Auf der anderen Seiten passen manchmal auch einfach die Skillsets nicht. Beispielsweise macht es einen enormen Unterschied ob man als Anforderungsmanager im Auftrag von Fachabteilungen einfache Aufgaben erledigt oder als Product Owner kreativ ttig wird. Neben den geeigneten Mitarbeitern muss das Management vor allem auch geeignete Umgebungsbedingungen schaffen. 4. Beweis fr die Leistung agiler Methoden?
1

Lt. dem letzten Standish Report sollen angeblich 40% aller agilen Projekte vs. 16% aller nicht-agilen Projekte erfolgreich sein, aber wer glaubt schon an den Standish Report ,-) Hufig steht die Angst dahinter, dass die neue Methodik im eigenen Unternehmen mglicherweise nicht funktioniert. Besser ist es sich gemeinsam mit dem Kunden auf das kleinstmgliche Experiment zu einigen, dass dem Kunden die Entscheidung fr oder gegen die Einfhrung agiler Methoden ermglicht. Alles in Allem ein spannender Tag und fr eine Konferenz ber ein so junges Thema schon sehr professionell. Dieses Posting Manage Agile Panel zu agilen KPIs, verbindlichen Roadmaps und der Suche nach den Top-Leuten wurde verffentlicht auf Unlocking Potential.

Dieses Posting Manage Agile Beispiel eines radikal agilen Unternehmens wurde verffentlicht auf Unlocking Potential.

Manage Agile Beispiel eines radikal agilen Unternehmens

By Andreas Heilwagen on October 22nd, 2012

Neben meinen Scrum Pattern gibt es noch weitere Anstze. Christian Dhn und Bernd Schiffer von it-agile haben heute ihre Agile Management Innovations (aka AMI) beschrieben. Auf Basis ihrer Beratungserfahrungen haben sie in den Bereichen Money Collaborative Infrastructure Teams Customer and Innovation Mastery Decisions insgesamt 26 AMIs definiert, die sie bereits grtenteils bei Kunden eingesetzt wurden. Ein Beispiel dafr sind die SlackRegelung, die am ehesten von Google bekannt ist, d.h. dort hat man einen Tag pro Woche Zeit eigene Projekte zu verfolgen. Spannend auch das Entscheidungsverfahren Konsent, bei dem eine Entscheidung nur dann gefllt werden kann wenn niemand dagegen ist. Wenn es ein Veto gibt, muss dies begrndet sein mit dem Ziel, die potentielle Entscheidung so weiterzuentwickeln, dass es kein Veto mehr gibt. Besonders weit entwickelt sind die Peer Groups der Mitarbeiter, bestehend aus drei Personen oder mehr, die im Fall von itagile auch ber Gehlter der Betroffenen entscheiden. Damit man am Anfang nicht verloren ist, werden Neueinsteigern Mentoren zugewiesen. Wer nicht mag, muss aber auch keine Peer Group haben. Soziokratie ist urspnglich eine Staatsform, in der u.a. der Konsent die Entscheidungsform ist. Der Sinn dieser AMI ist die organisationale Partitionierung in Business Teams mit Marktkontakt. D.h. die funktionalen Teams werden vollstndig aufgelst, die funktionalen Themen werden wiederum ber Open Spaces zusammengebracht. Darber hinaus kann jeder Mitarbeiter aufgrund des konsequenten Pull-Prinzips Anweisungen erteilen, wenn er fr ein Thema verantwortlich ist. Spannend ist dies so durchzufhren, dass die Akzeptanz gewhrleistet ist. Als Krnung sind alle Gehlter im Wiki auf einer Seite einsehbar und die Mitarbeiter halten 2/3 der Firmenanteile, so kommt itagile dem Thema Wirtschaftsdemokratie ziemlich nah. Super Vortrag!