Showing posts with label coaching. Show all posts
Showing posts with label coaching. Show all posts

Thursday, 9 July 2015

A template to communicate intent

In a corporate environment, teams face many different stakeholders.

Despite of best efforts, team members often have trouble judging requests for what they are actually worth, and tend to react to apparent urgency instead of actual value.

A team lead I recently met found himself in the very same situation, and prompted me for advice. In our conversation, we found out that in his particular case, the issue was partly about communication: the team members didn't know the teams goals, and so they had little to go against.

However, knowing that goal would only get them so far, because things are rarely cut clearly - a request may be out of scope for the team, but fully aligned with the division goal.

The template

Shortly after, I came up with a template to cover three levels of goals and intent:

We will [achieve the team goal],
in order to [achieve the division's goal]
so that the company can [achieve the company's goal].


For example:
"We will ensure the performance of the mainframe
in order to enable the free flow of data
so that Skynet always remains one step ahead of the resistance."

How to apply it

Facing fresh input, this enables team members to think on their feet and look beyond the team's immediate goals, judging issues not only by what their team lead told them, but also by the larger objectives.
This mirrors the military concept of commander's intent, where doctrine says that the aim, purpose and implications of an operation have to be understood two echelons down - something that can hardly be achieved in a single sentence.
By that measure, just filling in the blanks makes for a nice poster, but leaves half the work undone: The actual act of face-to-face communication, where the team lead informs his colleagues about the three levels and their implications - once to make them clear, and once again whenever they change.

Obviously, a dialogue like this requires knowledge of the higher level's intent - but that is hardly a bad thing, since communication goals in a clear and concise fashion is part of proper leadership.

By my assessment, this template works best when the team has an overarching goal or mission that keeps constant for at least some weeks. With small adjustments, though, you could easily use the template for short term objectives like Sprint goals in a Scrum process.

What do you think of the template? What do you do to communicate management intent to your teams? Please tell me in the comments.

Tuesday, 25 March 2014

Der Agile Entdecker

Gemeinsamer Post mit Sandra Reupke-Sieroux und Olaf Lewitz:

Cover Image: The People's Scrum
Bei der play4agile 2014 hat Olaf mir erzählt, dass er schon eine Weile daran sitzt, Tobias Mayers Buch "The People's Scrum" ins Deutsche zu übertragen. Im Gespräch am Abend hat er mich und Sandra eingeladen mitzumachen. Alan Cyment, der an der spanischen Version arbeitet, gab uns drei einen Haufen Tips, und seitdem arbeiten wir daran.

Wir wollen in den nächsten Wochen einige der Essays vorab veröffentlichen - das Buch ist ja aus einem Blog entstanden. Auch für die deutsche Version sind wir gespannt auf euer Feedback!

"Der Agile Entdecker" haben wir als ersten gemeinsamen Post ausgewählt, weil es der Essay im Buch war, bei dem wir unsere gemeinsame Sprache gefunden haben. Wie viele seiner Essays vereint er Kritik an einem bekannten und verbreiteten Konzept mit einer neue Idee - gerade ausreichend skizziert, um sich inspirieren zu lassen. Tobias sagt uns nicht, was wir tun sollen. Er öffnet unser Herz und unseren Verstand für Neues, manchmal Radikales.

Viel Spaß beim Lesen! Habt ihr Agile Entdecker im Unternehmen? Habt ihr so was schon mal gemacht?

Der Agile Entdecker

Während eines Projekts in Indianapolis unterhielt ich mich mit einem Entwickler.
“Was weißt Du über Atomkraft?” fragte er mich, und erzählte dann, dass er in einem Atomkraftwerk gearbeitet habe. Dort erfuhren alle Arbeiter regelmäßige Schulungen über die Sicherheitsbestimmungen, sogar noch nach langjähriger Anstellung.

Die beste Absicherung gegen eine Kernschmelze sei, sagte er, die Köpfe der Kollegen stets durch aktuelle Erkenntnisse und häufige Erinnerungen an gutes Vorgehen wach zu halten.

Er fragte mich, warum agile Ausbildungen nach einem Durchgang vorüber wären. Er habe in verschiedenen Organisationen während der agilen Transition beobachtet, dass die Leute nach dem Training gut voran kamen und voller Wissen und Begeisterung steckten, diese Energie jedoch schnell verebbte und das gewohnte Verhalten zurückkehrte.

“Auch Softwarefirmen schmelzen”, stellte er fest.

Daraufhin hab ich mich damit beschäftigt, wie Firmen Scrum einführen und verwalten. Die meisten heuern für eine kurze Zeit Berater oder Trainer an.

Die Engagierteren unter ihnen besorgen sich einen Scrum Master, der von einem der zahllosen Verbände zertifiziert ist - im festen Glauben, das Zertifikat gewähre Qualität. Beide Ansätze erreichen dieses Ziel selten.

Hin und wieder habe ich den Gedanken, dass der Begriff des “Scrum Masters” die Agile Bewegung aufhält, dass diese Position die Selbstorganisation behindert. Zwar ist die Absicht gut, doch in der Praxis wird die Rolle viel zu oft herabgewürdigt zum Metriksammler, zum Prozesswachhund, im schlimmsten Fall sogar zur Scrumpolizei oder zum agilen Projektmanager.

Dadurch entreißt man dem Team Verantwortung, und die Menschen unterwerfen sich dem Prozess, der ihnen aufgebürdet wird.
Tobias Mayer

In den letzten zwei Jahren ist die Rolle des Scrum Masters in meinen Kursen immer mehr in den Hintergrund getreten. Ich beschreibe Scrum als die Beziehung zwischen Product Owner und Team und erforsche diese Beziehung in Hinblick auf Teamkultur, Fokus, gemeinsame Ausrichtung und Zusammenarbeit.

Scrum verspricht engagierte Teams und glückliche Kunden, aber dieses Versprechen löst das Problem der Kernschmelze nicht. Die Organisation muss nach wie vor einen nachhaltigen Weg finden, um kontinuierliche Verbesserung rund um die Grundprinzipien des Scrum-Frameworks zu etablieren.

Scrum Master sind dieser Weg nicht, denn Scrum Master sind stets auf den untersten Rängen des hierarchischen Totempfahls angesiedelt. Häufig müssen sie einer Projektmanagementabteilung Rede und Antwort stehen oder einem Entwicklungsleiter. Sie haben wenig Autonomie und werden oft zu Helfershelfern des Status Quo.

Auch agiles Coaching ist nicht der Weg. Coaching hilft Einzelnen und Teams sich selbst zu verwirklichen, doch wie bei einer Therapie kommt der Moment, an dem der Coachee die Beziehung beenden muss. Tut er es nicht, läuft er Gefahr, sich mit seinem Coach im Kreis zu drehen und gemeinsam eine ungesunde Beziehung gegenseitiger Abhängigkeit zu schaffen.

Der Weg scheint mir zu sein, Agilität in die DNS der Organisation zu injizieren. Wir wissen, dass Viren die DNS von Organismen verändern können, wenn sie nur stark genug sind, die Antikörper des Wirts abzuwehren. Um die Kultur der Organisation zu verändern, brauchen wir genau so ein Virus.

Daher möchte ich eine neue Rolle vorschlagen, um das Virus zu verbreiten: Den Agilen Entdecker. Diese Rolle ist anders als die des “Paten der Agilität”. Der Pate ist jemand - häufig ein Geschäftsführer oder der Chef der Entwicklungsabteilung - der sagt: “Jetzt aber agil!”, aber der weder versteht, welcher Änderungen in der Organisation dieser Schritt bedarf, noch die Zeit hat, sich auf wirkliche Veränderung einzulassen.

Der Agile Entdecker ist jemand, der auf der Suche nach Wissen in unerforschtes Land reist. Er oder sie ist ein Visionär und ein furchtloser Abenteurer, der durch seine Handlungen andere inspiriert selbst aufzubrechen.

Agiler Entdecker ist ein Vollzeitjob. Am besten ist es, wenn er niemandem unterstellt ist, doch wenn es sein muss, dann sollte er der Geschäftsführung berichten, und zwar in einer autonome Position, deren Leistung nicht gemessen wird.

Es ist nicht die Aufgabe des Entdeckers, Teams zu coachen oder anderen zu helfen, besser mit Scrum umzugehen.

Er oder sie soll zuhören, denken, inspirieren, konfrontieren, anheizen, herausfordern und die kollektiven Augen der Organisation öffnen, damit sie neue Möglichkeiten erblicken können. So sät er die Saat eines neuen Seins.

Ein guter Agiler Entdecker bringt sich in die agile Gemeinschaft außerhalb seiner Firma ein, nimmt an Veranstaltungen teil, diskutiert online, liest ausgiebig, lernt Neues und fördert den Dialog mit anderen Organisationen und Individuen. Er sorgt für den Austausch im Haus, begründet Gesprächsrunden und Workshops und fördert Ideen rund um experimentelle Verbesserung.

Insbesondere aber ermutigt er andere, es ihm gleich zu tun.

Der Agile Entdecker webt aus Silos und Hierarchien faszinierende Werke kinetischer Kunst, die Ehrfurcht und Erstaunen erwecken. Diese Umgebungen lassen Selbstorganisation gedeihen; gegenseitiges Coaching floriert und ersetzt teure Hilfsarbeiter, die sich nicht ums Ergebnis scheren. Das Engagement wird stärker, die Freude wächst - und die Kernschmelze bleibt aus, Tag um inspirierten Tag.

Tobias Mayer, 19. April 2012

Monday, 11 November 2013

Retrospektiven über Distanz

Kürzlich habe ich für einen Kunden eine Retrospektive für ein verteiltes Team moderiert.
Ich habe ein paar Dinge gesehen, die ich vorher nicht erwartet habe - das habe ich gelernt:
  • Hope for the best, expect the worst
    Nur weil Dir eine Videokonferenz versprochen wird, heißt das noch lange nicht, dass auch eine Videokonferenz stattfindet.
    Sei darauf vorbereitet, dass Du zeitweise mit einem Telefon als einzigem Kanal auskommen musst.
  • Such Dir einen Partner auf der anderen Seite
    Für den Fall, dass die Verbindung zusammenbricht oder falls eine Erklärung schwierig ist; für den Umgang mit der Technik im Allgemeinen: Wähle Dir einen Partner auf der anderen Seite, der mit Dir zusammenarbeitet. Er muss nicht alles selbst können; aber er muss wissen, wen er Fragen kann.
    Er ersetzt Deine Augen und zum Teil auch Deine Ohren auf der anderen Seite und kann Dir klar sagen, wenn die andere Seite etwas braucht, was Du über das Telefon nicht mitbekommen hast.
  • Prüfe, dass Dein Werkzeug läuft (Vielen Dank an meinen Kollegen Stefan Roock!)
    Kein Video heißt: Kleine Klebezettel. Es muss Ersatz her.
    Es gibt einige Tools, die dabei helfen können – CardMeeting, GroupMind und PadLet und habe ich mir angesehen – aber das ist alles nutzlos, wenn Regeln oder Infrastruktur Dir verbieten, diese Werkzeuge auch einzusetzen.
    Bitte Deinen Partner, Dein Werkzeug vorher zu prüfen.
    Wenn es nicht geht, such Dir eine Desktop-Sharing-Lösung und lass z.B. PowerPoint darin laufen, das ist besser als nichts.
  • Zuhören ist anstrengend
    Es ist sehr anstrengend, die ganze Zeit dem Telefon zuzuhören, und alle Beteiligten sind froh, wenn Sie für einen Moment “normal” reden können.
    Das heißt:
  • Verlass Dich auf (mehr) Gruppenarbeit
    Visuelles Arbeiten ist durch den schmalen Kanal schwer, auch wenn Du ein gutes Werkzeug hast. Jede Seite kann es aber doch – für sich, in Gruppen.
    Trag die Ergebnisse hinterher in Deinem Werkzeug zusammen, und sei darauf vorbereitet, dass ihr mehr als üblich darüber sprechen müsst:
  • Es dauert länger, als Du glaubst
    Die schmale Verbindung hindert Dich und die Teilnehmer daran, während der Gruppenarbeit etwas von der anderen Seite mitzubekommen. Osmotische Kommunikation ist damit abgesagt, und einzelne Punkte werden mehr Fragen und Kommentare mit sich bringen, als Du es erwartest.
    Sprecht ihr nicht in eurer Muttersprache, erwarte noch mal mehr.
    Das bringt zwei weitere Punkte mit sich:
  • Erklären, Erklären, Erklären
    Normalerweise kriegst Du leicht mit, wenn jemand etwas nicht versteht und noch nicht bereit für eine Aktivität ist – hier nicht.
    Dummerweise wirst Du auch weniger Fragen vorab kriegen – und vermutlich erst recht keine währenddessen.
    Sei in Deiner Erklärung ausschweifend bis es Dir Kopfschmerzen bereitet.
  • Erwarte andere Kultur
    Anders als bei einer Retro in einem Raum hast Du wenig Einfluss auf einen Teil Deiner Teilnehmer. Rechne damit, dass Du eine Pause nicht mit Deinem Gong beenden kannst, erwarte, dass Pünktlichkeit zum Abschluss der Übungen nicht so hoch geschätzt, wie Du es gewohnt bist.
    Wenn es am anderen Ende länger dauert, dauert es (einen Moment) länger.
Was sind eure Erfahrungen mit verteilten Retros?