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.

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!

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!

Verbreitung der Definition of Ready

Viele Scrum Team kennen die “Definition of Done”, in der definiert wird, in welchem Zustand ein Inkrement den Sprint verlässt. Laut Jeff Sutherland wenden diese jedoch nur ca. 50% aller Teams konsequent an. Die” Definition of Ready” (Definition, in welchem Zustand eine Story den Sprint betritt) ist jedoch deutlich weniger Team bekannt. Nur ca. 1% aller Scrum Teams weltweit wenden eine Defnition von “Fertig für den Sprint” konsequent an.

Die inkonsequente Anwendung ist erstaunlich, da die Definition of Done als auch die Definition of Ready das Potential haben die Produktivität von Teams zu verdoppelt. Jeff Sutherland fasst dies unter dem Begriff “Hyperproductive Scrum Teams” zusammen. Zusammen mit einer echten Selbstorganisation, bietet die konsequente Anwendung von DONE und READY das Potential die Produktivität um den Faktor 4-8 zu erhöhen!

Stichprobe: Definition of Ready in der Community

Eine Stichprobe in der größten Scrum Mailingliste “scrumdevelopment” (Yahoo Group) bestätigt jedoch, dass gerade die Definition of Ready bei weitem nicht so bekannt ist, wie ihre Effekte nahelegen würden:

• „definition of done“: 1001
• „definition of ready“: 6
• „ready state“: 14

Was versteht man unter “READY”?

Vereinfacht ist eine Story bereit für die Implementierung, wenn die Anforderung verständlich beschrieben wurde und folgende Fragen beantwortet werden können:

Warum?

• Zielsetzung / Problemstellung klar,
• Geschäftswert verstanden

Was?

• Gewünschtes Ergebnis verstanden, Akzeptanzkriterien formuliert

Wie?

• Implementierungsstrategie/-konzept bekannt
• Kosten / Größe bekannt

Wichtig: Zuerst WARUM, dann WAS, dann WIE!

Alternative Erklärung

Roman Pichler, hat sich diesem Thema ebenfalls schon in einem Blog-Artikel zugewandt. Aus seiner Sicht muss eine Story folgende Kriterien erfüllen, um “READY” zu sein:

Klar

• Gemeinsames Verständnis was genau gemeint ist

Testbar

• Es gibt klare Entscheidungskriterien, ob etwas erfolgreich umgesetzt ist oder nicht.

Handhabbar

• Größe muss stimmen (nicht zu groß/klein)
• Komplexität muss handhabbar sein
• Unsicherheit, Abhängigkeiten

Eine teamspezifische Definition of READY listet meist detailliertere kontextbezogene Kriterien auf und dient als Quality Gate, um sicherzustellen, dass nur Stories in den Sprint übernommen werden, die wirklich bereit für die Implementierung sind.

Der Weg zu “READY”

Es ist die Aufgabe des Product Owners sicherzustellen, dass Stories bereit für die Implementierung sind, wenn er sie in einem Sprint umgesetzt bekommen soll. Hierzu arbeitet er mit allen Beteiligten eng zusammen, um von groben Ideen zu klaren – “bereiten” – Stories zu kommen. Gerade bei der technischen Analyse ist auch das Team gefragt, frühzeitig Informationen und Feedback zu liefern.

Ein Blick in das Backlog zeigt dann in etwa folgendes Bild:

Etwas genauer betrachtet, erkennt man, wie im Lebenszyklus von Anforderungen immer mehr Details hinzugefügt werden. Die Details sind meist das Ergebnis von Diskussionen und sollten – je nach Kontext – auch schriftlich festgehalten werden. Hierbei kann eine Vorlage oder eine Checkliste sehr hilfreich sein.

Eine solche Checkliste oder ein Template kann jedoch auch gefährlich sein. Wenn zu viel Augenmerk auf das Dokument und zu wenig auf die Diskussion gelegt wird, nähert man sich schnell dem alten Requirement Engineering an und verliert an Agilität.

Die Präsentation zu diesem Thema werde ich in absehbarer Zeit noch veröffentlichen.

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.

Die Agileee 2010 Konferenz findet zum zweiten Mal in Kiew  (Ukraine) statt.

Interessanterweise ist diese Konferenz bisher nahezu unbekannt in der deutschen “Agile Community”! Jeder weiß Bescheid über Konferenzen, die irgendwo auf der Welt stattfinden und viele besuchen diese auch – aber Osteuropa scheint immer noch bei vielen nicht auf  der Rechnung zu stehen!

Das ist in diesem Fall wirklich Schade – da die Agileee 2010 eine sehr hochkarätige Veranstaltung zu werden verspricht.

Ein kurzer Blick in das Konferenzprogramm zeigt, dass es eine Menge interessanter Vorträge geben wird, z.B.:

• Henrik Kniberg spricht zu “The Essence of Agile”
• Mary Poppendieck hält ihr Keynote über “It’s not about software”
• Paul Klipp greift das wichtige Thema Vertrieb von agilen Projekten auf (“Selling Agile”)
• Und dann gibt es (natürlich) einige Vorträge, die sich mit Agile Offshoring / Agile Nearshoring beschäftigen:
• Sergei Andrzeevski: “Management of offshore agile projects”
• Andrea Heck & Tibor Vida: “Agile Offshoring”
• Robert Dempsey: “Creating High Trust Distributed, Multicultural Agile Environments”
• … plus eine Menge weiterer interessanter Vorträge!

Hey, ich freue mich wirklich auf diese Konferenz, da ich glaube, dass es dort eine Menge Möglichkeiten geben wird mit sehr interessanten Leuten zu sprechen!

Auf ein Treffen in Kiew

Ich werde zusammen mit meinem Partner für agile-nearshoring.com schon etwas früher nach Kiew fahren. Wenn Du an einer Diskussion zu Agile Nearshoring interessiert bist, dann melde Dich einfach – ich freue mich auf jeden Erfahrungsaustausch!

Invitation Video

Agileee is calling you! from Agile Eastern Europe on Vimeo.

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.

Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.

Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.

Danach wurden typische Herausforderungen für den Product Owner gesammelt:

Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:

• Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
• Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
• POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
• POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.
• …

Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)

Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:

• Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
• Product Owner sollte ein gutes technisches Verständnis haben
• Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
• Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
• … sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)

Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).

Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.

Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu  der verbreitesten Form der Scrum Implementierung zählen ;-(