ReConf 2014

Von 12.-15. März war ich auf der ReConf in München und habe im Rahmen der Konferenz den 2-tägigen Management 3.0 Workshop bei Jürgen Dittmar besucht. In diesem Blogpost möchte ich meine Eindrücke von der ReConf Konferenz zusammenfassen, meine Take-aways aus dem Management 3.0 Workshop werde ich in einem seperatem Blogpost behandeln.

ReConf:

Ich war am 2. Konferenztag auf der ReConf und habe die unten gelisteten Sessions besucht und für den Blog erwähnenwert befunden. In Klammer neben den Vortragstiteln habe ich meine persönliche Five-Star-Bewertung vergeben.

Key-Note: Let’s Help Melly (*****)
Jurgen Appelo

Sehr inspirierender Vortrag vom Author des Buches “Management 3.0“. Inhaltlich war für mich viel Neues und manches Bekanntes dabei. Es wurden alle im Vortrag angesprochenen Themen im 2-tägigen Management 3.0 Workshop von Jürgen Dittmar tiefer behandelt, wofür ich einen eigenen Blogpost schreiben werde – bitte um etwas Geduld.

Anforderungsmanagement & Gamification (*)
Stefan Schuck, Polarion Software GmbH

Wenig überzeugender Vortrag, der sehr oberflächlich gehalten war und eigentlich für mich nichts neues gebracht hat. Das “Highlight” waren die beiden lustigen YouTube Videos zum Thema Gamification, die allerdings auch nicht mehr gerade neu sind (vgl. mein Blogpost aus dem Jahr 2009):

PO als Brückenbauer Business – IT (**)
Alex Rachmann & Frank Engel, Anforderungsfabrik GmbH & Co. KG

Guter Vortrag im Dialog-Stil. Inhaltlich sehr auf die “Basics” beschränkt und daher wenig interessantes dabei. Interessant war:

  • Wenn über Scrum gesprochen wird, dann wird wenig über den Product Owner geredet, viel über den Scrum Master
  • Google AdWords Statistiken zeigen, dass nach “Scrum Master” wesentlich häufiger gesucht wird als nach “Product Owner”

Management neu denken – Zusammenarbeit neu definieren (****)
Björn Schotte, Mayflower GmbH

Sehr spannender, praxisbezogener Vortrag mit vielen neuen Impulsen zu Teamzusammenstellung, Management, Innovationskultur, gutes Arbeitsklima, etc. Björn Schotte experiment anscheined sehr viel in seiner Firma, was mir persönlich sehr gut gefällt. Die Ergebnisser seiner Experimente und Erfahrungen hat er in seinem Vortrag gepackt.

Björn Schotte sprach zu Beginn seines Vortrages von der Wichtigkeit “Accidential Conversations” zu unterstützen um informellen Austausch der Mitarbeiter zu stimulieren und in Folge Ideen entstehen zu lassen. Er erzählte dann, dass er Persönlichkeitstests mit seinen Teams macht um ein Klima der Offenheit zu erzeugen und somit die Teamarbeit zu optimieren. Er nannte folgende Tests, die er als geeignet ansieht:

  • MBTI
  • HBTI
  • DISC
  • Big Five

Als weitere Methode nannte er Personality Poker (von Stephen Shapiro) um spielerischdie Zusammenstellung von innovativen Teams zu unterstützen.

Danach stellte er Marc Hedlund’s (VP SW-Engineering @ Etsy) Methode um Change im Unternehmen voranzutreiben vor: Marc bloggt im internen Abteiltungsblog über Dinge die er verändern möchte und wartet auf das Echo der Mitarbeiter. Die Mitarbeiter entscheiden letztlich über die Umsetzung. Wenn die Idee initial nicht gut ankommt betreibt er aktiv lobbying indem er gezielt mit Mitarbeitern darüber redet. Wenn das auch nicht hilft ist für ihn die Idee gestorben und er bloggt die nächste Idee.

Björn Schotte nannte nannte auch die Wichtigkeit “Danke” zu sagen und Mitarbeiter dazu zu inspireren das auch zu tun (z.B. mit der einer Kudo Box).

Er gibt seinen Mitarbeitern auch 10% Slacktime, in der die Mitarbeiter an beliebigen Dingen arbeiten könnenEinzige Bedingung: Es muss Teamarbeit sein. Der Ablauf eines Slackdays ist wie folgt:

  1. Ideen Pitch in der Früh und Teamfindung
  2. Vorgegebene Zeit für die Umsetzung der Ideen (12-24h)
  3. Präsentation der Ergebnisse vor allen Mitarbeitern

Björn Schotte macht auch eine Firmen- bzw. Bereichsretro 2x im Jahr mit allen Mitarbeitern des Bereichs / Firma. Das Streichen von Jobtiteln wird in seiner Firma derzeit noch kontrovers diskutiert. Open Salary (Offenlegung der Gehälter) wurde von der Mehrheit im Unternehmen abgelehnt und daher nicht umgesetzt.

Zum Ende sprach er noch 2 Empfehlungen aus:

  1. Macht ein Barcamp mit eurem Konkurrenten: Das gibt einen enormen Innovations-Drive und wertvollen Informationsaustausch. Das erste Barcamp war ein voller Erfolgt weshalb er es nun regelmäßig macht.
  2. Bloggt in eurem Corporate Wiki

Key-Note: Bridging the Gap Between RE, Process Definition and Successful Iterative Roll-out (***)
Colin Hood, Colin Hood Systems Engineering

Für mich passt der Titel nicht wirklich zum Inhalt Vortrag, der gut und unterhaltsam war, allerdings inhaltlich nichts neues bot. Colin Hood hat sich in seiner Key-Note ganz dem Thema “Organizational Change” gewidmet. Eine seiner ersten markanten Aussagen war: “You have to put people in the middle of your change initiative!” Weiters sprach Colin: “Humans are great at ignoring information when change happens” und untermauerte diese Aussage mit einem eingängigem Beispiel – einer wahren Geschichte oder eine Studie – ich weiß es leider nicht mehr. Soweit ich mich erinnere ging das Beispiel etwa so: Autofahrer sind es gewöhnt mit dem Lenkrad das Fahrzeug zu lenken. Wird während dem Autofahren der Zündschlüssel wird die Lenkradsperre aktiv und macht das Lenken unmöglich. Um das Lenken wieder möglich zu machen muss der Zündschlüssel wieder angesteckt werden. Menschen, denen das passiert, versuchen allerdings mit aller Gewalt zu lenken anstatt den Zündschlüssel wieder anzustecken, obwohl sie wissen, dass der Zündschlüssel das Problem beheben würde. Laut Colins zeigt das Beispiel, dass wir in veränderten Situationen nicht immer rational handeln und das Handeln nach alten Gewohnheiten (das Lenkrad lässt sich nach Links und Rechts drehen) bestimmend ist.

Laut Colins braucht es die folgenden 3 Dinge für organisatorischen Wandel:

  • Manager müssen den Mitarbeitern das Gefühl von Sicherheit geben (Fehler müssen erlaubt sein)
  • Es muss eine Chance auf Erfolg geben
  • Das “WARUM” muss klar sein

Abschließend kam Colins noch auf den Deming Cycle zu sprechen, den er als Modell für kontinuierlichen Change sieht.

User Story KATA

Um die Qualität der User Stories in unseren mittlerweile 25 Scrum Teams bei Infonova weiter zu verbessern und anzugleichen führe ich gerade eine User Story KATA in unsere Entwicklungsabteilung durch. Ich habe die KATA mit Kollegen gestaltet und möchte die Idee dahinter gerne vorstellen:

Motivation:

Ausschlaggebend für einen erfolgreichen Sprint ist die Vorbereitung der User Stories. User Stories zu strukturieren ist einfach (siehe BDD), wie jedoch Product Owner und Team zu einem gemeinsamen Verständnis der Requirements kommen ist eine Herausforderung, die es zu jedes Mal aufs Neue zu meistern gilt. Als Check, ob ein gemeinsames Verständnis gegeben ist dient uns die Schätzung des Teams und die Definition of Ready. Wird eine User Story ohne ausreichendem gemeinsamen Verständnis commitet, passiert es nicht selten, dass das Commitment nicht gehalten werden kann, was die Planbarkeit eines Projektes schwierig macht. Bisher ist die Verwendung der DoR noch nicht über alle Teams etabliert. Mit Hilfe der KATA soll die Ausrollungen der DoR unterstützt werden und zu einer Qualitätssteigerung der Arbeitsweise führen.

Ziel:

  • Die Planbarkeit durch die Richtige Handhabung einer DoR und die daraus resultierenden geringeren Unterbrechungen und Scope-Changes im Sprint steigern.
  • Das kollaborative Erarbeiten der Requirements mit Product Owner und Team, sowie die Handhabung der Definition of Ready erlebbar machen und bewusst üben.

Vorbereitung:

Die Grundlage der KATA ist ein fiktives Business Szenario und eine dazu definierte User Story, jedoch ohne Akzeptanzkriterien, die in der KATA von den Teilnehmern ausgearbeitet werden sollen. Das Beispiel erscheint auf den ersten Blick bewusst trivial, enthält jedoch eine gewisse Komplexität, die nur durch genauere Beschäftigung mit der User Story zum Vorschein kommt.

Ablauf:

Es nimmt jeweils ein Entwicklerteam (4-6 Entwickler) + Scrum Master + Product Owner and der KATA teil. Alle Teilnehmer sind in der KATA in der Rolle des Entwicklerteams. Ich spiele in der KATA den Product Owner und stelle dem Team die vorbereitete User Story vor. In den folgenden 60 Minuten ist es die Aufgabe des Teams die User Story durch geschickte Fragen zu erforschen und die Akzeptanzkriterien in Form von Szenarien (siehe BDD) zu definieren. Nach und nach zeigt sich dem Team die wahre Komplexität der User Story. Nach einer Stunde breche ich diesen Prozess ab und lasse das Team das Ergebnis mit einer DoR auf die Erfüllung Dieser prüfen und schließlich die User Story zu schätzen.

Erfahrungen:

Nachdem ich nun mit 5 Teams die KATA durchgeführt habe kann ich ein erstes Zwischenresüme ziehen. Was den Teilnehmern der KATA meist zum ersten mal bewusst wird ist, wie wenig Zeit sie eigentlich für die Vorbereitung von User Stories investieren (meist weniger als 5% eines Sprints). Zum Anderen ist vielen die Bedeutung der DoR auf den Sprinterfolg noch nicht klar und wird durch die KATA erst richtig verstanden. Die teilgenommenen Teams können in der täglichen Arbeit auf die KATA als gemeinsames Erlebnis zurückblicken und so den sich langsam einschleichenden Prozess-Schlendrian entgegenwirken. Die Teilnehmer haben Spass an der KATA, was die wichtigste Grundlage ist, damit das transportierte Wissen auch weiterhin im Arbeitsalltag Anwendung findet.

Conclusio:

Zur Einführung von zentralen Prozess-Veränderungen, wie einer DoR scheint eine KATA hervorragend geeignet zu sein. Die aktive Einbindung der Mitarbeiter, der Spass-Faktor und das gemeinsame Erlebnis sind wesentliche Erfolgskriterien für nachhaltige Veränderung. Vermutlich wird jedoch die KATA nach einer gewissen Zeit wiederholt werden müssen um einen erneuten Impuls zu geben.

Wer an Details interessiert ist, bitte direkt an mich wenden.