Agile Softwareentwicklung folgt den 6 Faktoren für produktive Wissensarbeit

“Die größte Herausforderung für das Management des 21. Jahrhunderts ist die Steigerung der Produktivität der Wissensarbeit”, schrieb Peter F. Drucker in seinem 1999 veröffentlichten Essay “Knowledge Workers – The biggest challenge”.

Er nannte darin die folgenden sechs Faktoren, um diese Produktivitätssteigerung zu erreichen. 

1. Wissensarbeiter definieren ihre Aufgabe selber.
2. Wissensarbeiter arbeiten eigenverantwortlich und autonom.
3. Kontinuierliche Innovation ist ein ständiger Bestandteil der Wissensarbeit.
4. Kontinuierliches Lernen und Lehren ist ebenfalls ständiger Bestandteil der Wissensarbeit.
5. Anders als in der Güterproduktion liegt der Fokus viel mehr auf Qualität als auf Quantität.
6. Wissensarbeiter sind nicht den Kosten einer Organisation, sondern vielmehr ihren Vermögenswerten zuzuordnen.

Keine anderthalb Jahre nach Druckers Veröffentlichung entstand das Agile Manifest. Auch darin geht es um Wissensarbeit und Produktivitätssteigerung. Oder sollte ich besser sagen, es geht um die Möglichkeit einer Produktivitätssteigerung? Diejenigen, die diese Möglichkeiten der Agilität erkannt und erlebt haben, werden sich von Druckers sechs Faktoren bestätigt sehen und noch genauer auf ihre Umsetzung und Förderung achten. Wer noch wenig mit Agiler Softwareentwicklung zu tun hatte, den hoffe ich zu ermutigen, sich weiter damit zu beschäftigen und Agile Softwareentwicklung insbesondere aus dem Blickwinkel der Wissensarbeit und Druckers Thesen zu betrachten. Diese Hoffnung habe ich letztlich auch für die kritischen Geister, sei es aus theoretischen Überlegungen oder praktischen Erfahrungen. Agile Softwareentwicklung ist in meinen Augen keine Alternative, sondern die Lösung – wenn sie im passenden Kontext zur Anwendung gebracht wird. Dieser Kontext erscheint mir da gegeben, wo Druckers sechs Faktoren beachtet und gefolgt werden.

Wer neugierig oder wenig vertraut mit Agiler Softwareentwicklung ist, holt sich vor dem nächsten Abschnitt vielleicht noch schnell einen frischen Kaffee. Wer Peter Drucker schon kennt, kann den nächsten Abschnitt überspringen. Wer’s lieber kurz mag, der darf jetzt zum letzten Abschnitt springen.

Peter Drucker – Vater der Wissensarbeit

Zunächst also noch ein paar Worte zu Peter F. Drucker und dem Begriff der Wissensarbeit. Drucker gilt als der große Management-Vordenker des 20. Jahrhunderts. Er ist Autor von 39 Büchern, arbeitete seit den 1940er Jahren als Berater für namhafte Unternehmen wie General Electric, Coca-Cola, Citicorp, IBM und Intel, daneben viele staatliche Einrichtungen aber auch NGOs. Außerdem lehrte er über 30 Jahre an der auch nach ihm benannten Peter F. Drucker & Masatoshi Ito Graduate School of Management an der Claremont Graduate University . Das 2006, ein Jahr nach seinem Tod, gegründete Drucker Institut  hat die Unterstützung und Stärkung von Organisationen durch Druckers Ideen zum Ziel um so positiven Einfluss auf die gesamte Gesellschaft zu nehmen – eines von Druckers großen Anliegen. Mit dem Drucker Institut verbunden ist die Peter Drucker Society , welche seit 2009 das Global Drucker Forum organisiert auf dem sich jährlich namhafte Managementexperten zusammenfinden um Druckers Ideen und Ideale in Organisationen und Gesellschaft weiter voranzubringen.

Peter Drucker hatte den Begriff der Wissensarbeit bereits gegen Ende der 1950er, also etwa 40 Jahre vorher, selber eingeführt. Das wichtigste Merkmal eines “knowledge workers” war für Drucker, dass dieser sein Wissen zur Verrichtung seiner Arbeit einsetzt. Im Gegensatz zum “manual worker”, der für seine Arbeit körperliche Kraft und Koordination verwendet. Das mag zur heutigen Zeit banal klingen und so sind die Definitionen derer, die sich heutzutage mit dem Thema auseinandersetzen, wesentlich differenzierter, wie man an der von Jörg Dierbach zusammengetragenen Liste  erkennen kann. Druckers Abgrenzung des “manual workers”, in Deutschland würden wir ihn wohl Fabrikarbeiter nennen, vom Wissensarbeiter hat natürlich seinen Grund.

Der wichtigste und tatsächlich einzigartige Beitrag des Managements im 20. Jahrhundert sei, so Drucker wörtlich, die Erhöhung der Produktivität der Arbeiter um das 50-Fache. Nun sei es, so Drucker weiter, der mit Abstand wichtigste Beitrag, den Management im 21. Jahrhundert liefern müsse, eine vergleichbare Produktivitätssteigerung in der Wissensarbeit mit den Wissensarbeitern zu erzielen. Die 50-fache Steigerung hat in etwa tatsächlich kumuliert über das vergangene Jahrhundert stattgefunden. Die Grundlage dafür liegt auch für die meisten Experten in den Erkenntnissen Frederick Winslow Taylors  begründet, welche dieser in seinem 1911 veröffentlichten Werk “The Principles of Scientific Management” zusammenfasste. Alle darauf folgenden produktivitätssteigernden Neuerungen im Bereich der Produktion, von Deming bis Lean, führt Drucker auf Taylor zurück, der seiner Ansicht nach der erste war, der Wissen auf manuelle Arbeit angewendet hat. 

Wissensarbeiter definieren ihre Aufgabe selber und arbeiten eigenverantwortlich und autonom

Der Kern von Taylors Arbeit mag mit unserem heutigen Wissensstand ebenfalls banal klingen. Vereinfacht dargestellt war es schlicht das Zerlegen, Analysieren und Verbessern der einzelnen Arbeitsschritte. Abgesehen natürlich von den nötigen technischen Voraussetzungen sind sich heutige Experten einig, dass uns erst Taylors Einsichten und Ansätze die immensen Produktivitätssteigerung in der Massenproduktion ermöglichten. Niels Pfläging, Autor von “Organisation für Komplexität”, weist darauf hin, dass hier allerdings auch der Ursprung der Trennung von Denken und Handeln, von Management und Arbeitern bzw. Vorgesetzten und Untergebenen liegt. Diese spiegelt sich bis heute in den Organigrammen unserer Organisationen wider. Vereinfacht dargestellt: Oben wird gedacht, unten wird gehandelt.

Denken ist aber gerade das herausragende Kennzeichen der Wissensarbeit. Eine Trennung von Denken und Handeln passt also überhaupt nicht dazu. Die Schlussfolgerung: Die Management-Methoden, welche immer noch das tayloristische Gen in sich tragen, passen nicht. Wissensarbeiter denken selber und folglich kann es auch nicht mehr das Management sein, welches die Aufgabe des Wissensarbeiters definiert, sondern nur der Wissensarbeiter selber. Ein herausragendes Beispiel dazu stellt für mich das Manifest der Agilen Softwareentwicklung dar. Hier liefern genau diejenigen, welche den Job machen, die Definition ihrer Aufgabe, beginnend mit dem ersten Satz.

“Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.” [http://agilemanifesto.org/iso/de/]

Wie jetzt? Was hat man denn bis dahin gemacht? In einem Wort: abgekupfert. Man hat versucht Softwareprojekte in ähnlicher Art und Weise zu realisieren, wie man ingenieurmäßige Projekte realisiert hat. Zum Beispiel wie den Bau eines Gebäudes. Dabei hat man den Softwareentwicklern mit Software Engineer zwar die Bezeichnung des Ingenieurs gegeben, sie aber weiter als Arbeiter einsortiert und behandelt. Ausnahmen waren vielleicht spezielle Rollen wie z.B. die des Software-Architekten.

Ich werde im Folgenden nur wenig auf die weiteren Details des Agilen Manifests eingehen. Der entscheidende Punkt ist, dass das Agile Manifest Druckers ersten Faktor zum Fundament hat. Um dies zu verdeutlichen, möchte ich die Frage stellen, wer in der Mehrzahl einerseits die sogenannten klassischen und andererseits die agilen Softwareentwicklungsansätze propagiert. Mein Empfinden ist, dass es bei ersterem vor allem Manager, darunter eben auch viele Projektmanager, sind. Wie sieht es bei der Agilen Softwareentwicklung aus? Hier scheint mir die Mehrzahl Entwickler zu sein. Ich behaupte, wenn Drucker recht hat und meine Einschätzung zutrifft, dann tragen Softwareentwicklungsprojekte nach klassischen Methoden nicht zur Produktivität der Softwareentwickler bei. Ganz im Gegensatz zur Agilen Softwareentwicklung. 

Der zweite von Drucker genannte Faktor ist die zwingende Folge des ersten. Wenn ich den Kern und Umfang meiner Tätigkeit als Wissensarbeiter festlege, so muss ich konsequenter Weise völlig autonom und eigenverantwortlich über den Weg und das Wie bestimmen können. In agilen Methoden wie beispielsweise Scrum oder Kanban spiegelt sich das meines Erachtens deutlich wider. Selbstorganisiation wird dabei inzwischen auch von tayloristisch geprägtem Management begrüßt. Aus eigener Erfahrung kann ich hier anmerken – leider häufig und letztlich schädlich aus der falschen Motivation heraus.

Der Fokus liegt viel mehr auf Qualität als auf Quantität

Eine Unterscheidung zwischen den klassischen und den agilen Ansätzen wird in letzter Zeit unter dem Begriff der “Bimodalen IT” getroffen. Dabei wird Qualität und Verlässlichkeit den klassischen Ansätzen und Geschwindigkeit und Flexibilität den agilen Ansätzen zugeordnet. Eine irreführendere Ansicht kann ich mir kaum vorstellen. Der Anspruch der Agilen Softwareentwicklung ist es, “bessere Wege” zu schaffen. Dass dies in fast allen Fällen mit kontinuierlicher Auslieferung und damit schneller Reaktion auf Veränderungen einhergeht, heißt doch nicht, dass man dies auf Kosten von Qualität und Verlässlichkeit tut. Im Gegenteil, den Anspruch an die Qualität der agilen Softwareentwickler zeigt sich für mich deutlich z.B. in den unter den Begriffen Software Craftmanship oder Clean Code angewandten Ansprüchen und Methoden. Wer meint, Agile Softwareentwicklung sei per se schneller, befindet sich auf dem Holzweg. Agile Softwareentwicklung hat höhere Qualität, nicht Quantität, zur Folge. Und zwar in dem Sinn, dass die Software die Erwartungen der Anwender trifft und den zum gegebenen Zeitpunkt größtmöglichen Wert liefert. Darüber hinaus ergibt sich der Geschwindigkeitsvorteil bei funktionierenden agilen Teams nicht hinsichtlich der Gesamtprojektdauer, sondern bezogen auf die schnellere Auslieferung von einzelnen und brauchbaren Softwarefeatures. 

Die Differenzierung von Quantität und Qualität liegt laut Drucker ebenfalls in der Verantwortung der Wissensarbeiter selber. Sie müssen bei der Umsetzung ihrer Aufgaben sowohl die benötigte Zeit als auch resultierende Kosten im Blick haben. Insbesondere im Hinblick auf die Kosten scheitert die Eigenverantwortung aus meiner Beobachtung häufig schon an mangelnder Transparenz über diese Kosten. Der Blick für diese Dinge muss sicherlich wie alle anderen Fähigkeiten geschult und entwickelt werden. Wenn ich dazu allerdings keinen Raum gebe, kann dies freilich nicht geschehen. Die Ansätze, den tatsächlichen Wertbeitrag einer realisierten Software oder einzelner Features zu ermitteln, können meines Erachtens dabei eine gute Grundlage bilden. 

Kontinuierliche Innovation und kontinuierliches Lernen und Lehren ist ständiger Bestandteil der Wissensarbeit

In der agilen Softwareentwicklung wird eigenverantwortliches und autonomes Arbeiten im übrigen auch nicht von jeder einzelnen Person erwartet, sondern vom Entwicklungsteam als Ganzem. Damit schafft die Agile Softwareentwicklung – oben genannte Faktoren vorausgesetzt – genau den Raum, um auch die Faktoren kontinuierliche Innovation sowie kontinuierliches Lernen und Lehren zu ermöglichen. Wenn ich z.B. die unzähligen Events auf http://www.meetup.com  anschaue oder die vielen Konferenzen zum Thema, kann ich nur feststellen, dass die Agile Community die letztgenannten Punkte absolut verinnerlicht hat. Wie viel persönliche Freizeit viele Agile Entwickler, Berater und Coaches sowohl in die eigenen Weiterbildung als auch Weitergabe von Erlerntem investieren ist Managern oder anderen Mitarbeitern in vielen Organisationen vermutlich gar nicht bewusst. Viele Agile Praktiken, wie z.B. Pair Programming oder Mob Programming, von dem ich selber vor kurzem erst in einem Kaffeeküchengespräch von einem Kollegen erfahren habe, dienen neben der Erhöhung der Qualität eben auch den kontinuierlichen Lern- und Lehrfortschritten und sorgen für ein erhöhtes Innovationspotential, weil sich niemand mehr für Fehler oder noch nicht vorhandenes Wissen schämen muss. Dass sich kontinuierliche Innovation, Lernen und Lehren ebenfalls allein aus dem einleitenden Satz des Manifests ableiten lassen, muss ich vermutlich gar nicht mehr erwähnen.

Wissensarbeiter müssen als Wert behandelt werden

Vor etwas über einem Jahr hat Christoph Niewerth vom Recruiting-Spezialisten Hays bezugnehmend auf eine umfangreiche Studie seines Hauses Peter Druckers Thesen im Praxischeck betrachtet. Zusammengefasst lässt sich feststellen, dass es nur wenige Unternehmen sind, die einige der Punkte umsetzen. Insbesondere da, wo Wissensarbeiter eigeninitiativ handeln können, werden die Faktoren gelebt. Lernen und Lehren kann man eben auch außerhalb seines Unternehmens. Oder aber es sind freiberuflich Tätige, die z.B. die Möglichkeiten des mobilen Arbeitens nutzen und aufgrund ihres Status autonomer arbeiten. Insbesondere, was die Behandlung von Wissensarbeitern und die Haltung der Manager angeht, stellt Niewerth ernüchternd fest, dass es (noch) nicht gelebt wird.  

“Wissen kann man nicht managen – es sitzt zwischen zwei Ohren”. Auch dieser Spruch stammt natürlich von Peter F. Drucker. Er bringt das ganze Dilemma des tayloristisch geprägten Managements zum Ausdruck. Druckers sechster Faktor weist auf die Lösung dieses Dilemmas hin. Christoph Niewerth fasst das sehr schön zusammen, wenn er schreibt, dass Führungskräfte Zeit in ihre Mitarbeiter investieren und zu Mentoren oder Coaches werden und ihren Mitarbeitern zuhören, sie herausfordern und ermutigen müssen. Hört sich das vielleicht nach einem Teil der Jobbeschreibung eines Scrummaster oder Agilen Coaches an? Für mich schon.

Peter Drucker bringt diesen neuen Blickwinkel auch mit der intrinsischen Motivation des Mitarbeiters in Verbindung, indem er weiter sagt, dass der Wissensarbeiter derart gewillt sein muss, für die Organisation zu arbeiten, dass es für ihn keine andere Option gibt. Intrinsischer Motivation ist zu eigen, dass sie eben nicht von außen angestoßen werden kann. Allerdings kann ihr Raum zur Entfaltung gegeben werden, wenn Demotivation von außen verhindert wird. Management muss Wissensarbeiter also nicht motivieren, sondern Demotivation verhindern, indem es Raum für alle vorgenannten Faktoren schafft. Auch hier muss ich gleich wieder an die Rollenbeschreibung des Scrummmaster denken, dessen Aufgabe es eben auch ist, das Team gegen Einflüsse von außen zu schützen. 

Und wie geht es weiter?

Alle Faktoren zusammen zeigen deutlich, dass Wissensarbeiter sich selber managen. Management, dessen Praktiken immer noch auf den Prinzipien des “Scientific Management” beruhen, wie es in den Anfängen der Massenfertigung funktioniert hat, ist für Wissensarbeiter nicht mehr anwendbar und meines Erachtens sogar schädlich. Es verhindert Produktivität in der Wissensarbeit. Dieser Umstand lässt sich leicht an den vielen Konflikten rund um die Einführung oder Durchführung von agiler Softwareentwicklung erkennen. Diese treten immer dort auf, wo die Organisationskultur die genannten Faktoren nicht oder unzureichend berücksichtigt. Dass die Berücksichtigung dieser Faktoren und Maßnahmen zur Schaffung entsprechender Umgebungen tatsächlich zu erheblichen Produktivitätszuwächsen führen kann, haben bereits viele Projekte und Produkte gezeigt, die nach den Grundsätzen des Agilen Manifests und abgeleiteter Methoden durchgeführt bzw. entwickelt wurden. Die vielen Beispiele, wie die 6 Faktoren auch bei der codecentric AG umgesetzt werden, sind für mich eine weitere Bestätigung von Druckers Faktoren. 

Die Werte und Prinzipien des Agilen Manifests und resultierende Methoden werden bereits in ganz anderen Bereichen als nur der Softwareentwicklung angewendet. Bewegungen und Netzwerke wie Beyond Budgeting, Beta Codex oder Intrinsify.me oder die Events, Diskussionen und Beiträge zu den Schlagworten Leadership und New Work zeigen mir persönlich ebenfalls, dass Druckers These den Nagel auf den Kopf trifft. Damit meine ich auch die Aussage, dass es beim Management liegt, für diese Produktivitätssteigerung in der Wissensarbeit zu sorgen – allerdings völlig anders, als sich dies so mancher Manager vorstellen mag.

Die Gründe, warum die Umsetzung in Unternehmen in den letzten 15 Jahren kaum vorangekommen sind, mögen vielfältig sein, die Lösung ist in meinen Augen die Gleiche. Manager müssen den Blick auf ihre Mitarbeiter ändern. Dazu ist es nötig, gegebenes Wissen kritisch zu hinterfragen und offen zu sein für völlig neue Sichtweisen. War die Aufgabe des Management bisher, verkürzt gesagt, das Denken für die Arbeiter zu übernehmen und Kosten zu minimieren, muss es in einer Gesellschaft der Wissensarbeiter nun die Freiräume schaffen, in denen sich Wissensarbeiter entfalten können. Statt auf Kosten muss sich das Management auf Werte konzentrieren – in jeder möglichen Bedeutung des Wortes.

Ich würde mich freuen, sowohl von betroffenen Wissensarbeitern / Softwareentwicklern als auch von Managern zu erfahren, wie weit sie die Umsetzung der von Drucker genannten Faktoren bereits sehen und ggf. selber fördern und/oder welche Umstände oder Argumente dieser Umsetzung entgegenstehen oder sie behindern.