Über Management und Effektivitätsteigerung - im Zeitalter der Informatik

Wie immer sind die Bücher von DeMarco und Konsorten ein großes Lesevergnügen.


Vom Buch: Wien wartet auf Dich!
Tom DeMarco, Timothy Lister, Peter Hruschka


"Trotz all dem Gerede über "smarteres Arbeiten" ist die Meinung weit verbreitet, dass richtiges Management nur damit zu tun hat, wie man seine Leute dazu bewegt, härter und länger zu arbeiten, meistens auf Kosten ihres Privatlebens. Manager geben immer damit an, wie viele Überstunden ihre Mitarbeiter leisten und welche Tricks man anwenden kann, um noch mehr aus ihnen herauszuholen."


Die Ideen in diesem Text sind nicht neu, doch schön auf dem Punkt gebracht.
Auffallend, auf jeden Fall, ist die dadurch zum Vorschein kommenden Einstellung (Arbeitsverständnis) des Managements: es wird nicht "geführt" oder "geleitet" ('gemanaged') sondern lediglich mit allen Mitteln versucht, das maximale Möglich von den Mitarbeitern herauszupressen. Dies, natürlich, ist nicht die richtige Vorgehensweise.

Eine Folge aus dieser Vorstellung bezüglich der Führung von Unternehmen (und auch Projekten) ist die, dass die Arbeiten, die Management-Inhärent sind, schlicht nicht durchgeführt bzw. an die Belegschaft weitergeleitet werden (manchmal ist das gut, manchmal aber auch nicht... nur: Was für eine Rolle soll eigentlich das Management dann spielen?).

Nun kann ich diese Gedanken weiter auf die "agilen" Methoden übertragen: Sind diese "Methoden" (insbesondere das "Gedraenge", Scrum, weil sehr stark Prozess-orientiert) doch nicht lediglich noch ein Versuch, nicht "managen" zu müssen, sondern mit Hilfe sogenannter "agilen" Vorgehensweisen sich noch weiter von den Management-Aufgaben (planen, schätzen, koordinieren/organisieren) zu entfernen?



Wenn Sie ein besseres agiles Arbeiten wünschen: http://amtrs.de/savap.htm


Doch wenn Sie überhaupt besser arbeiten wollen: http://amtrs.de/flepa.htm

Produktivitätsteigerung als Folge von "Investitionen", nicht als Folge von dem Einsatz irgendwelchen (agilen) Methoden

Aus dem Buch: Der Termin
Tom DeMarco (1997)

»Im Prinzip ist Prozessverbesserung eine gute Sache. Sie bedeutet, dass Sie Ihren Job immer besser machen. Aber ich bin wenig begeistert von Programmen wie dem CMM-Ansatz, die sich Prozessverbesserung auf ihre Fahne schreiben. Sie werden leicht zum Selbstzweck.«

»So etwas wie eine schnelle Lösung gibt es in unserer Branche nicht. Es gibt keine Möglichkeit, die Produktivität kurzfristig zu steigern. Die Produktivität, die Sie heute erreichen, ist das direkte Ergebnis der langfristigen Investitionen, die vor Ihrer Zeit getätigt wurden. Und auch Sie können die Produktivität nur beeinflussen, wenn Sie Ihrerseits eine langfristige Investition tätigen, die Ihren Nachfolgern zugute kommt.«

Soll man glauben (dürfen), dass man Produktivitätssteigerungen durch Einsatz von "agilen" Methoden erzielen kann?

Ich finde den Text im Buch ganz gut, denn einerseits halte ich auch sehr wenig von CMM und andererseits scheint mir die Erklärung mit der Investition sehr "bodenständig". So etwas fehlt heute in der IT-Industrie.

Auf jeden Fall finde ich die Aussage im Buch sehr interessant.

Kann man Produktivität schätzen? - Und, wichtiger eigentlich: Bringt das was?

Die Bücher von Tom DeMarco sind, irgendwie zeitlos, ein Lesevergnügen 1. Klasse für alle Projektbeteiligten :-)

Vom Buch: Wien wartet auf Dich!
Tom DeMarco, Timothy Lister, Peter Hruschka
Seite 27ff:

Lawrence und Jeffery wollten die Produktivitätseffekte verschiedener Schätzverfahren ermitteln. Ihr Ziel war es, den alten Glauben zu bestätigen oder zu widerlegen, wonach Entwickler (in diesem Fall Programmierer) härter arbeiten, wenn sie ihre eigenen Schätzungen einhalten wollen. Für jedes der 103 Projekte entwickelten Lawrence und Jeffery eine gewichtete Metrik für die Produktivität. Dann teilten sie ihre gesammelten Daten in Gruppen ein, gegliedert nach der Art, wie die ursprünglichen Schätzungen zustande kamen.
[...]
Systemanalytiker sind die besseren Schätzexperten; besser als die Programmierer und besser als die Manager. Sie verstehen typischerweise die Arbeit bis ins Detail, sind aber nicht von dem natürlichen Optimismus der Personen befallen, die die Arbeit durchführen müssen, und auch nicht von den politischen oder budgetären Randbedingungen des Chefs beeinflusst.
[...]
Schlechte Schätzungen und hoffnungslos enge Terminpläne schwächen die Energie von Entwicklern. Capers Jones, der für seine Metrikstudien über Entwicklungsmodelle bekannt ist, hat es folgendermaßen ausgedrückt: "Wenn der Terminplan eines Projekts von Grund auf unrealistisch und unvernünftig ist, so dass selbst mit einer Menge von Überstunden nichts erreicht werden kann, wird das Projektteam zornig und frustriert... und die Moral sinkt auf den Nullpunkt." (Capers Jones, Programming Productivity (New York, McGrawHill, 1986), S. 213)

Dabei spielt es fast keine Rolle, ob die von Grund auf unrealistischen und unvernünftigen Termine vom Chef oder von den Entwicklern stammen.

Das überraschendste Ergebnis der Studie von Lawrence und Jeffery aus dem Jahre 1985 stand ganz am Schluss, als sie die Produktivität der 24 Projekte untersuchten, für die es überhaupt keine Schätzungen gab. Diese Projekte wiesen eine viel höhere Produktivität auf.

[Siehe Tabelle im o.g. Buch. Inhalt: Produktivität ohne Schätzung = 50% mehr als die Schätzung der Programmierer.]

Die Projekte, bei denen der Chef keinerlei Druck bezüglich des Fertigstellungstermins ausübte ("Weckt mich auf, wenn ihr fertig seid!"), wiesen die höchste Produktivität auf.

Mein Fazit: Nun muss ich unbedingt als Systemanalytiker zwar schätzen, der PM muss die Entwickler aber sich selbst überlassen.

Heute was gelernt!

Wie auch immer, bei Projekten sind Schätzungen sehr wichtig, denn es wäre wirklich irrsinnig etwas anzufangen ohne klare Vorstellungen von Zeit und Kosten zu haben. Doch das Mikroschätzen der "agilen Methoden" ist, meiner Meinung nach, overkilled, demnach auch die Einteilung in starren, unflexiblen, "Time Boxen" ("Agilität" lässt gerade ganz lieb grüßen...). Viel besser natürlich: FlePA.

Aber wenn Sie es doch nicht sein lassen können, dann machen Sie es zumindest so richtig wie möglich: SAvAP.