Sonntag, 8. Februar 2015

Co-location als kontraproduktiv erachtet

Wo ein Entwicklungsteam noch an einem Ort sitzt, sollte es verteilt werden. Entwicklungsteams, die gebildet werden sollen, fangen am besten gar nicht erst an, sich an einem Ort zu versammeln. Verteilte Teams sollten der Default sein.

imageDie Sonne lacht in Hamburg, ein frischer Wind weht an der Alster. Ein guter Tag, um sich unbeliebt zu machen :-) Deshalb diese Vorschläge. Irgendwann muss ich damit mal raus. Warum nicht heute?

Ja, so denke ich inzwischen immer mehr. Co-location ist ein Problem.

Aber der Reihe nach:

Im Jahr 2001 wurde das Agile Manifest unterzeichnet von 17 umtriebigen Geistern - alle weiß, männlich, vor allem Amerikaner und im Durchschnitt zu dem Zeitpunkt wohl um die 50 Jahre alt. Das sage ich so, weil ich glaube, dass wir Agilität wie sie seitdem von den Unterzeichnern gepredigt und von anderen übernommen wurde, davon nicht unabhängig sehen dürfen. Die Unterzeichner sind auch nur Menschen. Sie sind mithin Kinder ihrer Zeit und ihrer Erfahrung. Sie hatten und haben einen je eigenen Horizont, in dem sie denken und innovieren können. Genauso wie Sie und ich ebenfalls.

Scrum wurde von Schaber/Sutherland Mitte der 1990er entwickelt. Da war Schwaber schon 50 und Sutherland wahrscheinlich auch. Sie haben sich darin eingebracht mit allem besten Willen und all ihrer Erfahrung. Nicht weniger - aber eben auch nicht mehr.

Die Frage ist daher: Was war ihre Erfahrung? Und was für ein Ziel lässt sich daraus ableiten?

Das Ziel beschreibt am Ende das Agile Manifest: Es geht um den Softwareproduktionsprozess. Der soll flüssiger werden, der soll näher am tatsächlichen Bedarf laufen. Die Softwareentwicklung soll sich nicht ablenken lassen durch eingefahrene Regularien, Werkzeuge, Dokumentationsanforderungen, Vertragsverhandlungen oder überdimensionierte, schnell veraltende Pläne.

Gut so! Das Manifest enthält wunderbare vier Maximen.

Und dennoch: Es geht um Produktivität. So sehen denn auch die Mittel aus, die zum Einsatz kommen:

  • Statt einmaliger Großplanung lieber iteratives Vorgehen in Lernschleifen.
  • Statt technischer Meilensteine lieber inkrementelles Vorgehen für schnelleres Feedback.
  • Statt Abteilungsgerangel lieber cross-functional teams.
  • Statt langsamer indirekter Kommunikation über Hierarchieebenen hinweg lieber schnelle persönliche Kommunikation auf Augenhöhe durch co-location aller Teammitglieder.

Habe ich noch etwas vergessen? Bestimmt. Aber ich glaube, das sind die zentralen Mittel agiler Softwareentwicklung. Auf die sind 50jährige Männer nach intensiver Beobachtung und Diskussion gekommen.

Das ist wunderbar - außer, wenn es nicht wunderbar ist ;-) Denn es steckt in diesen Mitteln Zeitgeist und technische Möglichkeit. Man wusste es halt nicht besser, man konnte nicht anders. Doch seitdem hat sich die Welt gedreht. Wir sind 20 Jahre nach Scrum, 14 Jahre nach dem Agilen Manifest.

Innerhalb meines bescheidenen Horizonts halte ich das iterative/reflektierende Vorgehen für zeitlos. Auch am inkrementellen Vorgehen habe ich nichts auszusetzen. Außer, dass ich es oft noch für zu grobgranular halte und die Iterationen mir zu lange dauern. Aber grundsätzlich bin ich ganz dafür. Und auch die cross-functional teams sind für mich eine sine qua non. Nur so lassen sich Abhängigkeiten flüssig entschärfen.

Bei der co-location hingegen bin ich nicht mehr dabei. Hier sehe ich die weithin real existierende agile Praxis in den 1990ern verharren. Schwaber, Jeffries, Martin & Co sind eben keine digital natives. Sie hatten Email, aber auch wenn Ward Cunningham mit von der agilen Partie war, waren Wikis kein für die Massen verfügbares Werkzeug. Social Media waren in den Kinderschuhen wenn überhaupt Smartphones gab es noch lange nicht. Verteilte Versionsverwaltung lag noch in der Zukunft. Infrastruktur in der Cloud zum kleinen Preis ließ sich noch nicht denken.

Und so sah man sich außerstande, etwas anderes als co-location für die Zusammenarbeit zu empfehlen. Das war ja auch viel besser, als Leute auf office cubicles zu verteilen, oder?[1]

Irgendwie schon. Aber dann doch wieder nicht. Denn ich sehe durch die co-location drei fundamentale Probleme in der Praxis entstehen:

  1. Co-location öffnet Unterbrechungen Tür und Tor. Wer im team room nahe beieinander sitzt, kann die Kollegen schnell mal ansprechen. Das ist auch Sinn und Zweck. Fowler sagt: “[I]t promotes lots of informal and deep communication between people on the team.” Was für den, der einen anderen anspricht eine tolle Vereinfachung ist, ist für den Angesprochenen hingegen oft das Gegenteil, nämlich eine Erschwernis seiner Arbeit. Wer angesprochen wird, wird unterbrochen, d.h. aus seinen Gedanken gerissen, im Arbeitsfluss gestört. Da macht es auch nichts, dass der Ansprechende ganz wohlmeinend oder sehr bedürftig ist. Unterbrechungen stören die konzentrierte Herstellung von Resultaten. Das gilt für Unterbrechungen durch Manager, die plötzlich im Raum stehen, genauso wie für Unterbrechungen durch Teammitglieder - oder auch selbstverschuldete Unterbrechungen durch Social Media Benachrichtungen.
  2. Co-location leistet unentdeckten Abhängigkeiten Vorschub. Wer im team room sitzt, muss sich tendenziell weniger Gedanken machen über das, was er braucht, um seine Resultate zu erzielen. Abhängigkeiten von Technologien oder Anforderungsverständnis müssen nicht vorher entdeckt und aus der Welt geschafft werden, sondern können ja im Zweifelsfall jederzeit durch Nachfrage bei einem Kollegen aufgelöst werden. Irgendwer weiß immer Bescheid, dafür ist das Team doch cross-functional. Daraus entstehen nicht nur Unterbrechungen für Kollegen, sondern auch geringere Produktivität. Denn so wie ein Koch produktiver ist, wenn er in Phasen arbeitet, also z.B. Gemüse erst komplett schneidet, so ist Softwareentwicklung auch produktiver, wenn sie in Phasen arbeitet; das sind mindestens Analyse, Entwurf, Implementation.[2]
  3. Co-location fördert monolithischen Code. Wenn auch nur irgendetwas an Conways Gesetz ist, dann dürfen wir uns nicht wundern, dass 14 Jahre Agilität den monolithischen Anwendungen nicht den Garaus gemacht haben.[3] “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” Und was für eine “communication structure” soll ein co-located team im team room haben? Eine sehr, sehr enge. Was bedeutet das für das “design”, d.h. die Struktur ihres Produktes Software? Es wird aus eng verbundenen Teilen bestehen.

Auch ich habe meinen Hintergrund. Vor dem sehe ich auf Agilität. Ich bin weniger am Prozess interessiert als am Code.[4] Der muss wandelbar, evolvierbar sein, sondern ist die Softwareentwicklung nicht zukunftsfähig.

Ja, da sehe ich das große Problem unserer Tage in der Softwareentwicklung: Wandelbarkeit. Sogar nicht nur Code, sondern auch Teams (und Unternehmen) müssen wandelbar sein, sich also anpassen können. Dazu gehört natürlich Reflexion, wie sie in der Agilität drinsteckt. Doch es braucht noch mehr. Ohne passende Strukturen lassen sich Ergebnisse der Reflexion nur schwer oder gar nicht umsetzen.

Die meisten Projekte leiden nicht unter technologischen Schwierigkeiten. Wir haben Hardware und Frameworks und Dienste, die leistungsfähig genug sind, um die Effizienzanforderungen an Software zu erfüllen. Das war bis vor 10 Jahren noch ganz anders. Deshalb war Wandelbarkeit für die Agilität auch kein großes Thema. Clean Code kam erst sieben Jahre nach dem Agilen Manifest und 13 Jahre nach Scrum.

Doch nun haben sich die Zeiten gewandelt. Wandelbarkeit ist das zentrale Thema - wenn man nicht grad dem nächsten noch besseren Framework hinterherjagt. Auch die aktuelle µService-Bewegung ist ein Ausdruck des Leidens am Monolithen, an der Unwandelbarkeit.

Und wodurch sind wandelbare Strukturen gekennzeichnet? Durch lose Kopplung. Ein älteres Prinzip gibt es wohl kaum in der Softwareentwicklung.

Lose Kopplung entsteht durch Kapselung (klare Schnittstellen, Autonomie, geringe Abhängigkeiten) und asynchrone Kommunikation.

Wenn man diese Eigenschaften für ein Softwaresystem will, wie ist das zu vereinbaren mit co-location im team room? Wie können lose Kopplung und auch wandelbare verteilte System einfach entstehen, wenn die, die sie herstellenn sollen, einander auf dem Schoß sitzen?

Hier sehe ich die vorherrschende Implementation von Agilität gegen eine Wand laufen. Man macht es sich schwer bis unmöglich, das zentrale Problem der Softwareentwicklung unserer Zeit zu lösen, wenn man als Default für die Teamorganisation den team room setzt.

Entwickler, die man im selben Raum zur selben Zeit sehen will, können eine Menge herstellen - aber entkoppelte Strukturen bzw. wandelbare Software ist sicherlich nicht das Produkt, was ihnen am leichtesten aus den Fingern fließt.

Das Agile Manifest ist gut, wofür es gedacht ist: Produktivität. Es kommt aber an seine Grenzen, wenn es Mittel verschreibt, die der Erfüllung anderer Anforderungen im Wege stehen, hier der Wandelbarkeit.

Deshalb mein radikaler Vorschlag: Geben wir die co-location auf! Setzen wir die Verteilung von Teams als Default. Befreien wir Teammitglieder von Bindungen an Raum und Zeit.

Wir haben genügend Kommunikationsmittel und Tools, um jederzeit Kontakt aufzunehmen zu Kollegen, egal wo sie sich befinden. Chat, Telefon mit Anrufbeantworter, Diskussionsforen, Wikis, Issue Tracker, Repositories, Videokonferenzen, online Whiteboards und was es noch alles gibt in tausend und einer Ausprägung. Asynchrone Kommunikation in unterschiedlicher Geschwindigkeit ist kein Problem. Jeder ist immer erreichbar. Gut so! Wir können unsere Anliegen immer zustellen - ohne den anderen zu unterbrechen. Das sorgt für konzentrierte Arbeit. Das ist gelebte Autonomie: Ich bestimmte selbst über die Nutzung meiner Zeit.

Wohlgemerkt schließt solcher Default der Verteilung nicht die synchrone Kommunikation aus. Zu einem Telefonat oder eine Videokonferenz kann man sich jederzeit verabreden. Das gilt sogar für persönliche Treffen, also Meetings. Niemandem wird verwehrt, sich eine Art der Zusammenarbeit zu wünschen, die für ihn und seine Resultate zuträglich ist. Nur muss das jeder mit den Kollegen verhandeln, denn die mögen andere Vorstellungen davon haben, wie sie ihre Ergebnisse am liebsten erzielen.

Verteilte Arbeit macht es schwerer, dass lokale Resultatsoptima entstehen. Ein Resultat kann weniger einfach auf Kosten vieler anderer Resultate hergestellt werden. Das Ganze wird betont, optimiert - ja, auch wenn ein Einzelner, ein individuelles Resultat dabei einmal zu kurz kommen sollte.

Dass man für verteiltes Arbeit ein paar andere oder gar mehr Soft Skills benötigt, als für die befohlene Arbeit am selben Ort zur selben Zeit wie andere, das mag sein. Man muss sich besser organisieren können, verantwortungsbewusster sein, expliziter und verlässlich kommunizieren… Aber nur weil das schwierig für manche sein mag (ja, auch und gerade für Manager), sollte das nicht bedeuten, dass verteilte Teams nicht anstrebenswert seien. Denn es steht viel auf dem Spiel. Es geht um nicht weniger als die verlässliche Herstellung von Wandelbarkeit. Ohne die gibt es nämlich keine Zukunftsfähigkeit. Sowohl für Code wie für Teams.

Mit verteilten Teams entstehen nämlich nicht nur (einfacher) wandelbare Softwarestrukturen, sondern auch wandelbare Teams. Wo ein Team verteilt arbeitet, ist die Einbindung von neuen Kollegen an beliebigen Orten einfacher. Das ist doch eine gute Nachricht für das Recruiting, oder? Dadurch kommen leichter neue Impulse zu allerlei fachlichen Aspekten ins Team.

Ganz davon abgesehen, dass verteilte Teams weniger hausinterne Infrastruktur brauchen. Heute gibt es alles, was das Entwicklerherz begehrt, in der Cloud. Wer wollte da auch nur einen Server kaufen? Was Entwickler brauchen, sind gute Laptops und viel Internetbandbreite. Gelegentlich noch ein Raum, um tatsächlich mal zusammenzukommen. Am besten mit Beamer/Smartboard und Flipchart. Und das Internet muss stets verlässlich da sein wie Strom aus der Steckdose. Ohne lästige Spezialfirewalls, die Superproxys brauchen, die den Zugriff auf ein DVCS behindern.

Wohlgemerkt, ich rede hier über Entwickler, nicht über sonstige Mitarbeiter von Unternehmen. Was die brauchen, ist eine andere Sache. Aber nur weil die vielleicht etwas brauchen - zum Beispiel ein total supersicheres Firmennetz -, sollte das nicht bedeuten, dass die Softwareentwicklung sich aus Solidarität auch ein Bein hochbinden muss.

Bottom line: Ich glaube, die Zeit der co-location als Default ist vorbei. Angesichts der Kommunikationsmöglichkeiten, die wir haben, hat sie den Punkt erreicht, wo sie kontraproduktiv wird.

Ja, wir haben das Zusammenhocken lieb gewonnen. Irgendwie ist es auch kuschelig mit den Kollegen. Aber was wollen wir? Kuscheln oder wandelbare Software?

Wer kuscheln will, kann z.B. per Chat im Team anfragen, wer mitmachen möchte. Dann kann ein Meeting vereinbart werden. Das sollte jedoch die Ausnahme sein. Synchrone persönliche Kommunikation vieler Teammitglieder macht vielleicht ein gutes Gefühl - aber es wird andererseits auch ganz schnell ganz viel Geld verbrannt.

Die Väter der Agilität haben es gut gemeint. Doch sie waren eben auch begrenzt in ihrer Erfahrung mit Kommunikationstechnologie. Ken Schwaber konnte z.B. nicht anders, als lange Jahre seines Lebens mit Telefon ohne Anrufbeantworter zu leben und zu arbeiten. Dann mit Anrufbeantworter und gelegentlichem Fax. Dann irgendwann später mit Email usw. Kein Wunder, dass er und die anderen co-location als Wunderwaffe empfanden. Irgendwie liegt sie uns ja auch im Blut. Die Bandbreite der Kommunikation ist da so schön hoch.

Aber kuschelige Bandbreite ist eben nicht alles. Wenn ungehinderte Kommunikation in hoher Bandbreite die Norm ist, ist irgendetwas optimiert – und irgendetwas bleibt auf der Strecke. Das ist die Wandelbarkeit.

Drum sage ich: Vorsicht vor der co-location!

So viel Verteilung und Autonomie und Entkopplung wie möglich, so wenig co-location wie nötig.


  1. Wir können spekulieren, wie das Agile Manifest ausgesehen hätte, wenn 50% der Unterzeichner Frauen gewesen wären. Oder das Durchschnittsalter 25 Jahre. Oder unterschiedliche Kulturen vertreten gewesen wären.

  2. Wer hier herauslesen will, dass ich für Big Design Up-Front (BDUF) wäre, liegt falsch. Diese Phasen können manchmal nur Minuten oder Stunden dauern. Selbst in der agile Praktik TDD stecken sie drin - ohne dass das betont würde. 30 Minuten Entwurf mit 2 Stunden folgender Implementation können 5 Stunden vermeintlich reiner Implementation ersetzen, in denen der Entwickler dauernd in unvermutete Abhängigkeiten läuft. Dass man durch beliebig lange Analyse- und Entwurfsphase alle Abhängigkeiten entdecken könnte, behaupte ich auch nicht. Aber ein gesundes Maß an Analyse und Entwurf ist nötig; mehr als oft aufgewandt wird in agilen, co-located Teams.

  3. Ganz davon abgesehen, dass Agilität ja nicht Wandelbarkeit als ausdrückliches Ziel hat. Wie man ganz deutlich an Scrum sehen kann, kümmert sich der agile Prozess gar nicht um die Sache - Code -, sondern nur um den Rahmen für die Produktion der Sache. Nicht umsonst hat Jeff Sutherland nun auch ein Buch geschrieben, das Scrum auf alle möglichen Arbeitsfelder anwendet (“The Art of Doing Twice the Work in Half the Time”).

  4. Allerdings verschiebt sich dieser Fokus notgedrungen in den letzten Jahren. Denn ich merke, dass ich die Verbesserungen, die mir für Code vorschweben, in Unternehmen nicht gut verankert bekomme, wenn mir der Prozess oder gar die Unternehmenskultur egal ist. Aber das ist ein Thema für einen anderen Artikel… ;-)

Donnerstag, 5. Februar 2015

Bessere Resultate ohne Abhängigkeit

Wie arbeiten Sie am liebsten, wenn Sie etwas schaffen wollen oder müssen? Was fördert Ihre Konzentration?

Die Menschen sind ja verschieden. Der eine möchte Ruhe haben, die andere Musik hören, der nächste ein Räucherstäbchen anzünden… Fenster auf, Fenster zu, mehr Licht, weniger Licht… Man kann es kaum allen recht machen, oder?

Eine Konstante gibt es jedoch hinter all dieser Verschiedenheit: den Wunsch nach Autonomie.

Sie wie ich möchten die Umstände unserer Arbeit möglichst weitgehend selbst bestimmen. Umso mehr, je stärker wir unter Druck stehen. Wer von uns Resultate sehen will, der sollte uns möglichst freie Hand lassen, wie wir uns einrichten, um sie zu erzielen. Zumindest wenn man uns vertraut, dass wir uns redlich bemühen, diese Resultate auch zu erbringen.

Ich als Freiberufler lebe und arbeite so. Meine “Resultatserzielungsumstände” kann ich zu 100% selbst bestimmen. Das macht mir Freude - und meinen Kunden auch. Verlässlichkeit und Qualität scheinen für sie zu stimmen.

Anders ist das bei den Entwicklern, Testern, Supportern, POs, die ich bei meinen Kunden treffe. Deren Autonomie ist minimal. Sie können (in den allermeisten Fälle) nicht über Arbeitsort, Arbeitszeit, Arbeitsplatz, Arbeitsmittel bestimmen. Ja, sie können sogar nur begrenzt über die Arbeitszeitnutzung bestimmen.

Das finde ich von Tag zu Tag kontraproduktiver. Je häufiger ich solche Umstände sehe und auf der anderen Seite Klagen darüber höre, was alles in Unternehmen nicht läuft, wie es laufen soll… desto mehr denke ich: Da gibt es einen Zusammenhang. Die Grundverhältnisse sind einfach so, dass es nicht besser klappen kann. Unternehmen wünschen sich also etwas, das sie nicht bekommen können, solange sie an ihren Glaubenssätzen festhalten, was die Einschränkung der Autonomie ihrer Mitarbeiter angeht.

Was wollen Unternehmen auch erwarten von Menschen, die offiziell “abhängig beschäftigt” sind? Diese Formulierung müssen Sie sich auf der Zunge zergehen lassen:

  • Wer angestellt ist, ist abhängig. Das Unternehmen bestimmt, der Angestellte wird bestimmt. Er ist auf die Gnade des Unternehmens angewiesen - sonst wäre er ja nicht in einem Abhängigkeitsverhältnis. Gleichberechtigung, Augenhöhe, Autonomie sind etwas anderes. Erwachsene sollten solche Beziehungen nicht eingehen wollen - sollte man meinen. Allemal ist zu fragen: Was kann ein Unternehmen erwarten von Abhängigen? Freiwilligkeit und Motivation? Kaum.
  • Wer angestellt ist, ist beschäftigt, nein, muss beschäftigt werden. Das hört sich an wie im Kindergarten, wo man Kinder beschäftigt, damit sie nicht auf dumme Gedanken kommen. “Beschäftigung” klingt auch nicht nach Motivation, Energie, Fokus. Wer beschäftigt wird, der tut auch eher nichts aus sich heraus, sondern braucht einen “Entertainer”. Sobald der nachlässt, kommt Langeweile auf.

“Abhängige Beschäftigung” soll etwas optimieren. Historisch gesehen ist sie eine große Leistung. Lieber abhängig beschäftigt im Schutz eines Unternehmens unter Aufsicht von Arbeits- und Sozialgesetzen, als frei, selbstständig, autonom - aber immer auch prekär am Rande des Existenzminimums.

Die positiven Effekte der “abhängigen Beschäftigung” möchte ich nicht schmälern. Doch sie hat eben ihren Preis. Und den zahlen nicht nur Unternehmen, sondern auch die Abhängigen. Der Preis der Abhängigkeit ist die Unterkomplexität.

Abhängigkeits- und Beschäftigungsverhältnisse sind immer hierarchisch. In Hierarchien fließen Segnungen von oben nach unten. Von unten nach oben wird geleistet und erbeten. Das ist klar, simpel, effizient. Das ist das Gegenteil von komplex. So soll es ja auch sein.

Historisch hat das auch lange gereicht, nein, konnte sogar nicht anders sein. Was immer an Resultaten zu erzielen war, war sehr einfach zu erzielen: Wenige denken und planen, viele, viele führen mit einfachen Handgriffen aus. Der kulturelle und bildungsmäßige Unterschied zwischen den Hierarchieebenen war bis neulich noch gigantisch.

In den letzten Jahrzehnten hat sich das nun radikal geändert. Ein Manager ist einem gemanageten Entwickler in nichts voraus. Sie sind in allem gleich - außer in ihrer Position in der Unternehmenshierarchie und damit im Gehalt und damit in den angehäuften materiellen Werten und damit in ihrem Anspruchsdenken. Allerdings leitet sich daraus kein Unterschied in der Angst ab. Angst ist auf jeder Ebene der Hierarchie gegenwärtig. Denn auf jeder Ebene ist man ja abhängig und will beschäftigt werden.

Diese Angst kostet natürlich Energie. Die wird investiert in Handlungen, die höhere Hierarchieebenen gnädig stimmen sollen. Ob daraus jedoch dem Unternehmenszweck dienliche Resultate erwachsen, ist zweitrangig. So kann es dann zu keinen besseren Resultaten kommen. Dass Unternehmen klagen, ist also nicht verwunderlich. Ihr grundsätzlicher Glaubenssatz ist falsch. Der lautet: Weil Angestellte so glücklich über die abhängige Geborgenheit sind, die das Unternehmen ihnen gibt, beschäftigen sie sich konzentriert mit der Erzielung von Resultaten zum Wohle eben dieses gnädigen Unternehmens.

Doch so funktioniert es eben nicht.

Ich glaube zwar daran, dass die meisten Angestellten gute Resultate zuverlässig liefern wollen - nur können sie es nicht. Sie sind umstellt von organisatorischen Mauern. Ihre Freiheitsgrade sind mindestens aus zwei Gründen beschnitten:

  • Das Unternehmen traut den Abhängigen nicht. Denn die haben ja eine Beschäftigungsmentalität. Falls man sie nicht konstant bespaßt und beaufsichtigt, langweilen sie sich und tun nichts. Nur wenn ein Regelkorsett eng geschnürt ist, bleibt den Abhängigen quasi nichts anderes übrig, als auch in der Langeweile irgendwie noch ein Resultat zu erzielen.
  • Unternehmen sind Zusammenschlüsse von Individuen, um durch ein engeres Verhältnis Energie zu sparen. Neben dem funktionalen Zweck (z.B. Software für Architekten) gibt es also auch einen nicht-funktionalen: Effizienzsteigerung. Der ist tief verankert und wird umso mehr beschworen, je enger der Markt wird. Im Verein mit der überkommenen Grundannahme, dass Abhängige, die beschäftigt werden müssen, weder rechte Motivation noch Kenntnis haben können, wie Ressourcen am besten eingesetzt werden, führt das zu weiteren Einschnürungen durch ein Regelkorsett. Vereinheitlichung, Standardisierung, Konsolidierung sind das Gegenteil von Autonomie.

Wenn ich “die Verhältnisse” so beschreibe, ist das natürlich überzeichnet. Doch nur durch die Überzeichnung wird die Grundhaltung erkennbar, die eben den meisten Unternehmen noch unterliegt. Es ist die der Hierarchie und der Unselbstständigkeit. Da helfen auch nicht 3 Monitore, der höhenverstellbare Schreibtisch oder die unternehmenseigene Kita. All das ist mit Hierarchie und Unselbstständigkeit vereinbar. Denn all das können einfach nur Geschenke und Zugeständnisse eben im Rahmen des überkommenden Paradigmas sein. Ein gelockertes Korsett ist immer noch ein Korsett - insbesondere, wenn man nicht wählen kann, ob man es auszieht.

Das Büro kann eingerichtet sein, wie es will. Mit Tischkicker und Ruheraum. Solange die, die Resultate erzielen sollen und wollen, nicht wahrhaft die Wahl haben, ihre Umstände bestmöglich selbst zu bestimmen, um eben diese Resultate zu erzielen… solange müssen sich Unternehmen nicht wundern, dass es nicht wie gewünscht klappt.

Je länger ich darüber nachdenke, desto mehr glaube ich, dass der Default für die Zusammenarbeit Unabhängigkeit sein sollte. Nur wenn Verlässlichkeit und/oder Resultat zu wünschen übrig lassen, sollte nachgebessert/optimiert werden. So wenig wie möglich.

Unternehmen als Ganzes und Manager in Unternehmen in ihren Bereichen sollten also nicht Regeln einführen, sondern stets Ausschau halten nach Regeln, die entfernt werden können. Denn je weniger Regeln, desto größer die Autonomie der Mitarbeiter. Und je größer die Autonomie, desto eher kann die Konzentration entstehen, die dafür nötig ist, dass Resultate verlässlich in hoher Qualität entstehen.

Wer Resultate sehen will, wer etwas bekommen will, sollte daher mit Geben beginnen. Das geschieht am besten mit einer simplen Frage: “Was brauchst du, um deine Resultate zu erzielen?”

Manchmal wünscht sich die Gefragte dann eine Regel; das ist nicht schlecht, denn dann kommt die Regel von unten, von dort, wo echter Bedarf ist.

Es können jedoch auch Antworten kommen, die dem Paradigma widersprechen. Aber warum davor Angst haben? Kann denn wirklich etwas Katastrophales passieren, wenn man die Leine der Abhängigkeit und der Beschäftigung lockert? Alle Wünsche sind doch nur Hypothesen. Auch der wünschende Angestellte weiß nicht wirklich, ob es stimmt, dass es seinen Resultaten hilft, wenn er nur seinen Wunsch erfüllt bekommt. Deshalb sollte die Wunscherfüllung zunächst als Experiment gesehen werden.

Auch hier gilt “Individuals and interactions over processes and tools” und “Responding to change over following a plan” und “Working software over comprehensive [rule set]” und “[…] collaboration over contract [adherence]”. Die Iterationen der Agilität helfen überall. Eine lernende Organisation gibt es nicht ohne Experimente. Die sollten nicht nur am Markt stattfinden, sondern eben auch intern. Viel mehr intern. Denn dort ist viel Potenzial für Kreativität, Motivation, gar Innovation hinter Mauern aus Regeln angestaut.

Wenn es also im Unternehmen im Allgemeinen bzw. in der Softwareentwicklung im Speziellen nicht läuft, wie es laufen sollte, wenn es knirscht in der Zusammenarbeit, wenn die Unzuverlässigkeit grassiert… dann, so glaube ich, ist eine wesentliche Stellschraube die Autonomie jedes einzelnen Beteiligten. Mehr und mehr Freiheitsgrade helfen. Nicht nur für sauberen Code gilt also: Raus aus den Abhängigkeiten! ;-)

 

PS: Dass Autonomie kein Garant für Erfolg ist, ist selbstverständlich. Sie ist keine hinreichende Voraussetzung. Aber ich halte sie für eine notwendige. Ohne Autonomie, ohne Augenhöhe, ohne Selbstbestimmung und damit einhergehend auch Selbstverantwortung keine wirklich dauerhaft guten Resultate. Autonomie ist insofern im eigenen Interesse jedes Unternehmens.

PPS: Zur gewährten Freiheit muss auf der anderen Seite natürlich auch Fähigkeit treten, damit umzugehen. Die mag nicht bei jedem “Befreiten” in gleichem Maße vorhanden sein. Aber wer seine Aufgaben als Manager schwinden sieht, bekommt hier ein bedenkenswertes neues Betätigungsfeld: die Förderung von echten Mit-Arbeitern. Die Frage bleibt nämlich: “Was brauchst du?” Dieses mal jedoch Bezogen auf die Autonomie: “Was brauchst du, um mit der neu gewonnenen Autonomie zum Nutzen der Resultate am besten umzugehen?”

PPS: Und wer nicht glaubt, dass man mit mehr Autonomie und Augenhöhe Erfolg haben kann, der schaue mal diesen Film: http://vimeo.com/118219210

AUGENHÖHE OmU (dt.) from Daniel Trebien on Vimeo.

Die meisten, die darin zu Wort kommen, sind zwar formal noch “abhängig beschäftigt”, doch ihre Berichte machen deutlich, dass auch in Angestelltenverhältnissen Autonomie und echte Mit-Arbeit möglich ist. Und das ist nur der Anfang.

Die Frage ist daher nicht, ob mehr Autonomie in Ihrem Unternehmen sein sollte, sondern wann das der Fall ist und unter wie großen Schmerzen es dazu kommen wird. Meine Empfehlung: Lieber bald mit der “Entkopplung” beginnen, um mehr Zeit zum Lernen und Anpassen zu haben.

Dienstag, 27. Januar 2015

Die Selbstlern-Challenge - Mitmachen und gewinnen!

500€ gibt es zu gewinnen. Ingesamt jedenfalls. Die bin ich bereit, als “Preisgeld” auszusetzen für diejenigen, die erfolgreich mitmachen.

Die Herausforderung

Ich suche 10 Freiwillige, die bereit sind, 10 Wochen lang sich im Selbststudium mit Flow Design auseinanderzusetzen. Das habe ich in einigen Büchern und vielen Blog-Artikeln ausführlich beschrieben. Dazu gehören Themen wie:

  • Radikale Objektorientierung / OOP as if you meant it
  • Agile Architektur / Die Anforderung-Logik-Lücke
  • Softwarezellen

Über die 10 Wochen ist nicht viel zu leisten. Es gibt nur drei Bedingungen:

  1. Wer teilnimmt, stellt mir jede Woche mindestens eine ernstgemeinte und nicht triviale Frage zu den obigen Themen. Diese Frage soll als minimale Dokumentation der kontinuierlichen und fortschreitenden Auseinandersetzung mit dem Stoff dienen. “Fragen auf Vorrat” sind nicht erlaubt, ebensowenig “aufholende Fragen”, die eine Woche ohne Frage kompensieren sollen.
  2. Wer teilnimmt, reagiert auf Emails von mir zum Lernstoff innerhalb von max. 24h. Dies dient der Sicherung einer verlässlichen, flüssigen Kommunikation zur Beförderung des Lernens.
  3. Wer teilnimmt, stimmt zu, dass sein/ihr Name veröffentlicht wird. Außerdem behalte ich mir vor, die Abschnitte zum Lernstoff aus der sich ergebenden Email-Konversation zu veröffentlichen.

Das ist alles. Es gibt keine Prüfung, es gibt überhaupt nichts, das am Ende abzuliefern wäre. Der Weg ist das Ziel :-)

Dieses Angebot gilt vom 27.1.2015 bis zum 17.5.2015 (oder anders: ab 5. KW bis inklusive 20. KW 2015). In der Zeit muss die 10-Wochen-Teilnahme abgeschlossen sein.

Update: Seit 28.1.2015 sind alle Teilnehmerplätze vergeben!

Die Teilnahme

Wer teilnehmen möchte, schreibt mir einfach eine Email. Dann beginnen die 10 Wochen zu laufen. Ich stelle daraufhin Lernmaterialien in Form von Links und Büchern zur Verfügung. Teilnehmer müssen also keinen Cent ausgeben.

Auf Wunsch stelle ich auch Aufgaben, an denen sich Teilnehmer versuchen können.

Der Gewinn

Der Gewinn der Teilnahme besteht natürlich vor allem in Wissens- und Erfahrungszuwachs. Darüber hinaus erhält aber auch jeder erfolgreiche Teilnehmer am Ende noch einen Amazon-Gutschein in Höhe von 50€.

Erfolgreich ist, wer die obigen Bedinungen erfüllt. Mehr ist nicht nötig, weniger allerdings auch nicht.

Die Hypothese

Mit dieser Herausforderung möchte ich eine Hypothese überprüfen, die ich zum autodidaktischen Lernen habe. Welche das ist, kann ich vorher nicht verraten. Damit würde ich die Durchführung des Experiments beeinflussen. Aber ich verspreche, dass ich am Ende der Herausforderung darüber berichte.

 

Und nun: Lasst das Selbstlernen beginnen!

Samstag, 29. November 2014

Die Nachwuchskatastrophe - 0% der Mädchen wollen in die Softwareentwicklung

Der Nachwuchs für die Softwareentwicklung ist männlich. Zu 100%. So scheint es derzeit nach einer Umfrage des Allensbach-Instituts.

image

0% der befragten Mädchen zeigte Interesse daran, einen Beruf im “Computer, IT-Bereich” zu wählen. Das betrifft auch die Softwareentwicklung.

Das ist eine Katastrophe!

Gründe zur Sorge

Warum ist das eine Katastrophe? Ich sehe da mindestens zwei Gründe:

  • Software ist der “Treibstoff” der Zukunft. Ohne Software geht nichts mehr und zukünftig noch weniger. Wir haben heute schon zu wenige Softwareentwickler. Das Verhältnis kann dann nur noch schlechter werden, wenn morgen der Bedarf an Software weiter steigt und gleichzeitig - zumindest in Deutschland - der Arbeitskräftemarkt in den nächsten 10 Jahren um bis zu 15% schrumpft. Offshoring ist doch keine wirkliche Lösung. Auch Flüchtlinge der einen oder anderen Art zu Softwareentwicklern fürs homeland umzuschmieden, ist doch auch keine Lösung. Wir brauchen schlicht mehr an dieser Arbeit interessierte Menschen beiderlei Geschlechts aus und in unserer Gesellschaft. Das ist schwierig genug. Wenn sich jetzt aber herausstellt, dass 50% des Potenzials schlicht verloren ist… Dann ist das eine Katastrophe. Uns geht der “Treibstoff” für unsere Unternehmen aus.[1]
  • Softwareentwicklung ist schon lange keine Sache mehr für einsame (männliche) Hacker. Jedenfalls nicht, wenn man nachhaltig Software bauen will. Softwareentwicklung braucht ein Team. Und Team braucht Vielfalt. Mehr Vielfalt als ein Fußballteam. Denn die Sache, um die es geht, ist komplexer und es hängt mehr von ihr ab. Zu Vielfalt gehört selbstverständlich, dass beide Geschlechter vertreten sind. Manager rufen gern Kriegsmetaphern auf, um ihre Arbeit zu beschreiben und sich zu rechtfertigen. Doch schon lange ist klar, dass der Erfolg für alle größer ist, wenn man nicht im Kampf miteinander steht, sondern kooperiert. Kooperation, gemeinschaftliches Schaffen, d.h. auch Empathie sind jedoch eher mit einer weiblichen Sicht der Dinge verbunden als mit der männlichen. Bei aller Gleichberechtigung, die wir schon erreicht haben mögen, ist eine Ungleichheit in der Herangehensweise ans Leben zwischen Frauen und Männern nicht wegzudiskutieren. Und warum auch? Warum soll alles gleich sein, nur weil alle gleichberechtigt sind? Lassen wir zu, dass Frauen und Männer unterschiedlich sind - und zusammen ein Ganzes ergeben.[2] Softwareentwicklung ist eine Arbeit, die solches Ganzes braucht. Denn es geht nicht um Maschinen, die nach Plan von muskelbepackten Männern im Schweiße ihres Angesichts zusammengeschraubt werden müssen. Es geht um sich ständig ändernde Prozesse, es geht um Komplexität, es geht um Verständnis (mindestens des Kunden) uvm. Das alles profitiert davon, Weiblichkeit im Team zu haben. Mehr Weiblichkeit als bisher jedenfalls. Wenn sich 0% der Weiblichkeit für die Softwareentwicklung interessieren, dann ist das also eine Katastrophe.

Was tun?

Die Katastrophe hat natürlich schon begonnen. Eine Generation ist bereits verloren. Und kein Wunder: Wenn ich mir das Gymnasium meiner Tochter ansehe, dann weiß ich, warum weder sie noch ihre Freundinnen für Softwareentwicklung interessieren. Es wird nichts dafür oder sogar alles was möglich ist, dagegen getan. Fächerkanon wie vor 50 Jahren. Bis zu diesem Jahr keine Erlaubnis, den Girls Day zu besuchen. Da hilft auch kein Studiensaal mit Laptops und Powerpoint-Präsentation in Geografie. Verständnis für den “Treibstoff” wird nicht geweckt. Nirgends.

Dabei ist dort mit Sicherheit Potenzial. Neulich habe ich meiner Tochter mal Lightbot aufs iPad geladen. Das hat sie besser gespielt als ich. Man(n) muss halt Angebote machen… Aber das ist natürlich schwer, wenn schon männliche Lehrer sich vom normalen Curriculum überfordert fühlen und ansonsten mindestens 7 Jahren Bildungsvermittlung in formativen Jahren (Kindergarten und Grundschule) zu min. 85% durch Frauen stattfindet.

Aber genug der Klage. Was könnten wir denn tun, um Mädchen für die Softwareentwicklung zu begeistern?

Am besten beginnen wir mit dem Verstehen. Quasi Anforderungsanalyse. Das können wir doch, oder? ;-)

Laut Studie ist es

[f]ür fast die Hälfte der befragten Mädchen […] wichtig, anderen Menschen zu helfen […]

Außerdem

[…] wollen [Schüler] sich in ihrem späteren Beruf vor allem selbst verwirklichen (87 Prozent), das steht noch vor dem Wunsch nach einem gut bezahlten (75 Prozent) und sicheren (71 Prozent) Arbeitsplatz.

Das wollen Mädchen? Anderen helfen und sich selbst verwirklich bei ordentlicher Bezahlung in realistischer Arbeitsplatzsicherheit?

WTF! Das können sie doch in der Softwareentwicklung haben. Oder nicht?

“Anderen Menschen helfen” bedeutet für Mädchen offensichtlich nicht, dass sie alle Krankenschwestern und Pflegerinnen werden. Sonst hätten wir da keine Nachwuchsprobleme. Sie ergreifen also andere Berufe. Sie werden Verkäuferin, Bankangestellte, Busfahrerin, Steuerberaterin usw. usf.

Aber, Leute, ehrlich, das sind doch keine Berufe, in denen man sehr speziell “Menschen hilft”. Klar, Frauen gehen in solche Berufe. Lehrkräfte sind zu 67% Frauen. Sie sind auch Sozialarbeiterinnen und Hebammen. Doch sie arbeiten eben auch in ganz anderen Berufen. Das Motiv “Menschen helfen” zieht für mich also nicht so ganz. Denn dann müssten viel mehr Mädchen auch Bestatterinnen werden wie meine Ex-Frau. Da kann man Menschen sehr unmittelbar helfen.

Oder es müssten mehr Mädchen Softwareentwicklerinnen werden. Denn da können sie auch Menschen helfen. Da sind Kollegen, denen immer wieder geholfen werden muss. Gerade in cross-functional Teams. Da sind Kunden, denen man im unmittelbaren Kontakt helfen kann, indem man sich um Verständnis bemüht und dann auch noch nützliche Software herstellt. Und da sind Anwendungen in der Medizintechnik oder für Behörden, die den Menschen helfen, für die die Anwender da sind.

Und wie steht es mit der Selbstverwirklichung, den Verdientschancen und der Arbeitsplatzsicherheit? Angesichts der Automatisierungsrevolution die in den nächsten 10 Jahren anrollt, sollte klar sein, dass Softwareentwicklung ein relativ sicherer Hafen sein wird. Es geht nicht mehr nur um Roboter, es geht um Expertensysteme aller Art. Die bringen Berufe in allen Teilen des Spektrums unter Beschuss: vom Taxifahrer bis zum Bankangestellten und darüber hinaus.

Bei der Softwareentwicklung hingegen sehe ich da noch keine große Gefahr. Auch neue Tools werden unsere Köpfe nicht ersetzen. Der Bedarf an Software wird den Produktivitätsgewinn mehr als auffressen. Die Softwarekrise ist nicht vorbei. Sie fängt womöglich sogar erst an.

Das kann sich auch nur positiv auf Gehälter und “Selbstverwirklichungsmöglichkeiten” auswirken, würde ich sagen.

Wo ist also das Problem? Softwareentwicklerin ist ein für Mädchen attraktiver Beruf. Jedenfalls, wenn man die angegebenen Motive für die Berufswahl ernst nimmt. Wir müssen nur lernen, das darzustellen. Wir müssen uns bemühen, an die Vorstellungen von Mädchen anzuschließen. Es braucht Rollenmodelle, es braucht eine Imagekampagne.

Da muss man sich ein bisschen Mühe geben. Mehr als bei dem grauslichen Barbie-Comic, der gerade durch die Medien geistert. Aber das sollte doch zu machen sein, oder? Warum nicht die Frauen fragen, die schon Softwareentwicklerinnen sind?

Nur wer ist für soetwas der Ansprechpartner? Große Firmen - aber nur in einem Zusammenschluss, sonst kommt etwas zu sehr auf ein Unternehmen Zugeschnittenes heraus. Ein Verband fehlt leider bisher. Medien? Ein Ministerium? Am besten wohl alle zusammen.

Was Mädchen wollen - Ein Versuch

Aber vorher müssen wir wohl noch besser verstehen, was Mädchen wirklich, wirklich wollen. Denn ich glaube, das drücken die genannten Motivbeschreibungen nur ungenügend aus.

Ich versuche mal, hinter die Begründungen zu schauen und spekuliere auf der Basis dessen, was ich so von außen in der Welt erkennen kann:

  • Mit “anderen Menschen helfen” ist nicht gemeint, echt Bedürftigen zu helfen. Ich glaube, es geht um etwas viel Allgemeineres: Beziehungen. Mädchen ist der direkte Umgang mit etwas Lebendigem (Mensch, Tier, Pflanze) wichtig. Ihr Interesse ist insofern eher nach außen gewandt, umweltbezogen. Männer die auf Maschinen starren, Frauen die mit Menschen reden. So könnte man es vielleicht überspitzt ausdrücken. “Helfen” ist also nicht so wichtig wie Dialog.
  • Mit “sich selbst verwirklichen” ist gemeint, sich immer wieder neu zu entscheiden. Mädchen wollen sich nicht auf eine Berufskarriere festlegen. Sie sind natürlich nicht mehr zufrieden mit “Hausfrauendasein”. Aber sie möchten die Idee einer Familie auch nicht dem Beruf opfern. Dazu braucht es Flexibilität: Der Beruf muss ermöglichen, eine Zeit lang zu arbeiten und dann zu pausieren und dann auch wieder anzufangen, womöglich in Teilzeit. Arbeitgeber und Metier müssen das hergeben.

In “manifest speak” ließe sich das vielleicht so zusammenfassen:

  • Communication over technology
  • Flexibility over career

Ha! Das ist knackig.

Und ließe sich das denn nicht einrichten? Keine Chance, dass sich Softwareentwicklung so darstellen bzw. sich dahin entwickeln ließe?

Wenn es da Schwierigkeiten geben sollte, dann nicht, weil die Softwareentwicklung so nicht sein kann. Nein, Schwierigkeiten sehe ich nicht im Metier, sondern nur im Willen von Unternehmen (und vielleicht einzelner Entwickler, die um einen Nimbus fürchten).

Die Nachwuchskatastrophe lässt sich also abwenden - wenn wir wollen. Ich denke, die Softwareentwicklung kann für Mädchen mindestens so attraktiv sein wie das Bankenwesen oder die Betriebswirtschaft oder das Behördenwesen. Wenn nicht sogar attraktiver, oder? Das können wir doch hinkriegen, my fellow men.


  1. Unternehmen mögen noch nicht glauben, dass Software so wichtig ist. Aber das wird sich noch verändern. Selbst der letzte mittelständische Maschinenbauer wird verstehen, dass der Milliardenumsatz seines 700 Mitarbeiter Unternehmens von den 15 Leuten in der ungeliebten Softwareabteilung abhängig ist. Man könnte fasst revolutionspoetisch werden: “Alle Räder stehen still, wenn der Programmierer es so will.” Der Hebel, den die Softwareentwicklung hat, ist sehr lang.

  2. Was nicht bedeuten soll, dass irgendwelche Attribute zwanghaft irgendeinem biologischen Geschlecht zugeordnet werden sollen. Männer dürfen, nein, sollen natürlich auch empathisch sein und Frauen tough. Je nach Neigung und Situation. Das ändert jedoch nichts daran, dass im Durchschnitt gewisse Eigenschaften eben doch nach biologischem Geschlecht unterschiedlich verteilt sind. (Womit ich keinen Kausalzusammenhang unterstellen will, sondern nur beschreibe, was ich sehe. In die nature vs nurture Debatte möchte ich hier nicht einsteigen.)

Sonntag, 23. November 2014

Praktische Führung

Es wird ja viel über Führung und Management geschrieben. Die einen sind dafür, die anderen dagegen. Aber was ist eigentlich die Aufgabe von Führungspersonen?

Eine sehr gute Erklärung liefert aus meiner Sicht Reinhard K. Sprengers Buch “Radikal führen”. Danach hat Führung fünf Kernaufgaben:

  • Zusammenarbeit organisieren - Klar, das ist der Ausgangspunkt. Verschiedene Aktivitäten müssen so “verdrahtet” werden, dass ein Gesamtergebnis entsteht. Dazu gehört natürlich auch die Zielsetzung.
  • Transaktionskosten senken - Für die Zusammenarbeit müssen günstige Rahmenbedingungen geschaffen werden. “Irgendwie” kann man sich auch ohne Führung zusammenraufen. Mit Führung soll es ökonomischer sein.
  • Konflikte auflösen helfen - Irgendwas ist immer. Dann muss Führung helfen, wieder Kohärenz herzustellen.
  • Zukunftsfähigkeit sichern - Heute gut zusammenarbeiten, bedeutet nicht, dass das auch noch morgen funktioniert. Innen wie außen können sich Verhältnisse verändern; darauf muss Führung (proaktiv) reagieren.
  • Mitarbeiter führen - Nicht nur die Zusammenarbeit will geführt werden, auch der Einzelne. Immer geht es ja um Ziele, die erreicht werden sollen. Hilfe kann da nicht schaden. Und schließlich müssen auch noch Stellen in der Zusammenarbeit geeignet besetzt werden, damit es bei guter “Verdrahtung” auch wirklich fließen kann.

Wenn ich durch diese Brille auf Unternehmen schaue, dann verstehe ich sehr gut, was funktioniert und was nicht - und warum. Ein Schema, das mir schon sehr geholfen hat.

Aber trotzdem: Irgendwas hat mir noch gefehlt beim Verständnis. Und das ist mir heute klar geworden, als ich mit meiner Tochter einen Nähkurs bei Zick und Zack in Hamburg besucht habe.

image

Dort wurde uns nämlich gesagt, dass eine Nähmaschine Führung brauche.

Der zu nähende Stoff muss unter der stationären automatischen Nadel entlangbewegt werden, um eine Naht zu produzieren. Das übernimmt der Transporteur unterhalb der Nadel.

image

Er zieht den Stoff, den der Nähfuß auf ihn drückt, an der Nadel vorbei. Die Richtung ist einstellbar; normalerweise bewegt sich der Stoff weg vom Näher, aber der kann ihn auch zu sich hin wandern lassen.

Der Stoff ist also grundsätzlich in Bewegung, die Naht entsteht von allein. Irgendwie. Denn bisher ist da sozusagen nur “rohe Kraft am walten”.

Was jetzt noch fehlt, das ist… Führung.

Die “rohe Kraft” des Transporteurs muss auf ein Ziel ausgerichtet werden. Und zwar immer wieder.

Hier sehen Sie, wie ich zur Übung entlang auf den Stoff gezeichneter Linien nähe. Der Stoff bewegt sich zwar von allein - nur nicht unbedingt “linientreu”. Ich muss ihn immer wieder nach-führen.

image

Dazu gehört, dass ich die Richtung korrigiere, indem ich den Stoff unter der Nadel drehe. Wenn die Richtungsänderung zu krass ist wie bei einer Zickzack-Linie, muss ich den Nähvorgang dafür sogar unterbrechen.

Darüber hinaus muss ich die “globale” Geschwindigkeit regulieren. Das tue ich über einen Fußschalter. Der bestimmt, wieviel “Input” sich die Maschine zum Nähen holt. Der Transporteur zieht sich ja den Stoff selbst.

Das ist aber noch nicht alles. Mein Aha-Moment bestand darin, dass ich fühlen konnte, was Micro-Management bedeutet.

Micro-Management entsteht nämlich immer dann, wenn zusätzlich zum allgemeinen Arbeitsfluss noch versucht wird, im Detail zu optimieren. Man überlässt das Resultat nicht dem Prozess, sondern greift lokal immer wieder ein.

Das führt bei Menschen zu Unmut. Die fühlen sich bevormundet; man lässt sie ja nicht die Arbeit tun, für die sie einmal kompetent gehalten wurden, sondern greift ein. Wer micro-managet, der vertraut nicht.

Daraus resultieren in Bezug auf den Produktionsfluss Stockungung und Qualitätsverlust.

Und genau das habe ich eben spüren können: Sobald ich anfing, den Stoff in Transportrichtung auf die Nadel noch zusätzlich zu zu schieben (Druck, push), war das Ergebnis schlechter. Dito, wenn ich anfing, den Stoff in Transportrichtung noch zusätzlich hinter der Nadel zu ziehen (pull).

Die Naht war sofort ungleichmäßig und die Ausrichtung entlang einer Linie fiel sofort schwerer.

Führung bedeutet mithin, einen Prozess aufzusetzen - und sich dann weitgehend rauszuhalten. Wer über die im Prozess wirkenden Kräfte noch drückt oder zieht… der betreibt Micro-Management. Das Ergebnis sind Stauungen oder Risse. In jedem Fall gerät etwas aus dem Gleichgewicht und der Arbeitsfluss wird gestört.

Führung bedeutet, in Kontakt bleiben mit dem Prozess. Immer wieder schauen, ob der noch fließt und auch noch auf das Ziel ausgerichtet ist. Falls nicht, muss nachjustiert werden - aber vorsichtig. Und eher nicht an den einzelnen Prozesselementen (lokale Optimierung), sondern am Ganzen (globale Optimierung).

Wenn es mit der Naht bei mir nicht geklappt hat, dann aufgrund von Micro-Management und zu wenig Blick auf das Ganze. Schlechte Führung also.

Es schien einfacher, nah an der Nadel den Stoff zu ziehen/drücken, als die Gesamtgeschwindigkeit zu regulieren. Und es war attraktiver, überhaupt mit der Maschine zu nähen, statt das Nähen vorzubereiten. So habe ich zum Beispiel ein Band, das ich auf eine Tasche nähen wollte, nicht vorher mit Nadeln ausreichend fixiert. Ich dachte, ich kriege es durch Eingriffe nahe an der Nadel während des Stoffdurchlaufs hin, das Band gerade drauf zu nähen. So musste ich auf die harte Tour lernen, dass gute Vorbereitung hilft, den Durchsatz zu erhöhen.

Auch das gehört zu Führung: Bewusstsein dafür vermitteln, dass zu guter Zusammenarbeit auch darin besteht, auf Qualität von Input und Output zu achten. Systeme definieren sich ja durch das, was zwischen ihren Bestandteilen fließt.

Aber auch das ist eine Sache, die eben nicht während der Produktion geschehen sollte. Da müssen die Prozessschritte schon gut “verdrahtet” sein. Führung ist eine Sache des Rahmens, in dem Produktion stattfindet.

An der Nähmaschine habe ich ja auch nicht selbst die Naht hergestellt. Dazu greifen die Teile der Nähmaschine ineinander. Vielmehr habe ich in guten Moment einfach nur “sanft” geführt.

image

Das Ergebnis war dann doch passable und nützlich. Ich habe bei der Führung die Kurve gekriegt. Aber wie ist das im Tagesgeschäft? Kriegt Management da auch immer die Führungskurve? Das scheint mir nicht der Fall zu sein.

Da ist Micro-Management an der Tagesordnung - insbesondere, wenn irgendetwas sowieso nicht rund läuft. Da wird gedrückt und gezogen, statt auf den Gesamtprozess zu schauen. Wie sind die Prozessbeteiligten eigentlich grundsätzlich zueinander angeordnet? Wie ist die Qualität des Input? Wo gibt es einen Engpass?

Vielleicht würde ja mal ein Nähkurs für Führungskräfte helfen? Da kann man eine Menge lernen, nicht nur über Führung. Und Spaß macht es obendrein, mal wieder etwas Anfassbares mit den Händen hergestellt zu haben.

Freitag, 21. November 2014

Hacker-Tool für Gedanken

Wie soll ich wissen, was ich denke, solange ich es nicht aufgeschrieben habe? So geht es mir oft. Deshalb schreibe ich Blog-Postings und Zeitschriftenartikel und auch Bücher. Das Schreiben hilft mir beim Denken.

Aber welches Werkzeug benutzen für das Schreiben? Für den Zeitschriftenartikel ist MS Word der Standard. Aber muss das so sein? Wie könnten Redaktion und Autor vielleicht noch besser zusammenarbeiten? Oder was ist “Gedankensammlungen” in Unternehmen? Oder mit selbstverlegten Büchern oder eben Blog-Artikeln, wo noch mehr Feedback gewünscht ist?

Für manches haben sich Wikis sehr empfohlen. Die Materialsammlung für Clean Code Developer haben wir auch in einem Wiki vorgenommen. Für ein Buchmanuskript schien mir das bisher jedoch nicht passend. Da setze ich auf Markdown-Texte, die ich in meiner Dropbox verwalte und per Leanpub veröffentliche. Alternativ könnte ich aber auch ein Git-Repository benutzen. Nur für Kommentare von Lesern nah am Text ist das noch nicht das Richtige.

Aber jetzt bin ich auf hackpad.com gestoßen. Das sieht irgendwie cool aus. Artikel, genannt Pads, lassen sich dort so einfach wie in einem Wiki bearbeiten und verlinken. Man kann sie mittels Tags und sog. Collections organisieren und unter dem Dach eines Workspace veröffentlichen.

Einfache Refaktorisierung wird unterstützt (“extract pad”), Verlinkungen wie in Wikis sind mühelos, Medien können eingebettet werden. Und: Mehrere Benutzer können am selben Text arbeiten. Gleichzeitig. Man sieht, welche Teile von wem stammen. Explizite Kommentare sind auch möglich. Das finde ich cool für Texte, die “work in progress” sind oder eben das Werk einer Gruppe.

Aufsetzen lässt sich ein Workspace bei Hackpad leichter als ein Wiki, finde ich. Deshalb überlege ich mit Stefan Lieser, ob wir unsere nächste Initiative nach Clean Code Developer dort hosten. Zu klären ist dafür jedoch noch, ob Google die Pads von öffentlichen Workspaces ordentlich indexiert.

Allemal, so glaube ich, lohnt Hackpad aber einen Blick für alle, die ein Unternehmenswiki einrichten wollen.

Hier als Beispiel eines Pads ein Text aus meinem englischen Blog. In dem Pad hier können Sie auch schreiben. Mit “//” beginnen Sie eine Kommentarzeile.

Viel Spaß beim einhacken von Gedanken! :-) Hackpad sozusagen als “thought IDE”.

Freitag, 14. November 2014

Wunderlist für Personal Kanban

Ein Tool ist kein Selbstzweck, sondern soll dienlich sein. Das trifft auf Software zu wie auf Methoden.

Um meine Arbeit zu organisieren, wenn es mal wieder etwas mehr wird, habe ich vor einiger Zeit Personal Kanban eingeführt. Naja, “einführen” kann man da nicht viel ;-) Ich habe also angefangen, nicht nur eine Aufgabenliste zu führen, sondern die Aufgaben über ein Brett zu ziehen.

image

Das funktioniert - aber irgendwie, irgendwie fand ich es zu aufwändig. Die Software KanbanFlow stand mir im Weg. Es fühlte sich umständlich an. Und so schlief die Methode immer wieder ein.

Doch nun bin ich wieder dabei. Neues Tool, neues Glück. Hier fühle ich mich freier. Irgendwie. Und das eherne Gesetz des Personal Kanban “Transparenz” wird immer noch erfüllt.

Mein neues Tool heißt Wunderlist. Das gibt es auf allen Geräten und im Browser, selbstverständlich synchronisiert.

Es ist viel einfacher. Nix Kanbanbrettspalten. Keine Kärtchen. Einfach nur Listen.

Aber genau das macht den Unterschied für mich. Die Bedienung ist mehr auf den Punkt, finde ich.

Mein “Backlog”, das, was zu tun ist, pflege ich in verschiedenen Listen. Hier eine als Beispiel geöffnet, weitere sind darunter links zu sehen:

image

Das, was ich gerade tue, markiere ich als wichtig, so dass es herausgestellt in einer eigenen Liste steht:

image

Das ist mein WIP (work in progress). Wunderlist bietet da zwar keine WIP-Begrenzung, aber das ist auch nicht so wichtig. Es ist halt meine Verantwortung, nicht mehr als 1–2 Einträge über die Listen hinweg jeweils bis zur Erledigung als wichtig zu markieren.

Und am Ende kommen alle Aufgaben ins Archiv. Sie sind dann done:

image

Termine, Notizen, Teilaufgaben, Kommentare… das alles gibt es auch. Gelegentlich nutze ich es. Für den häufigsten Fall jedoch, die Abarbeitung von ständig einfließenden Aufgaben, reicht es mir völlig, schnell einen Eintrag in einer Liste machen zu können.

Wer sich noch überwältigt fühlt von zu erfüllenden Wünschen, der kann ja mal versuchen, mit Wunderlist etwas Systematik reinzubringen.