Was ich kann, das kann ich! Ja, klar. Aber wie komme ich dahin? Wie komme ich zum Können? Der Weg scheint steinig und die meiste Zeit bergauf zu führen. Der Weg heißt Lernen. Gepflastert ist er mit Wissen. Das Vorwärtskommen ist die Erfahrung. Beides ist nötig, der Weg und das Voranschreiten. An den Zollstellen entrichten wir unser Lehrgeld aber am Ende wartet die Belohnung. Das Können.

Können warten am Ende des Wegs.

Lernen als Individuum

Wenn ich allein vor einer Aufgabe stehe, dann denke ich darüber nach, wie ich diese Lösen könnte. Wenn mir nichts einfällt, schaue ich im Internet nach oder frage jemand, der sich damit auskennt. Habe ich dann eine Idee, wie ich das Problem angehen kann, mache ich mich an die Arbeit. Das Ergebnis schaue ich mir an, und überlege, ob ich damit zufrieden bin. Wenn ja? Super. Wenn nicht, dann muss ich noch mal ran, bis es passt.

Individuelles Lernen

Ich lerne, indem ich mein Wissen verwende und ein Problem löse. Mit der Erfahrung, die ich beim Problemlösen sammle, erweitere ich mein Wissen und Können.

Lernen als Team

Was passiert, wenn ein Team, also mindestens zwei Beteiligte, eine Aufgabe lösen müssen? Wenn sie die Aufgabe schon tausendmal lösen mussten, dann denken sie nicht lange nach, sondern erledigen diese einfach. Sie sind ein eingespieltes Team. So wie die Techniker in der Formel 1.

Können in Aktion. Ein eingespieltes Team.

Wenn die Aufgabe aber neu ist oder in dieser Form noch nie gestellt wurde? Dann muss sich das Team gemeinsam eine Lösung überlegen. Das heißt, die Teammitglieder müssen miteinander kommunizieren. Sie werfen ihr Wissen in einen Topf, ziehen eventuell noch einen Experten zu Rate und machen sich an die Arbeit. Sie müssen sowohl einzeln als auch gemeinsam die Ergebnisse überprüfen und bewerten.

Teamlernen

Ein Team lernt, indem es das gemeinsame Wissen nutzt und ein Problem löst. Mit der Erfahrung die das gesamte Team beim Problemlösen sammelt, erweitert jedes Teammitglied und damit das gesamte Team sein Wissen und Können. Die Kommunikation zwischen den Teammitgliedern spielt dabei die wesentliche Rolle.

Werden Teams größer oder sitzen räumlich getrennt, dann ist die Kommunikation schwieriger und es gelten die gleichen Mechanismen wie beim Lernen als Organisation.

Lernen als Organisation

Wenn verschiedene Teams ähnliche Aufgaben lösen müssen, dann wäre es sinnvoll, wenn ein Team auf das Wissen und die Erfahrungen der anderen Teams zugreifen kann. Organisationen stehen vor der Aufgabe, das Wissen einzelner Personen oder Teams für andere Teams oder Personen zugänglich zu machen. Da nicht mehr, wie in Teams, Jeder mit Jedem reden kann, um sich Rat zu holen oder Erfahrungen zu vermitteln, müssen andere Strukturen geschaffen werden. Es muss eine Art Über- oder Organisatiosgehirn bereitgestellt werden, das Jeder anzapfen kann.

Lernen als Organisation

Eine Organisation lernt, indem sie das Wissen aller Personen und Teams nutzt, um Probleme zu lösen. Die Erfahrungen, die beim Problemlösen gesammelt werden, werden wiederum allen Personen und Teams bereitgestellt und vermittelt. Wesentlich sind dabei das Medium, das den Wissensspeicher der Organisation bildet und die Kommunikation mit diesem Speicher.

Lernen ist Reflexion und Veränderung

Der Ausgangspunkt in allen drei Szenarios ist vorhandenes Wissen. Durch die Erfahrungen die beim Lösen der Aufgaben gesammelt werden und der Reflexion darüber wird das vorhandene Wissen verändert. Es wird entweder umstrukturiert oder ergänzt.

 

Software Entwicklung ist Lernen

„Software development is an exercise in learning“ beginnt Allan Kelly sein Buch „Changing Software Development: Learning to Become Agile„. Er fährt fort mit „The process of learning and changing is an exercice in knowledge creation. Knowledge itself is learning with action…“.

Er identifiziert drei Bereiche in denen wir durch Software-Entwicklung unser Wissen erweitern:

• Fachwissen, das Wissen der Anwender in ihrer Fachdomäne, für die die Software entwickelt wird.
• Werkzeugwissen, das Wissen wie Programmiersprachen und -werkzeuge einzusetzen sind.
• Prozesswissen, das Wissen wie bei der Software-Entwicklung vorzugehen ist.

Ich ergänze die Liste noch um:

• Architekturwissen, das Wissen, wie Anwendungen „konstruiert“ werden.

Zu allen Wissensbereichen ist Wissen verfügbar. Es steckt in den Köpfen der Menschen, in den Werkzeugen die sie benutzen oder in allen denkbaren analogen und digitalen Medien. Dieses Wissen kann aber immer nur ein Ausgangspunkt sein. Damit dieses Wissen einen Wert hat, egal ob für einen Einzelnen, für ein Team oder für eine Organisation muss es veränderbar sein. Veränderbar, damit es Erfahrungen aufnehmen kann. Veränderbar, damit daraus eine Fähigkeit, ein Können wird.

Wissensgesellschaft?

Wir sind Wissensarbeiter, das Notebook verrät uns!

Wir sind Wissensarbeiter. Wissen ist aber nur die halbe Miete. Wissen ist der Weg. Die Steine einzusammeln, die den Weg pflastern, nutzt nichts. Der Weg will gegangen sein. Nicht der Weg ist das Ziel, sondern das Gehen. Das Können wartet erst am Ende.

Ivar Jacobson hat in seiner Keynote auf der TeamConf 2008 gefragt: Who loves processes? Who hates processes? Ich habe mich in beiden Antwortlagern wiedergefunden. Wenn ich an das Ausfüllen endloser Formulare denke, um einen Änderungsantrag einzureichen, sträuben sich mir die Nackenhaare. Aber andererseits bin ich froh, wenn ich zuverlässig informiert werde, dass ein Bug gefixt wurde und zum Testen bereit steht.

Was sind die Kriterien, um die empfundene Zu- oder Abneigung gegen Prozesse zu erklären? Intuitiv würde ich antworten: „Solange Prozesse meine Arbeit unterstützen und erleichtern finde ich sie gut aber wenn Prozesse mich in meiner Arbeit behindern, verzichte ich sehr gern darauf.“.

Ich versuche mich der Antwort durch zwei Hintertürchen zu nähern. An der ersten Tür steht: Systemtheorie.

Software Entwicklung als Soziotechnisches System

Dass Software gemeinsam mit dem Computer auf dem sie läuft, als System bezeichnet wird, ist so in unserem Sprachgebrauch aufgegangen, dass wir nicht mehr darüber nachdenken.

Ein System als Blackbox

Von Außen betrachtet ist ein System eine Blackbox, die auf unsere Eingaben (Input) irgendwie reagiert (Output). Wie dabei das Innere aussieht (Struktur) und was im Inneren vor sich geht (Verarbeitung) bleibt uns verborgen.

Wenn wir die Softwareentwicklung als Blackbox betrachten, würde es so aussehen:

Das System der Softwareentwicklung

Wir füttern diese Box mit Kundenwünschen und bekommen ein Softwareprodukt geliefert, dass (im Idealfall) diese Wünsche erfüllt. Wenn wir einen Blick in diese Box werfen, sehen wir Menschen, die an Computern sitzen und in Gemeinschaftsarbeit die Kundenwünsche in ein Softwareprodukt verwandeln. Während wir beim Computersystem von einem rein technischen System sprechen, wird die Softwareentwicklung als Soziotechnisches System bezeichnet. Die innere Struktur wird durch Menschen, Technologien und Prozesse gebildet.

Die innere Struktur eines Soziotechnischen Systems wird durch Menschen, Technologien und Prozessen gebildet.

Entropie – das Maß der Unordnung in einem System

An der zweiten Hintertür steht Entropie. Entropie wird als physikalische Zustandsgröße zur Beschreibung von Systemen verwendet. Für uns reicht es, wenn wir sie uns als Ordnung bzw. Unordnung vorstellen. Mein Arbeitsplatz am Freitag ist ein System mit hoher Entropie = hoher Unordnung und der „Pragmatische Programmierer“ spricht von Software Entropie und davon dass Software vergammelt.

Mein Arbeitsplatz am Freitag

Das Finanzamt ist ein gutes Beispiel für eine Einrichtung mit niedriger Entropie = hoher Ordnung.

Behörden als Einrichtungen großer Ordnung

Fluch oder Segen?

Eins fällt in beiden Beispielen auf. Richtig produktiv ist niemand. Ich brauche die meiste Zeit, um das Chaos zu beherrschen während die Beamten damit beschäftigt sind, die Ordnung aufrecht zu erhalten. Ich würde mehr auf die Reihe bekommen, wenn ich meinen Schreibtisch aufräumen würde und unsere Steuererklärungen würden schneller bearbeitet werden, wenn die Gesetze und Verfahren einfacher wären. Grafisch würde das so aussehen:

Einfluß der Ordnung / Unordnung auf die Produktivität

Interessanter Weise ist die Produktivität sowohl bei maximaler Unordnung als auch bei maximaler Ordnung am geringsten. Für die Softwareentwicklung bedeutet das, dass ganz links das Chaos und ganz rechts die formale Einhaltung von Arbeitsabläufen die Produktivität bremsen. Da die meisten Menschen etwas Sinnvolles in ihrem Leben leisten möchten, und sich am wohlsten fühlen, wenn sie „etwas geschafft“ haben, nimmt das subjektive Wohlbefinden (bezogen auf die Arbeit) zur Mitte hin zu. Da die Entropie in unserem System der Softwareentwicklung von den drei Strukturelementen Menschen, Technologien und Prozesse abhängt, können wir daraus ableiten, wie Prozesse von den beteiligten Personen empfunden werden:

Subjektives Empfinden von Prozessen

Auf der linken Seite helfen geordnetere Arbeitsabläufe, produktiver und damit zufriedener zu sein. Prozesse werden als Segen empfunden. Wenn das Prozessspiel aber weiter getrieben wird, kippt die Stimmung. Die Produktivität sinkt und damit auch das Wohlbefinden. Prozesse werden als sinnlos und als Behinderung angesehen. Sie werden zum Fluch!

無駄 (sprich: Muda)

Damit ein System etwas leisten kann, muss Energie zugeführt werden. Das ist beim Auto genauso wie in der Software  Entwicklung. Leider wird diese Energie nur zum Teil in nutzbare Leistung umgesetzt. Der Rest ist Verschwendung (Muda)! Aber selbst die Verschwendung kann noch einmal in notwendige und in unnötige Verschwendung unterteilt werden. Notwendig ist z.B. die Beleuchtung des Autos auch wenn sie nicht zur Fahrleistung beiträgt. Aber wenn zu wenig Luft auf den Reifen ist und dadurch mehr Sprit verbraucht wird ist das unnötige Verschwendung. 

Verwendung der zugeführten Energie

Wenn wir uns anschauen, wofür die Energie in der Software Entwicklung verbraucht wird, dann sehen wir, dass links und rechts in den „Produktivitätstälern“ gleich wenig Energie in die Wertschöpfung fließt. Der Energieverbrauch der Verschwendungsarten ist allerdings unterschiedlich. Während auf der linken Seite, dem Chaostal, die Unnötige die Oberhand hat, verschlingt im Ordnungstal die Notwendige Verschwendung die meiste Energie.

Energiebilanz im Verhältnis zur Entropie

Wenn wir nun den Berg aus dem Chaostal erklimmen wollen, müssen wir uns zwangsläufig mit der unnötigen Verschwendung auseinander setzen. Hier helfen uns Mery und Tom Poppendieck, die die Konzepte des Lean Product Development für die Software Entwicklung (Lean Software Development) aufbereitet haben.

Mt. Fuji

Das erste und wichtigste Prinzip der Lean Philosophie ist: Beseitige die Verschwendung (Muda)! Noch einmal: Verschwendung ist das, was keinen Wert für den Kunden erzeugt. Die größte und offensichtlichste Verschwendung sind also Dinge die produziert (oder mit auf den Berg getragen werden) und nicht gebraucht werden. Tolle Features, die niemals ein Anwender aufrufen wird. Diese Funktionen kosten nicht nur bei ihrer Herstellung Zeit, sie vergrößern auch die Komplexität der Anwendung. Da sich die Komplexität leider nicht linear auf die Kosten auswirkt sondern exponentiell, tragen also unnötige Funktionen exponentiell zur Verschwendung bei.

Wir wollen noch verweilen, die Aussicht ist so schön.

Nachdem wir uns von dem unnötigen Ballast befreit haben und auf dem Gipfel angekommen sind, wollen wir so schnell nicht wieder herunter. Die Aussicht ist so toll und der Abstieg ist nicht gut für die Knie.

Sonnenaufgang auf dem Mt. Fuji.

Aber was, wenn wir keine Wahl haben? Wenn Gesetzgeber oder Auftraggeber eine höhere Ordnung verlangen? Auch wenn akzeptiert wird, dass Softwareentwicklung in bestimmten Branchen aufwendiger und teurer ist, wird auch hier der Kostendruck immer größer. Wie kann verhindert werden, dass die Produktivität durch Ansteigen der Ordnung sinkt? Warum kann sie nicht auch weiter steigen?

Dilemma: Sinkende Produktivität bei steigender Ordnung

Um im Tal der Ordnung produktiver zu sein, muss auch hier die Verschwendung minimiert werden. Aber im Gegensatz zur Unnötigen Verschwendung im Chaostal, hat hier die Notwendige Verschwendung die Oberhand. Die Energie wird also benötigt, um die geforderte Ordnung aufrecht zu erhalten. Aber vielleicht sind ja die Maschinen und Verfahren veraltet, die zur Erhaltung der Ordnung verwendet werden? Vielleicht ist deren Wirkungsgrad so miserabel, das wir an die Anfänge der Dampfmaschine erinnert werden.

Wir begeben uns also wieder auf die Suche nach Dingen, die keinen Wert für den Kunden erzeugen. Das könnten z.B. Managementberichte sein, die benötigt werden, um das Projekt zu lenken. Die Notwendigkeit des Berichts ist begründet aber die Art und Weise, wie dieser Bericht erstellt wird, ist die pure Energieverschwendung. Wenn wir auf einen Berg steigen, nehmen wir sicherlich etwas zu trinken mit aber wir überlegen uns gut, ob wir für eine Tagestour 10 Liter Wasser nach oben tragen wollen oder ob wir nicht mit einem Liter auskommen und lieber etwas Geld mitnehmen, um uns oben mit einem frisch gezapften Bier zu belohnen.

Lösung: Energieaufwand für unterstützende Tätigkeiten verringern.

Wenn es uns gelingt, den Energieaufwand für die notwendigen, ordnenden Prozesse zu verringern, dann steigt nicht nur die Produktivität, auch die Prozesse werden nicht mehr als Arbeitsbehinderung, als Fluch wahrgenommen.

Selbstähnlichkeit

Eine mögliche Betrachtungsweise unserer Welt ist die Systemsicht. Die Welt besteht aus Systemen, die wiederum aus Systemen zusammengesetzt sind. Die Teilsysteme stehen untereinander in Beziehung und kommunizieren miteinander. Deshalb ist das Gesamtsystem mehr als nur die Summe der Subsysteme.

Im Großen wie im Kleinen (Selbstähnlichkeit)

Für die Software Entwicklung ist das kleinste System ein Programmierer, der an seinem Rechner eine Software erstellt. Er überlegt sich dafür, wie er vorgehen muss und wie er seine Arbeit organisiert. Ein Team besteht aus mehreren „kleinsten Systemen“. Hier müssen sie sich gemeinsam Gedanken machen, wie sie bei der Realisierung vorgehen. Das lässt sich weiter fortsetzen auf größere Projekte an denen mehrere Teams arbeiten oder auf Software Firmen, die mehrere Projekte gleichzeitig abwickeln. Die Strukturen sind gleich und damit gelten auch die gleichen Gesetze. Die Schwierigkeit besteht in der Beherrschung der steigenden Komplexität.