Abstract
Am Beispiel realer Firmen, erläutert Boris Gloger, was tatsächlich passiert, wenn man Scrum in einem Team, einer Abteilung oder einer Firma einführt. Wie verändert sich die Produktivität, wie verändern sich die Rollen der Mitarbeiter, gibt es wirklich eine Motivationssteigerung bei den Mitarbeitern?

Dieser Vortrag richtet sich an ScrumMaster, an Abteilungsleiter und an Geschäftsführer, die überlegen, ob Scrum ihnen dabei helfen kann: Qualitätsprobleme zu lösen, unzufriedene Kunden zu zufriedenen zu  machen, Mitarbeiter zu halten und verlässlich in der Entwicklung von Software Entwicklungsprodukten zu werden.

Referent
Boris Gloger, 41, ist ein international bekannter  Scrum Experte und Gründer der Firma bor!sgloger. Autor von “Scrum – Produkte zuverlässig und schnell entwickeln und extensiver Scrum-Blogger auf www.borisgloger.com. Seine Kundenliste liest sich wie ein  Auszug aus dem Who is Who: Nokia, Siemens, StudiVZ, Ing Diba, Immobilienscout24, O2 und und und…

Daneben ist das Boris Gloger Team ist darauf spezialisiert, Scrum auf Unternehmenslevel einzuführen. Boris hat u.a. als Certified Scrum Trainer mehr als 3000 Menschen in Deutschland, USA, Skandinavien, Ost Europa, China und Brasilien Scrum  erklärt. Boris Gloger lebt in Wien und schreibt wenn die Zeit bleibt Drehbücher.

Factbox
Zeit: Donnerstag, 04. Februar 2010, 18:00 Uhr
Ort: Fachhochschule Vorarlberg, Dornbirn, Raum W207/08
Kosten: € 30 / € 10 für Jahooda-Mitglieder und Studenten
Anmeldung: Frau Monja Domig,  T +43 (0)5572 792-7110, E-Mail monja.domig@fhv.at

Download Vortragsfolder [PDF]

Hier ein direkter Link zu den bisherigen Videoaufzeichnungen von Ralf Westphal:

• Exklusiv: “Menschenführung in der Wissensarbeit” von Ralf Westphal
• Exklusiv: “Softwarearchitektur für nachhaltige Entwicklung” von Ralf Westphal

P.S. Die Aufzeichnung von Ralfs Vortrag “Asynchrone Komponenten” ist in Produktion und wird von mir in den kommenden Tagen auf Jahooda veröffentlicht.

Beim letzten Breakfast referierte Daniel Tobler von Zühlke zur Frage: “Are there software projects to which agile processes do not apply?“. Sein überraschendes Fazit, agile Vorgehensmodelle sind nur in zwei Fällen nicht anwendbar:

• The team or management really does not want to do it
• All of the developers are really junior and need to guidance on what to do. This case applies particularly to a university context in which students are just learning the tools of the trade

Ich kann euch nur empfehlen seine Präsentation “Agile vs plandriven SW Processes” (in Form einer MindMap) sehr genau anzusehen, da stecken wirklich viele wertvolle Erfahrungen drin!

REVIEW 1: “Einführung in die agilen Methoden der SW-Entwicklung“

REVIEW 2: “Was ist eigentlich agiles Projektmanagement?“

…möchte ich diese Thematik vorläufig zu einem Ende bringen und in einer abschließenden Betrachtung kritisch hinterfragen.

Kritikpunkt 1: Agile Methoden sind nur bei Softwareprojekten einsetzbar
Gerade die Entwicklung von Systemarchitekturen in der Automobilindustrie zeigt auf, das agile Ansätze durchaus auch in anderen Bereichen denkbar sind und dort auch angewendet werden. Ergänzend wurden viele agile Methoden in der Automobilentwicklung erfunden, wie zum Beispiel: Simultaneous Engineering und Target-Costing bzw. Design-to-Cost.

Kritikpunkt 2: Agile Methoden lassen keine Festpreisverträge zu
In der Literatur existieren bereits zahlreiche Vertragsmodelle, mit denen in agilen Projekten gearbeitet werden kann (z.B. Coldewey und Poppendieck sowie Oestereich), ohne ein Pflichtenheft als scheinbar geeignet Grundlage für Preiskalkulationen. Gerade durch das umdrehen “des magischen Dreiecks”, was ja den Wechsel vom plangetriebenen zum agilen PM kennzeichnet, sehe ich ganz neue Möglichkeiten der Vertragsgestaltung – Kosten und Termine werden fixiert, die Merkmale beruhen auf Schätzungen. Somit bleibt nur noch eine Unbekannte, nämlich die Merkmale. Wohingegen wenn nach “Plan” gearbeitet wird lediglich die Anforderungen fixiert werden und folglich Kosten und Termine auf Schätzungen beruhen.

Kritikpunkt 3: Agile Methoden funktionieren nur für kleine Projekte
Es gibt Beispiele in denen agile Methoden auch für größere Projekte angewendet wurden (z.B. Scrum-Projekt mit 800 Mitarbeitern), jedoch kann nicht geleugnet werden, dass mit zunehmender Projektgröße auch der Kommunikations- und Dokumentationsbedarf zunimmt. Somit geht unweigerlich ein großer Teil der gewünschten Agilität verloren, folglich eignen sich hierfür plangetriebene Methoden besser.

Kritikpunkt 4: Agile Projekte bringen mehr Risiken mit sich
Agile Projekte können ein mehr an Risiko mit sich bringen: Systeme können durch die Forderung nach Einfachheit eine zu einfache, später nur noch mit erheblichem Aufwand erweiterbare Architektur erhalten. Bei Wechsel eines Mitarbeiters geht undokumentiertes Wissen verloren. Solche Punkte und weitere müssen im Risikomanagement agiler Projekte unbedingt beachtet werden und sofern möglich gegengesteuert werden.

Kritikpunkt 5: Die Einführung agiler Methoden ist mir einem erheblichen Aufwand verbunden
Kurzum, jeder Wandel (oder “Change”) ist mit erheblichem Aufwand verbunden. Schließlich geht es nicht “nur” darum neue Hardware zu kaufen oder “nur” einen neuen Mitarbeiter einzustellen. Es geht darum an der Kultur im Unternehmen nachhaltig etwas zu ändern. Konkret bedeutet das zum Beispiel, bereichsübergreifende Teamarbeit, Kunden- und Lieferantenintegration, Schulungs- und Trainingsaufwand für die Mitarbeiter, usw.

Quelle: Seibert, S.: Das aktuelle Stichwort: Agiles Projektmanagement. Projektmanagement Aktuell, 01/2007

Agiles Projektmanagement ist ein pragmatisch und situationsangemessen auf das Wesentliche konzentriertes Management von Projekten, bei dem Kundenzufriedenheit, motivierte Teams und effektives Risikomanagement im Mittelpunkt stehen.

Quelle: Hruschka, P./Rupp, C./Starke, G.: Agility kompakt: Tipps für erfolgreiche Systementwicklung. Spektrum, 2004

Soweit so gut zur Definition des agilen Projektmanagements, aber wie soll sich das in der Praxis äußern:

• Am Anfang bzw. zum Projektstart findet keine detaillierte Projektstrukturplanung statt
• Sondern lediglich eine grobe, dem Kenntnisstand angepasste, Produktstrukturierung
• In Planungsspielen wird der Projektaufwand ebenfalls nur grob eingeschätzt
• Es werden Featurelisten und Karteikarten mit Featurebeschreibungen erstellt
• Insbesondere verteilte Teams koordinieren ihre Arbeit über Sharepoint und Wikis, anstelle über Projekt-Server
• Es gibt keine Änderungskontrollverfahren mit Änderungsanträgen und Änderungskontrollausschüssen
• Änderungen werden über vom Kunden priorisierte Featurelisten am Beginn einer Iteration eingebracht
• Risikomanagement erfolgt als Bestandteil der täglichen Teamsitzungen

Quelle: Seibert, S.: Das aktuelle Stichwort: Agiles Projektmanagement. Projektmanagement Aktuell, 01/2007

Fazit: Beim agilen Projektmanagement sind die Produktmerkmale nicht mehr die feste, sondern die anpassbare Größe. Wohingegen beim plangetriebenen Projektmanagement die Anforderungen fixiert werden und darauf basierend Kosten und Termine geschätzt werden.

UPDATE 1: Rückblick auf die Grundlagen “Einführung in die agilen Methoden der SW-Entwicklung“

UPDATE 2: Zur kritischen Würdigung “Kritische Betrachtung des agilen Projektmanagements“