Jurgen Appelos Buch “Management 3.0 – Leading Agile Developers, Developing Agile Leaders” ist der legitime Nachfolger von DeMarco/Lister´s “Peopleware” (zu Deutsch: “Wien wartet auf dich“).

Appelo versucht Management-Konzepte vor dem Hintergrund agiler Software-Entwicklung und moderner Systemtheorie neu aufzurollen. Dies gelingt ihm sympatisch und kompetent. Das Buch hat sicherlich seine Macken (ich finde die Konzentration auf Software-Entwicklungsteams etwas künstlich und sein Umgang mit Fußnoten, die i.d.R. auf die eigene WebSite referenzieren ist zumindest gewöhnungsbedürftig, obwohl interessierte Leser mehr als genug (auch wissenschaftliche) Literaturhinweise finden). Alles in allem ist es aber anregend, kritisch, trotz theoretischem Fundaments praktisch orientiert und vor allem gut lesbar. Jurgen Appelo´s Pragmatismus kommt in seinem Schlusswort zum Ausdruck:

I know my book is “wrong,” but I sincerely hope you find it useful.

Aus dem bunten Konglomerat von Agiler Software Entwicklung, Systemtheorie und moderner Management Theorie leitet Jurgen sein Management 3.0 Modell mit der Comic-Figur Martie (sein Buch lebt auch von den Illustrationen), die sechs Augen hat und damit sechs unterschiedliche Sichtweisen repräsentiert, die ein agiles Management nach Jurgens Auffassung haben sollte:

• Energize People
• Empower Teams
• Align Constraints
• Develop Competence
• Grow Structure
• Improve Everything

Den ganzen Beitrag lesen…

Mit zahlreichen Fußballanalogien und -weisheiten führt uns Alexander Ockl durch ein Praxisbeispiel der Geschäftprozessgestaltung zwischen IT und Fachbereich. Er wählt dabei eine Romanform, wie man sie z.B. von DeMarco´s PM-Klassiker “Der Termin” kennt. Neben dem Praxisbeispiel zieht sich die Geschichte eines Revierderbys (Achtung, Fußball!), wie ein roter Faden durch das Buch.

Die anfängliche Projektkrise und die auftauchenden Konflikte werden seziert. Alexander Ockl führt dabei in die Welt der Business Analyse und Geschäftsprozessmodelierung ein. Es wird der Bogen gespannt von Requirements Engineering, ARIS-Modellierung bis hin zu Projektmanagement-Methoden, Qualitätsmanagement und Reifegradmodellen.

Eine gelungene Einführung, die sich angenehm leicht liest, sofern man von der Überdosis Fußball nicht abgeschreckt wird.

Und indirekt liefert Ockl auch einen interessanten Beitrag zum Thema Projekterfolg/Scheitern von Projekten: Das ursprünglich initiierte Projekt scheitert grandios. Das Buch schildert dennoch eine Success Story, denn durch die erfolgreiche Analyse werden viel tiefergehende Veränderungen angestossen, aber hier wird Ockl übertrieben optimistisch:

Es ist gar nicht selbstverständliche, dass die tatsächlichen Probleme so klar identifiziert und auch angenommen werden. Zu guter letzt macht ein Bereichsleiter auch noch Karriere und wird zusätzlich Qualitätsbeauftragter. Das ist für Ockl eine Art Ritterschlag. Der Firmenchef träumt obendrein davon Qualitätsmanagement als Führungsinstrument zu nutzen. Hier verliert mich Ockl komplett. Eine solche Welt besteht wohl vor allem im Wunschdenken von Business Process Management-Anhängern.

Alexander Ockl
Das Spiel. Brennpunkt Geschäftsprozesse – IT und Betrieb in einer Mannschaft. Projektmanagement, Business Analyse und Geschäftsprozessmanagement in der Praxis
München 2010
Addison-Wesley
ISBN 978-3827329066 

Viele englischsprachige PM-Beiträge ignoriere ich hier (weil ich sie meist nicht sonderlich innovativ finde), weiter gibt es zur Zeit so viele agile Postings, dass es schwer fällt die Spreu vom Weizen zu trennen. Ein echtes Highlight liefert jetzt Glen B. Alleman, den ich mit seinen häufig technokratischen PM-Ansichten gar nicht so sehr schätze, aber sein Vorschlag für einen Fix des agilen Manifests ist – ohne Ironie – nicht von schlechten Eltern. Er tauscht ganze vier Wörter aus und bringt mich gleich ins Grübeln. Die Thesen werden weniger moralisch und dafür präziser. UNBEDINGT LESEN!

Marcus Raitners Reihe Projektcoaching geht weiter mit 09 – Planung und 10 – Marketing.

Und auch Stefan Hagen war am Wochenende fleißig: Hier sein Konzept für die Professionalisierung von Projektmanagement in Unternehmen. Und auch Stefan beschäftigt sich mit dem Agilen Manifest. Und dann zweifelt er auch noch am PMI, aber seine Kritik lässt sich sicherlich auch auf andere Verbände übertragen.

Auf den PM-Blogs ist weiterhin das Thema Scrum sehr dominant:

• Bei SEIBERT/MEDIA macht sich Paul Herwarth Gedanken über Scrum Meetings und ihre Bedeutung.
• Nicht best practice, sondern ganz im Gegenteil. Eberhard Huber beschreibt, wie man Scrum grundsätzlich missverstehen kann: “Dann nennt es bitte nicht Scrum”.
• Robert Wiechmann von PROJEKT-LOG hat im Web den Vortrag “Agile Software-Entwicklung bei der XING AG” als Video ausgegraben.
• Last but not least zum Thema Agil/Scrum: Sebastian Schneider hat auf seiner Seite sehr umfangreich Resourcen zum Thema Scrum zusammen getragen.

Diesmal Ralf Westphal über “Agilität und Kultur” im Interview mit Patrick Fritz. wie gewohnt hier eine Zusammenfassung:

Eine entsprechende Kultur ist die Voraussetzung, damit sich Agilität in einem Unternehmen durchsetzen kann. Ralf zitiert hierzu den Management-Guru Peter Drucker:

Culture eats strategy for breakfast.

Die Kultur spiegelt sich wieder im Umgang mit Zeit, Fehlern, Fokus und Arbeitsbedingungen.

Agilität hat eigentlich nichts mit SW-Entwicklung zu tun. Ralf meint vielmehr:

It´s a way of life.

Den ganzen Beitrag lesen…

Im heutigen Beitrag widmet sich der bekannte Scrum-Autor Roman Pichler  der Rolle des Product Owners.

Bei der Einführung von agilen Projektmanagement-Methoden stellt die Rolle des Product Owners immer wieder eine Herausforderung dar und führt zu Schwierigkeiten. Die Rolle geht über das klassische Produktmanagement hinaus. Häufig besteht schon eine Schwierigkeit in der Besetzung der Rolle. Wer soll die Rolle des Product Owners übernehmen? Marketing, ein Programmierer oder gar der Kunde?

Den ganzen Beitrag lesen…

In Beitrag #435 von der Scrum-Konferenz bin ich noch die Inhalte von Jutta Ecksteins Podcast schuldig geblieben:

Die Zeiten eines Outsourcing und Offshoring in der Software-Entwicklung aus reinen Kostengründen sind aus ihrer Sicht vorbei, denn Spezifikationsaufwand, kulturelle Unterschiede und die erforderliche Kommunikation bergen erhebliche Risiken. Wer rein aus Kostengründen outsourct, wird vom Ergebnis in der Regel enttäuscht sein, so ihr Fazit.

Gründe, die auch heute dafür sprechen sind Personal-/Skill-Mangel und marktliche Anforderungen, etwa bei der Erschließung neuer Märkte oder um Kundennähe zu gewährleisten.

Die Entscheidung für verteilte Teams in der Software-Entwicklung ist in der Regel aus einer Notwendigkeit heraus geboren und keine “Liebesentscheidung”.

Den ganzen Beitrag lesen…

Heute ist Tag 4 der Konferenz und auf dem Programm steht Christoph Mathis über agile Engineering Techniken:

Scrum ist ein phantastisches PM-Framework, aber der Unterbau in Form von entsprechenden Engineering Techniken wird gerne vernachlässigt. Zu diesen Techniken zählen Continous Integration, Testgetriebene Entwicklung, permanentes Refactoring und Fair Programming.

Zur Architekturdefinition hat er ähnlich pragmatische Vorstellungen wie Stefan Roock.

Von den Entwicklungstechniken ist v.a. test-driven devlopment (TDD) einschließlich einer Refactoring Phase zur Säuberung des Codes sein Steckenpferd.

Team und Vertrauenskultur sind mit das Wichtigste. “Man muss die Leute lassen.” Reflektion (Retrospektiven/Lessons Learned) ist wichtig. Agilität ist eine Haltung. Sie braucht Voraussetzungen in der Kultur, damit es funktionieren kann.

Nicht nur Softwareentwicklung, auch andere Dinge, wie Marketing, Innovationsmanagemt oder Portfoliomanagemetn können mit Scrum erfolgreich bewältigt werden.

Last but not least gibt er vier Empfehlungen:

Ask the Team

Inspect & Adapt (aus dem ständigen Testen lernen und die SW anpassen)

Tatsächlich liefern. Nach jedem Sprint fertige SW liefern.

Die Leute als Erwachsene behandeln. Das bewirkt Wunder.

Heute geht es auf der Scrum-Konferenz weiter mit einem Podcast mit Jutta Eckstein über agile SW-Entwicklung mit verteilten Teams. Für eine inhaltliche Besprechung muss ich auf die kommenden Tage vertrösten.

Mittlerweile kommen auch die ersten Diskussionen in Gang: z.B. zum Thema Architekturdokumentation oder zu Rollenkonflikten.

Und weil es zum Thema passt: Vielleicht ist es ja eh schon bald wieder mit Scrum vorbei: Auf AgileScout findet sich aktuel ein Posting: Is Scrum is Dying? Keep Scrum Alive!

Aha, ein Hype löst den nächsten ab: Kanban statt Scrum!

Ehrlich gesagt haben mich die Moden noch nie interessiert, aber das Rollen/Kommunikationsmodell und die Vorgehensweise inkl. ihrer Umsetzung in Artefakte in Scrum finde ich trotzdem spannend.

Tag 2 mit einem Beitrag von Stefan Roock über das Spannungsfeld Architektur und Agilität:

• Was ist Architektur? – Sicherstellung von Änderungsfähigkeit (nach Tom DeMarco)
• Empfiehlt die Arbeit mit einer Architekturvision (“technischer Kumpel der Produktvision”) >> vor dem Start der Entwicklungsarbeit
• In Scrum braucht das Team Architekturwissen, ggf. Integration von Architekten in die Teams
• Ein Architekt darf nicht “hierarisch” eingebunden sein. Dies widerspricht dem agilen Manifest >> Rolle als Coach
• Untermauerung von Architekturvision mit Prototypen
• Die Architekturvision soll Änderungen unterstützen, dann müssen wir auch keine Angst vor Änderungen haben
• Die Architekturvision soll möglichst schlank sein, weil jede Vorgabe das Projekt weiter einschränkt
• Architekturaufgaben sind Sache des Teams und nicht des Product Owners
• Architektur kann ganz am Anfang mit der Entwicklung  eines “Tracer Bullet Features” ohne großen Mehwert für den Product Owner getestet werden. Dieses Vorgehen ist einem anfänglichen Architektur-Sprint vorzuziehen. Solche Architektur-Sprints produzieren häufig nur Luftnummern.
• Architektur-Vermittlung funktioniert nur in Face-to-Face-Kommunikation
• Dokumentation, wo erforderlich, möglichst aus dem System heraus (damit sie auch mit dem System übereinstimmt und der Aufwand sich in Grenzen hält)
• …