22.9.2009 von Jens Coldewey.

Eine beeindruckendes Beispiel für die Kraft einer Vision hat Jared Spool auf der Agile 2009 vorgeführt: Einen Film von Apple unter dem schönen Titel “Knowledge Navigator“. In diesem Film von 1987 zeigt Apple eine Vision von der Anwendung von Computern im Jahr 2010.

Zur Erinnerung: Im Jahr 1987 war der “IBM AT” Stand der Technik, der immerhin mit einem 80286 und 20-30 MHz ausgestattet war und über MS-DOS bedient wurde. Apple hatte damals schon die Idee der Xerox-Labs aufgegriffen und nach dem Lisa-Flop den ersten Mac auf den Markt gebracht. Und es gab mit dem “Osborne” auch schon die ersten “tragbaren” Rechner, die aber eher geeignet waren, die Statik des Schreibtischs zu prüfen, als dass man sie im Zug oder Flugzeug hätte einsetzen können. Das Internet war zu diesem Zeitpunkt ein reines Uni-Netzwerk, das World-Wide-Web noch nicht mal bei Cern erfunden, die E-Mail begann gerade, auch in Deutschland anzukommen und wer “DFÜ” betreiben wollte, musste sich von Postbeamten versiegelte Modemleitungen in die Wand schrauben lassen, deren Monatsgebühr selbst die Rechnungen vom Finanzamt als erstrebenswerte Mitteilungen erschienen ließen; Übertragungsrate: 56kByte/sec.

In diesem Kontext also entwirft Apple die Vision eines Rechners, der zugleich (Bild-)Telefon ist, wie auch umfassende Wissensquelle zu allen Themen der Welt. Ein Computer, der sich so einfach bedienen lässt, wie ein Buch und ganz normaler Teil des Alltags ist. Und — noch beeindruckender — ein Computer, der frappierende Ähnlichkeiten mit dem iPhone hat! Natürlich haben sich die Apple-Leute in einigen Punkten geirrt: Spracheingabe ist heute nur unwesentlich weiter entwickelt, als vor 23 Jahren und “künstliche Intelligenz” interessiert heute (fast) nur noch Informatik-Historiker. Dafür übersteigen die Effekte von Web 2.0 und modernen Suchmaschinen offensichtlich auch die gewagtesten Phantasien.

Falls Sie jetzt sagen: “Na ja, Steve Jobbs halt” ist vielleicht noch das Detail interessant, dass Jobbs zu dieser Zeit nicht bei Apple war, sondern versucht hat, Next aufzubauen. Die Vision entstand unter Leitung von John Sculley

Für mich ist dieses Video der Beleg für die Macht einer kraftvollen Vision: Seit fast einem viertel Jahrhundert arbeitet Apple konsequent daran, diese Vision umzusetzen. Manchmal waren sie ihrer Zeit voraus, wie bei der Lisa oder beim Newton, manchmal haben sie mit der Vision einen scheinbar gesetzten Markt komplett aufgerollt, wie beim iPhone. Eine solche Vision zu finden und konsistent zu verfolgen, sei es für ein Projekt oder auch ein Unternehmen, ist der Kern vieler erstaunlich erfolgreicher Vorhaben. Mittelmäßige Produkte und Projekte mussten in der Regel ohne solche Visionen auskommen und sich statt dessen an kurzfristige Terminpläne und Budgets klammern. Auch Terminpläne und Budgets haben ihre Bedeutung. Wirklich glänzen können sie aber nur, wenn dahinter eine Vision steht — selbst wenn sie nicht so beeidruckend ist, wie die von Apple.

Geschrieben in Management, Agilität | Drucken | 3 Kommentare »

10.9.2009 von Jens Coldewey.

Gemeinsam mit Traian Kaiser, Ralf Wirdemann und Stefan Roock habe wir auf XING ein neues Forum zum Thema “Lean Software Management” gestartet. Lesen ist frei, wer mitdiskutieren möchte, muss sich bei XING und in der Gruppe anmelden.

Zur Erinngerung: Lean Software Development ist eine “Unterdisziplin” der agilen Verfahren, die versucht, die Lehren und Erkenntnisse aus Lean Management und Lean Development von der Autoindustrie - und da vor allem von Toyota - auf die Entwicklung von Software zu übertragen. Basis sind vor allem die Arbeiten von Mary und Tom Poppendieck und ihre Bücher Lean Development Software: An Agile Toolkit for Software Development Managers und Implementing Lean Software Development: From Concept to Cash. Das Ergebnis ist erstaunlich ähnlich zu anderen agilen Verfahren wie Scrum etc., konzentriert sich aber deutlich mehr auf Zusammenhänge und weniger auf die genaue Einhaltung von Praktiken.

Eine Kurzfassung findet man in einem zweiteiligen Artikel von Mary Poppendieck und mir:

• Fastenkur für den Prozess in OBJEKTspektrum 4/2003
• Wir sind das Team in OBJEKTspektrum 4/2003

Geschrieben in Surftipp, Lean Software Development, Ankündigungen, Management, Buchtipp, Agilität | Drucken | Keine Kommentare »

16.7.2009 von Jens Coldewey.

Peter Kruse, Honorarprofessor für Organisationspsychologie in Bremen, hat 8 Regeln aufgestellt, um den völligen Stillstand in Unternehmen zu erreichen. 3 Minuten und 37 Sekunden sehr Amüsantes und Nachdenkliches zum Changemanagement: 8 Regeln für den totalen Stillstand

Geschrieben in Surftipp, Management | Drucken | 1 Kommentar »

10.7.2009 von Jens Coldewey.

Allen, die agile Entwicklung noch immer für eine Absurdität unprofessioneller Hobbyentwickler und Hippies halten, sei der Artikel “Windows aus der Asche” aus dem aktuellen SPIEGEL empfohlen, der auch auf SPIEGEL-Online verfügbar ist. Der Beitrag berichtet, wie Microsoft für die Entwicklung von Windows 7 konsequent auf Extreme Programming gesetzt hat (”Von nun an, so viel stand fest, sollte der Kunde treiben” und “in ganzen Abteilungen sitzen die teuren Programmierer nicht mehr allein, sondern paarweise vor den Monitoren”; “Beginne mit dem Machbaren, dann füge Stück für Stück hinzu. Und immer gleich gründlich testen!”) und welche Auswirkungen das hatte: “Plötzlich kommen der Reihe nach Produkte heraus, die den fast ungeteilten Beifall der Fachwelt finden”, und Brad Silverberg, Entwicklungsleiter von Windows 95, stellt fest: “Zum ersten Mal seit langer Zeit sind die Leute wirklich entzückt von neuen Microsoft-Produkten.” Auch Qualität und Terminplanung wurden beeinflusst: “Windows 7 […] ist nun nach kaum zwei Jahren fast fertig. Und der Start wurde schon zweimal vorverlegt, zuletzt auf den 22. Oktober.”

Ich denke, damit dürfte die Brauchbarkeit agiler Verfahren auch für große und schwierige Projekte endgültig empirisch gezeigt sein. Anders formuliert, agile Entwicklung ist jetzt nicht mehr nur Sache der Pioniere, sondern wird nach und nach zum entscheidenden Wettbewerbsvorteil — ein Vorteil, den vor Microsoft auch schon Google, Amazon und ebay genutzt haben.

Ich hoffe nur, dass die deutsche IT-Industrie hier nicht wieder durch “aktives Zuwarten” den Zug verpasst und weitere Arbeitsplätze gefährdet, sondern erkennt, dass es höchste Zeit wird, sich umfangreiches Know-How und Praxis angzueignen. Es ist schließlich wesentlich einfacher, die Organisation noch umzustellen, solange man das nach eigenem Zeitplan machen kann, als wenn man von der Konkurrenz vor sich her getrieben wird.

Geschrieben in Surftipp, Management, Agilität | Drucken | 3 Kommentare »

3.7.2009 von Jens Coldewey.

Felix Rüssel hat vor einiger Zeit in seinem — übrigens insgesamt sehr lesenswerten — Blog einen älteren Beitrag von mir zum Kundennutzen unter dem Titel “Kundenzufriedenheit vs Kosten” in die Kritik genommen. Einer von Felix’ Kernsätze war: “Die agile Sichtweise schlägt […] stark vereinfacht vor, Kundennutzen grundsätzlich zu maximieren. Dies darf jedoch nicht zu Lasten des Gesamtbudgets des Projektes gehen! Dieser Konflikt muss durch den ProductOwner bzw. den Projektleiter erkannt und zusammen mit dem Kunden gelöst werden”, und er beklagt sich: “Die Kundenzufriedenheit spielt […] unbestritten eine zentrale Rolle, wird jedoch gerade in der agilen Welt zu oft als alleiniges Heilmittel angesehen. Es wird oft aus der Sicht des Ingenieurs argumentiert, der Prozesse und Arbeitsergebnisse optimieren möchte.”

Ich teile Felix’ Auffassung nicht, dass die alleinige Fokussierung auf die Kundenzufriedenheit nur aus einer technokratischen Sicht kommt. Ich denke, sie hat auch handfeste betriebswirtschaftliche Gründe, zumindest wenn der Kontext stimmt. Felix argumentiert in seinem Beitrag aus der Sicht eines Softwarehauses: “In den meisten Fällen arbeiten heute Teams in der Projektentwicklung weiterhin mit Werkverträgen, d.h. es wird ein definiertes Ergebnis zu einem bestimmten Termin geschuldet.” Das bedeutet aber eben nicht nur ein Werkvertrag, sondern auch eine neue, künstlich eingezogene betriebswirtschaftliche Ebene: Für den Auftragnehmer ist in dieser Situation nicht mehr der betriebswirtschaftliche Erfolg der Software relevant, sondern einzig der Erfolg des Projekts ihrer Erstellung, gemessen an Einhaltung von Umfang und Termin möglichst unterhalb des Budgets und zu einer Qualität, die mir nicht gerichtsfest um die Ohren geschlagen werden kann.

Je weiter ich als Projektleiter also kurzfristige Kosten und damit Qualität nach unten drücken kann, um so erfolgreicher bin ich betriebswirtschaftlich als Projekthaus. Allerdings werden dabei die Kosten nicht wirklich reduziert, sondern nur vom Auftragnehmer zum Auftraggeber verlagert: Der Auftragnehmer spart vor der Produktionssetzung Kosten ein, indem er weniger in Qualität investiert, der Auftraggeber muss ein Mehrfaches dieser Kosten hinterher aufbringen, um die Fehler zu beheben, mit den Fehlerfolgen umzugehen und das verkorkste Design weiter zu entwickeln. In der Rechtstheorie könnte er dafür zwar den Auftragnehmer in Mängelhaftung nehmen, in der Praxis ist das jedoch nicht nachzuweisen.

Rob Austin bezeichnet diese Konstellation in einem meiner Lieblingsbücher “Measuring and Managing Performance in Organizations” als “Measurement Distortion”: Wenn ein System (oder Vertrag) von vier Parametern bestimmt wird (Termin, Umfang, Kosten und Qualität) und ich kann nur drei von ihnen einigermaßen messen (Termin, Umfang und Kosten), so werden diese auf Kosten des schlecht messbaren vierten Parameters (Qualität) optimiert. Wie das im Projektalltag dann aussieht, beschreibt Felix sehr richtig und treffend.

Die Schlussfolgerung ist aber nicht, dass Agilisten “das Thema ‘Kosten’ gerne verdrängen” würden, sondern dass Werkverträge nicht geeignet sind, betriebswirtschaftlich sinnvoll ein Softwaresystem zu erstellen: Hier geht es ja nicht nur um Entwicklungskosten (die der Auftragnehmer eines Werkvertrages optimiert), sondern um die Gesamtkosten (”Total Cost of Ownership”) des Systems, zu denen unter anderem auch Betriebs-, Wartungs-, Weiterentwicklungs- und Stilllegungskosten gehören. Die Rechnung wird also am Ende der Lebenszeit der Software aufgemacht, nicht zu Produktionsstart. Um die Tatsache abzubilden, dass bei den Kosten auch der Zeitfaktor mitspielt, arbeiten Betriebswirtschaftler mit Abzinsungsmodellen, die ein guter Product Owner meines Erachtens kennen und soweit sinnvoll berücksichtigen sollte. Mike Cohn beschreibt solche Modelle sehr gut in seinem Buch “Agile Estimating and Planning“, Kapitel 10.

Die agile Sicht stellt also dem traditionellen Projekt “Software bis zur Produktionsreife entwickeln” eine Produktsicht gegenüber: Der Return-on-Investment über den gesamten Lebenszyklus muss optimiert werden. Ich habe diesen Gedanken 2005 einmal in dem Artikel “Projektdämmerung” weiter ausgeführt. Es geht also um eine globale Optimierung statt einer lokalen, bzw. um eine ganzheitlichere Sicht auch in der betriebswirtschaftlichen Steuerung. In Scrum ist genau das die Aufgabe des Product Owners.

Mit anderen Worten: Die Abkehr vom Werkvertrag ist für den Auftraggeber wichtig und sinnvoll. Die Auftragnehmer haben sich mit Werkverträgen arrangiert, vom meist agilen, kundenorientierten Softwarehaus, das sich bemüht, das Spannungsfeld für alle Seiten einigermäßen erträglich auszubalanzieren bis zum eiskalten Homo Ökonomicus im Großkonzern, für den nur noch Termine und Kostenminimierung zählen und die nicht vertraglich fixierten Interessen des Kunden keine Rolle mehr spielen. Der Auftraggeber liefert sich in beiden Fällen ohne Not dem Auftragnehmer aus, seine Interessen kommen dabei in der Regel unter die Räder.

Geschrieben in Scrum, Management, Agilität | Drucken | Keine Kommentare »

6.6.2009 von Jens Coldewey.

Meine Moderationsausbildung ist jetzt über 15 Jahre her und ich habe seitdem ein paar hundert Workshops, Meetings und Retrospektiven geplant und moderiert; von Routinemeetings bis hin zu emotional und politisch hochbrisanten Konfliktmeetings. Dass ich mir Sam Kaners Buch bestellt habe, lag eher daran, dass Diana Larsen ihn empfohlen hatte: Da musste ja was dran sein. Und es ist etwas dran, sogar sehr viel! Es ist tatsächlich das beste Buch zur Moderation, das ich bisher in der Hand hatte.

Kaner führt in einem sehr kurzen Theorieteil ein in die Gruppendynamik von gemeinsamen Entscheidungsprozessen, stellt dann alle möglichen Werkzeuge und Techniken für die Moderation vor, die jeweils mit Anwendungsbereich, Durchführung und Konsequenzen beschrieben werden, gibt Hinweise, wie man nachhaltige Übereinstimmung herstellt und stellt schließlich Techniken vor, um verbindliche Abschlüsse zu erreichen. Etwa 70-80% der Techniken waren mir bekannt, die anderen sind interessante Variationen, von denen ich sicher das eine oder andere in mein Portfolio aufnehmen werde. Anders formuliert, inhaltlich leistet das Buch das, was geleistet werden muss.

Begeistert hat mich aber die Präsentation: Jede Seite kann für sich stehen, man kann das Buch ebenso als Nachschlagewerk verwenden, wie zum Durchlesen. Jedes Kapitel gibt eine ein- bis zweiseitige Einführung in die Theorie des Themas, dann kommen Praktiken. So enthält alleine das Kapitel “Alternatives to Open Discussion” zwölf Varianten für Meetingformate:

• Small Groups
• Jigsaw
• Multi-Tasking
• Fishbowls
• Scrambler
• Roleplays
• Tradeshows
• Open Discussion
• Individual Writing
• Listing Ideas
• Presentations and Reports
• Structured Go-Arounds

Jedes einzelne Format wird mit Empfehlungen über den Einsatzbereich, genauen Anweisungen zur Durchführung und Variationen beschrieben, in der Regel inklusive der Auswirkungen auf die Gruppendynamik. Da gibt es sowohl für Neueinsteiger als auch für alte Hasen einiges zum Lesen und Nachschlagen. Er spart auch “heiße” Themen wie den Umgang mit “diverse communication behaviour” nicht aus.

Einziger Wermutstropfen, den ich bisher gefunden habe: Zu den Übungen sind praktisch keine Zeitangaben enthalten. Wenn man ein wenig Erfahrung hat, lässt sich das sicher verschmerzen, aber ich empfinde nach wie vor die Zeitangaben in Esther Derbys und Diana Larsens “Agile Retrospectives” als sehr hilfreich bei der Vorbereitung. Zur Ehrenrettung muss man allerdings auch erwähnen, dass Kaner natürlich viel breiter ansetzt und auf jede Form des Workshops anwendbar ist. Das macht Zeitangaben schwierig.

Kurz und gut: Eines der besten Bücher, die ich die letzten Jahre in die Finger bekommen habe und das sicherlich noch viele Stunden auf meinem Schreibtisch vor sich haben wird, auf einem Ehrenplatz neben dem Buch von Esther Derby und Diana Larsen.

Sam Kaner with Lenny Lind, Catherine Toldi, Sarah Fisk, and Duane Berger: “Facilitator’s Guide to Participatory Decision Making”, 2nd edition, Jonny-Bass/Wiley, 2007, ISBN 978-0-7879-8266-9, 341 Seiten

Geschrieben in Management, Buchtipp | Drucken | Keine Kommentare »

22.12.2008 von Jens Coldewey.

Nachdem ich mich in meinem Beitrag “Was ist anders bei agiler Planung” mit den grundlegenden Mechanismen agiler Planung beschäftigt habe, stellte Maximilian Scherf die Frage, “Wie kann ich denn so beurteilen zu welchem Zeitpunkt ich was fertig haben werde?” Die Frage ist sehr berechtigt, aber nicht so einfach zu beantworten, so dass ich hier in einem eigenen Eintrag darauf antworten möchte - zumindest grob.

Grundsätzlich muss man sich darüber im klaren sein, dass eine Terminaussage in einem Softwareprojekt die Vorhersage eines chaotischen Systems ist und damit der Wettervorhersage ähnelt (ich rede hier von chaotischen Systemen im Sinne der Theorie komplexer Systeme, nicht aus der Perspektive von Eltern, die in das Kinderzimmer schauen). Chaotische Systeme zeichnen sich dadurch aus, dass ihr Verhalten umso schwerer vorhersagbar ist, je weiter man in die Zukunft schaut: Die Wettervorhersage für die nächsten fünf Minuten bekommt auch der Laie üblicherweise korrekt hin, für den nächsten Tag müssen selbst Profis erheblichen Aufwand treiben und für mehr als eine Woche sind seriöse Vorhersagen derzeit nicht möglich.

Im Projektmanagement sind die planbaren Zeithorizonte zum Glück deutlich länger: Eine Woche ist meist kein Problem, einen Monat bekommt man auch noch ganz gut hin, ab einem Quartal wird es eng. Eine “genaue” Vorhersage ist daher unmöglich, bei einer “verbindlichen” Zusage muss man schon relativ vorsichtig sein, was man unter welchen Voraussetzungen verspricht. Erlaubt ein Planungsverfahren nur digitale Aussagen darüber, was “geschafft wird”, ist es also unrealistisch und nur wenig brauchbar. Statt dessen braucht man ein Verfahren, das einem zumindest ungefähre Aussagen zur Wahrscheinlichkeit ermöglicht: “So wie dieses Feature derzeit priorisiert ist, wird es mit 80% Wahrscheinlichkeit im nächsten Release enthalten sein”. Genügen einem diese 80% nicht, muss man es eben höher priorisieren - auf Kosten anderer Features, die dadurch weniger wahrscheinlich werden.

Wie kommt man auf Basis agiler Planung zu einer solchen Aussage? Die Basis sind die Schätzungen und die Erfahrungswerte aus den vorigen Iterationen. Die Grafik unten stammt von einem meiner Kunden, also aus einem real existierenden Projekt. In ihr sieht man die aus der Häufigkeitsverteilung abgeleitete Wahrscheinlichkeit, dass innerhalb einer Iteration mindestens n Aufwandspunkte abgeschlossen werden. Man kann aus dieser Kurve zum Beispiel ablesen, dass in mehr als 50% der Fälle mindestens 21 Punkte abgeschlossen wurden, in mehr als 80% der Fälle mindestens 13 Punkte und so weiter. Mit anderen Worten: Ist eine Aufgabe so hoch priorisiert, dass ihr eigener geschätzter Aufwand und der aller höher priorisierten Aufgaben in Summe weniger als 13 Punkte ausmacht, so wird sie in dieser Iteration mit mindestens 80% abgeschlossen werden. Oder noch anders formuliert: Ich kann Aufgaben für bis zu dreizehn Punkte Aufwand für diese Iteration zusagen, wenn mir 80% Erfüllungswahrscheinlichkeit ausreichen. Brauche ich 90%, sollte ich mich auf 10 Punkte beschränken, mit (fast) 100% erreiche ich 8 Punkte und reichen mir 50% so kann ich munter 21 Punkte “versprechen”. Unabhängig von dem, was man versprochen hat, zeigt diese Grafik aber auch, dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen, auch wenn man ziemlich sicher weiß, dass man das kaum erreichen wird (Die Grafik stammt übrigens aus meinem Vortrag für die OOP 2009).

Kann ich für eine gegebene Aufgabe sagen, mit welcher Wahrscheinlichkeit sie innerhalb der nächsten Iteration fertig wird, so kann ich daraus auch längerfristige Vorhersagen ableiten, allerdings erstmal nur unter der — reichlich unrealistischen — Annahme, dass sich die Priorisierung in der Zwischenzeit nicht ändert. In der Regel ist das aber schon mehr als ausreichend, um zum Beispiel den Umfang des nächsten Releases kommunizieren zu können, ohne sich hinterher zu blamieren.

Für längerfristige Vorhersagen wird aber auch eine solche wahrscheinlichkeitsbasierte Technik zu unrealistisch. Hier kann man wieder Anleihen in der Meteorologie nehmen, diesmal in der Klimavorhersage. Dort wird nicht mit einem Modell gearbeitet, sondern es werden verschiedene Szenarien unter verschiedenen Annahmen berechnet, aus denen sich ein Korridor ergibt. Aber das würde jetzt den Umfang eines Blogeintrags endgültig sprengen.

Aufmerksame Leser werden jetzt anmerken, dass ich Maximilian Scherfs Frage eigentlich gar nicht beantwortet habe: Mit diesen Techniken kann man nämlich erstmal nur Vorhersagen darüber treffen, welche Features ich zu einem gegebenen Zeitpunkt wahrscheinlich fertig haben werde, nicht aber, wann ein gegebenes Feature fertig sein wird. Auch wenn der Unterschied subtil ist (und in den meisten Kontexten ohne Bedeutung), reflektiert das eine Grundidee iterativer Entwicklung: Die Termine stehen fest, gedreht wird am Umfang.

Das ist zwar unbequemer, als das übliche “Termine und Umfang stehen fest”, aber dafür erspart man sich das ebenfalls übliche Drehen an der Qualität, um die Zusage einzuhalten. Schlechte Qualität ist schließlich ein Selbst- und Fremdbetrug, der für alle Beteiligten sehr teuer ist. Zwar kann man auch bei agiler Planung darauf bestehen, dass bestimmte Features zu bestimmten Terminen fertig sind, aber eben nicht mehr, als erfahrungsgemäß realistisch sind. Also in unserem Beispiel für nicht mehr als 8 Punkte pro Iteration. Das ist zwar nicht immer bequem für die Verantwortlichen, aber realistisch. Und Management auf Basis unrealistischer Annahmen sollte angesichts der derzeit in der Weltwirtschaft zu besichtigenden Folgen nur noch von wenigen mit “durchsetzungstarkem Management” verwechselt werden und damit verdienter Maßen und endgültig wieder aus der Mode kommen.

Geschrieben in Praktiken, Planung, Management, Agilität | Drucken | 2 Kommentare »

17.12.2008 von Jens Coldewey.

Ein Thema, das meiner Meinung nach oft bei der Ausbildung von Coaches und Scrum Mastern und bei der Einführung von Agilität zu kurz kommt, ist agile Planung. Ich erlebe immer wieder Projektleiter und Scrum Master, die verzweifelt versuchen, ihre Teamplanung in MS Project zu gießen, “weil das hier so gefordert wird”. Das ist in etwa, als würden Sie Spikes unter Ihre Ski montieren, “weil das so gefordert wird”. Machbar, aber sicher keine gute Vorbereitung für außergewöhnlich gute Leistung. Was ist also anders bei agiler Planung?

Um den Eintrag in Grenzen zu halten, möchte ich mich auf die reine Planungstechnik beschränken, also Team- und Kooperationsaspekte außer Acht lassen. Schließlich kann ein Team auch kooperativ Gantt-Diagramme malen, nur es ist eben nicht sonderlich sinnvoll. Warum? Ein wesentlicher Unterschied zu traditioneller Projektplanung ist, dass bei der Agilität nicht die Auslastung der einzelnen “Ressourcen” (dieser Ausdruck lässt so schön vergessen, dass wir über vernunftbegabte Menschen reden!) optimieren, sondern den Durchflussgeschwindigkeit und Durchsatz von neuen Fähigkeiten des Systems. Wir versuchen also, so viel zusätzliche Wertschöpfung fertig zu stellen, wie in guter Qualität möglich, nicht so viel zu arbeiten, wie möglich.

Schlüssel zu diesem Ziel ist die Erkenntnis, dass in der DV-Entwicklung ja keine Maschinen verplant werden, sondern in der Regel hoch qualifizierte Experten, die durchaus in der Lage sind, sich um ihre eigene Auslastung zu kümmern. Die Planung dient also der Koordination und Fokussierung, nicht der der Arbeitszuweisung. Etwas weniger abstrakt wird festgelegt, was zu tun ist, nicht wer etwas tun soll. Die nächste Person, die frei ist, bzw. das nächste freie Paar kümmert sich dann um die nächste Aufgabe, die ansteht. Das wird üblicherweise als “Pull-Prinzip” bezeichnet, oft auch (nicht ganz korrekt) als Kanban.

Dieses System hat Vor- und Nachteile. Zum einen ist es wesentlich flexibler, als eine Zuteilungsplanung, die nur dann gut funktioniert, wenn die Bearbeitungsdauer pro “Ressource” gut vorhergesagt werden kann, aber sehr empfindlich auf Schätzfehler reagiert. Das lässt sich mathematisch mit Hilfe der dabei konstruierten gekoppelten Warteschlangen begründen, die ein chaotisches System darstellen, aber das würde hier zu weit führen. Intuitiv kann das jeder Projektleiter bestätigen, der einmal versucht hat, sein Gantt-Diagramm durchzuhalten oder auch nur aktuell zu halten. Das Pull-Prinzip hingegen reagiert sehr gutmütig auf Schätzfehler und Veränderungen in den Vorgaben, was ebenfalls warteschlangentheoretische Gründe hat.

Der Nachteil ist, dass das Verfahren einen Generalistenansatz im Team benötigt. Teams, in denen jedes Mitglied genaustens seinen “Claim” abgesteckt hat, in dem nur diese eine Person arbeiten darf (”Code Ownership”) bauen trotz Pull-Prinzips genau das gleiche fragile Warteschlangensystem auf, das die Auslastungsplanung schon instabil macht. In der agilen Planung erkennt man diese Situation normalerweise daran, dass an niedrig priorisierten Aufgaben gearbeitet wird, obwohl noch höher priorisierte Aufgaben anstehen, weil “das nur die Eva machen kann”.

Dieser Nachteil ist aber verschmerzbar, weil er ohnehin keine erstrebenswerte Situation darstellt: Wird Eva krank, kann daran das ganze Projekt scheitern. Zudem sind in meiner Erfahrung Kopfmonopole eine der wichtigsten Ursachen für verpasste Termine. Sicherlich wird es immer Aufgaben geben, die Eva effizienter erledigen kann, als Adam. Aber das spielt erst dann eine Rolle, wenn beide auch gleichzeitig anfangen könnten. Bei der Optimierung des Durchsatzes spielt nämlich die Wartezeit auch eine Rolle, anders als bei der Optimierung der Auslastung. Oder, wie Alistair Cockburn formuliert, “Effizienz wird zur Dispositionsmasse abseits des kritischen Pfades”.

Darf man also noch Gantt-Diagramme malen? In seiner Freizeit natürlich. Für ein agiles Projekt spielen sie aber keine Rolle, es gibt keine Entscheidungen, die auf ihnen basieren und sie sind daher Zeitverschwendung. Fortschritt wird mit Hilfe von Burnup bzw. Burndowncharts gemessen und mit lauffähiger Software. Das ist aussagekräftiger, als ein Balken im Gantt-Diagramm, der zu 80% fertig ist, weil 80% der Zeit vergangen sind. Diese Instrumente sind einfacher, effektiver und effizienter, als die beeindruckende Kombinatorik von Ressourcen bei Werkzeugen zur auslastungsbasierten Planung, die von der Realität in der Regel schneller überholt werden, als man sie an der Wand aufhängen kann.

Geschrieben in Planung, Management, Agilität | Drucken | 2 Kommentare »

1.12.2008 von Jens Coldewey.

Auf den XPDays in Hamburg stellte die Pychologin Maud Winkler das Tuckman-Modell der Teamentwicklung vor (genau genommen, das erweiterte Tuckman-Modell von Eberhard Stahl, das dieser in seinem Buch “Dynamik in Gruppen” vorstellt):

• Forming
• Storming
• Norming
• Performing
• Reforming

Die vierte Phase ist die produktivste Phase (wobei man hier vorsichtig sein muss, diese Phase nicht als konfliktfrei zu verstehen, nur werden hier Konflikte produktiv genutzt). Das Durchleben der anderen Phasen ist jedoch notwendige Voraussetzung dafür, dass das Team bei Performing gut arbeitet. Nicht erledigte Aufgaben aus den vorigen Phasen bleiben als Störfaktoren liegen und behindern das Team in der Arbeit. Um das Modell halbwegs realistisch zu gestalten, hat Eberhard Stahl das ursprüngliche Modell um eine iterative Komponente erweitert, die von Frau Winkler sehr betont wurde.

Dieses Modell erlaubt einen interessanten Blick auf agil geführte Teams. In diesen Teams werden regelmäßig Retrospektiven abgehalten, in denen sich das Team in eine Reflexionsphase begibt. Im Sinne des erweiterten Tuckman-Modells wird das Team also in regelmäßigen Abständen wieder in die Reformingphase “gestürzt”, die im Rahmen der Retrospektive bis zum Norming geführt wird. So werden sachliche und zwischenmenschliche Probleme auf einen klaren Zeitpunkt konzentriert, statt ständig im Untergrund zu rumoren.

Das bedeutet aber auch besondere Anforderungen an die Kompetenz des Moderators einer Retrospektive: Wer hier die Teamsituation falsch einschätzt oder angezeigte Interventionen unterlässt oder überspitzt, bewirkt bestenfalls, dass die “unproduktiven” Phasen während der Retrospektive nicht abgeschlossen werden und das Team weiter behindern. Schlimmstenfalls wird das Team gesprengt. Hier hilft ein erfahrener externer Moderator, der auch über den dafür notwendigen psychologischen Werkzeugkasten verfügt.

(Um einer Kritik an dem Modell zuvorzukommen, die Joseph Pelrine auf der Konferenz geäußert hat: Das Modell versucht weder einen Prozess zu beschreiben, noch erhebt es den Anspruch auf einzige Wahrheit. Es dient lediglich dazu, Anhaltspunkte für geeignete Intervention eines Leiters oder Moderators zu geben. Es ist also kein “RUP der Teamdynamik”, sondern eben “nur” ein psychologisches Modell, das ähnlich wie die einschlägigen Kommunikationsmodelle in bestimmten Situationen helfen kann, die aktuelle Situation zu verstehen. Zudem scheint mir das erweiterte Tuckman Modell wesentlich realistischer, als das recht lineare Original, auf das sich Joseph bezog).

Geschrieben in Management, Buchtipp, Konferenzen, Agilität | Drucken | Keine Kommentare »

25.11.2008 von Jens Coldewey.

Am kommenden Freitag, 28.11., werde ich auf den XPDays 2008 in Hamburg über agiles Schätzen und Planen sprechen. Nähere Informationen dazu finden Sie auf dem XPDays Blog.

Geschrieben in Ankündigungen, Planung, Management, Konferenzen, Agilität | Drucken | Keine Kommentare »