-->

Montag, 4. Oktober 2010

Wovon zum Teufel redet ihr überhaupt?

Warum typische Probleme des klassischen Projektmanagements bei Agilem Vorgehen gar nicht vorkommen

Als ich meine ersten Projekte planen muste, bin ich – wie viele andere wahrscheinlich auch – erst mal los gezogen und habe mir ein Buch über Projektmanagement besorgt. So mit Gant-Charts und allem drum und dran. Bloß habe ich es nie hinbekommen, damit irgendein Projekt zu managen, weil die Realität immer so aussah, dass alle Projektpläne nach zwei Tagen Makulatur waren und das Updaten so viel Zeit in Anspruch genommen hat, dass ich am Ende mehr mit der Verwaltung der Pläne als dem Projekt zu tun hatte.

Natürlich hatte ich dann ein schlechtes Gefühl, weil ich dachte, dass ich Projektmanagement irgendwie nicht kapiere. Vielleicht würde ich etwas Wichtiges übersehen und es deshalb falsch machen. Oder noch schlimmer: Ich wäre vieleicht "führungsschwach" und müsste meinen Leuten mehr in den Allerwertesten treten?

Egal, da Projektmanagement und ich offensichtlich nicht füreinander bestimmt waren, habe ich die ganzen Tools irgendwann quasi gezwungenermaßen in die Ecke geworfen und mich so gut wie möglich durchgewurschelt. Interessanterweise funktionierte das erstens ganz gut und zweitens - aber das habe ich erst viel später gelernt - ähnelte meine Vorgehensweise dann dem, was man heute als Agile Methode bezeichnet.



Eigentlich könnte man es jetzt dabei bewenden lassen, aber eines Tages habe ich die Kritische Kette von Eliya Goldratt kennen gelernt und DAS war dann wieder richtig spannend, obwohl es dabei eigentlich um klassisches Projektmanagement geht. Denn Goldratt konnte  erklären, wo meine Probleme her kamen und dass es nicht an mir lag, sondern dass beim klassischen Projektmanagement einige wichtige Punkte tatsächlich konzeptionell falsch sind. Darüber hinaus zeigt er dann auch noch, wie man es besser machen kann.

Der Grund, warum ich diesen Beitrag hier schreibe, ist, dass auch für die Anwender Agiler Vorgehensweisen Goldratts Analysen sehr hilfreich sind. Insbesondere hilft Goldratts Analse, einige typische Planungsfallen zu vermeiden, in die man auch als Projektleiter oder Teammitglied in einem Agilen Team hineinfallen kann.

Goldratt nennt drei Gründe, warum es bei klassischem Projektmanagement (*) zu massiven Verzögerungen oder gar zum Scheitern von Projekten kommt:

1. Falscher Umgang mit Aufwandsschätzungen
2. Verspätungen addieren sich, Gewinne gehen verloren
3. Multitasking verschlimmert die Situation

1. Falscher Umgang mit Aufwandsschätzungen

Geht man eine Planung so an, dass man die Arbeitsschritte oder Aufgaben festlegt und dann die Ausführenden um eine Aufwandsschätzung bittet, so wird bei den Angefragten mehr oder weniger folgende Überlegung ablaufen:

"Hm, ich brauche dafür drei Tage. Aber irgendwas geht immer. Also besser kein Stress. Ich melde mal fünf Tage. Aber dem Kollegen haben die neulich böse das Zeitbudget gekürzt. Besser, ich melde sieben Tage, dann sollte ich auf der sicheren Seite sein."

--

Nun schalten wir kurz auf Fast Forward und schauen uns an, was an dem Tag passiert, an dem laut Plan die Aufgabe zur Bearbeitung an stünde. Wir erinnern uns: Der Schätzwert waren drei Tage, gemeldet wurden sieben.

Am Tag minus sieben vor Abgabe: "Man, die haben mir nicht mal eine Kürzung reingesetzt. Na, dann habe ich ja richtig üppig Zeit."

Am Tag minus fünf vor Abgabe: "Eigentlich sollte ich heute ich starten. Aber die Arbeit braucht sowieso nur drei Tage, also nehm ich mir lieber etwas anderes, Dringenderes vor. "

Am Tag minus drei vor Abgabe: "Mist, heute wollte ich es machen, aber gerade heute brennt es bei meinem Hauptkunden. Ok, ich schiebe es noch einen Tag, morgen und übermorgen muss ich eben richtig ranklotzen."

Am Tag minus eins vor Abgabe: "So was aber auch, die eine Teilaufgabe war echt tricky, das mit den zwei Tagen war doch zu knapp. Was soll's, muß ich halt zwei Tage Verzögerung melden. Wird schon nicht so schlimm sein, die anderen überziehen ja auch immer."



Ich denke, jeder Mensch mit etwas Berufserfahrung als Entwickler oder Projektleiter hat solch einen Ablauf schon häufiger erlebt :((

Goldratt rät übrigens nicht von Pufferzeiten ab (in unserem Beispiel die vier Tage, die über die drei Tage "Rohschätzung" hinaus angegeben werden), sondern zeigt in seinen Veröffentlichungen auf, wie man diese richtig einsetzt und managed. Was es damit auf sich hat, werde ich aber in einem anderen Beitrag unterbringen, heute geht es erst mal um die drei genannten Aspekte.

2. Verspätungen addieren sich, Gewinne gehen verloren

Jedes Projekt hat eine Vielzahl von Aufgaben, die jeweils von mehreren Unteraufgaben abhängig sind, die alle vollständig erfüllt sein müssen, bevor weiter gearbeitet werden kann. Ein Auto kann erst die Werkstatt verlassen, wenn der Motor repariert und die Räder angeschraubt sind; das Hauptgericht im Restaurant kann die Küche erst verlassen, wenn Fleisch und Gemüse und Beilage auf dem Teller liegen – die Beispiele lassen sich unendlich fortsetzen. Verzögert sich nur eine der Teilaufgaben, wirkt sich dies an solch einem "Integrationspunkt" auf den gesamten Projektverlauf aus. Andererseits ist es so, dass die frühere Fertigstellung von mehreren anderen Teilaufgaben gar nichts nutzt. Dieser "Vorsprung" wird einfach verpuffen. Die Grafik zeigt ein schönes Beispiel: Obwohl zwei der eingezeichneten Aufgaben früher fertig sind, verpufft der Vorsprung, da die Integration erst statt finden kann, wenn auch die unterste Aufgabe erledigt ist.



3. Multitasking verschlimmert die Situation

Liegen die Einzelplanungen vor, geht man in der klassischen Projektplanung gerne davon aus, dass man diese nun nach Belieben auf die Mitarbeiter verteilen kann. Das ein Mitarbeiter dann mehrere Aufgaben parallel bearbeiten soll, ist dabei eher die Regel als die Ausnahme. Dass die parallele Bearbeitung aber immer auch zusätzliche Umschaltzeiten erfordert, wird gerne übersehen. Schon ein einfaches Telefonat genügt, um einen Mitarbeiter für eine Viertelstunde aus dem Tritt zu bringen, die mentale und tatsächlichen Reorganisation des Arbeitsplatzes beim Umschalten auf eine andere Aufgabe wirkt sich natürlich noch viel deutlicher aus (Hier ein guter Artikel über eine ausführliche Studie dazu).



"Wovon zum Teufel redet ihr überhaupt?"
Wie Agiles Vorgehen diese Probleme vermeidet


Für die "klassische" Projektarbeit mit ihrem Top-Down-Ansatz einer zentralen Steuerung bietet das Konzept der Kritischen Kette ein gutes Instrument, Planung und Abarbeitung zu verbessern. Wirklich Interessant ist aber, dass in der Agilen Projektentwicklung diese Probleme gar nicht berücksichtigt werden müssen, da sie aufgrund einer besseren, weil zeitnäheren, genaueren und transparenteren Planungsmethodik erst gar nicht auftreten. Besonders gut lässt sich dies am Beispiel von Scrum zeigen.


Vor der Arbeit: Gemeinsame, transparente Aufwandschätzungen


Die Aufwandschätzungen in Scrum werden im Rahmen der Sprintlog-Planung kurz vor der Bearbeitung vorgenommen und gemeinsam diskutiert. Damit fließen in diese Aufwandsschätzung bereits eine Vielzahl von Erfahrungen und Informationen aus dem bisherigen Projektverlauf ein, was die Zuverlässigkeit deutlich erhöht, taktische Spielchen wie die Einberechnung unnötiger Puffer entfallen.

Während der Arbeit: Keine Verzögerungen / Momentum wird aufrecht gehalten


Das Herunterbrechen der Aufgaben in überschaubare Einzelaufgaben von nicht mehr als 16 Stunden, verhindert, dass große Überraschungen entstehen können.

Die täglichen Scrum-Meetings führen dazu, dass jederzeit klar ist, wer an was arbeitet und wie jedes Teammitglied voran kommt. Kritische Situationen wie in dem obenstehenden Beispiel (siehe Grafik) mit der um einen Tag verzögerten Integration werden sofort bekannt und können gemeinsam bearbeitet werden.

Die tägliche Dokumentation und Veröffentlichung des Burn-Down-Charts macht das Releaseziel kontinuierlich sichtbar, hält das Momentum im Team aufrecht.

Das Vermeiden von Multitasking


Dadurch, das die Aufgaben jeweils nur für einen Sprint und von allen Teammitgliedern gemeinsam geplant werden, ist die Planung beim Agilen Vorgehen automatisch wesentlich feingliedriger und realistischer, sowohl was die Einzelaufgaben angeht, als auch was die Abstimmung der Abhängigkeiten angeht. Ohne dass darauf gesondert geachtet werden muss, ergibt sich aus dieser besseren Planung sowie aus dem ausdrücklichen Verbot, dass Product Owner oder andere Nicht-Teammitglieder in die Arbeitsplanung eingreifen, praktisch automatisch eine optimierte, serielle Arbeitsplanung für die einzelnen Teammitglieder.

Mehr zur Kritischen Kette

Es gibt zur Kritischen Kette eine Reihe von Wiki-Einträgen und Webseiten. Ich persönlich finde die aber alle nicht so hilfreich. Ganz anders dagegen die Bücher. Da schafft es Goldratt m.E. sehr gut, das Thema Projektmanagement lebendig und gut nachvollziehbar darzustellen.

Für den Einstieg lohnt sich auf jeden Fall dieses Buch:

"Die Kritische Kette: Das neue Konzept im Projektmanagement"
von Eliyahu M. Goldratt, hier bei Amazon




(*) Mit klassischem Projektmanagement meine ich hier eine Top-Down-Vorgehensweise, bei der vorab ein Masterplan erstellt wird, in den idealerweise vor Projektbeginn alle Aktivitäten, die Aufwandschätzungen und die Bearbeitungsfolge eingetragen und dann nach Plan abgearbeitet werden.

Sonntag, 3. Oktober 2010

Die unbekannten Labore der Telko-Industrie

Der Mythos des Hackers, der in dunklen Hinterhöfen den tiefsten Geheimnissen fremder Systeme auf den Grund geht, zieht sich schon seit langem durch die verschiedensten Strömungen der Science-Fiction-Literatur und anderer Technikdramen.

An einem warmen Sommertag bin ich selbst auf dem Weg in den digitalen Untergrund. Ich sitze in einem Privattaxi, dass mich in eine osteuropäische Großstadt bringt. In einem Land, aus dem meine beiden Eltern stammen, das ich aber nur einmal vorher besucht habe und dessen Sprache ich selbt überhaupt nicht spreche. Im Flugzeug habe ich mir das kyrillische Alphabet beigebracht, das hilft schon mal viel.

Ich bin unterwegs, weil mein Projekt, ein Testautomatisierungswerkzeug für eine bestimmte Art von IBM-Datenbanken steckt in massiven Schwierigkeiten steckt.

Ein Testautomatisierungswerkzeug ist eigentlich nichts anderes, als eine Software, die eine andere Software bedienen kann, mehr oder weniger genau so, wie ein menschlicher Benutzer. In manchen Teilen der Softwareindustrie sind solche Werkzeuge von entscheidender Bedeutung. Wenn z.B. die Postleitzahlen in Deutschland von vier auf fünf Stellen umgestellt werden, dann erledigen die Programmierer die notwendige Änderung in ein paar Minuten. Danach kann es beispielsweise in einer Versicherung aber Wochen oder Monate dauern, zu überprüfen, ob alle anderen Teilprogramme, die die Postleitzahl benötigen, immer noch richtig arbeiten.

Wir selbst arbeiten bereits mit Reverse Engineering, um unsere Software in die IBM-Datenbanken einzuklinken. Wir haben Teile der IBM-Software mittels verschiedener Werkzeuge entschlüsselt, die internen Kommunikationsmechanismen untersucht und Einstiegspunkte gefunden, über die wir diese Software von außen so steuern können, als würden alle Eingaben von einem echten Benutzer ausgeführt. Aber irgendwie funktioniert unsere Methode nicht zufriedenstellend und was wir jetzt dringend brauchen, sind frische Ideen, ein neuer Ansatz, eine alternative Lösung.

Mein Taxi nähert sich unserem Ziel, einer Industriestadt mit fast anderthalb Millionen Einwohnern und eines der Zentren der Rüstungsindustrie. Bis zum Zusammenbruch des Sowjetischen Imperiums war die gesamte Stadt Sperrgebiet. Ich bin dort mit Ivan verabredet,dem Leiter einer Truppe, die im Internet unter dem Namen Assassin Software antritt. Zumindest aus Marketingsicht erscheint der Name etwas, hm, sagen wir mal unkonventionell. Die Assassini waren eine sagenumwobene arabische Sekte fanatischer Meuchelmörder, die in dem Ruf standen, in jedes Haus und jede Festung eindringen zu können. Für westliche Ohren klingt der Firmenname also nicht gerade vertrauenerweckend, aber ich bin ja nicht wegen des Firmennamens hier, sondern um Experten im Reverse Engineering zu finden - eine Dienstleistung, die auf dem freien Markt offiziell recht schwer zu finden ist(*).

Je mehr wir uns dem Ziel nähern, desto abenteuerlicher wird die Fahrt. Statt ins Zentrum geht es in ein Randgebiet. Die ohnehin schon kleine Seitenstraße, in die wir einbiegen, verwandelt sich von einer geteerten Straße in einen Schotterweg an dessen Ende wir in einen Hof einbiegen. Am Tor fängt uns ein misstrauischer Wächter ab, erst nach dem mein Fahrer Ivans Namen nennt, dürfen wir hinein. Kaum kommt der Wagen zum Stehen, öffent sich an einem fensterlosen Gebäude eine Stahltüre und ein junger Mann Ende Zwanzig mit Vollbart und langem Pferdeschwanz begrüßt mich in flüssigem Englisch. Kurz darauf stoßen zwei weitere Miteigentümer dazu. Das fensterlose Gebäude hält, was es verspricht. Über einen fensterlosen Vorraum werde ich in einen fensterlosen Konferenzraum geführt, wo mich die erste Überraschung erwartet: Das gesamte Equipment ist vom feinsten, mehrere Macbooks, ein hochwertiger Beamer und ein riesiger Flachbildfernseher stehen für Präsentationen aller Art zur Verfügung.

Ivan und seine beiden Kollegen stellen sich als Mathematiker und Physiker vor, das Geschäftsfeld Reverse Engineering sei ihnen vor fünf Jahren zufällig zugewachsen, als sie ihre Programmierdienste im Internet angeboten haben. Schritt für Schritt steigen wir in die Diskussion ein, ich erläutere unser Problem, beschreibe unser Vorgehen, wir diskutieren mögliche Vorgehensweisen.

Irgendwann wird es Zeit für das Mittagessen. Bevor wir aufbrechen, nutze ich die Gelegenheit und frage, ob wir vielleicht einen kurzen Rundgang durch die Firma machen könnten. Klar, kein Problem, meine Gastgeber freuen sich über mein Interesse - was mich wiederum etwas überrascht. Eigentlich vermute ich bisher, das Assissin Software hauptsächlich aus diesen drei plus ein paar Freunden besteht. Aber es soll anders kommen.

Der Rundgang beginnt wieder in dem fensterlosen Raum, über eine fensterlose Treppe geht es hinauf zu einem langen Flur mit abgewetztem Teppichboden. Oben öffnet sich dann die Türe zum ersten erste Büro, diesmal ein richtiger Raum mit Fenstern, Regalen, Schreibtischen. Rund zehn Programmierer arbeiten hier, an den Wänden Regale mit Boxen, darauf vor allem bekannte Name aus der Telekom-Industrie: Motorolla, Sony-Erricson, Nokia.

Im nächsten Raum das gleiche Bild, ein Raum weiter wieder das gleiche, jeweils zwischen zehn und fünfzehn Mitarbeiter, die konzentriert alleine oder in kleinen Gruppen arbeiten. Und überall Unmengen von Kabeln, Hardware und immer weiteren Boxen mit Beschriftungen aus der Telekomindustrie. Ivan bemerkt, wie ich immer aufmerksamer die Boxen und die Hardware mustere und fängt an zu grinsen.

Beim Essen erfahre ich dann die ganze Geschichte: Die Hauptkunden von Assassin Software sind nicht irgendwelche Unternehmen, die illegal Industriegeheimnisse entschlüsselt haben möchten, sondern hauptsächlich Mobilfunkprovider aus aller Welt, die technische Informationen oder Modifikationen für das Branding und Customizing der von ihnen vertriebenen Mobilfunkgeräte benötigen: Die Start-Routine ändern? Automatische Abfragen mit den Servern des Providers implementieren, das Bios anpassen – Assassin Software hilft Kunden weltweit. Und das ist durchaus wörtlich zu nehmen. Mit rund achtzig Mitarbeitern arbeitet man hier im zwei-Schichtbetrieb, um den Kunden aus Asien, Europa und den USA jeweils passende Zeitfenster für die Online-Konferenzen und Projektbesprechungen anzubieten. Inzwischen ist man sogar zertifizierter Microsoft-Partner, Scrum ist das Standardmodell für die Projektorganisation und über allem liegt ein detailliertes Kennzahlensystem, das täglich die Projektfortschritte und den Beitrag jedes Teams und jedes Entwicklers transparent macht. Ich gebe zu, dass hätte ich alles nicht erwartet.

Wenn ich heute in einem Blog lese, dass V-Mobile oder H2O leider noch zwei Monate brauchen, bis sie das in den USA bereits verfügbare Betriebsystem-Update auch für ihre Handy bereit stellen können, dann ahne ich, dass der Bearbeitungsengpass nicht in Berlin oder München liegt und denke grinsend an meinen Ausflug zurück.



Aus unserer Zusammenarbeit ist dann übrigens doch nichts geworden, unsere Programmierer haben das Problem glücklicherweise selbst in den Griff bekoimmen. Wenn einer der Leser aber zufällig bei einem Mobilfunkprovider anbietet, eine seriöse Reverse Engineering-Firma sucht, die auch von den Top-Telcos dieser Welt regelmäßig in Anspruch genommen wird, kann mir gerne eine Email schreiben.

Lessons to learn

  • Sei vorsichtig mit der Anwendung westlicher Vorstellungen von Marketing und dem repräsentativen Aussehen eines Firmensitzes.

  • Es gibt neben vielen Billigheimern in Osteuropa durchaus auch Teams, die es lässig mit westlichen Firmen aufnehmen können.



(*) Reverse Engineering wurde bis in die 90er-Jahre häufig eingesetzt, um die Funktionalität eines Konkurrenz-Produkts zu entschlüsseln und nachzubauen. Mit dem Digital Millenium Copyright Act der 1998 in den USA in Kraft trat und ähnlichen Regelungen in Europa wurde Reverse Engineering weitgehend illegal. Außer, wenn es wie in unserem Fall darum ging, die "Kommunikation zwischen verschiedenen Programmen zu ermöglichen". Bingo!