Nächste Woche ist es soweit: Das erste D-A-CH PM Camp 2011 DACH findet vom 3.-5. November an der FH Vorarlberg in Dornbirn statt. Das Programm ist eine interessante Mischung aus geplanten Vorträgen und offenen Slots (Barcamp Style).

Eine unabhängige, offene und kollaborative Standortbestimmung jenseits des Einflusses großer PM-Organisationen ist unser Ziel. Gängige Standards sind für uns nur eine Facette des immer vielfältiger werdenden PM-Kosmos. Spannend wird es dort, wo die klassische Lehre im (scheinbaren) Gegensatz zu neuen Strömungen steht. Das PM-Camp schlägt eine Brücke zwischen (scheinbar) widerstrebenden Aspekten des gelebten Projektmanagements

Spannend wird sicherlich die Marcus Raitner (u.a.) begonnene Diskussion rund um Open-PM. Dahinter versteckt sich eine Idee, eine Alternative zu GPM und PMI zu etablieren.

Freue mich auf die Vorträge, aber ganz besonders auf die Diskussionen mit den anderen Teilnehmern!

Neuigkeiten zum PMCamp können via RSS und Twitter (PMCamp11) verfolgt werden.

Wojciech beschreibt dieses Thema natürlich am Beispiel der Projektplattform twago etwas genauer.

Wie man heutzutage ein virtuelles Team erstellt

Noch vor einem Jahrzehnt war für viele unvorstellbar die Arbeit in Projekten komplett online zu organisieren und durchzuführen. Auch damals gab es natürlich Freelancer, die auf verschiedene Weisen ihre Aufträge akquirieren und durchführen konnten. Erst die Entwicklung des Internets und die rapide Steigung der Anzahl der Internetnutzer haben jedoch den Alltag des Freelancings stark verändert. Heutzutage können freie Mitarbeiter neben den traditionellen Methoden auch verstärkt die modernen Medien, wie zum Beispiel das Internet zur Suche nach Projekten, nutzen. Die Online-Welt bietet den Freelancern viele Möglichkeiten, neue Aufträge zu finden. Den traditionellen Jobanzeigen aus den Tageszeitungen entsprechen die Online Jobbörsen. Auch gibt es verschiedene themenspezifische Foren und Business-Netzwerke wie XING und LinkedIn, in denen man neue Kontakte knüpfen und aktiv nach neuen Aufträgen suchen kann. Eine weitere  Möglichkeit bieten Projektvermittlungsplattformen wie zum Beispiel twago, elance.com oder odesk.com. Dort haben Freelancer die Chance sich auf international ausgeschriebenen Projekten zu bewerben und den Auftraggeber von sich zu überzeugen.

Was soll jedoch der Auftraggeber machen, wenn man für ein komplexes Projekt verantwortlich ist und verschiedene Spezialisten braucht?

Diesen Fall möchte ich an einem Beispiel erläutern: Ein Unternehmen (weiter ein Kunde) braucht eine moderne Internetseite. Um diese zu realisieren, benötigt der Auftraggeber einen PHP-Programmierer (Beispiel: PHP Programmierer bei twago ) oder auch Programmierer und Graphikdesigner.

Um ein solches Projekt auszuschreiben, kann sich der Kunde auf Projektplattformen registrieren. Nachdem das Projekt genau beschrieben und die eigenen Wünsche erklärt sind, bekommen alle auf der Plattform registrierten Freelancer, die in der Beschreibung geforderte Fähigkeiten in ihren Profilen angegeben haben, eine Benachrichtigung. Die Fachspezialisten aus den gewünschten Bereichen setzen sich mit dem Kunden in Verbindung und klären die noch unklaren Details und Erwartungen des Auftraggebers.

Twago im Vergleich mit US amerikanischen Portalen

Im Gegensatz zu amerikanischen Portalen richtet sich twago eindeutig an den europäischen Markt. Auf twago schreiben hauptsächlich Kunden aus Deutschland (derzeitiger Kernmarkt), Italien und Spanien Projekte aus. Dienstleister kommen ebenfalls aus diesen Ländern, aber auch zu einem großen Teil aus aller Welt. Kunden können dementsprechend entweder Dienstleister in ihrem direkten Umfeld/Stadt bzw. in ihrem Land oder aus anderen Ländern auswählen und die entsprechenden Vorteile nutzen (lokale Nähe und gleiche Sprache vs. größere Dienstleisterauswahl und Kostenvorteile).  Mit safePay bietet twago zudem als einzige europäische Plattform einen sicheren Treuhand-Bezahlservice an. Vor Projektbeginn zahlt der Auftraggeber dabei den Betrag ein. Der Dienstleister weiß dann, dass seine Bezahlung gesicher ist. Keiner der beiden hat jedoch während des Projekts Zugriff auf das Geld. Erst nach erfolgreichem Abschluss gibt der Kunde die Bezahlung frei und der Dienstleister erhält den vereinbarten Betrag.

Vorteile einer Projektvermittlungsplattform

Eine solche Zusammenarbeit ist sehr bequem, sowohl für den Auftraggeber, als auch für die Freelancer, der sich auf diese Weise einen internationalen Kundenstamm aufbauen kann. Der Kunde kann zwischen vielen Spezialisten einen für sein Projekt auswählen. Die Dienstleister haben die Möglichkeit, mit mehreren Auftraggebern, in Kontakt zu treten. Und das ohne zunächst selbst aktiv akquirieren zu müssen, da die Benachrichtigung über ein neues Projekt automatisch verschickt wird. Als Dienstleister muss man jetzt nicht mehr stundenlang nach neuen Aufträgen suchen, sondern nur auf eine Benachrichtigung warten.

Die Projektvermittlungsplattformen werden immer populärer, weil sie ihren Kunden Kontakte mit Spezialisten aus der  ganzen Welt ermöglichen. Die Freelancer können von zu Hause weltweit arbeiten. Zum Beispiel kann ein deutscher Programmierer (Beispiele für deutsche Programmierer bei twago) zusammen mit einem chinesischen Graphikdesigner und einem australischen PHP-Programmierer für einen Kunden aus den USA arbeiten. Noch vor 10 Jahren war das nicht ohne weiteres möglich und heute gehört solch ein virtuelles Team für viele schon zum Alltag.

Wojciech Dziedzic von twago

Hierbei bezieht er sich zu großen Teilen auf Thesen zur “positiven Aggressivität” von Prof. Jens Weidner, der diese in seinem Buch “Die Peperoni Strategie” zusammengefasst hat. Die Ansätze werden mittlerweile bei Management-Trainings genutzt, um Führungskräfte darauf vorzubereiten mit fremder Aggression besser zurecht zu kommen und die eigene Aggression gewinnbringend einzusetzen.

Er erzählte von vielen hochqualifizierten Führungskräften, die stagnieren, weil sie in Deckung gingen, sobald es Gegenwind gab.

– Verlieren ist erlaubt, nicht kämpfen verboten

Ein Projektleiter  ist nicht erfolgreich durch unausgegorene Kompromisse sondern dadurch, den eigenen Standpunkt klar zu machen und zu verteidigen. Widersacher, die die eigene Person, das eigene Projekt oder die eigene Organisation angreifen müssen auch einmal bewusst und überlegt attackiert werden, um so möglichen Schaden abzuwenden.

Ein Projektleiter kann nicht einfach nur “nett” sein. Es gehören auch Bissigkeit und Schärfe (“… etwas so, wie man eine feurige Peperoni nutzt, um aus einem faden Einheitsbreis ein köstliches Chili zu zaubern …”).

Ein Projektleiter muss sich Fragen stellen wie: “Woher droht mir potentieller Ärger?”, “Welche Rolle weisen mir die anderen im Team zu (bin ich vielleicht der Sündenbock?)?”, um dann entsprechend handeln zu können.

Mario Neumann weist mehrmals darauf hin, dass die diskutierten Fähigkeiten wie “eigenen Wissensvorsprung nutzen, Gegner ins Leere laufen zu lassen und Distanz mit einem Hauch Arroganz” nicht sonderlich sympathisch klingen, aber zwingend notwendig sind, um Projekte zu Ende zu bringen.

Kurz: Projektleiter sind keine Schäfchen, sondern müssen auch Biss haben.

Verhaltensregeln

Im zweiten Teil des Podcasts stellt die acht Verhaltensregeln von Prof. Jens Weidner für positiv aggressive Menschen kurz vor:

1. Positives Ziel definieren
1. eigene gute Ziele als Grundlage für das Handel – auch für unangenehme Themen
2. Aussichtslose Kraftproben unterlassen
1. Gewinnchancen prüfen und nur wenn Chancen überwiegen agieren
3. Klar Stellung beziehen
1. nicht warten, bis nach der Meinung gefragt wird
2. Mut zu haben, ungefragt Meinung zu sagen
4. Nörgler, Loser, Bedenkenträger meiden
1. Eindruck der Solidarität mit ewig Jammernden vermeiden
5. Nehmerqualitäten pflegen
1. kühlen Kopf bewahren
6. Abwehrrhetorik perfektionieren
1. verbale Angriffe meist sehr unerwartet
2. vorbeugend rhetorische Redewendungen üben, um sich Zeit zum Nachdenken zu verschaffen (” … das ist ja sehr interessant was Sie da sagen, ich denk’ darüber nach …”)
7. Sofort auf negative Gerüchte reagieren
1. Gerüchte schwächen jede Position, auch wenn unwahr
8. Gegenspieler regelmäßig analysieren
1. Wissen, wer faktisch gegen das Projekt ist oder es in Frage stellt

POSITIV aggressiv

Schlussendlich beton Mario Neumann, dass positiv aggressive Menschen, sehr wohl stets das Gemeinwohl im Auge haben, eine Win-Win-Situation anstreben und auf die Einhaltung moralischer Werte und  Fairness achten.

Trotzdem sind diese Ansätze nicht für alle leicht verdaulich. Eine entsprechende Diskussion hat in XING bereits begonnen.

Probleme mit den Teams

In seinem Artikel bezieht er sich hauptsächlich auf das teilweise angespannte Verhältnis zwischen Projektleiter und Team. So führt er auf, dass in technisch geprägten Unternehmen häufig PLs ohne technischen Hintergrund einen schweren Stand haben oder dass Teams durch das Zurückhalten von Informationen einen Projektleiter auflaufen lassen können.

Ich stimme dem zu, habe dies teilweise auch schon erlebt. Als (früher) angestellter Projektleiter habe ich jedoch stets das Spannungsverhältnis Projektverantwortlicher <-> Linienverantwortlicher wie es in Matrixorganisationen existiert als am problematischsten empfunden. Im Vergleich dazu sind die Probleme mit Teams oder Teammitgliedern relativ einfach in den Griff zu bekommen, zumindest wenn man die gleiche Sprache (Business/IT) spricht und die grob die selben Ziele teilt. Ein gutes Team identifiziert sich weitgehend mit seiner Arbeit – bei Managern ist dies nicht immer der Fall. Viele Politiker unter den Managern verfolgen ganz eigene Pläne.

Warum ist die Rolle des Projektleiters so problematisch?

Als Projektleiter nimmt man eine Rolle ein, die sehr konfliktbehaftet ist. Wir müssen um Budget, Scope, Ressourcen, Managementattention kämpfen. Wir müssen frühzeitig auf Risiken und nicht mehr einhaltbare Ziele hinweisen. Wir müssen durch Transparenz eine Entscheidungsgrundlage für das Top-Management erzeugen. Das alles in einem Umfeld, welches immer komplexer wird und sich immer schneller verändert.

Ein guter Projektleiter sagt nicht Schönwetter voraus, nur weil es dem Abteilungsleiter dann in den Plan passt. Das widerstrebt der Linienhierarchie häufig, vgl. auch “Watermelon Reporting” (Marc Löffler).

Ein Projektleiter macht sich also relativ schnell unbeliebt, da er stört und von Risiken redet. Hat der Projektleiter nun kein Rückendeckung durch seine Vorgesetzten und hat die Organisation nicht erkannt, dass Projektmanagement wichtig ist, dann erleidet er über kurz oder lang Schiffbruch.

Ein Projektleiter ist unbequemer Zeitgenosse!

Denn gerade wenn eine Organisation nicht optimal aufgestellt ist und funktioniert wird ein Projektleiter häufig unbequeme Wahrheiten ansprechen. Das kann nicht im Sinne etablierter Linienführungskräfte sein, v.a. wenn Sie mitverantwortlich für die Gemengelage sind.

Der Projektleiter ist schuld!

Aus Sicht der Linie ist es einfach: Geht ein schwachsinniger Plan eines Linienkapitäns nicht auf, dann sind die Projektleiter schuld.

Ist der Entwicklungsleiter nicht in der Lage eine vernünftige Ressourcenplanung zu erstellen sondern verspricht immer mehr als er halten kann – dann sind die Projektleiter schuld. Mein beliebtester Spruch hier: “Dann soll der Projektleiter das programmieren / konfigurieren / installieren / machen …”. Man langweilt sich ja sonst als PL, gell?

Berücksichtigt der Vertrieb gegen Rat des Projektleiters die Risiken nicht in einem Angebot und diese treten dann ein – natürlich das Pech des Projektleiters (“Ja, mach mal ..”).

Das Unternehmen frisst seine Projektleiter …

Hinzu kommen dann meistens noch Rahmenbedingungen/Faktoren, die sich oft aus der Unternehmenskultur oder der Unternehmenshistorie ergeben:

• Führungskräfte in der Linie werde mehr geschult und gefördert als Führungskräfte in Projektorganisationen (ich habe noch nie das Gegenteil erlebt). Häufig laufen Projektleiter in der Kategorie der normalen Mitarbeiter und erhalten weniger Schulungen als Abteilungsleiter mit 3 Personen in der Abteilung (diese sind ja “Führungskräfte”). Coaching? Nein, der Karl kann das Millionenprojekt doch schön alleine in den Sand setzen …
• Projektleiter werden in vielen kleineren Unternehmen ohne Karrieremodell im Projektmanagement nur schlecht oder mittelmäßig bezahlt. Schließlich kann jeder den Job machen?! Die Arbeitsbelastung, Verantwortung und das benötigte Skillset wird nicht wertgeschätzt.
• Management hat keine Ahnung von Projektmanagement bzw. assoziiert die “hands on” Methode damit. Alles was Prozesskosten verursacht wird abgelehnt und es wird nur den Linienführungskräften vertraut. Diese wiederum halten sich nicht an gemacht Zusagen – schließlich genießen Sie die Rückendeckung des Top-Managements.
• Management verwechselt Berater mit Projektmanager. Gerne gesehen in Unternehmen mit Ingenieurbüro-Charakter.
• Management übergeht Projektleiter sobald nicht mehr “Schönwetter!” gemeldet wird. Schließlich war doch gerade noch alles ok. Der Projektleiter verliert seinen letzten Einfluss und wird nur noch verwaltend tätig … und später als Prügelknabe (weil der Vorstand/Geschäftsführer/Bereichsleiter kann es ja nicht gewesen sein …).
• Jeder darf mal Projektleiter spielen. Jeder Entwickler oder Vertriebler, der mal schnell etwas organisiert, wird mit Vollzeit-PLs gleichgesetzt. Auf eine ordentliche Ausbildung wird verzichtet, Standards (soweit im Unternehmen etabliert) werden ignoriert.

Eigentlich alles No-Go-Themen, die verhindert, dass Projektmanagement erfolgreich durchgeführt werden kann. Solche Unternehmen verlassen sich dann gerne auf Helden, denn die guten Projektleiter haben ihrerseits bereits das Unternehmen verlassen.

Arroganz als Selbstschutz?

Im Umkehrschluss wird natürlich auch ein Schuh daraus: Durch die schlechten Erfahrungen und die aufreibenden Kämpfe um Einfluss hat sich so mancher alter PL-Hase in einen arroganten Besserwisser verwandelt. Er nimmt die Teams nicht mehr mit sondern ordnet an. Schließlich hat er sich die Macht anordnen zu können in vielen Auseinandersetzungen erkämpft.

Was tun?

Sollten Projekte für ein Unternehmen von großer Bedeutung sein, so muss das Thema Projektmanagement professionalisiert werden. Eine schwierige Situation von Projektleitern im Unternehmen muss thematisiert und die spezifischen Gründe analysiert werden.

Projektmanagement sollte auch keine einfache Station auf der Karriereleiter sein, nach dem Motto: Guter Entwickler wird Projektleiter und wenn es klappt Abteilungsleiter. Dies verhindert die Professionalisierung des Projektmanagements, da alle daran arbeiten in die Linie zurück zu wechseln.

Der PL-Verantwortliche muss diesen Punkt ganz oben auf seine Prioritätenliste setzen und auch gegen alle Widerstände verteidigen. Als Chef der PLs wird er dadurch natürlich massiv unter Druck geraten. Dies muss er aushalten und alles dafür tun, dass seinen Mitarbeitern der Rücken gestärkt wird. Nur so können diese – und mit ihnen die Projekte des Unternehmens – Erfolg haben.

Die Projektleiter selbst müssen sich ebenfalls soweit wie möglich professionalisieren. Kämpft um Budget für Schulungen, finanziert notfalls selbst kleinere Weiterbildungen, Geht in die Community und ganz wichtig: Versorgt das Management  mit Informationen, wie wichtig professionelles Projektmanagement ist! Falls ihr es schafft, dass sich jemand aus dem Top-Management im Bereich Projektmanagement richtig schulen lässt (und sei es nur ein Tag auf einer Konferenz), dann habt ihr viel gewonnen.

Letztendlich ist es zwingend erforderlich die Rückendeckung des Top-Managements zu bekommen. Erhält man diese nicht in Taten, dann hilft wohl doch nur eines: Den eigenen Exit-Plan entwerfen, umsetzen und den verbleibenden Helden das Spielfeld überlassen.

Early this year we decided to attend the Agileee 2010 in Kiev, Ukraine after reading the positive reviews of Agileee 2009. Now – after several days in Kiev – we can tell you that this was probably one of the best conference we have attended for years. Not only good sessions but a lot of very interesting discussions with the participants during the icebreaker party and during the conference days.

Here our short summary of this fantastic conference:

Thursday – Sightseeing and Icebreaker Party

On Thursday we visited the headquarters of Ciklum – one of the largest nearshoring providers in Ukraine. We were introduced to several Scrum teams working for different clients and we were allowed to take part in a Daily Scrum via video conference (client in Denmark). Our summary to this visit is a very positive one. What we saw exceeded our expectation on agile adoption and English skills by far.

After our visit at Ciklum we decided to spend the afternoon sightseeing in Kiev.

Monastery of the Caves

We have been  told a lot about the Kiev Monastery of the Caves and so we decided to visit this world famous attraction. It’s a really impressive monastery that includes caverns – a very complex system of (very) narrow underground corridors.

You can find more information about this monastery in Wikipedia:

Kiev Pechersk Lavra (Ukrainian: Києво-Печерська лавра, Kyievo-Pechers’ka lavra), also known as the Kiev Monastery of the Caves, is a historic Orthodox Christian monastery in Kiev, Ukraine. Since its foundation as the cave monastery in 1015 the Lavra has been a preeminent center of the Eastern Orthodox Christianity in Eastern Europe.

Source: http://en.wikipedia.org/wiki/Kiev_Pechersk_Lavra

Icebreaker Party

In the evening we have been invited to the icebreaker party held in a local pub called “The Barrel”. First we were reluctant to go there as we were quite exhausted by the tourist program we had but we finally got our self moved to the party place. WHAT A FANTASTIC DECISSION! Yes, this was probably the best conference start I have been for years. This was purely relaxing. Several speakers gave spontaneous Jam sessions and it was a fantastic friendly atmosphere.

Agileee 2010 Ice-breaker from Agile Eastern Europe on Vimeo.

Guess what the German conferences are lacking? Such an icebreaker event!

Friday & Saturday: Agileee 2010 Conference

After finishing the registration and getting rid of the clothes we were welcomed with classical music played live!

Infrastructure

The conference had the usual infrastructure including WiFi– and this was a problem. As everybody was using WiFi enabled devices it was sometimes not possible to connect to the internet. The day before the conference started we bought a very cheap 3G SIM card from a local provider (available everywhere in small shops) with some free hundred megabytes of internet access – so no big problem for us.

Keynotes from Henrik Kniberg and Mary Poppendieck

The conference program started with two key notes given by Henrik and Mary. While both were interesting I liked the keynote from Henrik more as it introduces some new ways how to explain the essence of agile to people new to Scrum / XP.

Selling Agile by Paul Klipp

Selling projects done in an agile way is usually hard work as most buyers still believe a fixed price contract is best for them as all the risk is on the side of the provider. If you have been involved in calculating and setting up a project based on a fixed price contract you know that this is not true. Usually both sides have to pay for the risk and changes during the project will result in a lot of discussion and additional costs. So fixed price usually is a lose-lose setup. In his presentation Paul outlines why projects run with agile principles and based on an agile contract are better for both sides. Really liked his arguments and tips.

Management of Offshore Agile Projects

This presentation given  by Sergei Andrzeevski caused a discussion whether what he does is still “agile” or just some best practices that can be used to make distributed projects more successful. As we know that the trade off between real agile practices and compatibility to traditional established company processes always must be considered, we were happy to get some new ideas how to handle problems.

Agile Offshoring

We met Andrea Heck and Tibor Vida at the ice breaker party and had some interesting discussions with them. In their presentation they were talking about how agile methods were introduced at Siemens healthcare.

Siemens healthcare is working in a very regulated environment with audits that are necessary for markets like EU, USA, China or Brazil. Something you would expect is difficult to combine with agile processes. They explained how they started (very strict contracts with incentives, V-Modell (phase oriented process model) widely used, documents as interfaces, a lot of overhead by managers, task forces, experts, …) and how they made a successful transition to agile processes by bringing in external experts and visualizing the business processes by value stream mapping. Guess they made a really good job there!

Meeting a lot of interesting people.

Beside the official presentations I had a lot of very interesting discussions in the breaks and enjoyed several interesting open space discussion: One with Paul Klipp about “Personal Productivity”, one about "How to transform the company from outsourcing to product business?" with Nikolay Pavlov and one about “Smells in your Scrum implementation” by Radu Davidescu. Thanks guys for sharing your ideas and experience!

Another important reason for traveling to Kiev was meeting one of our oldest partners: Ainstainer Group. We finally made it to personally meet the Semenov brothers (Artem and Stanislav) and had a lot of discussions how we can help our customers to succeed using agile processes and teams located in the Ukraine.

While Ainstainer Group currently still is a quite small company you can expect to hear more from them in the future as the management is very dedicated to success, having a clear customer focus and is working in a highly professional manner.

BTW: We (Ainstainer Group & Agile-Nearshoring.com) started a “Scrum Tool Review project” for which the first review (VersionOne) is already available in the Ainstainers Blog.

Summary

Not more to add: Was a great conference, we will be there next year again!

Disclaimer: This article was initially published on the Agile-Nearshoring.com blog. As there are still only a few readers registered I decided to publish it on Armerkater.de to reach a wider audience.

Wenn es wie eine Ente watschelt, wie eine Ente quakt und wie eine Ente aussieht, kannst du es eine Giraffe nennen, aber es ist dennoch eine Ente.

Wir wissen ja: Chaos im Unternehmen ist bekanntlich Folge des bösen und generell untauglichen Wasserfallmodells. Fortschritt durch das neue Vorgehen ist hingegen wissenschaftlich belegt gemäß des Axioms “Tausend Gurus können nicht irren” sowie Beweis durch vollständige Anekdote.

Eine dieser Anekdoten geht wie folgt: Man nehme ein vorzugsweise leicht ausgebranntes Entwicklerteam, schule es ein paar Tage in angenehmer Umgebung durch einen hochmotivierten Scrumverkäufer, zelebriere einen unbelasteten Neubeginn, lasse das Team in Ruhe werkeln und messe sodann die Arbeitseffizienz. Überraschung – die Effizienz steigt! Wer hätte das gedacht? Und wer glaubt, dass ein solcher Versuch etwas nachweisen kann?

Alter Wein in neuen Schläuchen

Es lebe die neue, agile Welt, alles wird gut. Nun, mit Sicherheit wird alles für Autoren gut, denn jetzt kann man viele Bücher füllen mit Dingen, die es alle schon mal gab und jetzt neu erklärt werden müssen.

Ein kleines Wörterbuch für Traditionalisten

Miesmacher, so bin ich eben, Europäer halt: wir vermarkten nicht jeden Pups als wundervoll. Dabei mag ich Scrum. Hassen tue ich die Evangelisten, die olle Kamellen über den Klee loben und sich wundern, warum die Entscheider auf ihren Etagen immer noch so zögerlich sind.

Vertriebs-Bullshit

Ich kann es ihnen nicht verdenken, ich habe selbst genug Genglishen Bullshit gehört und gelesen in den letzten Jahren, als heilige Wahrheit deklariert:

• “Wasserfall ist total veraltet und kann gar nicht funktionieren.”, und
• “CMMI ist überholt. Und mit Scrum hat man CMMI Level 3 ohnehin schon implementiert.”, und
• “Klassische Planung ist deterministisch, deterministische Pläne sind nutzlos, nur agile Methoden können mit Änderungen umgehen.”, und
• “Up-front Requirements können nicht funktionieren. Erzählt lieber eine Geschichte anstelle Anforderungen zu schreiben.”

Was schon eher stimmt

Dabei sind die Aussagen nicht völlig verkehrt, mit etwas Mühe kann man ein paar Körner Wahrheit finden. Legen wir die rosa Brille des Verkäufers ab und differenzieren wir:

• Echte Arbeitsabläufe sind viel turbulenter als Phasenmodelle sie beschreiben; sich sklavisch an Phasen zu klammern ist daher schädlich.
• Scrum ist kompatibel mit den CMMI-Anforderungen und erfüllt viele davon adäquat. CMMI Assessoren lösen sich langsam auch von der Faustregel, im Zweifel einfach alles zu dokumentieren.
• Neuplanung ist seit jeher ein Teil der Planung; anscheinend haben das viele Planer verdrängt. Effizientes Änderungsmanagement ist aber essentiell für effiziente Projekte.
• Man muss nicht alle Anforderungen kennen, um beginnen zu können, aber je früher man klare Anforderungen festhält, desto unwahrscheinlicher werden böse Überraschungen. Um Anforderungen richtig interpretieren zu können, muss man Motivation und Zielgruppe kennen.”

Oooh, das klingt jetzt nicht mehr wirklich spektakulär, dürfte aber vorstandstauglich sein.

Bedeutung von Marketing

Aus eigener Erfahrung weiß ich: Wenn man das Marketing unterschätzt, wird Scrum für praktisch alle Probleme verantwortlich gemacht, die es gibt, inklusive der ausgegangenen Kaffeebohnen. Die wenigsten Probleme sind von dabei Scrum abhängig; schaut man genauer hin (wir haben die rosa Brille ja oben abgesetzt), kann man oft Rahmenbedingungen vorfinden, mit denen man jeden Prozess, und sei er noch so gut, hätte torpedieren können. Da werden Product Owner eingesetzt, die inhaltlich gar nicht verantwortlich waren (also keine “Schweine” im Sprachgebrauch von Scrum, wenn man mal vom Grunzen absieht), Teams mit zig parallelen Projekten überfrachtet, Wander-Stories zwischen den Sprints hin- und hergeschubst, Voraussetzungen für Stories übersehen, oder schlicht Dinge entwickelt, die keiner braucht.

Selbst wenn diese Rahmenbedingungen kommuniziert sind, bleiben Zweifel, auch bei den gutwilligsten Schlipsträgern. Scrum kommt bei ihnen nämlich nicht als sehr “agil” herüber: Wenn man die Regeln strikt handhabt,  dann könnte Vertriebsmanager McNuggets gackern wie er will – seine Abschätzung für ein Angebot bekäme er erst im nächsten Sprint. Freilich: Niemand zwingt einen, Scrum den Buchstaben nach einzuhalten. Ganz positivistisch gesehen: Wenn’s funktioniert ist’s richtig. Doch dazu ein andermal mehr.

Argumente für Führungskräfte

Wenn mich heute Entscheidungsträger zu Scrum befragen, führe ich gerne Argumente der folgenden Bauart ins Feld:

• Scrum ist ein mit geringer Investition zu etablierender Prozess: Die Schulung ist nicht aufwändig und die bestehende Infrastruktur reicht völlig aus.
• Scrum fördert das Arbeitsklima in der Entwicklung; dies verbessert die Attraktivität des Unternehmens auf dem Arbeitsmarkt.
• In Scrum ist das “Mikromanagement” Aufgabe des Entwicklerteams; der Projektleiter wird dadurch entlastet und ist dennoch sehr gut informiert.

Ich habe gute Erfahrungen mit so einer Darstellung gemacht: Budgetverantwortliche denken gerne strategisch und  wirtschaftlich, und von dort muss man sie abholen. Manchmal frage ich mich, was geschähe, wenn die Evangelisten mit solchen Argumenten bewaffnet ins Feld zögen.

Hinweis zum Autor:

Dies ist der erste (und hoffentlich nicht letzte) Artikel unseres Gastautors “Ludi”. Er arbeitet aktuell für ein mittelständisches Unternehmen im Bereich Projekt- und Qualitätsmanagement. Neben seiner Tätigkeit als Product Owner (erfolgreiche Entwicklung eines neuen Produktes) zeichnet er zudem verantwortlich für die Ausgestaltung der nun unternehmensweit geltenden PM-Richtlinien, die Ansätze aus den klassischen Phasenmodellen und den agilen Methoden miteinander verbinden.

http://securerespond.com/thoughtworks/offshorewebinar/

Ansehen lohnt sich auf jeden Fall!

Zunächst geht er auf die grundlegenden Herausforderungen bei verteilten Projekten ein: Kommunikation, Beziehungen, Vertrauen. Um diese Herausforderungen meistern zu können, müssen entsprechende organisatorische Maßnahmen ergriffen werden. Ich möchte hier jedoch einen kommentierten Auszug aus der Liste der empfohlenen Tools geben, die helfen verteilte Projekte erfolgreich durchführen zu können.

Communication Tools

Instant Messaging (IM)

IM Tools dienen zum schnellen (synchronen) Austausch von Informationen. Man sieht, wann jemand verfügbar ist und schnelle – oft informelle – Chats sind möglich. Sehr gut geeignet auch als Fallback bei Telefonkonferenzen. Ausgesprochene Empfehlung: Camp Fire.

• Anmerkung: Ich persönlich nutze gerne Google Talk, da hier keine Installation nötig ist, weil ein einfaches Web-Interface existiert. Zudem ist ein GMail-Account weit verbreitet.

Screen-Sharing

Werkzeuge für Screen-Sharing werden vor allem bei Projektmeetings eingesetzt, um die gleichen Dokumente zu sehen, darüber zu diskutieren und direkt gemeinsamt Änderungen daran vorzunehmen. Desweitere interessant für Reviews und beim Pairing über die Distanz. Ausgesprochene Empfehlung: YuuGuu.

• Anmerkung: Wir machen seit Jahren sehr gute Erfahrungen mit dem Werkzeug eines Karlsruher Herstellers: “Netviewer”. So gut wie gibt es Probleme mit Netwerkrestriktionen (Firewall).

Voice over IP / VOIP

Wichtigstes Tool bei internationalen Projekten, da es sehr einfach die (nahezu) kostenlose Kommunikation zwischen den Projektbeteiligten erlaubt. Ausgesprochene Empfehlung: Skype

• Anmerkung: Teilweise wird Skype bewusst ersetzt durch eine Lösung, in dem die VoIP nur über unternehmensinterne Infrastruktur geleitet wird und offene Protokolle zum Einsatz kommen.

Wiki & Collaboration

Informationen festhalten und austauschen. Ausgesprochene Empfehlung: MediaWiki & Confluence

• Anmerkung: Sehr gute Erfahrungen habe ich mit Confluence gemacht. Vor allem wenn Jira als Werkzeug für Issue-Tracking, bieten sich sehr interessante Integrationsmöglichkeiten. Ein Dash-Board für ein Projekt oder eine Team-Seite ist damit schnell erstellt – inkl. dynamischer Daten (Issues, Stories) aus Jira.

Issue/Task Tracking

Um Aufgaben, Fehler und Risiken verwalten und allen Teammitgliedern zugänglich zu machen wird ein Issue/Task Tracker benötigt. Ausgesprochene Empfehlung: Mingel, Jira, BaseCamp.

• Anmerkung: Ich habe sehr gute Erfahrungen mit Jira gemacht. Hierbei spielt gerade die Nutzung von zusätzlichen Issue-Attributen und Filtern eine wichtige Rolle, um z.B. Team-Backlogs zu erstellen, die sich aus mehreren Projekten zusammensetzen (Multi-Projekt-Multi-Team). Hilft, v.a. wenn die Ergebnisse dann in Excel exportiert und ausgewertet/aufbereitet werden. Greenhopper (Jira Plugin für Scrum) scheint aktuell noch auf einzelne Jira-Projekte beschränkt zu sein.

Zusammenfassung

Meiner Meinung nach sind die genannten Werkzeuge sehr wichtig, um verteilten Projekten sinnvoll koordinieren/durchführen zu können. Zusätzlich muss auch die gesamte Entwicklungsumgebung so aufgestellt sein, dass verteiltes Arbeiten möglich ist: Continuous Integration, Testabdeckungen, Standardisierung, direkt verfügbares Repository, Werkzeuge zur AUswertung von Code-Qualität – aber dies ist Inhalt eines eigenen Artikels.

(Oft habe ich mich gefragt, wer den CSMs diesen Unsinn erzählt hat… )

Wahnsinn, wie innovativ ich schon vor Jahren war ;-) – damals mit einem Kollegen (Wolfgang for president!) ein Excel-Spielzeug ähnlich wie es Jeff Sutherland jetzt promotet erstellt und dann Aussagen wie “It’s Effort, Not Complexity” von Mike Cohn.

Wirklich befriedigend, diese Bestätigung zu bekommen. Schade nur, dass wir gerade zurechtgestutzt werden, nachdem wir die Probleme transparent gemacht haben. Ist die Gegenreaktion der Linie, vgl. auch “Die dunkle Seite von Scrum”.