Stephan Schwab's Personal Blog
Es ist gängige Praxis in vielen Unternehmen neue Mitarbeiter durch einen mehrstufigen Prozeß auszuwählen. Da werden Lebensläufe angeschaut und bewertet und so eine Vorauswahl getroffen. Dann werden aussichtsreiche Kandidaten telefonisch befragt und nach einer weiteren Auswahl Termine für persönliche Vorstellungsgespräche ausgemacht.
Kommt es dann zum Vorstellungsgespräch sitzt der Kandidat mehreren Personen gegenüber, die alle seinen Lebenslauf vor sich haben. Meist stellt sich am Anfang erstmal jeder vor, dann wird ein wenig über das Unternehmen berichtet und generell erzählt für welche Tätigkeit man einen zusätzlichen Mitarbeiter sucht. Dem schließt sich die ausführliche Befragung des Kandidaten an.
Prüfung der Eignung des Spezialisten
Wenn das Unternehmen einen Java-Programmierer oder einen Bediener für eine CNC-Maschine sucht, dann mag dieses Vorgehen noch einigermaßen Sinn machen. Man kann durch Fragen prüfen, ob die Angaben im Lebenslauf korrekt sind oder sich vielleicht Widersprüche ergeben. Es könnte ja sein, daß der Kandidat angibt X gemacht zu haben, aber es stellt sich dann heraus das X von jemand anderem durchgeführt wurde. Im Falle des CNC-Bedieners kann man seine Detailkenntnisse von Maschine Z abfragen. Den Java-Programmierer kann man befragen, ob der genügend Kenntnisse der Programmiersprache und der vom Unternehmen benutzten Bibliotheken und frameworks hat.
Am Ende wird man versuchen einem Bewerber den Zuschlag zu geben, dessen Fertigkeiten und Erfahrungen möglichst weitgehend oder exakt mit der in der jeweiligen Abteilung erstellten Anforderungsliste übereinstimmen.
Was letztlich ausgewählt wird ist ein paßgenaues Bauteil für einen Produktionsprozeß - ganz so wie man Materialeigenschaften, Lieferbarkeit und Preis beim Einkauf von Betriebs- und Produktionsmitteln prüft und auf dieser Basis entscheidet. Deshalb ist bei der Auswahl von temporären Mitarbeitern (Zeitarbeiter, Leiharbeiter, Freiberufler) auch der Einkauf beteiligt - damit für das Unternehmen günstige Einkaufsbedingungen mit dem Lieferanten ausgehandelt werden.
Paßgenaue Auswahl verhindert Lernen und Entwicklung
Um noch einen Moment bei der Auswahl des Spezialisten als paßgenaues Bauteil für einen Produktionsprozeß zu bleiben: je mehr ich darauf achte, daß jemand möglichst genau die gestellten Anforderungen erfüllt und dabei eine technisch orientierte Liste verwende, desto mehr verhindere ich letztlich Lernen und Entwicklung. Wenn ich z.B. einen Java-Programmierer suche, der 5 Jahre Erfahrung mit den frameworks Spring und Struts hat, dann werde ich möglicherweise nie jemanden finden, der modernere Verfahren kennt oder Interesse hat diese zu erlernen. Es besteht das große Risiko, daß ich zu eng auswähle und dabei - ganz besonders bei temporären Arbeitsverhältnissen, nur Opportunisten finde, die X abliefern und sich für nichts anderes interessieren. Damit verstärkt sich maschinistisches Denken und Verhalten. Lernen und Entwicklung organisatorischer und technischer Fähigkeiten wird verhindert. Schließlich wird es ja nicht gefordert. Es soll ja jemand ausgewählt werden, der genau paßt und das bisher Übliche weiterhin macht.
Qualität des Agile Coach erfährt man nicht durch Befragen des Coaches
Diejenigen, die über die Qualität eines Agile Coaches eine wirkliche Aussage treffen können, sind die Mitglieder und das Umfeld der Teams, für die der Agile Coach bisher tätig war. Gute Coaches publizieren auch sehr viel. Da gibt es Bücher, Artikel in Zeitschriften und ganz besonders häufig und gern schreiben engagierte Coaches ein Blog oder publizieren in anderer Form auf einer Website.
Anstelle einer Befragung sollte man sich in die Gedankenwelt des Coaches einlesen. Schließlich öffnet sich der Coach von sich aus und teilt sich regelmäßig mit. Da kann man von seinen Erfahrungen lesen, lernt Lösungsvorschläge kennen, sieht welche Ideen er hat und was er wie zu einzelnen Fachgebieten beiträgt.
Man kann Coaches ausprobieren
Gute Coaches wollen sich selbst so schnell wie möglich überflüssig machen. Kein Agile Coach möchte langfristig bei ein und demselben Unternehmen arbeiten. Schließlich würde das seine Fähigkeit neue Ideen, Veränderungen, Verbesserungen zur Entwicklung organisatorischer und technischer Fähigkeiten einzubringen behindern. Je mehr er herumkommt, desto mehr Erfahrung kann er mit Teams teilen.
Von daher ist die beste Möglichkeit einen Coach auszuwählen ihn einfach auszuprobieren. Viele Agile Coaches sind gern bereit einfach nur ein paar Tage zu helfen. Andere bieten sogar an auf ihr Honorar zu verzichten, wenn ihre Hilfe keine positive Wirkung hat. Das ist risikolos und hilft jemanden zu finden, der bei der Entwicklung von Teams tatsächlich effektiv ist.
Im Scrum Guide (2011) wird die Aufgabe des Scrum Master als Hüter des Scrum-Prozesses beschrieben:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
Gleichzeitig wird der Scrum Master aber auch als servant-leader des Teams bezeichnet. Bevor ich jetzt einfach diesen Begriff als dienender Führer übernehme, möchte ich einmal nachsehen wie servant leadership definiert ist. Im Wikipedia-Artikel, der dies auf Basis des Werkes von Greenleaf zusammenfaßt wird dies so definiert:
A servant leader is someone who is servant first, who has responsibility to be in the world, and so he contributes to the well-being of people and community. A servant leader looks to the needs of the people and asks himself how he can help them to solve problems and promote personal development.
Dort findet sich also ein Element des Entwickelns von Personen (personal development) ebenso wie der Gedanke den Menschen bessere Bedingungen (damit ist wohl Arbeitsbedingungen gemeint) zu verschaffen.
Teil des gängigen Verständnisses der Aufgaben eines Scrum Masters ist das Team zu schützen, damit es sich selbst organisieren kann und z.B. nicht während des Sprints mit anderen Aufgaben unterbrochen wird. Entsprechend sagt der Scrum Guide dann auch:
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Die restliche Organisation soll also bei der Interaktion mit dem Scrum-Team jeweils überlegen, ob das eigene Tun hilfreich oder hinderlich ist. Der Scrum Master soll sich einmischen, vermitteln und nicht hilfreiches Verhalten korrigieren.
Viel zu viel
Im Scrum Guide werden dann Beispiele für die Leistungen, die der Scrum Master für den Product Owner, das Team und die restliche Organisation erbringt, gegeben. Die dargestellten Leistungen für den Product Owner und das Team (die gehören ja ohnehin zusammen) betrachte ich als absolut zweckmäßig und sie sind ganz sicher von einer Person so erfüllbar.
Doch was dann hinsichtlich der restlichen Organisation erwartet wird, erscheint mir eine Aufgabe, die so wohl nur in sehr kleinen Unternehmen umgesetzt werden kann und/oder dazu führt, daß der Scrum Master sehr häufig sein Team allein lassen muß.
- Leading and coaching the organization in its Scrum adoption;
- Planning Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact Scrum and empirical product
development;
- Causing change that increases the productivity of the Scrum Team; and,
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum
in the organization.
Vor allem sehe ich auch ingesamt den Widerspruch, daß auf der einen Seite der Scrum Master für das Scrum-Team zuständig ist und dann auf der anderen Seite der Organisation (ist das das restliche Unternehmen?) generell bei der Einführung von Scrum helfen soll.
Wie soll das gehen? Ich kann verstehen, daß manche Scrum Master, wenn sie denn das alles wirklich machen, am Rande des burn-out stehen.
Mehrere Scrum Master bilden ein Team
In einem Unternehmen, welches mehrere Entwicklungsteams hat, bilden mehrere Scrum Mastern ein Team. Zusammen können sie dann die Aufgabe Leading and coaching the organization in its Scrum adoption möglicherweise wahrnehmen. Wenn Scrum Master A ein Problem mit jemandem außerhalb von Team A zu lösen hat, kann ihn Scrum Master B teilweise bei der Arbeit mit Team A vertreten.
Parallelorganisation als potentieller Konfliktherd
Doch mich beschleicht bei dem Ganzen ein ungutes Gefühl. Führt das alles nicht zum Aufbau einer Parallelorganisation innerhalb des Unternehmens? Geht es am Ende dann gar nicht mehr um den Aufbau einer lernenden Organisation und die Entwicklung organisatorischer und technischer Fähigkeiten im Sinne des Unternehmenszweckes? Sondern womöglich mehr um Scrum Scrums wegen?
Ich erinnere mich an eine Aussage von Tobias Mayer im Rahmen seines Vortrages auf der SF Agile 2012 und auch als Tweet:
The purpose of a #Scrum retrospective is to learn how to stop doing Scrum. #SFAgile2012
— Tweet von Tobias Mayer vom 05.06.2012
Lernen ist das Ziel und nicht das Befolgen eines bestimmten Prozesses.
Nach dem Scrum Guide stellt der Scrum Master sicher das Scrum verstanden und korrekt angewandt wird. Dabei sollte man es bewenden lassen. Sonst behindert man durch das eigene Tun - Scrum - das erwünschte Lernen, weil man quasi nur lernt, wie man besser im Scrum machen wird.
Coaching zur Entwicklung organisatorischer und technischer Fähigkeiten
Statt sich auf Scrum oder Kanban oder andere definierte Vorgehensweisen zu konzentrieren, sollte man sich fortwährend Hilfe durch verschiedene Coaches zum Entwickeln organisatorischer und technischer Fähigkeiten holen. Es ist vollkommen in Ordnung dabei Scrum oder Kanban als Werkzeug einzusetzen.
Wenn Scrum für einige Zeit sinnvoll erscheint, dann wird man auch einen Scrum Master für die im Scrum Guide definierten Aufgaben haben. Es ist aber jemand, der das übergangsweise für ein Team oder mehrere macht. Der externe Coach bildet so jemanden aus, übernimmt am Anfang übergangsweise diese Rolle, aber gibt sie nach kurzer Zeit wieder ab. Und kümmert sich dann darum immer wieder zu sehen, ob das Team bereits gelernt hat ohne Scrum auszukommen.
Das Team wird, wenn es denn über Jahre zusammenbleiben darf, seine ganz eigene Art zu arbeiten entwickeln. Ein Coach kann dabei helfen. Ein Scrum Master kann das nicht.
Kann man Teams in der Softwareentwicklung sinnvoll und nachhaltig zur Verbesserung ihrer technischen und organisatorischen Fähigkeiten coachen ohne selbst langjährige Erfahrung in der Entwicklung von Software-Produkten zu haben? Das ist die Frage, die mir schon seit einiger Zeit durch den Kopf geht.
Verbesserung von Fertigkeiten, um Fähigkeiten zu haben
Während meiner Zeit in USA hatte ich das Vergnügen häufig mit Coaches zusammenarbeiten zu dürfen, die selbst auch ziemlich gute aktive Softwareentwickler sind. Dort werden Coaches meist für den “skill uplift”, also die Verbesserung von Fertigkeiten, in’s Haus geholt. Die dortige Auffassung von Coach ist, daß ein Coach den Teammitgliedern beibringt eine bessere Arbeit zu leisten als ohne (get better at the job). Das ist wie im Sport. Auch dort ist der Coach vom Fach. Der Sportcoach war früher meist ein ziemlich guter Sportler in der jeweiligen Disziplin und hat sich zum Coach fortentwickelt, sodaß er nun in der Lage ist den Nachwuchs auf sein eigenes früheres Niveau zu heben oder darüber hinaus. Das deckt sich auch mit dem Ursprung des Wortes “coach” und seiner Referenz an die Kutsche, die jemanden zum Ziel trägt.
Entsprechend stehen auch viele dieser Coaches der Bewegung software craftsmanship sehr positiv gegenüber.
In Deutschland ist mir aufgefallen, daß unter “Coaching” teilweise etwas ganz anderes verstanden wird, als ich diese bisher in USA kennengelernt habe. Ich habe seit meiner Rückkehr Personen getroffen, die sich häufig als Scrum Master vorstellen und Software-Teams coachen. Mancher berichtete dann auch, daß er/sie eine Ausbildung zum systemischen Coach gemacht hat oder in irgendeiner Weise etwas mit einem der vielen Coaching-Verbände zu tun hat.
Mir war gar nicht bewußt, daß es im relativ kleinen Deutschland eine Vielzahl Verbände für Coaching gibt. Also habe ich ein wenig recherchiert und ich finde zum Thema Coaching alles Mögliche. Es reicht von Hilfe in schwierigen Lebenslagen, über das Bauen von Brücken im Wald als Teambildungsmaßnahme bis hin zum Coaching von Führungskräften. Mir scheint als hätten viele der Beteiligten Psychologie oder eine andere Geisteswissenschaft studiert.
Das alles ist natürlich nicht falsch und es steht mir wirklich fern irgendjemanden in einem mir fremden Betätigungsfeld zu kritisieren. Das ist nicht meine Absicht. Ich möchte in diesem Artikel über Coaching in der Softwareentwicklung sprechen.
Ein Blick in’s Wörterbuch
Oben sprach ich vom Ursprung des Wortes “Coach”. Das Wörterbuch der englischen Sprache sagt, daß “to coach” ausbilden bedeutet. Das tun auch die Wörter “to train” und “to educate”, doch spricht man von “to coach” erst wenn die Ausbildung mit dem Verfeinern von bereits existierenden Fertigkeiten zu tun hat. Das von mir benutzte Wörterbuch erwähnt auch den Coach im Sport als Ausbilder eines Teams explizit. Im Deutschen würde man den als Trainer bezeichnen. Aber auch das Wort Trainer ist ein importiertes Wort. Die deutschen Begriffe wären Lehrer oder Ausbilder.
Ziel: Ein Meister werden
Softwareentwicklung ist eine Tätigkeit, die Elemente von Forschung, Design, Handwerk, Kunst und auch ein wenig Psychologie und cognitive sciences beinhaltet. Ein erfahrener Softwareentwickler sollte meiner Meinung nach in der Lage sein ein Produkt von der Idee bis zur Auslieferung an Endanwender zu realisieren. Wenn man das japanische Modell Shu-Ha-Ri oder das deutsche Modell Lehrling-Geselle-Meister zu Grund legt, dann wäre diese Person auf dem Ri-Niveau bzw. ein Meister. Ich meine damit natürlich nun nicht, daß alle aufgeführten Tätigkeiten von einer einzelnen Person durchzuführen seien. Es braucht schon ein Team für eine so große Aufgabe. Ein Handwerksmeister arbeitet auch mit vielen anderen Menschen zusammen. Als Meister kann er aber jederzeit helfen und aushelfen - ganz egal worum es geht.
Je mehr Meister eine Organisation beschäftigt, desto eher wird sie in der Lage sein fortwährend gute Produkte zu erschaffen. Es sollte im ureigensten Interesse der Organisation sein möglichst viele Mitarbeiter in jedem Tätigkeitsbereich zu Meistern ihres jeweiligen Faches fortzuentwickeln.
Das Ziel kennen
Kann man gute Softwareentwickler zu Meistern fortentwickeln ohne selbst erfahren zu haben wie eine von einem Meister gemachte Arbeit eigentlich aussieht? Kann man dies nur mit theoretischem Wissen oder Beoachtungen im Fachgebiet erreichen?
Coaching ist eine Vorgehensweise
Entsprechend meiner bisherigen Erfahrung in USA und entsprechend der Bedeutung des Wortes “to coach” ist Coaching nichts anderes als eine bestimmte Vorgehensweise für die Ausbildung von Menschen, die bereits reichlich Erfahrung haben.
Es gibt da das Modell von Dreyfus zur Wissensaneignung. Je nachdem auf welchem Niveau sich jemand oder ein Team befindet sollte der Ausbilder unterschiedliche Techniken benutzen.
Wechsel zwischen verschiedenen Methoden
Wenn ich z.B. einem Programmierer, welcher bisher noch nie testgetriebene Entwicklung (TDD) gemacht hat, helfen soll dies zu erlernen und von vornherein abgesprochen ist, daß dieser TDD lernen will, dann wäre Coaching die verkehrte Vorgehensweise. Da muß ich ganz direkt als eine Art Lehrer agieren und ihm die Grundlagen dieser Technik vermitteln und mit ihm gemeinsam praktische Aufgaben lösen. Das geht nicht durch Frontalunterricht. Das geht aber auch nicht durch geschicktes Fragenstellen. Also werde ich am Anfang eher klare Anweisungen geben (“wir schreiben jetzt den Test in der Form”), dann immer mal wieder den Schüler eigene Wege gehen lassen (er kann ja programmieren) und wieder zu einer direkteren Form zurückkehren. Am Ende ist die Vorgehensweise eine Mischung aus unterschiedlichen Vorgehensweisen.
Fertigkeiten verbessern oder nur Denkanstöße liefern
Das gerade Beschriebene kann jemand, der selbst kein Softwareentwickler ist, nicht leisten. Ein Coach, der nicht vom Fach ist, kann durch Lesen erfahren, daß es verschiedene hilfreiche Techniken gibt. Ob das jetzt TDD oder Scrum ist, spielt eigentlich keine Rolle. Aber er kann unmöglich den “skill uplift”, die Verbesserung von Fertigkeiten, erreichen. Wer nicht vom Fach ist, kann nur Denkanstöße liefern, aber nicht bei der Umsetzung helfen.
Aus Fertigkeiten werden Fähigkeiten
Am Ende des Tages wird von Software-Teams erwartet funktionsfähige Software abzuliefern, die einem bestimmten Zweck dient. Das sagt auch z.B. der Scrum-Guide, nach dem am Ende eines jeden Sprints ein potentially shipable product increment, also eine potentiell auslieferbare Verbesserung der Software, erwartet wird. Es muß funktionieren und benutzbar sein.
Verfügen die Mitglieder eines Teams über gut entwickelte Fertigkeiten, die für die gestellte Aufgabe hilfreich sind, dann verfügt das Team über Fähigkeiten. Gute Zusammenarbeit untereinander und mit dem Auftraggeber ist eine organisatorische Fähigkeit. Fertigkeiten, die es ermöglichen qualitativ hochwertige Software zu erstellen, bilden technische Fähigkeiten. Nämlich die Fähigkeit Anforderungen auch tatsächlich umzusetzen.
Also ist es die Aufgabe eines Coaches in der Softwareentwicklung den einzelnen Personen und dem Team als Ganzes bei der Entwicklung von organisatorischen und technischen Fähigkeiten zu helfen. Ein Scrum Master, welcher keine Erfahrung in der praktischen Softwareentwicklung hat, kann das nicht. Und seine Rolle ist entsprechend dem Scrum Guide ja ohnehin darauf beschränkt sicherzustellen, daß Scrum verstanden und korrekt angewandt wird. Als Coach muß man zunächst einmal ein Meister des Faches sein und dann zusätzlich über die Fähigkeiten verfügen, die es ermöglichen Wissen und Erfahrung an andere weiterzugeben.
Aktualisierung 31.10.2012
Stefan Haas wies mich auf Developing Great Agile Coaches - Towards a Framework of Agile Coaching Competency von Lyssa Adkins, Autorin des Buches Coaching Agile Teams und Michael K. Spayd, Agile Coach und einer der Teilnehmer am ersten Treffen der Stoos-Bewegung, hin. Besonders gefällt mir an diesem Vorschlag, daß “domain mastery”, also fachliches Wissen, neben dem Beherrschen von Techniken zum Vermitteln von Wissen gefordert wird. Paßt genau zu meiner eigenen Denkweise.
In verschiedenen XING-Gruppen, wie z.B. 1x1 für Führungskräfte und Personalmanagement & Führung drücken einige Teilnehmer ihr Unbehagen bzgl. agiler Entwicklung aus. Jene begreifen agile Entwicklung als so eine Art Rebellion und nutzen den Begriff “führungskräftefreie Zone”.
Sehr häufig wird Scrum gleichgesetzt mit agiler Entwicklung. Das ist zwar nicht der Fall, denn eigentlich ist Scrum nur ein Werkzeug zum Fördern agiler Entwicklung und keineswegs gleichbedeutend mit agiler Entwicklung an sich. Da gehört weit mehr dazu. Doch für die Diskussion um das Thema “führungskräftefreie Zone” macht es meiner Ansicht nach Sinn zunächst die allgemein bekannteste Erscheinungsform agiler Entwicklung zu betrachten. Im Scrum Guide wird von selbstorganisierenden Teams gesprochen.
Scrum Teams sind selbstorganisiert und interdisziplinär. Selbstorganisierte Teams entscheiden eigenständig darüber, wie die zu erledigende Arbeit am besten bewältigt werden kann. Es gibt niemanden, der einem selbstorganisierten Team von außen vorgibt, wie die Arbeit zu erledigen ist.
Da steht nun wirklich nicht, daß es keine Führungskräfte geben solle. Ist es vermessen wenn erfahrene Fachkräfte oder gar Experten erwarten, daß sie allein über das Wie ihrer Arbeit entscheiden wollen?
Als Frederick Taylor die Trennung von Kopf- und Handarbeit und damit modernes Management in den Fabriken Anfang 1900 propagierte hatte er es mehrheitlich mit ungebildeten Arbeitern zu tun. Es machte gewissen Sinn dem Arbeiter die Benutzung der richtigen Schaufel und die richtige Vorgehensweise vorzuschreiben. Es ging primär um wiederholtes Ausführen von immer gleichen monotonen Tätigkeiten.
Vergleichen wir das einmal mit der Arbeit eines Zimmerers. Von einem Zimmerer wurde über Jahrhunderte erwartet, daß er ein ganzes Haus vollständig und eigenständig aus Rohmaterial - das sind in diesem Fall die natürlich gewachsenen Bäume - errichten kann. Über Jahrhunderte haben Handwerker Wissen und Erfahrung von den Meistern an die Gesellen und Lehrlinge weitergegeben. Aus den Gesellen und Lehrlingen wurden Jahre später neue Meister. Es gibt einen guten Grund warum auch heute noch nur Meister ihres Faches die Ausbildung des Nachwuchses im Handwerk übernehmen dürfen.
Diese langwierige Ausbildung und das intime Fachwissen war aber nicht mehr hilfreich als es um Massenfertigung von immer gleichen Produkten ging. Es ging darum mehr vom Gleichen zu produzieren und dabei die Komplexität abzuschaffen. Je simpler die Vorgänge wurden, desto mehr konnte man Tätigkeiten von ungebildeten Arbeitskräften ausführen lassen. Statt Jahre auf neue Meister zu warten, konnte man Hunderte Handlanger billig einstellen - einfach weil die Anforderungen extrem gesunken waren und damit jeder mit zwei Händen qualifiziert genug war.
Softwareentwicklung ist komplexe Kopfarbeit
Die Entwicklung von Software ist eine Tätigkeit, die sich durch Komplexität auszeichnet. Wie schon der Begriff “Entwicklung” andeutet ist am Anfang nicht völlig klar was am Ende herauskommen wird. Man kann nicht wissen was man während der Entwicklung von Software entdecken wird.
Vielfach wird versucht der Softwareentwicklung ihre Komplexität zu nehmen. Das hat gut mit anderen Dingen funktioniert. Gelänge es die Komplexität dieser Tätigkeit zu reduzieren, dann könnte man viel mehr Software viel billiger herstellen und damit die Produktivität und den Gewinn steigern.
Doch geht das wirklich?
Was Software ist
In meinem Buch Smarter Software with Activity-Centered Design biete ich als Definition von Software das Folgende an:
Software is an executable model for an activity. It provides affordances to perform actions that contribute to the activity. It is a mediating tool that guides, supports, and influences user actions and perceptions.
Auf Deutsch:
Software ist ein ausführbares Modell für eine Tätigkeit. Sie bietet Bedienelemente zum Durchführen von Aufgaben, die zur Tätigkeit beitragen. Sie ist ein vermittelndes Werkzeug, welches führt, unterstützt und die Aufgaben und Wahrnehmung des Benutzers beinflußt.
Wenn nun Software ein Modell für eine Tätigkeit ist, dann muß man ja erstmal jene Tätigkeit begreifen bevor man dafür Software machen kann. Es existiert die Notwendigkeit des Erforschens, des Entdeckens. Das erfordert Neugierde und Experimente.
Führungskräfte als Unternehmer - nicht als Verwalter
Bei agiler Entwicklung geht es darum die Führungskräfte daran zu erinnern was eigentlich ihre eigentliche Aufgabe ist. Die Aufgabe einer Führungskraft ist, wie der Begriff schon impliziert, zu führen. Das bedeutet die Richtung vorzugeben und damit unternehmerisch tätig zu sein.
Scrum sieht z.B. die Rolle des Product Owner vor. Das ist ein Unternehmer mit der Verantwortung für ein zu entwickelndes Produkt. Der Product Owner ist damit eine echte Führungskraft.
Im Gegensatz zu inhabergeführten Unternehmen haben in vielen Großunternehmen die Verwalter die Macht übernommen. Diese nennen sich gern Führungskräfte. Doch in Wirklichkeit üben sie lediglich Kontrolle durch die Verwaltung der Geldmittel aus. Das hat nichts mit Führen im Sinne des Vorgebens einer Richtung oder dem Gestalten zu tun. Die Verwalter haben den Unternehmer verdrängt.
Weil sich nun diese falschen “Führungskräfte” anmaßen den Spezialisten detailliert vorzuschreiben wie und mit welchen Werkzeugen sie Software entwickeln sollen, versuchen die Spezialisten echte Führungskräfte zu finden. Man will die störenden Verwalter, die mit der Krämerseele, loswerden und durch Führungskräfte, durch Unternehmer mit Weitblick, ersetzen.
Agile Entwicklung ist eine Chance - keine Bedrohung
Für unternehmerisch denkende Menschen ist agile Entwicklung eine Chance. Sie ermöglicht neue Produkte zu entwickeln und neue Kundensegmente dadurch zu erschließen. Sie ermöglicht Fortentwicklung und trägt damit auch zum nachhaltigen Bestand des Unternehmens bei.
Für rückwärtsgewandte Verwalter, jene, die sich mehr um die Zahlen der Vergangenheit sorgen, kann agile Entwicklung schon eine Bedrohung darstellen. Schließlich weist man damit die Verwalter in ihre Schranken.
Doch … Haben jemals Verwalter Unternehmen gegründet? Haben Verwalter je neues Land entdeckt? Haben Verwalter je neue Dinge erschaffen? Dinge, die nicht der Verwaltung an sich dienlich sind?
Agile Entwicklung stellt die Sinnfrage nach dem Zweck eines Unternehmens. Die Antwort wird von den Kunden gegeben werden.
This blog has been quite since May. The reason for that is that we have relocated to Germany and I’ve been quite busy working on presentations for conferences, going to conferences and generally establishing my new venture.
Instead of writing here on this blog I’ve been writing a ton on http://www.caimito.net and mostly in German on http://www.caimito.net/de.
Relocating internationally with a horse and other things isn’t that easy and it is still work in progress. So I’m sure I will come back to this and tell the story in a little while when everything is done.
Many believe the best way to communicate is face to face. Being able to see the other person allows both communication partners to read each other’s body language and facial expressions. It feels most natural and doesn’t require additional effort, as that’s the form of communication we humans have been used to ever since.
In fact for almost all beings on planet Earth being within close range to each other when communicating is the only form possible. All those beings need to either see, hear or smell their communication partners. All, but humans. Humans have evolved into a species that can leverage two new forms of communication: one is sophisticated verbal communication and the other is communication through symbols.
Throughout our existence, we humans have developed thousands of different languages and usually also a corresponding form of scripture that allows us to record information, share and transmit it or get back to it at a later time. Being able to perform these activities has allowed us to evolve even further mentally and create complex societies and tools.
But why is it so difficult for us to communicate well with only the written word? Isn’t it that the same written word has allowed us to get to where we are now?
Maybe it is because not all of us possess the same skill to read and process the written word?
There is an activity that teaches us the skill to read and process the written word. It is called interpreting literature. The mechanics of this activity can be visualized as in the following diagram.
As the reader I will understand any text from within my own context. Context is the combination of my work/life situation, my education, my acquired believes, my skill of reading in a given language (the language of the text) and whatever else has influence on my understanding of what I read. For the writer there is also his own context and when he writes a text there is the context of the moment when the text is written.
The simpler and the shorter a text is, the less information about its context can be revealed to the reader. Think about Twitter messages. They are limited to 140 characters. People send them out of a situation at work, when they had a thought while walking or talking to a friend or something else. My, limited, observation is that people do take into account that limited context and don’t get into arguments because they understand that they can’t understand well what the person says. So they, when in doubt, assume the best.
In the case of email we don’t have that limitation. We can write very long texts and it may take an hour to write a meaningful email that not only transports what we want to say but also enough context so that the recipient understands why we write and what our situation was.
The challenge now becomes one of reading. Given the writer is good at expressing complex thoughts in a concise manner, if the reader just skims over the text due to time constraints or isn’t really willing to read thoroughly, we have a communication breakdown despite all good intentions and effort. It’s the context of the reader that becomes an impediment to working communication.
I feel that written communication only works when the communication partners are willing to invest and keep an open mind. In the case of literature the writer just puts the text out for anyone interested to read. It’s more a broadcast model. Writer and reader don’t have a tight relationship so there is not much harm being done, if the reader doesn’t understand the text as indented. However, in a work context, a lot of harm is being done when writer and reader don’t understand each other.
We can mitigate the negative effects of our natural inability to communicate well or we can invest into an improvement of our communication skills.
The prevalent recommendation to work within co-located teams to enable face to face communication is such a mitigation strategy. It creates a multi-channel situation for all communication partners but as soon as some leave the room and start relying on less channels the problems show up again.
Agile software development practitioners have shown us many good techniques to create high quality software. Once we start to use the agile mindset outside of software development teams we will need to solve the communication problem.
Software teams can share working software with the rest of the organization. For example, one team can share a library with other teams and the library is their product. They can send an ambassador with the code to the other team for a while to carry the context of the text to their colleagues.
What about when the product is something else than software?
I was just saying ambassador. I’ve seen some thoughts about a lattice organization where each group within the lattice shares a member with neighboring groups.
When coaching, I frequently make this observation. People want to receive instructions about how to do something and then move on. “Tell me what to do” is the question in their mind. When I respond to their request by explaining why they should do something, I start to loose their interest. There is really no difference between a regular team member and their manager. But it seems to correlate with the culture of their organizations.
These people are interested in being shown and taught a process. First you do this, then you continue with that and finally you check that and if it’s right, then you continue here. They like a linear and predictable way of doing things. Show up for work, do the things you have to do and leave.
A while ago I read somewhere that our human brain likes linear processes. First you get hungry, then you find food by doing all these steps and then you will feel happy. If that’s the case, then these people act perfectly normal.
But then creating things - and that includes software - is so much more than finding food or shuffling information from desk to desk. It is an entirely creative activity in which there is no clear separation between right or wrong. There are many wrong ways of doing it but also many right ways of doing it. So knowing and understanding why someone is doing it in a specific way seems to be important. Important because that knowledge may guide you to further learn in the direction of that person or someone else.
What I just called ‘learn in the direction’ is a complicated and probably entirely wrong way of calling this a ‘mindset’.
A mindset is not a belief. It has to do with assumptions and with a point of view. In German there is the term “Weltanschauung”. It means how someone views the world, which is a general philosophy of understanding the world based on assumptions and cultural background.
Something like “Agile” as expressed in the Agile Manifesto is clearly a mindset. It also is a preference. By saying “Individuals and interactions over processes and tools” the speaker makes it clear that he prefers one thing over the other and on request will explain why he does. He will likely not accept the opposite until you convince him that the other provides more benefit.
A mindset is based on experience and teaching. A process is purely based on teaching. You cannot successfully follow a mindset because someone taught you the rules but you can successfully follow a process after being taught the rules.
Acquiring a mindset requires to understand the Why of all the things the other carriers of said mindset do. In the case of a process understanding why you do something is not really important. You can still use it and be successful.
A mindset will grow stronger and become more and you will defend it more and more once you make enough positive experiences of applying it. That is when a mindset starts to morph into a belief. A process is easily abandoned. After all it is just a bunch of rules to follow and after changing employers you can quickly learn to deal with a new set of rules.
“Agile” - with uppercase A - can be a process. It can be working in iterations with all the ceremony before and after. It can be the XP flavor with things like TDD. Or something else that people have come up with. “agile” with lowercase A - is - just by looking at the word itself - an attribute.
“Being agile” is different from “doing Agile”.
By being agile I am able to react to change easily without loosing my balance. I can do this because I have solid grounding due to my experience in my profession. I have my preferences for how I do things and what I use to perform my work based on experience. I want to know for whom I do something because I want to tailor what I do towards that person. My agile mindset defines who I am, what I do and how I do it.
This is an experimental attempt to finding an explanation of why programmers don’t want to write tests first using Activity Theory.
The programmer is the subject and writing tests is the object. The outcome of this activity is well tested software.
According to Activity Theory there are rules, community, the division of labor, as well as the mediating artifacts that influence an activity. They themselves, are also influenced by the activity.
Let’s go through rules, community and division of labor first.
If there are no rules in place that demand writing tests, then nobody is being forced to do it. In the case of an organization with a traditional test approach (QA after the fact) there might be a rule that requires the team to deliver something that works or else the team will get back a report with a huge number of defects from the QA people. The rule may come in the form of bad performance reports or similar. If that’s the case, then there would be an incentive to writing tests to prevent defects.
In the case of the organization with the traditional test approach the community within the organization does not promote writing tests first. There may be a few people here and there but the community at large does not do it. So there is no good example for doing it. “Others don’t, why should I?” may be the question some programmers ask themselves in silence.
A huge influencer is the existing way of how labor is divided within the organization. If there are strongly separated groups and membership in these groups is static - based on job description -, then a programmer will not want to do the job of testers. He may be actively prevented from doing someone else’s job. In an extreme case he may do work outside of his job description and, who knows, could be accused of violating his work contract. How far this goes is also dependent on the rules and the community factors within the organization.
The fourth element that influences subject and object and is influenced by them is the mediating artifact. For a programmer this refers to the tools he uses to perform his work but also to things like the runtime environment or where software gets deployed too. Things like the version control system, how a build runs, etc. - all that is a mediating artefact. It’s basically everything that he uses to make software. Those artifacts are also influenced by the community within the organization and what is being used to make software does shape the community.
If at some point important decisions about tools were made and those tools don’t make testing easy, then a community will have evolved where testing first is seen as too difficult and not worth to pursue. A change of those tools might be very difficult, because the community is heavily invested into those tools, as the tools have influence onto rules and the division of labor within the organization.
I will stop here exploring this any further, as this is meant only as a little experiment. However, I hope that it shows how Activity Theory can be used to explain observed behavior. I believe that it can further be used to identify those factors that stand most in the way of making changes that allow the desired activity to happen.
As Activity Theory also takes into account for which reason, the motive, people perform an activity and helps to identify goal-based actions that contribute to the activity, there seems to be another handle for change.
Keeping the reins a bit loose instead of maintaining a tight contact with his head (we use a bit-less bridle) changed Maximiliano’s wish to go faster. We had some nice weather here in Buffalo, NY, and were out at the training court. He let me mount without moving his feet. He walked around the court in a slow walk. Everything was perfect. At least as long as we were going left.
As soon as we were going right, things started to change. Suddenly he wanted to go faster again. So I let him and apparently moving his feet faster made him calm down.
There is that interesting phenomenon of the two hemispheres of the horses brain. They are interconnected but horses can focus on two different things at the same time. They can watch a potential threat on one side and be curious about something else on the other.
According to Parelli right-brain horses tend to be submissive, fearful, not confident, nervous and reactive. That pretty much describes Maximiliano in his current stage of development. He can’t stand still easily, panics easily because of a perceived threat and is always very alert. That does qualify him enough so that I say he is a right-brain extrovert.
Today we were in the aisle between the stalls and it was feeding time. All the other horses got excited because there were food coming their way. What did Maximiliano do? He jumped in the air. All four feet went up and somehow he managed to do a jump while keeping in position. I was holding him with the lead rope and after a quick “hey!” he calmed down. But still… So that’s another point for begin a right-brain extrovert: over reactive.
Max, on the other hand, seems to be just the opposite. He is dominant, brave (approaches new object without fear to investigate), confident and pretty calm. He does tolerate many things too. There is hardly anything that worries or frightens him. Now I see that a left-brain introvert also gets easily bored, is pushy and has a tendency to buck or charge. Also they are stubborn and food focused and lazy. Well… That again is a pretty accurate description of little Max.
Today the two spent some time in the indoor arena. There was little Max pushing around the much bigger Maximiliano who was trying to get away from the little bugger. Max played the dominant horse biting the other one a bit to make him move. At one point - I was standing in the center of the arena - Maximiliano got bored of the game and went to me - like seeking refuge. So I grabbed his halter and ordered the approaching Max to stop and go away, which he did. We were clearly playing the game of finding out what our pecking order is. Little Max got the message and went to play elsewhere and Maximiliano apparently was happy to be with me instead of with pushy Max.
So it appears that I have two horses with exactly the opposite personality. Now, that’s fun. It certainly is a great opportunity for my own education. We shall see how it turns out in the long run.
Yesterday I was finally able to actually ride my Peruvian Paso Maximiliano again. All the desensitizing and being all over him rubbing, tapping and otherwise treating him like a big teddy while whispering in his ear seems to have had the desired effect. I was able to mount completely and he did not move. Only after I gave the signal his feet started to move. There we go. He did remember what changing weight in the stirrups means but he still wants to get into his preferred gait instead of just walk slowly.
Peruvian Paso horses move in a different way than other horses. Regular - non-gaited - horses walk, trot, canter and then gallop. Peruvians walk, then go into a faster walk called paso llano, followed by another much faster walk called sobreandando and then eventually gallop. With my Peruvian Paso mare Topacio in Panama I was fortunate enough to enjoy this walking horse sensation. It is like flying. You just go faster and faster but still it’s a very smooth and relaxing ride. There is no abrupt change between the different speeds. This video shows nicely how it looks like.
Maximiliano - even during round-penning - wants to go at the paso llano. The paso llano is the gait that allows these horse to cover long distances without getting tired. So he must feel most comfortable at that pace. Still it is important to teach him at a slower walk. Simply because the faster he moves, the more abrupt - and dangerous - misunderstandings can materialize.
We need to work on that next. Step by step.
Max on the other hand is a totally different character. He is like a young child with too much energy. He is just about 3 years old. When I took him out for a lesson he needed to disburse all that extra energy. So he started to jump around and was unwilling to go in circles. That of course cannot be tolerated. He needs to learn to respect humans and be calm around them. So it took about 10 minutes to get that clear between us. “You don’t want to behave? I make you run.” always works. After that he was a different horse trotting around in the circle and changing directions following my hand signals.
See a listing of all posts on this site
