Gunter Dueck gibt interessante Anregungen, nicht nur weil er quasi einer von uns Tekkis bzw. ehemaligen Tekkis ist, sondern weil er auch über die weitergehenden Fragen nachdenkt und reflektiert. Im globalen Wirtschaftsgeschehen, das durchaus auch von unseren Alltagsentscheidungen etwa in Projekten beeinflußt werden kann, ist es eine Hilfe, jemanden zu haben, der auch philosophisch darüber nachdenkt, was ein nächster sinnvoller Schritt in unser aller Weiterentwicklung bzw. jener unserer Gesellschaft sein kann.

Hier also mal wieder eines seiner Werkzeuge zum Verständnis von “So geht Innovation”. Er erklärt uns etwas über normale Menschen und warum er mit seiner Prognose Recht behalten wird:

Buch Das Neue und seine Feinde: Wie Ideen verhindert werden und wie sie sich trotzdem durchsetzen

Die Beispiele zur Entwicklung der Digital-Kamera bzw. des eBooks erinnern mich an einen Moment aus meiner beruflichen Vergangenheit. Als ich 2000 zu Sun gewechselt bin wegen Java, sagte ich meinen alten Kollegen, daß Delphi tot sei. Ähnlich wie im Video wurde ich für einen Spinner gehalten. Auch bei mir war es nur eine logische Konsequenz diese Entwicklung abzuleiten. Ich vermisse bis heute die Möglichkeiten, die Delphi als IDE geboten hat. Aber es war klar, daß Object Pascal nach Borland-Art keine Zukunft mehr hatte. Bei mir hat es 5 Jahre gedauert, bis mir die Marktentwicklung Recht gab .

Stellt sich die Frage, ob dies auch in 5 Jahren für agiles Projekt-Management gilt. Da diese disruptive Veränderung ganze Industriezweige durcheinander würfeln könnte und emense Widerstände zu erwarten sind, muß ich vielleicht sogar 10 Jahre warten. Aber wie bei meinem Delphi-Beispiel ist absehbar, daß Unternehmen, die davon heute noch nichts wissen wollen, dann dazu gezwungen sein werden zu wechseln. Mindestens der Kostenfaktor wird sie dazu bewegen. Evtl. auch die nicht erreichbare Qualität oder gar die Verfügbarkeit von Mitarbeitern. Reinhard K. Sprenger z.B. hält die Verfügbarkeit von Mitarbeitern in seinem neuen Werk “Radikal führen” für den eigentlichen Konkurrenzmarkt der Zukunft. Ein erster Hinweis: schon heute werden agile Unternehmen bei Tekkis bevorzugt. Jedenfalls werden in Zukunft einige Unternehmen feststellen müssen, daß sie die Wichtigkeit ihrer Mitarbeiter auch im realen Projektalltag hätten leben sollen und nicht nur im Hochglanzprospekt für Kunden und Bewerber .

Buch Radikal führen

So what about the license? Is it allowed to use? It is not prohibited to use this license (sic!), but it is not recommended. Adobe tells us that this is a special offer of former CS2 and Acrobat 7 users after the support has stopped. For me this looks like you will get into trouble if you use it in a commercial environment. So currently it is only useful to install this release if you want to have a look at it for private purposes.

It is worth to have a look at it. You will get access to the full-blown Photoshop and Premiere Pro – and it looks like that both offer still much more useful functionality than the current Photoshop Elements and Premiere Elements licenses. There are other interesting applications: Acrobat Pro/3D, GoLive, After Effects, Audition, InCopy, InDesign and Illustrator.

Installation on Windows 8

There is no support for Windows versions later than Windows XP. But with the compatibility modus of Windows 8 we get everything to work.

Download

If you have a look at the download page of Adobe CS2 you only need these downloads to get a full-blown CS2 (there is no fully integrated installer for all applications):

• Creative Suite 2 (comes with Photoshop, ImageReady, InDesign, Illustrator, Bridge, Version Cue) 
• Acrobat 3D 1.0 Windows (includes the Pro version)
• After Effects
• Audition 3.0
• GoLive CS2
• InCopy CS2
• Adobe Premiere Pro 2.0

Installation

It is a good idea to follow the list above when you install CS2. It corresponds to the table you will find on the download page that also lists the license keys. Keep in mind that Adobe delivers different license keys for the Mac and Windows installers when you copy one from the table.

Have a look at the installation details in “CS2_install_Win.pdf”, first. We only have a look at the problems here that occur trying to install Adobe CS2 on Windows 8.

So we start with “Creative Suite 2″. There is a numbered bunch of installer files that represent the installer CDs. We need to extract those in a common installation folder. This is a bit tricky if you start “CS2_RetNon_xxx_1.exe”. It will start the “inside” setup file right after the extraction. But this will not work because the other archives are not extracted automatically. So if you get an error message when the setup tries to install the second CD you have to extract the ”CS2_RetNon_xxx_2.exe” and “CS2_RetNon_xxx_3.exe” right into the already existing installation folder (that you can define yourself at the beginning of the installation process).

Don’t forget to activate the compatibility modus of ”CS2_RetNon_xxx_1.exe” so that it runs in Windows XP mode and start the installer as administrator. And also use a folder name that has no special characters in it, e.g. “C:\Adobe”. The 32bit application folder “C:\Program Files (x86)” does not work. I found a hint that you can use “C:\Program~2\” instead, but I did not try it out.

There is something special with the licensing of the Creative Suite 2. In the corresponding dialog you are asked for the name, company and the license key. Although the company field is not defined as required it is a good idea to set it. I had to reinstall after I understood why the most applications showed a license key error dialog and stopped immediately. Don’t forget to set the compatiblity modus of “Bridge” to Windows XP. If you forget it you will get an error “missing libagluc28.dll – reinstall again” when starting Bridge. If you start InDesign and select from the templates you also get a dll error. So it is a good idea to change it to the Windows XP compatibility mode, too. You may have to do it with all installed application in the end – I had no time left to test all this in detail.

The single application installers from the list above work like expected.

Zur Aktivierung der hier präsentierten SlidePresenter Präsentation wird JavaScript und die neueste Version des Adobe Flash Players benötigt. Falls JavaScript in Ihrem Browser deaktiviert ist, aktivieren Sie es bitte jetzt. Andernfalls laden Sie die neueste Version des kostenlosen Adobe Flash Players herunter.

Einige Gedanken von Stefan Hagen in Bezug auf Projektmanagement:

Auch interessant:

Komfortzone Zukunft oder Wider die Gewöhnung: “Ab und zu muß der Schizoide mal einen stolzen Beitrag bei Google+ leisten. Die Depressiven sind mehr bei Facebook.”

Über Tetrisspielen zum Urgrund des Managements: “Kurz oder Klappe!”

Noch mal Professionelle Intelligenz für Studenten:

Wir betrachten hier nur das Vorgehen, wie man dieses Ziel erreichen kann. Ob es sich wirklich lohnt bzgl. der angestrebten Kostenersparnis Teams zu verteilen sei mal dahingestellt. Hier spielen Skills, kulturelle und soziale Aspekte stets eine wichtige Rolle und diese bringen auch immer zusätzliche Herausforderungen mit sich.

Damit die Kommunikation in derart verteilten Teams funktioniert, müssen sich die Teammitglieder persönlich kennen. Dies funktioniert nur, wenn sie sich bereits aus der Vergangenheit kennen, beispielsweise durch Zusammenarbeit in anderen Projekten oder auch private Kontakte, oder aber im laufenden Projekt die Möglichkeit bekommen, sich persönlich von Angesicht-zu-Angesicht kennenzulernen. Gerade in den ersten Sprints sollten die Teammitglieder tatsächlich an einem Ort zusammenarbeiten, um eine entsprechende Vertrauensbasis aufbauen zu können. Team-Events können diese Entwicklung positiv unterstützen.

Soweit diese Grundlagen gelegt sind, können die Teammitglieder über bestimmte Zeiträume voneinander getrennt arbeiten. Allerdings sollten diese Zeiträume nicht zu lang sein. Ganz auf den Kontakt von Angesicht-zu-Angesicht kann nicht verzichtet werden. Die Retrospektiven sind ein guter Indikator in den Teams, wie lang diese Zeiträume maximal sein dürfen.

Für die Zusammenarbeit über Entfernungen hinweg braucht es eine spezielle Infrastruktur. Dies gilt übrigens auch für Teammitglieder, die ab und an im HomeOffice arbeiten. Grundsätzlich sollte die Teilnahme für alle Scrum Meetings verbindlich sein, ob nun vor Ort tätig (also dort wo z.B. der Hauptteil des Teams arbeitet) oder entfernt tätig.

Da es uns die Technik relativ einfach macht, weltweit und ortsunabhängig per Video zu kommunizieren, sollte diese Möglichkeit grundsätzlich genutzt werden. Mimik, Gestik und andere Aspekte der Körpersprache sind wichtig für eine gute Kommunikation. Wer Videokonferenzräume regelmäßig nutzen kann, ist natürlich fein raus. Aber auch hochauflösende Webcams erlauben heute bereits, die Karten an Taskboards zu lesen. Die Audioübertragung steht dabei in entsprechend guter Qualität zur Verfügung.

Soweit das Team sich um eine solche Webcam herum aufstellt, reicht diese simple Technik aus, damit die entfernten Teammitglieder alles mitbekommen. Hier ist besonders die Aufnahme des Audiosignals durch die Webcam entscheidend. Es ist zudem hilfreich, wenn beide Seiten einen großen PC-Monitor zur Volldarstellung der anderen Seite verwenden, damit wichtige Details der Kommunikation nicht verloren gehen. Der Scrum Master kann so z.B. auch für die entfernten Teammitglieder Befindlichkeiten wahrnehmen, die bei einem Telefonkonferenzsystem nicht so offensichtlich wären.

Soweit auch Teammitglieder hinter einer Webcam agieren, beispielsweise bei Vorträgen mit Zuschauerfragen, sollten Funkmikrofone eingesetzt werden (ähnlich der Publikumsdiskussionen im Fernsehen). Ansonsten bleibt nur, die Fragen des Publikums vom Vortragenden wiederholen zu lassen, bevor dieser eine Antwort formuliert.

Wenn die oben erwähnten PC-Monitore das Audiosignal der anderen Seite wiedergeben und diese mit zu kleinen Lautsprechern ausgestattet sind, oder die Lautsprecher das Signal nicht optimal im Raum verteilen können, bieten sich separate Lautsprecherboxen an, die so aufgestellt werden, daß sie das Signal in verschiedene Richtungen des Raums verteilen können.

Bei all der Technik bleibt natürlich weiterhin die Herausforderung bestehen, daß die Teammitglieder tatsächlich den angebotenen Kommunikationskanal nutzen. Die Leute müssen letztendlich auch miteinander reden wollen. Neben den obligatorischen Scrum Meetings kann es hilfreich sein, wenn die Video/Audio-Verbindung permanent aufrecht erhalten wird. So können beide Seiten auch die Gespräche “zwischen den Scrum Meetings” mitbekommen und deren Erkenntnisse direkt in ihre eigene Arbeit einfließen lassen. Vorausgesetzt die Bürosituation läßt dies ohne großartige Störungen für die Gegenseite zu.

Zur Einstimmung mein neues Video:

Gleich mal nachschauen bei openPM.info

Der Text:

openPM – ich bin dein größter Fan
bei offen und frei bin ich sowieso dabei
Meinungen und Idee, ich kann nicht widerstehn
die Nutzung kommerziell, das Wissen aktuell
mal intensiver Plausch, mal Wissensaustausch
vielfältige Aspekte für meine Projekte

Aus der Praxis für die Praxis
Tools aus der PM-Galaxis

Anmeldedetails

Hier das Einführungsvideo von mir:

Details auf dem openPM Blog

Zertifizierungen sind so eine Sache. In guter Absicht definiert können diese zwar die Grundlagen legen, aber nur selten kommt das dabei raus, was sich Personaler dann darunter vorstellen in Bezug auf Können. Ein gutes theoretisches Gebäude ist eine Hilfe, aber die Erfahrung ist diejenige, die es letztendlich macht.

Nun ist ja über die Zertifizierung von Scrum Mastern schon einiges geschrieben worden. Das möchte ich hier nicht wiederholen. Egal welche man nimmt, Scrum Alliance oder Scrum.org, eine Zertifizierung alleine reicht keinesfalls aus. Auch bei Scrum gelten die alten Regeln: Soziale Kompetenz ist Trumpf. Wer andere Menschen anleiten will, muß wissen was er tut.

Neben den schönen Floskeln aus den Stellenanzeigen ist Lebenserfahrung ein wesentlicher Bestandteil des Skillsets eines Scrum Masters. Er muß Erfahrung im Umgang mit verschiedensten Typen von Menschen gesammelt haben und auch mit deren Macken umgehen können. Er muß abschätzen können, welche Typen er vor sich hat und wie diese zu behandeln sind.

Kommunikationsfähigkeit wird vor allem für das Überzeugen gebraucht. Wer Scrum einführt gewinnt nur, wenn er Leute von dieser Idee überzeugen kann. Auch und gerade gegen Widerstände, die sich bei einer derartigen Veränderung erwartungsgemäß einstellen. Das braucht viel Einfühlungsvermögen bzw. Empathie.

Ebenso muß er in kürzester Zeit Beziehungsnetzwerke schmieden können, um z.B. ein Gegengewicht zu Widerständlern aufbauen zu können. Er muß sowohl auf der Ebene des Managements als auch unter Team-Mitgliedern taktieren können, um seine Sache voranbringen zu können. Dabei ist Durchhaltevermögen der Schlüssel zum Erfolg.

Scrum Master müssen die Ideen von Scrum verinnerlicht haben, um andere wirklich davon überzeugen zu können. Dazu müssen sie selbst mal in dem Dilemma gesteckt haben, das zur Entwicklung des Scrum Frameworks geführt hat. Tiefe Überzeugung läßt sich nicht anlesen, hier braucht es Lebenserfahrung.

Teams zu coachen heißt nicht nur diesen die Scrum Regeln beizubringen. Der Scrum Master muß feine Antennen für die Befindlichkeit des Teams haben, um im richtigen Moment mit den richtigen Maßnahmen einzugreifen. Er muß mit Unsicherheit ebenso umgehen können wie mit überschwänglicher Euphorie. Beide Extrema können sich in regelmäßigen Abständen ablösen und erfordern ein geschicktes Gegensteuern.

Grundsätzlich ist es hilfreich, wenn Scrum Master sich mit der Psychologie, also der Lehre vom Menschen, beschäftigt haben. Letztendlich geht es um das Verstehen menschlicher Verhaltensmuster in den jeweiligen Rollen und Lebensräumen, in denen sie sich bewegen, und der Interaktion von Individuen untereinander.

…wenn bereits gefestigte Projektstrukturen existieren und entsprechende Rollen gelebt werden. Besonders wenn die Führungsebene den Command-und-Control-Ansatz lebt, wird Scrum eine Entmachtung einleiten, gegen die eine oder mehrere Personen politisch taktieren werden. Der notwendige Energieaufwand für einen Sinneswandel ist in diesen Fällen viel zu hoch. Zudem besteht die Gefahr wichtige Know-How-Träger zu verlieren.

…wenn sich Mitglieder im Team befinden, die sich mit dem Command-und-Control-Ansatz engagiert haben. Die Idee des verantwortlichen, selbstbestimmten Arbeitens wird Verunsicherung schaffen, die entweder Ablehnung oder Gleichgültigkeit erzeugt, aber in jedem Fall die Produktivität negativ beeinflußt.

…wenn die Ressourcen fehlen, die Scrum Rollen auszufüllen. Nichts ist schlimmer, als ein Rollenmix zwischen Scrum Master, Product Owner oder Entwickler bzw. der Wegfall einer dieser Rollen. Ebenso ineffizient ist der Mix zwischen im Projekt existierenden, beibehaltenen Rollen mit den neu eingeführten von Scrum. Eine saubere Trennung dieser Rollen durch eine einzelne Person ist nicht durchzuhalten. Neben der Verwirrung für den Einzelnen wird auch das Ziel der einzelnen Rollen verwässert.

…wenn der Projektmanager seine Leitungsfunktion nicht aufgeben will. Dies macht selbstbestimmtes Arbeiten der Team-Mitglieder unmöglich und die einsetzende Demotivation lähmt schließlich alles.

…wenn der Kunde nicht zur Verfügung steht. Soweit nur eine Kommunikation via Spezifikationsdokumenten möglich ist und eine mündliche Kommunikation mit dem Kunden die Ausnahme bleibt, kann die Rolle Product Owner nicht gelebt werden. Somit können auch alle davon abhängenden Scrum-Strukturen nicht effizient arbeiten.

…wenn der Management-Support fehlt. Wenn der kurzfristige Abbruch der Einführung von Scrum wie ein Damoklesschwert über dem Projekt schwebt, weil das Management schnelle Resultate sehen will, wird sich das Projekt nicht einschwingen können. Dies ist aber die Voraussetzung für die Realisierung möglicher Effizienzsteigerungen.

Nun kann man der Idee nicht grundsätzlich allen Charme absprechen. Scrum, wenn einigermaßen aufgesetzt und vernünftig begleitet, kann etwas verbessern. Wenn das Team nicht sowieso schon völlig zermürbt dasteht, nachdem es verzweifelt versucht hat, zu retten was noch zu retten ist, besteht die Möglichkeit, durch mehr Verantwortung und eigenständiges Handeln verschüttete Effizienzpotentiale zu heben. Die vorangegangenen Erfahrungen haben meist zusammengeschweißt und die meisten Team-Mitglieder spüren immer noch ein Verlangen, die Sache voranzubringen. Wie gut, wenn jemand da ist, der Behinderungen aus dem Weg räumt, die dies bisher nicht möglich gemacht haben.

Ein guter Scrum Master, der es versteht, Impediments zu identifizieren und zu beseitigen, kann diesen Effekt verstärken. Dazu muß er allerdings besonderes Spitzengefühl an den Tag legen. Verstörte Teams, die noch immer versuchen, die Quadratur des Kreises zu erreichen, in dem sie Zeit einzusparen versuchen wo es nur geht, damit der Termin doch noch gehalten werden kann, müssen erst mal aus ihrem Dornröschenschlaf aufgeweckt werden. Die Erkenntnis, daß man zwar besser werden kann, aber die Realität nicht zu überlisten ist, ist schwer zu verdauen.

Meist haben sich unstrukturierte Vorgehensweisen eingeschlichen, die sich in der Vergangenheit einmal als Lösung für aufgetretene Problem bewährt hatten. Dieses Verhalten steht dem von Scrum meist entgegen. Unterbrechungsfreies Arbeiten muß erst einmal wieder neu erlernt werden. Die Bewertung beider Verhaltensweisen ist meist vertauscht. Aus der Situation heraus getriebenes Arbeiten wird als effizient betrachtet und die von Scrum vorgegebene Taktung als eine Art Korsett. Leider wird dabei übersehen, daß die ständigen Unterbrechungen den Arbeitsfluss derart stören, daß an effizientes Arbeiten nicht mehr gedacht werden kann.

Im Prinzip wird dieses Vorgehen tatsächlich als belastend empfunden, aber gleichzeitig als alternativlos bewertet. Alles andere wird als schlechte Lösung betrachtet. Hierbei kann es zu einem mühsamen Unterfangen für den Scrum Master werden, die “paar” Scrum Regeln zu etablieren. Ohne Management-Support ist das kaum zu erreichen.

Allerdings ist ein Commitment des Managements erst mal als vorläufig einzustufen. Man läßt Scrum in diesen Projektsituationen selten aus Überzeugung einführen. Schon eher wird den Erfolgsgeschichten Glauben geschenkt, die man über Scrum gehört und gelesen hat, und leitet für das eigene Projekt eine ebensolche Erfolgchance ab. Der Irrtum ist natürlich vorprogrammiert.

Jeder Scrum Master, der in solch einem Umfeld tätig wird, sollte zunächst dem Management klar machen, daß Scrum nicht die Lösung für die vorhandenen Probleme sein kann. Ein Projektverzug kann allenfalls gemildert, aber niemals gelöst werden. Letzendlich kann nur das Neuverhandeln mit dem Kunden die Problematik bereinigen.

Scrum kann für die Zukunft eine Verbesserung herbeiführen, so daß derartige Verzögerungen mit geringerer Wahrscheinlichkeit auftreten. Man kann allerdings nicht erwarten, daß keine Probleme mehr auftreten, solange nur die Möglichkeit besteht einen ScrumBut zu etablieren. Es ist ein langer Weg, bis das Management erkennt, daß agile Vorgehensweisen effizienter sind. Erst dann kann man versuchen Scrum vollständig umzusetzen. Aber erst einmal muß es überhaupt soweit kommen.

In Krisenprojekten bleibt kaum Zeit etwas so Grundlegendes wie den Wechsel vom klassischen zum agilen Vorgehen zu etablieren. Es ist sehr herausfordernd für den Scrum Master, in vielen Gesprächen die Vorteile von Scrum hervorzuheben und gleichzeitig in einer derart angespannten Lage die zunächst auftretende Langsamkeit zu rechtfertigen. Wenn das Management nicht die Geduld aufbringen kann, also zu schwache Nerven besitzt, dann kann dies im schlimmsten Fall zu einem vollständigen Zurückrudern führen. Das wird dem Team natürlich den Rest geben und die Motivation ist dahin.

Scrum Master sollten sich gut überlegen, wie groß die Gefahr ist, ein derartiges Ergebnis zu erzielen. Im Zweifel sollten sie die Einführung von Scrum nicht unterstützen. Es ist allemal besser, ein Team in seiner Ineffizienz zu belassen, als es seiner Motivation vollständig zu berauben.