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

]]> http://www.armerkater.de/2011/10/projektvermittlungsplattformen/feed/ 2 http://www.armerkater.de/2011/10/agileee2011-videos-der-keynotes-online/ http://www.armerkater.de/2011/10/agileee2011-videos-der-keynotes-online/#comments Sat, 15 Oct 2011 09:48:49 +0000 Felix http://www.armerkater.de/2011/10/agileee2011-videos-der-keynotes-online/ Continue reading →]]> Die wichtigsten Vorträge der Agile Eastern Europe 2011 werden jetzt nach und nach ins Netz gestellt. Die Videos sind alle sehr gelungen und die Präsentationen sind ebenfalls abrufbar.

Es dauerte nicht lange, bis auch darüber diskutiert wurde, ob Dinge, die keine User Stories sind, in ein Product Backlog gehören. Dies ist nicht ungewöhnlich – an der Frage, ob es technische Stories in einem Scrum Product Backlog geben darf scheiden sich bekanntlich die Geister.

Ich schaue mir das Hin- und Her jetzt mehr als 6 Jahre an und ehrlich gesagt – mich langweilt es. Die einen verkaufen den Ansatz “nur Kundenanforderungen im Backlog”, die anderen beharren darauf, dass auch technische Themen explizit im Backlog zu platzieren sind.

Die einen sagen “technische Themen müssen autmatisch miterledigt werden”, die anderen weisen darauf hin, dass dies bei vielen Themen nicht möglich ist.

Die einen leben in einer Welt, in der (fast) alles neu ist, das Team organisatorisch gut aufgestellt und technisch überdurchschnittlich gut ist, die anderen stecken im Sumpf der Mittelmäßigkeit und wissen, dass sie froh darum sein müssen, zumindest durchschnittliche Entwickler zu haben, die an einem durchschnittlich gutem Bestandprodukt arbeiten.

Sind wir einmal ehrlich: Wir alle wissen, dass gewisse technische Themen nicht einfach “mit gemacht” werden können, da dies einen mehr als spürbaren Impact auf die Lieferleistung von Kundenanforderungen hat. Und wer hat ein Interesse an der Lieferleistung? Der Product Owner und die ganzen Stakeholder. Diese müssen wissen was passiert, schon alleine, da wir sonst nicht offen kommunizieren würden, was wir gerade tun (Verstoß gegen den Wert “Offenheit”).

Refactoring vs Redesign

Ich rede jetzt nicht vom einfachen Refactoring, welches im Rahmen einer Story durchgeführt werden kann, sondern von einem Redesign, welches auf Grund der Entscheidungen einer mehrjährigen Produktentwicklung mit einem durchschnittlichen Team irgendwann nötig wird. Interessant hierbei ist auch die Definition von Refactoring und Redesign: Ich verstehe unter Refactoring Arbeit zur Verbesserung der Softwarestruktur, die nicht mehr als 1-2 Tage maximal benötigt. Bei mehr Aufwand ist es kein Refactoring mehr sondern ein Redesign.

Qualität gesetzt?

Da können jetzt alle schreien: “Hey! Nicht sauber gearbeitet! Nicht aufgepasst!”. Aber wisst ihr was? Selbst ein Kernkraftwerk fliegt in die Luft weil es nicht perfekt ist und es zu Fehlern im Detail kommt. Wie soll es da um eine 08/15 Softwarelösung stehen, die unter Kostendruck mehrere Jahre lang entwickelt wurde? Bei der fast keiner der ursprünglichen Entwickler mehr da ist?

Kunde ist nicht der einzige Stakeholder

Für mich bedeutet dies, daß man sich der Realität stellen muss. Nicht nur Kunden haben ein Interesse an den durch das Team erstellen Artefakten. Nein, es sind ganze Heerscharen an Stakeholder. Was hilft es mir beispielsweise, wenn ich Mehrwert für Kunden schaffe, aber interne Reportingvorgaben nicht erfüllen kann?

Budget gestrichen, Produkt tot, alle arbeitslos. Kunden glücklich?

Das Problem mit der USER Story

Die Frage ist natürlich, ob dies eine USER Story ist oder eine andere Art von Backlog Item. Mittlerweile bin ich immer skeptischer, was USER Stories angeht. Folgt man der grundlegenden Idee von User Stories, dann wird man in komplexen Umgebungen Probleme bekommen. Warum? Werfen wir doch einen Blick in das Buch von Frank Wirdemann: “Scrum mit User Stories”. Erst kürzlich erneut versucht zu lesen, es aber nach kurzer Zeit wegen akutem Bluthochdruck wieder zur Seite gelegt. Das Buch ist “old school”, so wie ich Scrum vor 7 Jahren verstanden haben:

• Eine User Story beschreibt keine Details sondern nur den Benutzeraspekt. Details sind böse, böse, böse!
• Spezifikation erfolgt mündlich. Schriftliche Dokumentation ist böse, böse, böse!
• Geschätzt wird in Story Points, die Dauer ist zu vernachlässigen (nicht relevant)
• Man arbeitet mit einer gemittelten Velocity, Schwankungen in der Kapazität (Urlaub etc) werden nicht berücksichtigt (übers Jahr gesehen sind wir ja beim Mittel)

Ja, ich möchte in einem Umfeld arbeiten, in dem diese Ansätze ausreichen, um erfolgreich zu sein. Ich kann jedoch nur jeden warnen, in einem komplexeren Umfeld mit mehreren Stakeholdern, externen Terminen, Budgetplanungen etc. sich komplett auf diese vereinfachte Sichtweise zu verlassen

Ich habe mehr als ein Team gesehen, das “so” in das Verderben geführt wurde. Als Product Owner bin ich dann auch meist gezwungen, harte Kämpfe durchzustehen, um eine Planbarkeit zu bekommen. Die brauche ich, um ausserhalb des Scrum Teams argumentieren zu können. Kann ich dies nicht, dann stehe ich blank da.

Ja, das ist ein Impediment. Ja, daran muss gearbeitet werden. Aber hey, es ist zu just diesem Zeitpunkt eben Realität. Und jetzt einmal unter uns: Das Ignorieren der Realität hilft nur in Ausnahmefällen.

Vorgehensweise

Hierbei hilft es eine Kernaussage (User Story) ganz bewusst in der Nähe des Implementierungshorizontes mit Details zu annotieren. Oft ist es jedoch nicht leicht, herauszufinden, wann welche Details hinzugefügt werden müssen.

Damit wird wir schnell bei einem zentralen Thema in agilen Prozessen: Wie formulieren ich Anforderungen?

Dieses Thema werde ich in einem anderen Artikel – “Lebenszyklus eines Backlog Items” (ich vermeide hier “User Story”) diskutieren.

Ach – wer sich für ein umfassendes Modell von agilen Anforderungen interessiert, dem sei ein Artikel von Dean Leffingwell empfohlen: Updated Agile Requirements Metamodel (Enterprise Backlog Model)

Anmelden via EVENT in XING.

Beginn: 05.10.2011, 20:00
Ort: Restaurant Großer Kurfürst, Sophienstrasse 80, 76135 Karlsruhe

Thema dieses Mal: WorldCafé zum Thema “Unser Product Backlog”.
“Wir erleben täglich Fragen nach Backlogtools, Granularität, Ausrichtung auf PO oder eher auf Teambedürfnisse,… ”

Wichtig: Wer etwas essen möchte, sollte spätestens 19:30 Uhr im Restaurant sein, da für das WorldCafe die Tische gebraucht werden.

Nun, dies ist nicht ganz richtig.

2003 – ERSTE SIG IN KARLSRUHE ZUM THEMA “AGILE”

Bereits ab 2002 waren Themen rund um Agilität (und hier besonders XP) etwas, was meine Interesse wecken konnte. Mitte 2003 habe ich schließlich mit ein paar weiteren “Early Adopters” (u.a. Ilja Preuss, Malte Finsterwalder, Johanness Link, …) eine Special Interest Group in Karlsruhe gegründet: “Methoden der agilen Softwareentwicklung” (KAgile).

Diese Karlsruher Gruppe war eine Zeit lang recht aktiv, es gab einige sehr interessante Treffen zu den unterschiedlichsten Themen rund um “Agile”. Ende 2005 ging aus verschiedenen Gründen die Aktivität zurück und mittlerweile wurde die Gruppe de facto durch die viel später gegründete “SCRUM User Group Karlsruhe” abgelöst.

Als “KAgile” gegründet wurde, war ich noch als Entwickler in einem Portalprojekt (Java Enterprise, Spring, Lucene – ja das konnte ich mal richtig gut) tätig, in dem wir auf eigene Faust (Bottom Up) im Laufe der Jahre 2003 und 2004 zunehmend agile Organisationsmethoden eingesetzt und somit mehr oder weniger das operative IT Projektmanagement übernommen haben. Leider ist es uns nicht gelungen auch die agile Entwicklungsmethoden so konsequent umzusetzen, wie wir uns das vorgenommen hatten. Im Nachhinein etwas, was ich sehr bedaure, da ich später nie mehr so intensiv Software entwickeln konnte wie bis 2005.

AGILISIERUNG

Anfangs 2004 hatte ich den sehr zielführenden Einfall meinen Abteilungsleiter zu überzeugen, dass wir an einer Einführungsveranstaltung zu SCRUM teilnehmen sollten, die zu dieser Zeit durch die Andrena Objects in Zusammenarbeit mit Joseph Pelrine angeboten wurde. Die entscheidenden Kriterien damals waren: GÜNSTIG! KURZ!. Damit war es viel einfacher, “das Management” von dieser Investition zu überzeugen als bei einem Zertifizierungskurs. Die Strategie ging auf – nach dem Seminar wurden unsere Ideen endlich ernst genommen und wir konnten sie zunehmend konsequent in unserem Projekt einsetzen.

Im Nachhinein wurde dieses Projekt von meinem damaligen Abteilungsleiter als eines der bestgeführten Projekte seiner Laufbahn bezeichnet. Transparentes, inkrementelles, iteratives Vorgehen sowie die grundlegenden Werte der agilen Philosophie. Ein schönes und positives Feedback!

Auch meine weiteren beruflichen Stationen waren geprägt von “Agile” und im Speziellen von “SCRUM”. Ich konnte dabei mitwirken agile Methoden einzuführen, sehen wie erste Erfolge gefeiert wurden und wie immer mehr Kollegen die Vorteile eines agilen Vorgehen erkannten. Ich habe aber auch immer wieder erlebt, wie Wunschdenken (auch und gerade bei den neu agilisierten Kollegen/Vorgesetzten) positive Ansätze verwässert und ad absurdum geführt haben. Seit jener Zeit reagiere ich recht empfindlich auf Wunschdenken / “Wishful Thinking”. Der Weg zur Hölle ist gepflastert mit guten Vorsätzen. Ja, das ist wohl wahr.

Auch ist es interessant zu sehen, wie die gleichen Fehler immer wieder gemacht werden. Egal, ob in “Wasserfall” oder in “Agile” verpackt. Jeder neu zertifizierte SCRUM Master (oder neu zertifizierte Projektleiter) erfindet vieles neu, ignoriert gerne den Status Quo und überschätzt im Allgemeinen seinen Einfluss. Schön, wenn ein etwas erfahrener Kollege diesen Willen zur Veränderung auf Themen lenken kann, die konkret angegangen werden können. Strategie der kleinen Schritte – und zusammen mit wirklich erfahrenen Experten dann der große Sprung! Aber man kann das natürlich auch ignorieren und das eigene Team/Projekt schön an die Wand fahren lassen. Für was sind Wände denn sonst da?

Seit 2010 bzw. 2011 (Vollzeit) bin ich als Berater für agile Organisationsformen tätig. Hierbei helfe ich gerne als Sparringspartner das ALTE aber auch das NEUE in Frage zu stellen, um dann gemeinsam gute Lösungswege zu erarbeiten. Eine Aufgabe, die mir viel Spaß macht, da ich meine langjährige Erfahrung einbringen kann, wovon wiederum meine Kunden profitieren.

STATE OF AGILE

Mittlerweile sind agile Methoden weit verbreitet und de facto Standard in der Softwareentwicklung. Allerdings gibt es auch häufiger warnende Stimmen vor einer Verwässerung bzw. vor dem “2. Graben” zwischen Early und Late Majority.

ES GIBT ETWAS ZU FEIERN …

Nun, ich werde 2012 wohl mein persönliches Jubiläum “Zehn Jahre Agile” feiern. Um herauszufinden, wann genau, muss ich wohl noch etwas E-Mail-Archäologie betreiben.

… UND IHR?

Wisst ihr noch, wann ihr AGILISIERT wurdet? Welche Erfahrungen habt ihr auch eurem Weg der “Agilisierung” gemacht? Welche Erfolge und Rückschläge erlebt?

Über ein paar Kommentare würde ich mich freuen!

On Saturday I gave a short lightening talk about “Definition of READY”. I didn’t like my performance on the stage but I got some positive feedback from Oleksiy Rezchykov in his blog post where he recommends my lightening  talk.

Another article with positive feedback for my Lightening Talk can be found at ConfRadar:

Felix Russel did a good job reminding about the “definition of ready” and the time each product owner should spend on preparing stories before the team can actually swarm around them. It was one of the lighting talks during the second day, that I attended.

The slides are available via Slideshare:

Rein kommerzielle Schulungen sollten nicht aufgenommen werden, die Präferenz liegt auf offenen Veranstaltungen. Besonders interessant sind sicherlich die regionalen Termine (Treffen Scrum User Group etc.).

Natürlich könnte man mit etwas Aufwand richtig viel daraus machen: Datenbasis, zu filtern nach Themen, Region und Zeitraum. Anzeige auf Karte mit Einzugsgebiet. Bewertungen (“lohnt es sich dort hin zu gehen?!”) wären auch interessant.

Aktuell steckt ein einfacher Google-Kalender dahinter. Naja, besser als nichts ;-).

Fehlen Termine? Einfach eine Mail an “events” auf der Domain “armerkater.de“.

I will give a short version of my presentation about "Definition of READY". For more information see the list of lightening talks.

See you in Kiev @ Agile Easter Europe 2011!