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!

Advertisements

Auf die Informationskultur kommt es an – Lesson learned

(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.

Auf die Informationskultur kommt es an

(Teil 1 von 2)

Nach Atlassians Gründung im Jahr 2003 hat man schnell festgestellt, dass man ein Tool benötigt, in dem man die Unternehmenskommunikation und Dokumentation online ablegen kann. Das ganze hat Geschichte gemacht: Es wurde Confluence entwickelt und hat unsere Informationskultur sehr stark geprägt. Wir hatten das Glück, von Anfang an ein Kollaborationstool zur Ablage und Verteilung von Informationen zu nutzen. Aber kein Tool der Welt, kann die Unternehmenskommunikation ändern. Das muss vom Management des Unternehmens gewollt und gelebt werden.

Informationen bei Atlassian

1. Open Company, no Bullshit

Mike & Scott, die Gründer von Atlassian, war der Gedanke sehr wichtig, ein offenes Unternehmen zu schaffen. Das sollte für beides gelten: Interne und externe Kommunikation.

interne Kommunikation externe Kommunikation
  • Geschäftspläne
  • Produktpläne
  • Technische Dokumentation
  • Online Diskussionen
  • Kommentare und Kritiken
  • Kunden Feedback
  • Berichte
  • Preisinformationen
  • Dokumentation
  • kostenlose Testversionen
  • Quellcode
  • Softwarefehler
  • Featureanfragen
  • Unternehmensblog

Neue Mitarbeiter haben sofort Zugang zu historischen Daten, ohne lange in “Legacy” Dateistrukturen herumzusuchen.  Als ich das erste mal meinem Chef einen Bericht über eine Konferenz schicken wollte, sagte der zu mir: “Blog es, damit das Unternehmen davon mitbekommt”. Nichts hat unsere Informationskultur für mich besser beschrieben als dieser Satz.

2. Online zusammenarbeiten

Ein sehr wichtiger aber oft unterschätzter Aspekt von Wikis ist die Kommentarfunktion, um sich über Inhalte zu unterhalten. Bei Atlassian kommentieren wir  wie wild auf Wiki-Seiten. Hier einige Anwendungsbeispiele:

  • Ideen zu Projektplänen äußern
  • Kritik an Informationen im Wiki
  • Links zu weiteren Quellen für Informationen hinzufügen
  • mit Kollegen aus anderen Büros über Inhalte diskutieren

Alle diese Sachen macht das Wiki nicht nur zu einer Quelle der Informationen, sondern zu einem öffentlichen Ort für Debatten, an denen wirklich jeder teilhaben kann.

3. Die News vom Unternehmen verfolgen

Bei Atlassian wird von Mitarbeitern erwartet, dass wirklich jeder die Neuigkeiten verfolgt, die in unserem Wiki erstellt werden. Jeder Mitarbeiter kann seinen NewsFeed selbst definieren, also nur die Neuigkeiten, die für ihn auch interessant sind. So ein NewsFeed bietet viele Vorteile:

  • Es werden keine Emails an alle Mitarbeiter verschickt, da Neuigkeiten, die jeder lesen soll, über das Wiki verteilt werden. Das schont die Inbox.
  • Alle sind über alles informiert. Die Verteilung von Nachrichten durch Wikis bietet den Vorteil, dass jeder Nachrichten aus allen Bereichen des Unternehmens lesen kann. Es gibt keinen eingeschränkten Verteiler.

Bei Atalssian schreiben unsere Gründer Mike & Scott in regelmäßigen Abständen sogenannte Founder Updates, in denen sie uns über die aktuelle Situation und Zukunftspläne informieren. Als ich bei Atlassian angefangen bin, war es sehr interessant die alten Founder Updates durchzulesen, um mir ein Gesamtbild der Unternehmensstrategie zu machen.

4. Internes Blogging

Atlassian betreibt mehrere öffentliche Blogs, auf denen wir Kunden über unsere Aktivitäten informieren. Es sind aber unsere internen Blogs, die so wichtig für unsere Informationskultur sind.

Ein interner Blogpost ist eigentlich wie eine Wiki Seite, die automatisch in dem eigenen Newsfeed auftaucht. Jeder Mitarbeiter betreibt seinen eigenen Blog, den nur Atlassianer lesen können. Wir schreiben über jedes Thema:

  • Erfahrungen mit einer neuen Programmiersprache
  • Ein Bericht über den Besuch eines Kunden
  • Eine Anfrage für Reisetipps
  • Einen Link zu einem interessanten Artikel im Internet

Viele Unternehmen richten ein schwarzes Brett hierfür ein, das aber häufig nicht aktuell ist oder nicht gelesen wird. Mit der Kombination aus persönlichen News und Unternehmensupdates hat Atlassian eine Plattform für einen offenen Informationsaustausch geschaffen, das wirklich von unseren Mitarbeitern intensiv genutzt wird.

5. Nach außen offen

Die oben beschriebenen Punkte gelten für internes Blogging, aber Atlassian ist auch offen nach außen. Wir glauben, dass Kunden von unserer offenen Informationspolitik profitieren. Diese Offenheit spiegelt sich in folgende Punkten wieder:

  • unsere Produktpreise sind für jeden sichtbar
  • zukünftige Kunden können unsere Software für 30 Tage kostenlos ausprobieren
  • unsere Dokumentation ist öffentlich für jeden einsehbar
  • Fehlerberichte und Featurewünsche sind öffentlich. Man kann für seine Lieblingsfunktionalität abstimmen

Man kennt das von verschiedenen Unternehmenswebseiten: Der Vertrieb ist nur über ein Kontaktformular erreichbar -Preise auf Anfrage. Wir glauben bei Atlassian daran, dass unsere Produkte selbst überzeugen müssen und verzichten daher auf Vertriebspersonal.

In Teil 2 werde ich über Herausforderungen und Chancen einer solchen Informationskultur schreiben.

Das Glück-O-Meter. Zufriedenheit der Mitarbeiter messen

Wie Zufrieden ist Ihr Team? Fragen Sie doch öfter mal Ihre Mitarbeiter! Aber wie erreicht man auf einfache Wiese alle Mitarbeiter und wie ehrlich sind diese, wenn sie gefragt werden? Wie stellt man sofort fest, dass die Stimmung unter den Mitarbeitern gekippt ist?

Mit dem Atlassian- Glück-O-Meter!

Das Glück-O-Meter

Wir bei Atlassian messen die Mitarbeiterzufriedenheit jeden Tag! An jedem Ausgang unserer Büros in Amsterdam, San Francisco und Sydney haben wir iPads aufgestellt, auf denen jeder Mitarbeiter  in Echtzeit sein Feedback abgeben kann. Es wird nur eine Frage gestellt, die man mit einmaligen drücken eines Symbols beantworten kann. Jeder Mitarbeiter soll beim Verlassen des Gebäudes die aktuelle Stimmung abgeben. Unsere momentane Antwortquote liegt bei 87%!

Wir stellen also sofort fest, wenn die Stimmung kippt. Der Stress-Level erhöht sich normalerweise, wenn ein Release ansteht oder unsere eigene Konferenz, das Atlassian Summit, stattfindet. Das Management kann sofort reagieren, wenn ein Zufriedensheitsschwellwert unterschritten wird.

Jeder Mitarbeiter kann anonym und ehrlich antworten, das erhöht die Belastbarkeit der Daten. Wenn ein Manager seine Mitarbeiter direkt fragt: “Wie geht es euch?”, gibt es nur wenige, die bei schlechter Stimmung ehrlich antworten. Auch verblassen bei jährlichen oder auch vierteljährlichen Zufriedenheitsabfragen die anstrengende Zeiten und die Unzufriedenheit.

Eine einfache App, die vieles verändern kann… und dann sieht so ein iPad am Firmeneingang auch noch cool aus!

Wir überlegen uns, auch mal die Fragen wöchentlich zu wechseln, um noch weitere Dinge abzufragen. Jedoch wird es bei nur einer Frage bleiben, damit die hohe Akzeptanz erhalten bleibt.

Die Evolution von FedEx Days – Innovationen fördern

Innovationen sind wichtig für Unternehmen. Ohne neue coole Produkte oder Features, hat man heutzutage wenig Chancen am Markt lange zu bestehen. Wie aber fördert man die Innovation in Unternehmen? Wie kommt man von der Idee zum Prototypen oder sogar zum fertigen Produkt? Eine konzentrierte Zeit für Innovationen hat sich dabei als nützlich erwiesen. Hier 4 Beispiele wie es gelingen kann.

FedEx Day

Atlassian hat den FedEx Day erfunden: Entwickler bekommen 24 Stunden Zeit, an ihren eigenen Ideen zu arbeiten. Dies ist eine sehr konzentrierte Zeit für Innovationen. Das coole an einem FedEx Day ist die begrenzte Dauer und der Wille der Entwickler, am Ende des Tages etwas vorführen zu können. Aber FedEx Days dienen nicht nur als Innovationsfabrik und zum Testen der Machbarkeit verschiedener Ideen, sondern auch zur Teambildung und Mitarbeitermotivation. Es arbeitet nämlich meist ein Team an einer Idee.

Round the Clock, Round the world

Foursquare hat einen 48 Stunden andauernden Hackathon auf 6 Kontinenten mit mehr als 500 Entwicklern durchgeführt. Das Coole an dem Foursquare-Ansatz ist, dass sie die Community aufgefordert haben, daran teilzunehmen. Man holt sich also die Innovation aus der Community und erhöht die Motivation von Foursquare-Hackern, indem man die Location und die Verpflegung sponsort.

Prototyping Days

Die Prototyping Days von Xing kann man auch als verlängerten FedEx Day bezeichnen. Das Unternehmen hat letztes Jahr ihren Mitarbeitern 3 Tage Zeit gegeben, an neuen eigenen innovativen Ideen zu arbeiten. Ist die Idee eher klein, lässt sich in 3 Tagen schon ein ordentliches Produkt entwickeln. Xing hat die Prototyping Days mit einem Vortrag von Robert Powell (Prototypen-Designer für Autos) eröffnet und in guter FedEx-Tradition mit einer Party beendet.

Innovation Lab

Innovation Lab ist ein coole Idee von Nordstrom, eine amerikanische Kauf- und Versandhauskette. Das Innovation Lab  besteht aus einem hochengagiertes Team, dass die Ideen von Kunden direkt vor Ort umsetzt. Die Mitarbeiter kommen mit einem mobilen Kanbanboard, Post Its und PCs in die Filialen und entwickeln den Prototypen einer Idee direkt an Ort und Stelle. Eine Mischung aus Lean Start up und FedEx day. In einer Timebox von einer Woche baut das Team ein fertiges Produkt und der Kunde kann während der Entwicklung sofort Feedback geben.

Wikis bringen Multimedia in die Dokumentation

Willkommen im HTML 5 Zeitalter. Es war nie einfacher Dokumentation mit Daten aus anderen Systemen zu verknüpfen und zu publizieren. Der Einsatz von Wikis für die Softwaredokumentation macht auch aus diesem Grund Sinn. Wer hat denn das letzte mal ein Handbuch für eine Software durchgeblättert? Hier also einige Tipps, wie man Dokumentation und Multimedia miteinander verknüpfen kann.

Bilder nutzen

Mit Bildern bleiben Informationen besser im Gedächtnis haften. Mehr noch: Bilder transportieren Informationen meist besser als nur Text. Man kann Daten kompakter und greifbarer in einem Diagramm unterbringen als ein schriftlicher Form. Zusätzlich wecken Bilder das Interesse der Leser.

Moderne Wikis geben den Editoren die Möglichkeit mit einfachen Mitteln ein Bild hinzuzufügen. Beispielsweise bietet das Enterprise Wiki Confluence eine Drag und Drop Funktion im Browser an, um beispielsweise ein Foto zum Text hinzuzufügen. Aber wo Wikis wirklich herausstechen, ist die Möglichkeit, die Doku mit dynamischen Daten aus anderen Seiten anzureichern.

Multimedialer Inhalt

Hier ein Überlbick, was alles mit modernen Wikis möglich ist

  • Video und Audio: Fügen Sie Multimediadateien zu Seiten hinzu oder betten Sie YouTube oder Vimeo Videos ein. Gerade für Anleitungen ist ein Video oft besser geeignet. Gleiches gilt für Screencasts. Aber: Natürlich ist diese Form der Dokumentation sehr zeit- und pflegeintensiv.
  • Bilder und Diagramme: Screenshots sollten in jeder Softwaredokumentation vorhanden sein. In Confluence ist es auch möglich Gliffy Diagramme direkt auf einer Seite anzuzeigen und zu editieren.
  • Präsentationen und andere Dokumente: Fügen Sie auch PDF-, Powerpoint-, SlideRocket oder Slideshare-Präsentationen zu ihrer Dokumentation hinzu, so dass Benutzer diese direkt auf der Dokuseite durchklicken können. Gleiches gilt für MS-Office Dokumente und GoogleDocs, die nicht erst vom Benutzer heruntergeladen werden müssen, sondern direkt auf der Seite betrachtet werden können.
Technische Redakteure sollten sich diese Funtionen zu nutze machen. Vielleicht hat Ihr Marketing Team gerade ein Anleitungsvideo produziert oder der Kollege aus der Technik hat einen Vortrag auf Slideshare veröffenlticht, der das System erklärt. Fügen Sie einfach diese Resourcen zur Dokumentation hinzu, ohne diese konvertieren zu müssen. Das sind tolle Resourcen für die Leser Ihrer Doku.

Echzeit-Daten

Ihre Seite kann Live-Informationen aus anderen Seiten enthalten. Wenn also Benutzer die Seite öffnen, sehen diese die neusten Informationen, die auf anderen Seiten publiziert worden sind:

  • Gadgets. iGoogle Gadgets bieten die Möglichkeit, beispielsweise eine Übersetzer-App, aktuelle Wetterinformationen, Landkarten und vieles mehr auf einfache Weise auf einer Wiki-Seite zu intgrieren.
  • Aufgabenverfolgung. Reichern Sie Ihre Release Notes mit erledigten Aufgaben aus Ihrer Aufgabenverfolgung an. Die Daten werden dynamisch aus dem Issue Tracker ausgelesen und in ihrer Releaseinformationsseite angezeigt.
  • und noch vieles mehr: Aktivitätsströme, Blogposts, Kalendar…

Twitter + Wiki = Tolle Kombination

Twitter ist für viele Menschen heutzutage die erste Wahl, um Informationen schnell zu verbreiten. Man liest und versendet Informationen im Netz, auf dem Smartphone, auf Facebook, via Email, RSS, spezielle Apps… An jedem Ort, zu jeder Zeit.

Wäre es nicht cool, wenn man technische Informationen über Twitter verschicken könnte? Noch besser: Wie wäre es wenn man Personen über Twitter an die Dokumentation heranführen kann? Atlassian hat mit beiden Sachen experimentiert.

Wir haben Kunden gebeten, über Tipps und Tricks für unsere Produkte zu twittern. Über ein speziellen HashTag teilen die Kunden Informationen mit uns und anderen Kunden. Diese Tweets werden dann auf unseren Doku-Seiten live veröffentlicht. Hier können Sie sich selbst davon überzeugen:

Interaktive und spielerische Dokumentation

Man glaubt es kaum, aber: Technische Doku kann von Spaß und Spiel profitieren. Diesen Gamifaction-Ansatz haben wir bei unserer Dragon Slayer Doku verfolgt. Dabei handelt es sich einfach um eine spielerische Anleitung, wie man Podukte installieren und konfigurieren kann. Die Installation und Konfiguration der gesamten Atlassian Produkte braucht ein wenig Zeit und kann auch mal ziemlich langweilig und tricky werden. Also haben wir Sir Charly von Atlassian, den furchtlose Drachentöter erfunden, der einen durch den Prozess leitet. Die Installation wurde dafür in verschieden Abschnitte unterteilt, an dessen jeweiligem Ende man über die Erfahrungen twittern soll.

“Fare ye well, brave souls and true. I’m starting the Atlassian Dragon Quest!”

Wir haben durchweg gute Erfahrungen mit der Einführung von Social Media – Fuktionalität in unserer Dokumentation mit Conflucence gemacht. Die Kunden schätzen die offene Kommunikation und lieben die Echtzeit-Funktionen.

Was für weitere Vorteile ein Wiki für die Softwaredokumentation im Team bietet, kann man hier nachlesen.

Software-Dokumentation im Team erstellen mit Wikis

Das gemeinsame Erstellen von Anforderungsdokumenten kennt man ja als Softwareentwickler: Der Product Owner schreibt, der Entwickler ändert oder kommentiert. Nach ein paar Schleifen steht dann ein fertiges Dokument. Wenn man aber technische Dokumentation erstellt, sind noch eine Menge mehr Leute involviert: Technische Redakteure, Entwickler, Marketing, Support und Endanwender. Das gibt oftmals ein ganz schönes Chaos, oder wird in einigen Unternehmen so strikt gehandhabt, dass die Dokumentation oft starr und veraltet wirkt.

Die Vorteile eines Wikis nutzen

Wir bei Atlassian benutzen das Enterprise Wiki Confluence zur Dokumentation unserer Software (-> Dogfooding: auch für Confluence). Wir haben 2 Seiten, die wir pflegen: Atlassian Anwender Doku und Atlassian Developer Doku. Bei uns erstellen neben den technischen Redakteuren auch Entwickler und Support die Dokumentation (und machmal auch unser CEO). Da wir nur 7 Redakteure haben, ist dies auch notwendig. Dazu kommen noch ca. 50 Helfer aus unserer Community.
Der Vorteil des Einsatzes eines Wikis sehen wir auch darin, dass Dokumentation und Zusammenarbeit unabhängig von geografischen Hürden und Zeitzonen erstellt werden kann. Ein Wiki steht immer und überall zur Verfügung.

Verantwortung übernehmen

Rechte: Es macht Sinn, an einigen Stellen die Rechte zu beschränken. In Confluence kann man Gruppen wie Entwickler, Redakteure und Community einrichten und die Rechte in verschiedenen Bereichen unterschiedlich vergeben.
Informiert sein: Man sollte immer über Änderungen informiert sein. Meist bieten Wikis einen Machanismus an, damit man über Email oder RSS-Feed immer auf dem Laufenden bleibt. Sie können dann regieren, wenn sie Zeit haben
Menschen beteiligen: Teilen Sie Inhalte anderen Personen mit und lassen sie diese an der Erstellung der Dokumentation teilhaben.
Verschicken Sie einen Link per Email oder benutzen sie die “Teilen”.-Funktion von Confluence. Die angesprochene Person kann sich dann einfach im Wiki einloggen und Inhalte verändern oder kommentieren.
Auch mal löschen: Hat jemand am Thema vorbeigeschrieben, oder ist eine Seite veraltet, sollte man nicht davor zurückschrecken auch mal Inhalte zu verschieben oder zu löschen. So bleibt ihre Dokumentation immer frisch (ist ja auch bei Quellcode so).

Kommentare nutzen

Die Kommentarfunktion ist eine der besten Features moderner Wikis. Man kann direkt in den Dialog mit dem Autor oder anderen an der Doku beitligten Personen einsteigen.

Achtung: Es können recht viele Kommantare werden, stellen Sie deshalb sicher, dass man die nötige Zeit und Resourcen hat, um sich auch darum zu kümmern. Nichts ist schlimmer, als die Kommentarfunktion anzubieten, dann aber nicht auf Anfragen zu antworten!
Nicht nur Dokumentation: Es werden meist nicht nur Kommentare zur Dokumentation gestellt. Meist sind es Fragen technischer Natur. Die technischen Redaktuere sollten sich also hier durch die Entwicklung unterstützen lassen.
Gegenseitige Hilfe: Das Beste, was passieren kann, ist, wenn eine Community entsteht, die sich gegenseitig hilft. Es gibt immer Fan-Boys der Produkte, die gerne anderen helfen möchten. Dadurch braucht auch die technische Redaktion weniger Resourcen. Unterstützen und bekräftigen sie ihre größten Fans.
Kommentar nicht erwünscht? Auf einigen Seiten machen Kommentare keinen Sinn oder sind nicht erwünscht. Schalten Sie die Kommentarfunktion für solche Bereiche ab.
Nett bleiben: Beiben Sie bei Antworten immer nett und höflich. Antworten Sie direkt und bestimmt, so wird ihre Wiki-gestützte Dokumentation zu einer guten Kommunikationsplattform.
Kommentare löschen: Ist eine Frage beantwortet, kann sie auch wieder nach einiger Zeit gelöscht werden. Passen Sie also ihre Doku an, wenn es hier ein Missverständnis gab, oder einige Dinge beschreiben wurden. Zu viele Kommentare lenken von der Dokumentation ab und helfen dem Benutzer nicht weiter, da diese meist nicht strukturiert sind. Wir löschen geklärte Kommentare bei Atlassian in der Regel nach 14 Tagen.

Die Verbindung halten

Wikis verbinden Menschen und verschiedene Aufgaben im Unternehmen miteinander. Gemeinsam kann man eine außergewöhnliche und frische Dokumentation erstellen. Ihre Nutzer werden es klasse finden, wenn Sie direkt mit Ihnen über Inhalte diskutieren können. Aber auch für Kollaboration im Unternehmen sind Dokumentationen in Wikis erstklassig geeignet.

Mehr über technische Dokuemtation mit Confluence gibt es auf unserer Webpage oder in Sarah Maddox Buch “Confluence, Tech Comm, Chocolate: A wiki as platform extraordinaire for technical communication”

6 Tipps zu einer guten Online-Präsenz für Softwareentwickler

Es gibt eine Menge Softwareentwickler auf der Welt, aber nur eine begrenzte Anzahl cooler Jobs. Wie kann man also am erfolgreichsten auf sich aufmerksam machen, ohne dass man gleich 18 Stunden am Tag arbeitet? Hier sind einige Ideen:

1. Teile deinen Code mit anderen

Personalabteilung schauen sich gerade bei einer Vielzahl von Bewerbungen immer öfter im Internet um. Der am meisten genutzte Weg ist wohl sich Code der Kandidaten aus Github oder Bitbucket anzuschauen.

Es ist keine Überraschung, dass zukünftige Arbeitgeber sich nach Bewerbern umschauen, die guten und sauberen Code schreiben können. Aber wie viel Code kann man schon in eine Bewerbung packen?

Entwickler sollten die Vorteile daran erkennen, ihre privaten Projekte öffentlich mit anderen zu teilen. Das ist eine gute Möglichkeit seine Interessen und Fähigkeiten zu präsentieren.

Gute Arbeitgeber halten auch nach aktiven Committern von Open Source Projekten Ausschau, um den Entwickler besser beurteilen zu können. An einem Open Source Projekt zu arbeiten, zeigt unter anderem deine Qualitäten im Team zu arbeiten. Es geht als nicht nur darum guten Code zu schreiben, sondern auch gut mit der User-Gemeinde zu kommunizieren.

2. Stelle Verbindungen her

Bei Xing und LinkedIn kann man einfach seinen Lebenslauf online stellen und sich mit interessanten Menschen verbinden. Man sollte allerdings seine Daten immer aktuell halten und auch die Beteiligung an Communities erwähnen. Das rundet dein Gesamtbild ab.

3. Get social

Ich habe Twitter nicht von Anfang an verstanden, bis ich Tweetdeck entdeckt habe. Solche Tools helfen einem das Rauschen zu reduzieren und Twitter zu einem exzellentem Research- und Kommunikationstool zu machen. Egal, ob ein interessantes Ereignis ansteht, es einen neuen interessanten Artikel zu lesen gibt oder ob für ein Tool ein neues cooles Update bereitsteht – auf Twitter liest man es zuerst.

Mit Twitter kann man interessanten Personen folgen, oder interessanten Hash-Tags, wie z.B. #Openjdk oder #Atlassian ;-). Viele Veranstaltungen benutzen ein Hash-Tag. Es ist also einfach Feedback zu geben oder Erfahrungen von diesen Events weiterzugeben.

Twitter tools: Hootsuite (web 2.0), Tweetdeck (Desktop und mobile App)

4. Vergiss nicht, deine Erfahrungen weiterzugeben…

Dein Quellcode erzählt nicht die ganze Geschichte (auch wenn Uncle Bob uns das immer weismachen möchte). Du solltest deine Gedanken, Meinungen und Ideen anderen Leuten mitteilen.

Interessante Blogs sollten Aspekte aufzeigen, an die man noch nicht gedacht hat, oder Tools und Techniken vorstellen, die für die Leser interessant sein könnten. Erzähle den Leuten deine Geschichte, was du gelernt hast. Versuch eine Diskussion zu starten, ohne andere gleich mit deiner Meinung vor den Kopf zu stoßen.

Lies andere Weblogs und trete in die Kommunikation ein. Wenn du eine Meinung hast, teile diese dem Autor über die Kommentarfunktion mit.

Gute Blog-Tools: blogger.com , wordpress.com

5. Komm auch mal weg vom Bildschirm

Ein Teil der technischen Community zu sein, bedeutet auch, sich außerhalb des Internets zu bewegen und Offlineverbindungen zu Personen aufzubauen. Wirklich von Angesicht zu Angesicht über die neusten Trends, Technologien oder Programmiersprachen zu sprechen macht viel mehr Spaß. Es gibt viele technischen Communities in jeder größeren Stadt in Deutschland. Xing und Meetup.com sind gute Plattformen, um sich über Communities zu informieren und die Termine zu den Treffen zu erfahren.

Lanyrd ist social Konferenzplattform auf der viele Communities ihre Events einstellen und managen. Man kann sich dort auch über die Sprecher und Vorträge informieren, oder wer sonst noch an der Konferenz teilnimmt. Lanyrd ist auch ein großartiges Tool um sein eigenes Profil als Sprecher aufzubauen 😉

6. Lightning Talks und Vorträge halten

Man sollte keine Angst davor haben vor Leuten zu sprechen, wir sind alle Geeks. Es ist wie mit allen Dingen, je mehr man vorträgt, desto sicherer wird man. Beginne einfach mit Themen, über die du wirklich viel weisst und mache eine kleine Präsentation, z.B. ein 5-Minuten Lightning Talk.

Auf Community Events zu sprechen ist ein gute Möglichkeit vor einem dir freundlichem Publikum zu stehen und positives Feedback zu bekommen.

Also keine Angst: Einfach mal ins kalte Wasser springen und loslegen… So etwas macht sich auch gut im Lebenslauf.

Event tools: Meetup.comLanyrdBuch: Bekenntnisse eines Redners

Auf Git & Mercurial wechseln – ohne Furcht

Am 20.3.2012 halte ich in Frankfurt auf dem Atlassian Unite einen Talk: “DVCS in the Enterprise: How Atlassian made the switch”. Der Vortrag handelt von unseren Migrationserfahrungen von Subversion zu Mercurial und Git.

Jeder der noch Subversion zur Versionskontrolle einsetzt wird heutzutage schief angeschaut und gefragt:  “Hast du denn noch nicht von Git oder Mercurial gehört. Das benutzt man doch heutzutage”. Ich persönlich kenne auch kein Team, dass bei einem neuen Projekt noch SVN oder sogar CVS einsetzt (Wenn es nicht schon eine SVN Server gibt, den man benutzen muss). Die Argumente der Verteidiger von zentralisierten Versionssystemen sind meist:

  • wir entwickeln doch keinen Linuxkernel, bei uns sind alle Codeänderungen wichtig und müssen im Master übernommen werden
  • wir arbeiten eh alle mit Netzwerkanschluss am Code. Wir brauchen kein offlinefähiges Repository
  • bei uns arbeiten alle auf dem Trunk; wir brauchen die ganzen Merging-Vorteile gar nicht

DVCS – viele Vorteile

Verteilte Versionskontrollsysteme bieten die gleichen Features wie ihre zentralisierten Kollegen und darüber hinaus noch mehr:

  • vollständige lokale Historie des Quellcodes (viel schneller)
  • wirklich jeder Commit und Comitter wird in der Historie festgehalten – nicht nur derjenige der den Merge durchgeführt hat
  • einfaches und sehr mächtiges Mergen (keine Angst vor langen Branches)
  • neue Möglichkeiten für Continuous Integration / Delivery mit Code-Staging
  • Die Toolunterstützung ist teilweise besser
  • es geht viel schneller den Code zu mergen oder einen Branch/Fork zu erstellen

Angst vor dem Wechsel?

Die Vorteile liegen auf der Hand. Es liegt meiner Meinung nach eher an der Furcht vor einem Wechsel aus zwei Gründen:

  1. Angst, dass das Team das Konzept hinter DVCS nicht versteht  und somit viel Zeit beim Lernprozess verliert.
  2. Angst vor der Migration. Der Wechsel auf ein neues System an einer so zentralen Stelle kann den Entwicklungsbetrieb für mehrere Tage lahmlegen, oder es kann gar nicht alles vollständig migriert werden.

Unsere Erfahrungen

Natürlich hatten wir bei Atlassian auch bedenken vor einem Wechsel auf ein konzeptionell neues Versionskontrollsystem. Wir haben es allerdings geschafft ohne Downtime für unsere Entwicklung den Wechsel durchzuführen. Auch haben wir vorher im Team den Wechsel im einzelnen besprochen und auf unseren Wiki-Seiten dokumentiert, so dass jeder am Ende keine Bedenken mehr vor dem Wechsel gehabt hat.

Wir haben auch erst einmal nichts an unserer Art, wie wir Code einchecken, Branches erstellen und mergen, geändert. Es hat sich allerdings schnell herausgestellt, das die Möglichkeiten, die einem Git und Mercurial bieten, die tägliche Arbeit beschleunigen und vereinfachen können… Aber: Die ersten Wochen haben wir genauso wie vorher gearbeitet (bis auf die Tatsache, dass wir nicht mehr subclipse oder ähnliches benutzen haben).

Die Migration wurde bei uns sorgfältig geplant. Wir haben zeitweise den in Subversion eingecheckten Code automatisiert in Mercurial importiert und Builds davon erstellt. Das ganze hat uns die Sicherheit gegeben, dass der Code in einem DVCS genauso gut – wenn nicht sogar besser – aufgehoben ist als in SVN.

Mein Kollege Stefan Saasen hat einen sehr detaillierten Blogeintrag für Praktiker darüber geschrieben, wie das Confluence Team zu Git gewechselt hat.

Noch mehr Erfahrungen?

Ich halte einen Vortag über genau dieses Thema auf der in Frankfurt stattfindenden Atlassian Konferenz (Atlassian Unite). Dort werde ich noch einmal genau erklären was uns der Wechsel gebracht hat, wie wir unsere Workflows ausgewählt haben und wie verschiedene Teams zu DVCS migriert sind. Außerdem finden auf dem Atlassian Unite noch weitere Talks zu JIRA, Confluence, agiler Softwareentwicklung und vieles mehr statt. Das ganze Programm gibt es hier.

Blitzstart in den neuen IT Job

Für neue Mitarbeiter hat Atlassian seit zwei Jahren ein eigenes Programm entwickelt. Wir finden es extrem wichtig, dass neue Atlassianer so schnell wie möglich unsere Kultur, Werte und Grundlagen aus jedem Arbeitsbereich kennenlernen. Bei Google sind es Noodles und bei uns heißt es Bootcamp.

Bootcamp

Das Bootcamp geht über 2-3 Wochen mit ca. 4 Präsentationen am Tag. Man lernt beispielsweise wie ein Technischer Redakteur zu denken, erfährt alles über UI-Design bei Atlassian und lernt Scott & Mike kennen, die Gründer von Atlassian. Die Vorträge werden von einem Entwickler, QA-Mitarbeiter, Team Lead oder einem anderen “normalen” Atlassian Mitarbeiter gehalten. Normalerweise beginnt man mit dem Bootcamp am ersten Arbeitstag, ich durfte nach 6 Monaten Atlassian auch zum Bootcamp nach Sydney. Nach einem Tag voller Informationen ist man am Abend ziemlich erschlagen, nach so vielen interessanten Themen, vorgetragen von noch mehr interessanteren Persönlichkeiten. Der JIRA Plugin-Tages-Workshop war mein ganz persönliches Highlight.

Will man, dass sich neue Mitarbeiter schnell einarbeiten, sollte man ein solch intensives Training zum Jobstart einführen. Es dauert manchmal Jahre, bis man bei einem neuen Arbeitgeber verstanden hat, wie das Unternehmen tickt oder wie andere Abteilungen arbeiten. Man verliert am Anfang zu viel Zeit damit, zu verstehen, wer wichtig ist, welche Abteilung wofür zuständig ist oder einfach nur warum es überhaupt keinen Vertrieb gibt (-> wir haben kein einzigen Vertriebsmitarbeiter bei Atlassian).

Hack House

Für unsere Studienabgänger haben wir uns dieses Jahr etwas ganz besonderes ausgedacht. Wir haben ein Haus direkt am Strand gemietet. Aus 430 Bewerbern haben wir die besten 10 Abgänger für unser Geek-Abenteuer ausgewählt. Dabei haben wir darauf geachtet, dass das Team aus verschiedenen hoch motivierten Spezialisten besteht, die sich gegenseitig bei den Aufgaben unterstützen können. So hatten wir Studenten für Web-Design, Java Script-Entwickler, Datenbankarchitekten, etc. Unsere 10 “Gradlassians” wurden gebeten Badesachen, Surfboards und Sonnencreme einzupacken, denn ein bisschen Spaß ohne Tastatur sollte man ja auch noch haben. Es gab allerdings 5 Regeln im Hack House:

  • seinen eigenen Kram aufräumen
  • 23:00 Uhr Nachtruhe
  • keine unangemeldeten Besucher
  • Lebe Atlassian’s Werte
  • Arbeite hart und hab’ Spaß

Dazu hat Atlassian einen eigens fürs’ Hack House entworfenen Stundenplan zusammengestellt:

Man konnte die Hack House Bewohner über unsere Webcam beobachten. Das ganze hatte ein bisschen was von BigBrother für Geeks.

Nach einem Mini-Bootcamp haben unsere ehemaligen Studenten einen ganzen FedEx Day absolviert. Die Ergebnisse wurden allen Atlassian Mitarbeitern am Freitag Nachmittag präsentiert. Es ist unglaublich was so eine konzentrierte Lern- und Arbeitswoche an Produktivität und Motivation in unseren Gradlassians hervorgerufen hat.

Wir sind immer auf der Suche nach neuen motivierten Talenten. Hier gehts’ zu unseren Stellenangeboten