Archive | May, 2012

Video: Beste Arbeitsbedingungen für Geeks

29 May

In meinem letzten Blogpost habe ich die Bilder von unserem absolut atemberaubendem Büro in San Francisco gepostet. Meine Erfahrungen nachdem ich eine Woche dort gearbeitet habe: Absolut motivierend… mehr Arbeitszeit dort zu verbringen. Ja, das ist wahrscheinlich der Nachteil dieser Arbeitsumgebung: Man arbeitet mehr, da es einfach cool ist im Dschungel in der Hängematte zu liegen und die neusten Tweets zu lesen. Durch Massagestühle und kostenlose Verpflegung schafft Atlassian auch eine  Bindung mit dem Mitarbeiter. Wer möchte den gerne wieder zurück in ein 30 stöckiges anonymes Bürogebäude, um dort eine Kick Ass Software zu programmieren? Hier also noch einmal das neue Büro als Video:

Beste Arbeitsbedingungen für Geeks

23 May

Bei Atlassian in San Francisco hat man sich sehr viel Gedanken über die Arbeitsbedingungen gemacht. Eine umgebaute Lagerhalle mit viel Raum zum Bewegen, ein voll mit Lebensmitteln ausgestattete Küche, Massagesessel und vieles mehr bietet das Atlassian Office in den USA. Es ist extrem wichtig, dass sich die Mitarbeiter wohlfühlen… und das ist den Designern wirklich gelungen.

Hier gibt es noch mehr Fotos

Im Flow programmieren

21 May

Ich habe meinen Talk “7 Dinge: Wie man gute Teams großartig macht” auf verschiedenen Konferenzen vorgetragen. Leider gibt es noch kein Video von dem gesamten Talk, also habe jedes einzelne Ding mit der Videokamera aufgenommen und werde es im Laufe der nächsten Wochen hier auf svenpet.com veröffentlichen. Heute: It’s Flowtime

Als Flow bezeichnet man die Zeit, in der man hoch konzentriert ist. Als Softwareentwickler bedeutet das, dass man das gesamte Softwaredesign im Kopf hat und wie in der Matrix nur noch in abstrakten Klassen und Vererbung denkt. Man möchte als Programmierer so lange und so oft wie möglich im Flow bleiben. Wie verträgt sich das am Besten mit der Forderung nach Kollaboration im Team? Tipps gibt es im Video “It’s Flowtime”

Mehr über Motivation im Team gibt  es auch hier

Retrospektive: Gute Teams großartig machen.

10 May

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!

Auf die Informationskultur kommt es an – Lesson learned

3 May
(Teil 2 von 2)

Im ersten Teil dieser Mini-Blogserie habe ich bereits darüber geschrieben, wie ein Wiki unsere Informations- und Kommunikationskultur unterstützt hat. Im zweiten Teil möchte ich gerne auf die Herausforderungen einer offenen Informationskultur eingehen und Tipps geben, wie man diese überwindet.

 Herausforderungen und Lösungen

1. Einführen in die Kultur

Schreiben von Wiki Seiten, kommentieren, und bloggen gehören nicht zu den traditionellen Kompetenzen von Mitarbeitern. Man ist es eher gewohnt Emails und Dokumente zu verfassen. Dies ist also eine Herausforderung für jeden neuen Mitarbeiter bei Atlassian.

Unsere Lösung ist eine einfache Regel:

Am ersten Arbeitstag eines neuen Mitarbeiters, muss dieser einen internen Vorstellungsartikel verfassen und veröffentlichen. Der Inhalt variiert von einem einfachen “Hallo” zu einem vollständigen Artikel über die Motivation für Atlassian zu arbeiten.

Die populärsten Blogposts sind die, die eine persönliche Seite des neuen Mitarbeiters zeigen, wie beispielsweise exotische Reiseziele oder Hobbys. Das führt oft zu vielen Kommentaren und Fragen von alten Mitarbeiter. Der Austausch von Dingen mit dem der neue Mitarbeiter vertraut ist, hilft ihm, sich mit der neuen Form der Konversation anzufreunden.

2. Das neue Medium kennenlernen

Viele Leute kennen Wikis durch Wikipedia. Aber in einem Wiki zu lesen, ist etwas anderes, als in einem Wiki zu schreiben. Wenn man eine weiße Wiki Seite vor sich hat, kann das schon einmal zu einer Schreibblockade führen.

Atlassian hat hierfür zwei Lösungen: Training und gute Beispiele:

Wir führen “Schulungen” mit neuen Mitarbeitern durch, indem wir ihnen zeigen, was man alles mit dem Wiki machen kann. Ohne eine solche Heranführung kann es passieren, dass Mitarbeiter Angst vor dem neuen Medium bekommen und wieder in alte Kommunikationsgewohnheiten zurückfallen. Es hat sich gezeigt, dass die weniger technisch versierten Mitarbeiter mehr Probleme mit der täglichen Benutzung von Wikis haben.

Glücklicherweise benutzen wir schon seit Jahren unseren Unternehmenswiki, so dass es dort gute Beispiele gibt, wie man ein Wiki benutzt. Man muss auch nicht den Aufbau einer Seite neu erfinden, sondern kann sich Inhalte aus ähnlichen Seiten (wie Projektpläne oder Meeting-Protokolle) einfach kopieren und dann ändern.

3. Informationsflut

Ein Nachteil eines häufig genutzten Wikis ist die Informationsflut, die es für Mitarbeitern schwer macht, wichtige vom unwichtigen Neuigkeiten zu unterscheiden. Es besteht das Risiko, dass Mitarbeiter wichtige Informationen übersehen.

Atlassian hat hierzu einen “Teilen”-Button in Confluence eingebaut, mit dessen Hilfe man direkt an einem oder mehrere Benutzer eine Email verschicken kann. Die Mail beinhaltet aber nicht den Inhalt der Seite, sie verweist einfach nur auf das Wiki, indem man wieder in die Diskussion online einsteigen kann.

Was wir gelernt haben

Es kommt auf die Kultur an!

Wenn man die Art, wie Leute arbeiten, ändern möchte, bedeutet das eine Veränderung der Arbeitskultur selber. Die Techniken gehen einen dann in Fleisch und Blut über. Neue Mitarbeiter haben es anfänglich schwer zurechtzukommen. Aber sie werden am ersten Tag schon aufgefordert, an dieser Kultur mitzuarbeiten.

Wenn man eine solche Kultur schon frühzeitig in einem Unternehmen einführt, macht das Skalieren später einfacher. Es müssen nur die neuen Mitarbeiter an die offene Kommunikation herangeführt werden und nicht das gesamte Unternehmen.

Mit gutem Beispiel vorangehen

Die Entscheidung eine offene Informationskultur zu implementieren, bedeutet vom CEO und dem Management als gutes Beispiel für den Rest des Unternehmens zu dienen. Wenn beispielsweise einem Manager Informationen per Email zukommen lässt, sollte dieser den Mitarbeiter motivieren, das Wiki zu benutzen, damit auch alle die Infos bekommen. Natürlich gibt es auch Informationen, die vertraulich sind (z.B. Firmenübernahmen oder Personalangelegenheiten).

Alle Mitarbeiter müssen mit gutem Beispiel vorangehen, damit diese offene Informationskultur gelebt wird.

 Systeme verändern

Von einem Dokumentenmanagement zu einem Informationsmanagement zu wechseln, kann schwierig werden, bietet aber auch neue Möglichkeiten. Auch hier sollte man vorsichtig und langsam vorgehen.

Bei Atlassian vermeiden wir es, mit Word und ähnlichen Office-Tools zu arbeiten. Das Wiki ersetzt den Word-Editor und Tabellenkalkulation wird bei uns nur vom Controlling und Marketing benutzt. Die Wiki-Nutzung wird zusätzlich dadurch unterstützt, dass wir keinen Dateiserver zum Informationsaustausch besitzen. Informationen sind somit immer aktuell, da man sich nicht mit verschiedenen Versionen auseinandersetzen muss.

Follow

Get every new post delivered to your Inbox.

Join 26 other followers