Tag: Communication

Kollegen-Bashing – Überraschung, es hilft nicht!

Bei allen Konferenzen, die meinen Kollegen und ich besuchen, poppt früher oder später das Thema Team-Kultur auf, als Grund von vielen/allen Problemen. Wenn wir erzählen, wie wir arbeiten, landen wir unausweichlich bei der Aussage “eine selbstorganisierte crossfunktionale Organisation ohne einen Chef, der DAS Sagen hat, ist naiv und nicht realistisch“. “Ihr habt irgendwo sicher einen Chef, ihr wisst es nur nicht!” war eine der abgefahrensten Antworten, die wir unlängst gehört haben, nur weil der Gesprächspartner nicht in der Lage war, dieses Bild zu verarbeiten: 5 Selbstorganisierte Teams, ohne Chefs, ohne CTO, ohne Projektmanager, ohne irgendwelche von außen eingekippte Regeln und Anforderungen, ohne Deadlines denen wir widerspruchslos unterliegen würden. Dafür aber mit selbst auferlegten Deadlines, mit Budgets, mit Freiheiten und Verantwortung gleichermaßen.

Ich spreche jetzt hier nicht vom Gesetz und von der Papierform: natürlich haben wir in der Firma einen CTO, einen Head of Development, einen CFO, sie entscheiden nur nicht wann, was und wie wir etwas tun. Sie definieren die Rahmen, in der die Geschäftsleitung in das Produkt/Vorhaben investiert, aber den Rest tun wir: POs und Scrum Master und Entwickler, gemeinsam.

Wir arbeiten seit mehr als einem Jahr in dieser Konstellation und wir können noch 6 Monate Vorlaufzeit dazurechnen, bis wir in der Lage waren, dieses Projekt auf Basis von Conways-Law zu starten.

“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” [Wikipedia]

In Umkehrschluss (und freie Übersetzung) heißt das “wie deine Organisation ist, so wird auch dein Produkt, dein Code strukturiert sein”. Wir haben also an unserer Organisation gearbeitet. Das Ziel war, ein verantwortungsvolles Team aufzubauen, das frei zum Träumen ist, um ein neues, großartiges Produkt zu bauen, ohne auferlegten Fesseln.

Wir haben jetzt dieses Team, wir leben jetzt diesen Traum – der natürlich auch Schatten hat, das Leben ist schließlich kein Ponyhof :). Der Unterschied ist: es sind unsere Probleme und wir drücken uns nicht davor, wir lösen sie zusammen.

Bevor ihr sagt “das ist ein Glücksfall, passiert normalerweise nicht” würde ich widersprechen. Bei uns ist es auch nicht nur einfach so passiert, wir haben (ungefähr 6 Monate) daran gearbeitet, und tun es weiterhin kontinuierlich. Der Clou, der Schlüssel zu dieser Organisation ist nämlich eine offene Feedback-Kultur.

Was soll das heißen, wie haben wir das bei uns erreicht?

  • Wir haben gelernt, Feedback zu geben und zu nehmen – ja, das ist nicht so einfach. Das sind die Regeln
    • Alle Aussagen sind Subjektiv: “Gestern als ich Review gemacht habe, habe ich das und das gesehen. Das finde ich aus folgenden Gründen nicht gut genug/gefährlich. Ich könnte mir vorstellen, dass so oder so es uns schneller zum Ziel bringen könnte.” Ihr merkt: niemals DU sagen, alles in Ich-Form, ohne vorgefertigten Meinungen oder Annahmen.
    • Alle Aussagen mit konkreten Beispielen. Aussagen mit “ich glaube, habe das Gefühl, etc.” sind Meinungen und keine Tatsachen. Man muss ein Beispiel finden sonst ist das Feedback nicht “zulässig”
    • Das Feedback wird immer konstruktiv formuliert. Es hilft nicht zu sagen, was schlecht ist, es ist viel wichtiger zu sagen woran man arbeiten sollte: “Ich weiß aus eigener Erfahrung, dass Pair-Programming in solchen Fällen sehr hilfreich ist” z.B.
    • Derjenige, die Feedback bekommt, muss es anhören ohne sich zu recht fertigen. Sie muss sich selber entscheiden, was sie mit dem Feedback macht. Jeder, der sich verbessern möchte, wird versuchen, dieses Feedback zu Herzen zu nehmen und an sich zu arbeiten. Das muss man nicht vorschreiben!
  • One-and-Ones: das sind Feedback-Runden zwischen 2 Personen in einem Team, am Anfang mit Scrum Master, solange die Leute sich an die Formulierung gewöhnt haben (wir haben am Anfang die ganze Idee ausgelacht) und später dann nur noch die Paare. Jedes mal nur in eine Richtung (nur der eine bekommt Feedback) und z.B. eine Woche später in die andere Richtung. Das Ergebnis ist, das wir inzwischen keine Termine mehr haben, wir machen das automatisch, jedes Mal, wenn etwas zu “Feedbacken” ist.
  • Team-Feedback: ist die letzte Stufe, läuft nach den gleichen regeln. Wird nicht nur zwischen Teams sondern auch zwischen Gruppen/Gilden gehalten, wie POs oder Architektur-Owner.

Das war’s. Ich habe seit über einem Jahr nicht mehr Sätze gehört, wie “die Teppen von dem anderen Team waren, die alles verbockt haben” oder “Die kriegen es ja sowieso nicht hin” oder “Was kümmert es mich, sie haben ja den Fehler eingecheckt” Und diese Arbeitsatmosphäre verleiht Flügel! (sorry für die copy-right-Verletzung 😉 )

You never code alone!

Meine letzte Woche in der Arbeit würde ich gerne the cleverbridge-University-Woche nennen, so großartig war sie. Wir haben 3 von 5 Tagen damit verbracht, unseren Code, unsere Prozesse, unseres Miteinander zu analysieren, zu sezieren, zu verbessern:

  • Dienstag hatten wir fast einen ganz Tag Architektur-Workshop um die Vision und die Strukturen für unseren Code zu definieren.
  • Den Freitag haben wir gemeinsam bei der dotnet-cologne 2014 verbracht.

Das wichtigste hat allerdings am Donnerstag stattgefunden: wir haben uns einen ganz Tag Zeit genommen, um von Ilker, meinem TDD-Mentor, so viel wie möglich über Specs, Tests, Teams und Kommunikation zu verstehen.

Es geht nichts über Verstehen!

from requirement to specifications
Wie schafft es ein Team, das und nur das zu bauen, was der Kunde braucht?

  1. Findet alle zusammen – product owner, Entwickler, Tester – das richtige Wording, die “ubiquitous language” heraus, die die Anforderung beschreiben
  2. Versteht alle zusammen, worum es geht.
  3. Definiert zusammen das Feature
  4. Schreibt zusammen die Akzeptanzkriterien

Wie werden eigentlich eine paar Menschen zu einem Team?

Dies ist wahrscheinlich das Problem aller Firmen weltweit, die sich weiterentwickeln möchten. Und das zu Recht: stell dir vor, du bist ein C#-Entwickler mit zum Beispiel Schwerpunkt Web, hast JavaScript warscheinlich noch nie als Programmiersprache betrachtet und von der Arbeit der anderen C#-Entwickler weißt nichts, außer dass sie existiert und sie irgendwann später erfolgen wird, nachdem du deine Aufgaben schon längst erledigt hast. Einen Abteilungsleiter hast natürlich auch und deine Entscheidungsgewalt beschränkt sich auf “soll ich foreach oder lieber LINQ verwenden?”

Das ist allerdings nicht alles: deine Aufgaben überschreiten niemals die Grenzen deiner Abteilung, genauso wenig wie dein Verständnis über die Anforderungen. Und das stört dich seit langem und nicht nur dich sondern auch den JavaScript-Typen und die Frontend-Entwicklerin und wenn du Glück hast, dann auch deinen Abteilungsleiter. Wenn das der Fall ist, dann hat deine Firma Glück: ihr seid offen für ein Crossfunktionales Team. Ihr musst nur diese Frage bejahen:

Bin ich bereit, jede Rolle in diesem Team zu erfüllen?
Auch mit der Gefahr, dass ich das nicht kann? Wenigstens noch nicht, oder noch nicht gut genug…

Jedes Team braucht noch ein paar Zutaten:

  1. Ein Ziel
  2. Eine Partizipation – eine gemeinsame “Teilhaberschaft”
  3. Den Respekt der Individualität
  4. Die gemeinsame Verantwortung

oder wie Ilker sagt “oder mindestens 3 davon plus jemanden, der die anderen die ganze Zeit daran erinnert”.

 

Ich will nicht behaupten, dass wir bereits alles darauf haben – aber wir sind auf dem besten Wege dahin. Und was das Wichtigste ist: wir werden diesen Weg sicherlich nicht verlassen.

Open Space – agiler geht es nicht

Letztes Wochenende war wieder Hightide für Entwickler: es war “Open Space Süd Time” in Karlsruhe. Es gab viele bekannte und viele unbekannte (= neue) Gesichter. Es gab sogar ich glaube fünf weibliche Teilnehmer und auch noch einen Hund 😀

Wegen den vielen neuen Teilnehmer war es nach mehreren Jahren wieder notwendig, die Prinzipien zu erklären, die bei einem Open Space gelten:

Regeln

Im Open Space gibt es vier Prinzipien (eigentlich eher Beobachtungen, wie sich die Welt zeigt)

  1. Wer auch immer kommt, es sind die richtigen Leute – einer oder 25 ist egal, und jeder ist wichtig und motiviert.
  2. Was auch immer geschieht, es ist das Einzige, was geschehen konnte – Ungeplantes und Unerwartetes ist oft kreativ und nützlich.
  3. Es beginnt, wenn die Zeit reif ist – wichtig ist die Energie (nicht die Pünktlichkeit)
  4. Vorbei ist vorbei – Nicht vorbei ist Nicht-vorbei – wenn die Energie zu Ende ist, ist die Zeit um.

und ein Gesetz:
Gesetz der zwei Füße

Das Gesetz der zwei Füße ist Ausdruck der Freiheit und Selbstverantwortung: Der Teilnehmer bleibt nur so lange in einer Gruppe, wie er es für sinnvoll erachtet, also solange er etwas lernen und/oder beitragen kann.
(Wikipedia)

Es gibt auch eine Beschreibung der Teilnehmer:

Teilnehmer

Bei Open Space gibt es nicht den richtigen oder falschen Teilnehmer. Jeder ist willkommen, der oder die sich direkt betroffen und motiviert fühlt, etwas verändern zu wollen. Es sollen möglichst unterschiedliche Menschen eingeladen werden (Berufsgruppen, Verantwortungsbereiche, Alter, aber auch Kunden, Nachbarn, etc.), darunter die wesentlichen Meinungsmacher und Multiplikatoren.

Nach diesem letzten Open Space würde ich diese Definition erweitern:
jeder, der teil nimmt muss zu einem offenem Gespräch bereit sein. Das bedeutet, er muss nicht nur neugierig auf die Meinung der anderen sein, sondern muss bereit sein, seine Ansichten zu revidieren, wenn er sich geirrt hat.

Kommt jemand hin, um etwas zu präsentieren anstatt zu diskutieren: dafür ist Open Space nicht geeignet. Das ist keine Konferenz, wo die Leute bezahlen und hoffen, dass es sich lohnt 😉
Andererseits kommt jemand ohne irgendwelche Ansichten dahin, hat er die Möglichkeit, sie hier zu formen, die Meinung der anderen an zu hören und seine eigenen Schlussfolgerungen zu ziehen.

Was hat das alles mit Agilität zu tun? Schauen wir mal, was während diesen 2 1/2 Tagen immer wieder – in Zyklen sozusagen – passiert:

  1. – wir beschreiben Probleme oder Angebote und schmeißen sie in die Runde. Es werden die Interessenten gezählt und auf die Karte notiert => hört sich wie Planungsmeeting an, oder?
  2. – wenn das Bord voll ist – wie ein Backlog – , muss die zeitliche und räumliche Reihenfolge definiert werden, und zwar nach Sinn und Machbarkeit => genau wie in einem Priomeeting?
  3. – jetzt kommt die größte Herausforderung: welchen Session soll ich besuchen? Welcher hat für MICH die höchste Prio? Wie organisiere ich meine Zeit so, dass mein “Backlog” auch abgearbeitet wird?

Die ganzen Zeit stellen wir Fragen gestellt und Antworten überlegt: Anforderungen an andere definiert und selbst welche erfüllt. Wenn diese Anforderungen sich geändert haben – siehe spontane Coding Dojo von 18 bis fast 20 Uhr am Samstag Abend – dann wird vom Team sofort eine Entscheidung getroffen: passt es noch in diesem oder erst im nächsten Sprint (also am zweiten Tag).

Wir versuchen ununterbrochen durch die richtige Kommunikation die Lücken zu schließen, die wegen den Unterschiede in Erfahrung, Ausbildung, Alter, Geschlecht, Herkunft usw. existieren. Wir haben eine zeitliche Vorgabe – jeder Timeslot ist 45 Minuten lang – den wir zwar wahrnehmen aber uns damit nicht unter Druck setzen lassen.

Und jeden Abend wird der wichtigste Teil eines agilen Prozesses zelebriert: die Retrospektive – bei einem kühlen Bier 🙂