Retrospektive: Gute Teams großartig machen.

Dieses Jahr auf der JAX in Mainz habe ich den Vortrag “7 Dinge: Wie man gute Teams großartig macht” gehalten. Dieser handelte im wesentlichen darüber, sein Team zu motivieren, um es produktiver, effizienter, neugieriger und innovativer zu machen. Eben aus einem schon guten Team, das Beste herausholen. Dabei habe ich über folgende Dinge gesprochen:

1. Flowtime – So lange und oft wie möglich im Flow bleiben, ohne die Zusammenarbeit zu vergessen
2. Feed your brain – Gemeinsam mit dem Team lernen und sich gegenseitig etwas beibringen
3. Say: Well done – Auch die kleinen Dinge würdigen. Anerkennung ist eines der wichtigen Dinge, warum wir täglich zur Arbeit gehen
4. Report Robot: Projektberichte automatisch generieren lassen: Spart Zeit und macht mehr Spaß!
5. Dogfooding: Das ganze Unternehmen soll die eigene Software benutzen, um selbst zu merken, wo man diese verbessern kann
6. Innovation Days: Neue eigene Ideen in Prototypen innerhalb von 24 Stunden umsetzen, um die Machbarkeit zu demonstrieren
7. 20% Zeit: Innovationen bis zur Produktreife entwickeln

Die Folien zum Talk findet man hier.

Probleme mit Innovation Days

Bei Innovation oder Prototype Days handelt es sich darum, 24 Stunden mit seinem Team oder mit der ganzen Abteilung neuen Produktideen auszuprobieren. Dabei kommt es nicht darauf an, den Code 100% “clean” zu programmieren und das System stabil zum Laufen zu bekommen, sondern einen Prototypen zu bauen!

• Problem: 24 Stunden arbeiten, so etwas lässt das Arbeitszeitgesetz in Deutschland gar nicht zu: Hier sollte man als Team kreativ sein. Vielleicht lässt man den Arbeitstag direkt mit dem Innovationstag beginnen, so dass man die maximale Arbeitszeit zur Verfügung hat und dehnt den Prototypentag auf 2 Arbeitstage auf (Bei Atlassian programmieren die meisten auch keine 24 Stunden durch). Allerdings verliert dieser Tag dann ein wenig an Reiz, da man nicht das Gefühl hat, einen super außergewöhnlichen Arbeitstag zu haben.
• Problem: Teammitglieder, die nicht bis spät am Abend programmieren wollen, fühlen sich jedoch genötigt, lange zu bleiben: Darum hieß mein Talk: Wie man gute Teams großartig macht. Ich glaube in einem guten Team ist es auch vollkommen in Ordnung, wenn jemand früher gehen möchte. Jeder respektiert hier die Bedürfnisse des anderen. Wenn man also im voraus weiss, dass jemand früher geht, kann man die Aufgaben dementsprechend planen.
• Problem: Das küren eines Gewinners am Ende des Tages, kann Mitarbeiter demotivieren: Wenn man das Gefühl hat, dass sich das ganze Team nicht für den einen Gewinner freuen kann, sollte man die Abstimmung am Ende weglassen. Ich glaube dennoch, dass ein wenig Konkurrenz, das Ergebnis verbessert. Man ist noch motivierter ein Kick-Ass Feature zu programmieren.

Probleme mit Flowtime

Im Flowtime Teil meines Talks habe ich den Tipp gegeben, für ein paar Stunden am Tag die Abteilung für Telefonanfragen, Emails und sonstigen Störungen zu schließen und sich auf das Programmieren zu konzentrieren.

• Problem: Einige Zeit, nachdem man die Flowtime eingeführt hat, machen Mitarbeiter nicht mehr mit und sehen  den Sinn dieser Zeit nicht mehr. Das habe ich auch selbst erlebt: Wenn sich die anderen Abteilungen an die Konzentrationszeit gewöhnt haben, ist es nachmittags eh still und keiner ruft an. Man sieht dann die Notwendigkeit nicht mehr, jeden zurechzuweisen, dass doch Flowtime ist. Ich fand es total OK, dass das Team an Flowtime keinen Bedarf mehr hatte  und diese kollektiv abgeschafft hat. In stürmischen Tagen kann man diese dann ja auch wieder einführen. Die Abteilung kennt dann zumindest schon die Regeln.

Probleme mit Dogfooding

Dogfooding bedeutet, dass das gesamte Unternehmen die entwickelte Software in einer alpha-Version benutzt – Vom CEO bis zur Sekretärin, aber am wichtigsten ist, dass die Entwickler Ihre programmierte Software benutzen, um Kunden besser zu verstehen und die Feedback-Zyklen so kurz wie möglich zu halten.

Problem: Wir machen eine Help Desk Software, die wir in der Softwareentwicklung nicht einsetzen und somit nicht selbst testen können: Ja, es gibt bestimmt Anwendungsfälle, bei denen man die Software schwer selbst ausprobieren kann. Aber die meisten machen es sich zu einfach: Eine Software, die im eigenen Help Desk eingesetzt wird, kann man sehr wohl selbst ausprobieren. Man muss sich nur einen halben Tag pro Woche Zeit nehmen und die HelpDesk Mitarbeiter unterstützen. Das wichtige dabei ist, dass dies regelmäßig in relativ kurzen Abständen passiert (mind. einmal wöchentlich bis 14-täglich).

Wer mehr über die 7 Dinge erfahren möchte, kann meine Blogserie zu diesem Thema hier lesen. Ich werde demnächst hier die Videos zu dem Talk veröffentlichen, also ein wenig Geduld noch bitte!