-->

Mittwoch, 1. Dezember 2010

Der Loop-2-Fragebogen für Agile Teams V1.1.

In vielen Industrien und Dienstleistungsbereichen werden bereits seit langem ausführliche Evaluationswerkzeuge eingesetzt. Diese unterstützen Arbeitsgruppen und Teams unterschiedlichster Art durch das gezielte Abfragen von Best Practices bei der Reflektion ihrer Arbeitsweise und Arbeitsorganisation.

Im Bereich der Agilen Softwareentwicklung gibt es jedoch nur wenig Review-Instrumente, die breit einsetzbar sind. Entweder dienen sie wie der Nokia-Test eher einer Statusabfrage für das Top-Management oder sie zielen dezidiert auf Scrum ab und sind damit nur eingeschränkt für Teams geeignet, die andere Agile Methoden einsetzen.

Ich habe mich deshalb hingesetzt und einen breiter einsetzbaren Fragebogen entwickelt. Das Ziel war ein Werkzeug, dass agile Teams jeder Coleur dabei hilft, ihre Review-Meetings besser zu strukturieren und ihre Prioritäten sebst zu bestimmen.

Einen solches generisches Instrument zu entwickeln, war deshalb möglich, wei allen Varianten der agilen Softwareentwicklung drei wichtige Gemeinsamkeiten zugrunde liegen. Ideale Agile Entwicklerteams sind unabhängig vom jeweiligen Framework, d.h. unabhängig von Scrum, Kanban etc. immer:

  • Sich selbst organisierende und
  • lernende Teams,
  • die zusätzlich softwarespezifische Arbeitstechniken einsetzen.

Der so entstandene Fragebogen und die dazu gehörigen Erläuterungen liefern bereits durch die Fragestellung viele Hinweise auf Best Practices in agilen Entwicklungsteams. Dies ersetzt aber keine Fachliteratur und keine Schulungen oder Trainings.

Ihr könnt den Fragebogen frei verwenden (Details stehen in der Creative Commons Lizenz ganz unten). Hier ist die druckfertige PDF-Version. Dazu meine Bitte: Wenn Ihr den Fragebogen an Kollegen weiter geben wollt, so verschickt bitte nicht die Datei, sondern den Link zu diesem Blog:

http://blog.loop-2.net/2010/12/der-loop-2-fragebogen-fur-agile-teams.html

Ich freue mich über Rückmeldungen, Kritik und Verbesserungsvorschläge. Benutzt dazu am besten die Kommentarfunktion, dann haben alle anderen Leser auch etwas davon.

Halle, den 30. November 2010

Lucius Bobikiewicz


Der Loop-2-Fragebogen für Agile Teams

Version 1.1


Zielorientierung und Verantwortung

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W + G)
1
Das gesamte Team kennt die Ziele und Rahmenbedingungen des Projekts



2
Die Prioritäten des Kunden sind allen Teammitgliedern immer bekannt



3
Die Erfolge des Teams werden wahrgenommen und anerkannt



4
Die Einzelleistung jedes Teammitglieds ist für alle sichtbar






Koordination und Planung

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
5
Die Aufwandsschätzungen und die Arbeitspläne werden ausschließlich von Mitgliedern des Teams erstellt



6
Der aktuelle Projektplan wird immer mit allen Teammitgliedern abgestimmt.



7
Die Dauer der Arbeitsphasen zwischen zwei Planungs- intervallen sind den Projektphasen angemessen



8
Die Aufgabenliste für eine Arbeitsphase ist immer auf maximalen Durchsatz ausgelegt, es werden keine Puffer eingebaut



9
Wir pflegen in unserem Projektmanagement nur Daten ein, die wir für unsere Arbeit brauchen



10
Unser Projektmanagement ist leicht zu verstehen und angenehm zu benutzen



11
Jeder weiß, welche Probleme es gerade gibt und wer sich darum kümmert






Arbeitsplatz und Arbeitsprozess

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
12
Jeder hat alle Werkzeuge und Informationen, die er zum guten Arbeiten braucht, jederzeit zur Verfügung



13
Jeder bei uns kann die für seine eigene Arbeit notwendigen Entscheidungen selbst treffen



14
Alle Teammitglieder wissen, was die anderen jeweils gerade tun



15
Jeder kann jederzeit einen neuen Build mit dem eigenen Code und/oder dem neuen Code der Teamkollegen veranlassen



16
Jeder kann sich sich hier voll auf seine Aufgaben konzentrieren. Es gibt kein Multitasking und keine Unterbrechungen



17
Unser Auftraggeber ist immer verfügbar, wenn wir ihn brauchen





Ergebnisprüfung

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
18
Allen Teammitgliedern sind der aktuelle Projektfortschritt und die noch offenen Aufgaben jederzeit bekannt



19
Jeder von uns kann jederzeit einen vollständigen Testlauf anstoßen und die Ergebnisse der Tests sind für ihn selbst und für alle anderen sofort verfügbar



20
Die Abnahme von Zwischenreleases oder Meilensteinen findet zu definierten und sinnvollen Intervallen statt






Lernen

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
21
Probleme und Fehlschläge finden wir interessant, wir analysieren sie gerne, weil dies hilft, besser zu werden



22
Neue Erkenntnisse werden von uns sofort in den Arbeitsprozess integriert



23
Wir nehmen regelmäßig und systematisch Auszeiten, um über unsere Arbeit und unsere Arbeitsweise zu reflektieren



24
Das Experimentieren mit neuen Werkzeugen oder Abläufen gehört bei uns selbstverständlich zur Arbeit dazu



25
Wir wechseln intern immer wieder Aufgaben und Rollen



26
Wir tauschen uns immer wieder mit anderen Teams / anderen Organisationen aus und versuchen, von diesen zu lernen





Teamstärke

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
27
Unsere Auftraggeber schätzen die Zusammenarbeit mit uns



28
Bei uns herrscht eine Atmosphäre gegenseitiger Anerkennung und Wertschätzung



29
Wir verwenden gezielt Techniken oder Methoden, die sicher stellen, dass jeder von uns seine Sichtweise beitragen kann



30
Unser Team wählt seine Sprecher oder Teamleiter selbst



31
Ich arbeite gerne hier





Abschluss

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
32
Die Ergebnisse der letzten Befragung wurden umgehend ausgewertet und es wurden wirksame Maßnahmen ergriffen



33
Diese Befragung wird in einem festgelegten, verläßlichen Rhythmus durchgeführt



34
An diesem Fragebogen gibt es nichts mehr zu verbessern ;)





Wie der Fragebogen angewendet wird


Regelmäßige Durchführung

Da sich Entwicklungsmethoden und Projekte laufend verändern, gibt es keinen Fixpunkt in der Teamentwicklung. Die Frage “Was könnten wir besser machen” muss immer wieder gestellt werden. In Scrum gibt es hierfür die Daily Scrums und die Sprint Reviews. Genau so kann dieser Fragebogen eingesetzt werden. Es bieten sich hierfür sowohl zeitliche Intervalle an, z.B. alle zwei Monate, oder ereignisgesteuerte Intervalle, z.B. eine Rückschau nach jeder Veröffentlichung eines neuen Release.

Anonyme Befragung

Um eine gegenseitige Beeinflussungen oder eine Beeinflussung von einzelnen Teammitgliedern zu vermeiden, sollte der Fragebogen grundsätzlich anonym ausgefüllt werden. Desweiteren sollte er von allen Teammitgliedern ausgefüllt werden, damit er ein möglichst vollständiges Bild liefert.

Die Antwortskala

Bitte geben Sie für jede Aussage mit einer Wertung von -2 bis +2 an, wie weit diese ihrer Ansicht nach auf die aktuelle Situation zutrifft:
Überhaupt nicht
eher nicht
weiß nicht
eher ja
völlig
-2
-1
0
+1
+2

Beim Gewicht geben Sie mit der gleichen Skala an, wie sich der aktuelle Status ihrer Einschätzung nach auf die Arbeit des Teams auswirkt:
sehr negativ
eher negativ
akzeptabel
eher positiv
sehr positiv
-2
-1
0
+1
+2

Der Score errechnet sich dann einfach aus der Addition von Wertung und Gewicht. Ein Score von +4 zeigt beispielsweise einen sehr positiven Aspekt auf, während bei -4 dringender Bedarf an Verbesserungen besteht.

Auswertung

Identifizieren Sie mit dem Team zusammen :

  • die drei Aussagen mit dem höchsten Score, dass sind die Aspekte, die sehr positiv gesehen werden. Schreiben Sie diese an eine Tafel oder einen Flipchart, damit diese von allen wahr genommen werden.

  • die drei Aussagen, mit dem niedrigsten Score. Das sind die Punkte, bei denen der dringendste Bedarf für Verbesserungen besteht. Schreiben Sie auch diese an die Tafel. Wenn es mehr als drei mit höchstem Score gibt, dann einigen Sie sich auf die drei, maximal vier, die sie für besonders wichtig halten.

Diskutieren Sie für die Punkte, bei denen das Team den dringendsten Handlungsbedarf sieht, welche Maßnahmen zur Verbesserung ergriffen werden können. Entwickeln sie gemeinsam konkrete Maßnahmen und einen Arbeitsplan und bestimmen Sie Verantwortliche dafür.

Erläuterungen zu den Fragen


Zielorientierung und Verantwortlichkeit

Erst ein gemeinsames Ziel verwandelt eine Gruppe von Individuen in ein Team. Damit alle Mitglieder ihre Tätigkeit an dem Ziel ausrichten können, ist es notwendig, dass alle Teammitglieder das Ziel des Projekts und seine Rahmenbedingungen kennen.

Während das gemeinsame Ziel und die gemeinsame Beurteilung als Team der Kit sind, der die Gruppe zusammen hält, ist es gleichzeitig wichtig, auch jeden Einzelnen in die Verantwortung zu nehmen. Sonst kommt es zum “Wo alle zuständig sind, ist keiner zuständig”-Effekt.

Die Erfolge des Teams lassen sich während dem Projekt in Burn-Down-Charts messen oder beim Projektabschluss über die Kundenzufriedenheit, den finanziellen Ertrag und ähnlichem.

Auch die individuelle Leistung der einzelnen Teammitglieder sollte teamintern sichbar gemacht werden. Z.B. in dem über Reports aus dem Ticketsystem angezeigt wird, wer welche Aufgaben bearbeitet hat und wie lange er dafür benötigt hat. Oder wieviele Storypoints jemand im Laufe der Woche abgearbeitet hat. Oder indem auf der Startseite des Projektmanagementsystems angezeigt wird, wer wie oft von Kollegen um ein Code-Review gebeten wurde.

Wichtig ist, dass jedes Teammitglied weiß, dass seine positiven Beiträge von den anderen gesehen und werden.

Koordination und Planung

Komplexe Aufgabenstellungen erfordern das Wissen und die Erfahrung aller Beteiligten. Eine Planung unter Einbeziehung aller Teammitglieder ist in der Regel wünschenswert, in der Praxis kommt es aber immer wieder vor, dass einzelne Aspekte oder Aufgaben wie z.B. das Systemdesign doch nur von einem oder wenigen Spezialisten geplant werden können. Aber in diesem Fall sollte zumindest ein ausführlicher Review-Termin statt finden, in dem diese Spezialisten ihre Entscheidungen darlegen, begründen und mit den übrigen Teammitgliedern diskutieren.

Auch Planungsprozesse beanspruchen viel Zeit und Ressourcen. Deshalb ist es wichtig, dass diese so oft wie nötig, aber auch nicht öfter als notwendig statt finden. Da agile Entwicklung im wesentlichen ein Dreischritt von Planen, Umsetzen und Analysieren (Lernen) ist, hängt der richtige Rhythmus von der Veränderungsdynamik in der jeweiligen Projektphase ab. Eine Arbeitsphase sollte immer genau so lange dauern, bis das Weiterarbeiten anfängt, zu unreifen, nicht mehr verwendbaren Implementierungen zu führen.

Im agilen Vorgehen werden die Aufgaben so geplant, dass alle Beteiligten ohne Leerlaufzeit kontinuierlich arbeiten können. Dies entspricht den Prinzipien der Kritischen Kette von E. Goldratt.

Das Projektmanagementsystem soll auf allen Ebenen, von der User Story oder der Featurebeschreibung bis hin zum Bearbeitungsstatus und Workflow nur Daten enthalten, die die Entwickler benötigen. Pflichtfelder, die nur aufgrund von Verwaltungsvorschriften ausgefüllt werden, sind nicht nur wertlos, sondern vernichten sogar kostbare Entwicklungszeit. Auf der anderen Seite muss, was immer an Daten benötigt wird, darin auch für alle zugänglich abgelegt werden können. Falls notwendig gehören dazu auch Bilder, Diagramme, Videos etc.. Gleichzeitig sollte das Projektmanagementwerkzeug leicht und intuitiv zu bedienen sein.

Unbeseitigte Probleme führen bei allen Beteiligten zu “Stuff” (s.a. "Getting Things Done" von David Allen), zu Ablenkung und mentalem Overhead. Werden Probleme jedoch gemeinsam besprochen, bewertet und für alle sichtbar in eine Maßnahmenplanung umgesetzt, schafft dies Klarheit und Handlungsfreiheit für das gesamte Team. In Scrum wird für die Problemidentifikation das Daily Scrum Meeting und die Impediment-Liste verwendet. Andere denkbare Lösungen sind aber auch Team-Wikis oder Shared Spreadsheets.

Arbeitsplatz und Arbeitsprozess

Jeder Arbeitsplaz sollte selbstverständlich so ausgestattet sein, dass alle erforderliche Soft- und Hardware zur Verfügung steht. Dazu gehören neben der IDE und dem Projektmanagementsystem inbesondere die Testumgebung, der freie Zugriff auf Repositories, die Verfügbarkeit von Handbüchern aller Art, aber auch Hardware wie beispielsweise große Bildschirme oder Multi-Bildschirm-Setups.

Ein wesentliches Element eines motivierenden Arbeitsplatzes ist die Befugnis, die eigenen Aufgaben in Eigenregie organisieren und bearbeiten zu können. Dazu gehört die Freiheit des Wann, des Wie, des Womit etc.

Erst das Wissen um die Tätigkeit der anderen ermöglicht es den übrigen Teammitgliedern, Unterstützung und Hilfe zu geben. Eine Nachricht wie “Du fängst mit Task 231 an? Pass auf, die Methode in der Library XYZ hat noch keinen Freeze-Status” kann teure Fehl-Arbeit verhindern. Die Information über “was tue ich gerade” kann auf vielfältige Weise weiter gegeben werden. Außer dem Arbeiten im gemeinsamen Büro bieten sich heute beispielsweise auch Twitter, IM oder ein automatische Verknüpfung von Projektmanagement mit einem RSS-Feed an. Zum Beispiel so: “Michael has just opened Task 231 >>Save-Button<<; Workflow Status: Testing”.

Je flexibler eigener Code zusammen mit dem Code anderer Kollegen getested werden kann, desto leichter können Abhängigkeiten und unerwünschte Nebeneffekte identifiziert werden, ohne das zentrale Repository mit mangelhaften Implementierungen zu füttern. Das saubere Setup des Repositories ist entscheidend, richtig genutzt können auch sehr einfache Tools wie z.B. die Kombination von Dropbox mit Git perfekte Lösungen liefern.

Damit Unklarheiten nicht zu Fehlentwicklungen oder Verzögerungen führen, ist eine enge Abstimmung wichtig. Was angemessen und möglich ist, muss für jedes Projekt neu definiert und ausgelotet werden.

Ergebnisüberprüfung

Der gemeinsame Abgleich des Ist- mit dem Sollzustand schafft Klarheit über Prioritäten und Probleme, motiviert die Teammitglieder durch die Sichtbarkeit des Projektfortschritts und führt automatisch zur Synchronisation der nächsten Aktivitäten. Je sichtbarer und zeitnäher dieser Abgleich statt findet, z.B. über eine Wandtafel, die Login-Seite des Projektmanagementsystems o.ä. desto genauer und kleinteiliger kann sich das Team abstimmen.

Der freie Zugriff auf Testressourcen ermöglicht ein interaktives “Modelieren”. Die Teammitglieder können um so effizienter und effektiver arbeiten, je kürzer die Zeitspanne zwischen Codeerzeugung und Rückmeldung ist.

Feste Abnahmetermine und Meilensteine erzeugen Planungssicherheit, verhindern das unwillkürliche Abdriften des Projekts. In Verbindung mit gleichzeitigen Arbeitsphasen- und Projektreviews stellen sie sicher, dass der Fokus auf Qualität und Wertschöfpung aufrecht erhalten bleibt.

Lernen

Wirksames Lernen basiert darauf, dass über Fehler oder Unzulänglichkeiten offen und mit Interesse gesprochen wird. Alle erfolgreichen Teams pflegen eine Kombination aus Hochleistungsansprüchen bei gleichzeitiger no “No Blame”-Mentalität.

Lernen ist umso wirksamer, je schneller das gelernte in Lösungen umgesetzt werden kann. Ein ausschließlich strukturiertes Lernen, z.B. in Form von zweiwöchigen Review-Meetings führt dazu, dass viele wichtige Punkte in Vergessenheit geraten oder nur noch unvollständig rekonstruiert werden können.

Trotzdem ist auch das formalisierte Lernen, z.B. in Form des Daily Scrums und vor allem in Form von Sprint-Reviews und Projektreviews von großer Wichtigkeit. Die Formalisierung erzeugt Sicherheit und Verlässlichkeit, hält den Fokus auf die kontinuierliche Verbesserung aufrecht und stellt - sofern gut moderiert - sicher, dass auch “leise” Beiträge gehört werden.

Der Vergleich mit anderen Teams schafft ein Bewusstsein für das Entwicklungspotenzial, motiviert zur Aufholjagt oder erzeugt Stolz auf das Erreichte.

Änderungen in der Arbeitsweise sind immer mit dem Risiken eines Rückschlags verbunden. Aber nur wenn dieses Risiko akzeptiert und bewusst eingegangen wird, können echte Verbesserungspotenziale erschlossen werden. Auch scheinbare Fehlschläge beinhalten wichtige Lernerfahrungen und Wissenszuwachs!

Der breitest mögliche Wechsel von Aufgaben und Rollen stellt die Teammitglieder vor neue Herausforderungen, verbreitert die Wissens- und Erfahrungsbasis im Team und fördert die persönliche Entwicklung der Einzelnen.

Teamstärke

Ein Team ist nur dann ein Team, wenn die Mitglieder ein gemeinsames Ziel haben und gemeinsam für die Zielerreichung verantwortlich sind.

Soziale Wertschätzung und Anerkennung gehören für Menschen zu den wichtigsten Motivationsfaktoren.

In jeder sozialen Gruppe kann es dazu kommen, dass starke Persönlichkeiten Entscheidungsprozesse dominieren oder dass es zur Entwicklung von schädlichen Gruppendenken kommt. Techniken wie das Schätzpokern in Scrum, Ideajams oder moderierte, gecoachte Review-Meetings wirken dem systemisch entgegen und stellen sicher, dass auch eher stille Teammitglieder sich einbringen können und gehört werden.

Sofern die Mutterorganisation dies zulässt, kann die Wirksamkeit selbstorganisierender Teams soweit gehen, dass nicht nur die internen Abläufe, sondern auch die auch Sprecher und Teamleiter vom Team selbst bestimmt werden.

Die allgemeine Zufriedenheit mit dem Arbeitsplatz entscheidet über die innere Motivation und damit über die Leistungsfähigkeit. Allerdings kann die Frage “Ich arbeite gerne hier”  nur als Frühindikator bei neu auftauchenden Problemen verwendet werden. Hat sich in einem selbst organisierten Team beispielsweise bereits schädliches Gruppendenken etabliert, wird bald eine Abkoppelung von der Orientierung auf die Ziele, ein Ansteigen der Fehlerquote oder ähnliches zu registrieren sein. Trotzdem sind es dann aber nur noch die ehemaligen (!) Teammitglieder, die aufgrund ihrer Aussensicht verlässlich Auskunft über mögliche interne Probleme des Teams geben können.

Abschluss

Da sich Teams, Projekte und Technologien laufend verändern, sollte der Fragebogen, bzw. die damit verbundene Analyse zu festgelegten Intervallen durchgeführt werden. Dies können zeitliche Intervalle sein, z.B. alle zwei Monate, oder ereignisgesteuerte Intervalle wie z.B. nach jeder Veröffentlichung eines neuen Release.

Wie alle Aktivitäten in einer lernenden Organsation, muss auch der Review-Prozess selbst einem Review unterliegen. Deshalb schliesst der Fragebogen mit zwei rekursiven Fragen zur Auswertung und zur Qualität ab.

Lizenz

Der Fragebogen und die zugehörigen Erläuterungen stehen unter der "Creative Commons Lizenz 3.0" in der sogenannten "by-sa"-Form: http://creativecommons.org/licenses/by-sa/3.0/de/legalcode.

Sie dürfen alle Bestandteile frei verwenden und auch verändern, müssen aber in der Fußzeile aller Seiten in gleicher Schrift wie im Erläuterungstext den Vermerk anbringen: "Basierend auf dem Loop-2-Fragebogen für Agile Teams, Vers. 1.1"'.

Weiter müssen auch die neue und alle weiteren Fassungen die hier formulierte Lizenzbestimmung übernehmen.

30. Nov. 2010

Lucius Bobikiewicz

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!