Blitz Test – Die QA beim Softwaretest unterstützen

Für das ganze Unternehmen ist die Qualität der Software wichtig. Warum also nicht das ganze Unternehmen in die Verantwortung nehmen, dass die Qualität stimmt? Und das mit der Unterstützung einer leichtgewichtigen Methode wie Blitz Tests?

QA bei Atlassian

Die QA bei Atlassian ist nicht allein für die Qualität der Software verantwortlich. Vielmehr ist für die Fehlerfreiheit von JIRA, Confluence, Fisheye, Bamboo und Co. bei uns jeder verantwortlich! Bei uns testen auch Softwareentwickler, deshalb nennt sich unsere QA auch nicht Quality Assurence sondern Quality Assistance. Damit kann sich unsere QA viel besser auf Testautomatisierung und Testinfrastruktur konzentrieren.

Blitz Test

Atlassian experimentiert gerne mit neuen Methoden und so sind wir auf Blitz Tests gekommen: Es ist so was wie ein Flashmob bei dem man die Software testet… allerdings nicht ganz so spontan. Mitarbeiter aus verschiedenen Teilen des Unternehmens, wie Entwicklung, QA, Produktmanagement, Marketing, Support und jeder der Lust und Zeit hat  nehmen sich eine Stunde Zeit, eine neue Version auf Herz und Nieren zu testen! Ziel ist es nicht nur einzelne Teile der Software zu überprüfen, sondern das gesamt Produkt. Dieser Blick geht ja meistens beim alltäglichen Testen und Entwickeln ein wenig verloren. Dabei gibt es kaum Regeln:

  • eine fest definierte Timebox, damit Anfang und Ende der Blitz Test Session klar ist!
  • Aufteilung der Teams auf verschiedene größere Teile der Software
  • die QA sammelt Fehler und wertet diese am Ende aus

Das ist es schon! Eine Stunde konzentriertes Testen!

Besseres Produkt, besseres Gefühl

Auch wenn man die einzelnen Teile des Programms schon getestet und die Tests automatisiert hat, sind bei uns doch noch immer Fehler vorgekommen, die nur im Blitz Test aufgefallen sind. Eine Stunde Konzentration auf das Testen der neusten Software, bringt auch Abwechslung in die tägliche Arbeit, stört aber eigentlich nicht sehr die aktuelle Entwicklungsiteration. Natürlich bedeutet es aber Vor- und Nachbereitungszeit für die QA, bringt aber anderseits unheimlich viel Unterstützung. Das ganze wirkt sich auch noch positiv auf die Teambildung aus: Man ist als Team und Unternehmen gemeinsam dafür verantwortlich, ein gutes Produkt auszuliefern. Einfach mal ausprobieren und die Fehler am Besten mit Bonfire in JIRA eintragen 🙂

Advertisements

Reinventing ist nicht Rewriting

Vor ca. 3 Monaten habe ich auf der Devoxx und auf der W-Jax einen Talk über Legacy Code gehalten. Dabei kam auch das Thema Rewriting, also die Software mit modernerer Architektur und stabilerem Code neu zu schreiben, zur Sprache. Ich habe dabei die Meinung vetreten, ein Rewrite sei keine Lösung für schwer wartbaren Quellcode. Vielmehr sollte man die Codebasis langsam erneuern… Bis ich kürzlich den Artikel “Starting over Again” von Jason Fried (37signals) gelesen habe. Jason schreibt, dass die Konzepte des neuen aber noch nicht erschienenen Basecamp so revolutionär sind, dass  diese nicht in die 10 Jahre alte Codebase gepasst hätten. Hier hat sich 37signals also für ein Rewrite ihres erfolgreichen Task-Managers entschieden.

ReWriting

Bisher gab es für mich nur wenige Ausnahmen, die einen Rewrite einer Software gerechtfertigt haben.

  • die Programmiersprache ist so alt, dass meine keine Entwickler bekommt, die diese noch programmieren wollen / können
  • es handelt sich um eine kleine, sehr verschmutzt Codebase oder um einen kleinen unabhängigen Teil eines Programms (was ja schon eher ein Refactoring wäre)
Will man wirklich eine große Applikation neu schreiben, sollte man dies an der bestehenden Codebasis durchführen und langsam Teile des Programmes durch die neu geschriebenen austauschen. Natürlich vorausgesetzt, der Code lässt ein solches Vorgehen zu, sonst müsste man vorher doch noch die bestehende Basis erst mal refactorfähig machen.

ReInventing

Passt allerdings das neue Konzept so gar nicht in das Design des alten, ist ein Rewrite meiner Meinung nach auch sinnvoll. Wenn man sich das mobile Betriebssystem “Windows Mobile 6.5” von Microsoft ansieht und es mit dem seinerzeit auf dem Markt vorhandenen iOS vergleicht, war ein Rewrite sehr sinnvoll. Windows Phone 7 wurde entwickelt und kann jetzt auch wirklich mit dem Finger bedient werden (=neues Konzept). Ich schätze einmal, dass das nächste Jahr zeigen wird, ob Microsofts Entscheidung ein neues Betriebssystem zu entwickeln, nicht zu spät gekommen ist.

Allerdings würde ich das auch nicht unter das Thema Rewrite fallen lassen. Die Konzepte hinter Windows Phone 7 sind komplett andere, als bei seinem Vorgänger. Nichts wurde übernommen, sondern neu erfunden. Eine Art Reinvent also!

Fazit

Reinventing ist meiner Meinung nach nicht Rewriting. Wenn man also eine neue revolutionäre Idee für ein Produkt hat, macht es manchmal Sinn von vorne anzufangen, als die neuen Konzepte irgendwie in die alten reinzupressen. Das ist natürlich immer eine Gradwanderung: Wann handelt es sich wirklich um ein Reinvent?

Ich würde mich sehr über Feedback zu diesem Thema freuen!

Code Reviews – aber richtig!

Die beste aber am meisten verhasste XP-Technik für guten Quellcode ist… Pair Programming. Ich habe es etliche Male versucht. Das Ergebnis war großartig und jeder Mythos von Managern, dass in der gleichen Zeit Programmierer einzeln doppelt so viel Code (mit nahezu der gleichen Qualität und Quantität) schreiben könnten, gehört definitiv der Vergangenheit an. ABER: Es ist wirklich hart 4-6 Stunden konzentriert gemeinsam am Code zu arbeiten. Programmierer sind ein eigener Schlag Menschen, die dieser Praxis meist nicht sehr zugeneigt sind. Fakt ist: Pair Programming ist nicht sehr verbreitet.

Gute Codequalität und mehr durch Code Reviews

Unbestritten sehen vier Augen mehr als zwei. Was also tun? Man führt Code Reviews ein. Also eine Überprüfung der Codequalität durch ein oder mehrerer Teammitglieder. Diese können dann Kommentare zum programmierten Code abgeben und Fehler identifizieren. Aber wer mag schon gerne kritisiert werden? Genau das passiert aber bei Code Reviews. Wenn man das ganze natürlich im Team nur als Kritik betrachtet, hat man meiner Meinung nach Code Reviews missverstanden. Es geht hierbei vielmehr um “Collective Code Ownership”, also dass sich alle Teammitglieder in nahezu allen Bereichen des Codes auskennen. Dies hilft dabei,dass die Qualität und der Stil des Quellcodes über die gesamte Codebase gleich ist. Ich persönlich fand es immer interessant zu sehen, wie meine Kollegen Probleme gelöst haben. Gerade für neue Mitarbeiter und Junior Programmierer sind Code Reviews ein tolles Instrument: Als Reviewer lernt man die neue Codebase besser kennen und für den Programmierer wird sichergestellt, dass die Qualität des neuen Codes stimmt.

Best Code Reviews Practicies

Die Best Practicies beziehen sich auf Erfahrung im Einsatz von Crucible – dem Online Code Review Tool von Atlassian. Es ist sehr simpel, Mitarbeiter einzuladen, sich Änderungen am Code  anzuschauen und ggf. zu kommentieren. Es gibt einige Regeln zu beachten, damit Code Reviews nicht zum Bottleneck werden und zu Frustrationen führen:

  1. Nicht zu viele Kollegen zu einem Review einladen
    Lädt man zu viele Mitarbeiter zu einem Review ein, fühlen sich die einzelnen Programmierer nicht für die Qualität des Reviews verantwortlich und übersehen Code-Smells und Fehler. Zwei Reviewer pro Änderung haben sich für Atlassian als sehr praktikabel erwiesen.
  2. Reviews dürfen nicht zu groß sein
    Wenn man 100 Änderungen in 80 Klassen reviewen soll, verliert man schnell den Überblick und findet wenig Fehler. Man sollte vielmehr kleine Änderungen für ein Review einstellen.
  3. Reviews für Refactorings von Features trennen
    Damit man den Grund von Änderungen im Review versteht, sollten Refactorings von Änderungen für neue Features oder Bugfixes getrennt werden.  Man verliert sonst schnell die Übersicht.
  4. Nicht alles unter Review stellen
    Man sollte eine pragmatischen Ansatz für Code Reviews wählen, und nur relevante Änderungen unter Review stellen. Macht man simple Änderungen an Valueobjekten oder ändert den Namen einer Methode mit Änderungen in 300 Klassen, macht ein Review nicht unbedingt Sinn.
  5. Reviews sofort durchführen
    Um schnell Feedback zu erhalten, sollten Code Reviews nicht länger als 48 Stunden offen sein. Das heisst, dass der Code nach 48 Stunden vollständig reviewt sein sollte. Sind Änderungen notwendig, sollte diese sofort gemacht werden. Es sollten keine langen Diskussionen im Online Tool stattfinden. Lieber sollten der Autor und der Reviewer dann direkt miteinander sprechen, damit der Code so schnell wie möglich korrigiert wird. Erst dann ist der Task fertig (Definition of Done).
  6. Nicht sarkastisch sein
    Keiner sollte vor Code Reviews Angst haben. Sarkastische Kommentare sollten vermieden werden, sonst werden Code Reviews nicht im Team akzeptiert. Die Kommunikation in Code Reviews sollte der im Team entsprechen: Offen und wertschätzend!
Klar: Code Reviews sind nicht umsonst. Es wird Zeit der Entwickler kosten. Man fühlt sich aber um einiges besser, wenn noch einmal jemand über den programmierten Code schaut.

Atlassian Unite + AtlasCamp Europe

Dieses Frühjahr wird die Rhein-Main Region zur Atlassian-Region. Eine Woche Ende März kommt Atlassian nach Deutschland. Erst wird am 2o. März das Atlassian Unite in Frankfurt stattfinden und vom 22. bis 23. März das AtlasCamp Europa in Wiesbaden.

Die Anwenderkonferenz – Atlassian Unite


Das Atlassian Unite findet an 3 Orten in Europa statt: In Paris (15.3.2012), London (12.3.2012) und Frankfurt (20.3.2012). Hier werden hauptsächlich Vorträge rund um Atlassians Produkte stattfinden:

  • verschiedene Anwendungsfälle unserer Produkte und Plugins
  • die Roadmap für JIRA, Confluence & Co.
  • Best Practices
  • wie wir die Zukunft der Softwareentwicklung sehen
  • die lokale Atlassian Community
  • zusätzlich würden wir uns über Beiträge unserer Kunden freuen: Hier kann man sich für einen Vortrag bewerben

Atlassians Experten werden natürlich den ganzen Tag dabei sein und Rede und Antwort stehen. Das ganze wäre natürlich kein typisches Atlassian Event wenn es nicht am Abend mit einer Atlasbier-Zeit ausklingen würde.

Unsere Mitarbeiter aus San Francisco, Sydney und Amsterdam werden Ihre Vorträge meist auf Englisch halten, so dass es nur einen kleineren deutschsprachigen Teil geben wird.

Wir rechnen damit, dass unsere erste Anwenderkonferenz auf deutschem Boden schnell ausverkauft ist, also am Besten heute noch seinen Platz reservieren.

Die Entwicklerkonferenz – AtlasCamp Europe

Die jährlich in der Half Moon Bay stattfindende Entwicklerkonferenz kommt über den Atlantik! Europäischen Atlassian Plugin-Entwickler treffen sich für 2 Tage mit Atlassian Entwicklern zu diesem Geek-Event in Wiesbaden. Hier lernt man alles darüber, wie man ein Open Social Gadget oder Plugin programmiert, optimiert, erweitert, integriert und testet. Wir haben sichergestellt, dass es genug Zeit gibt, sich mit unseren Mitarbeitern oder Plugin-Partnern zu unterhalten. Weitere Details auch zu Hotels gibt es auf unserer AtlasCamp Europe Webseite.

Natürlich wird auch für ein Abendprogramm gesorgt. Die AtlasCamp Parties sind legendär und man sollte diese sich auf keinen Fall entgehen lassen…

Ich durfte auf dem letzten AtlasCamp in Kalifornien dabei sein… Hier schon als Einstimmung auf Wiesbaden mein Video:

Die richtige Arbeitsumgebung für Softwareentwickler

Die Atlassian Kollegen aus San Francisco sind kürzlich in ihre neuen Büroräume umgezogen. Natürlich war viel Wehmut dabei, aber mit der Aussicht in eine eigens für Atlassian geschaffene Umgebung zu ziehen, war der Abschied nicht ganz so schwer. Jetzt haben wir bei Atlassian den Anspruch, in allem was wir tun, excellent zu sein, und so haben wir uns auch bei der Einrichtung der Räume sehr viel Gedanken gemacht. Man verbringt mehr Zeit im Büro als zu Hause (wenn man die Zeit, die man schläft abzieht), und somit sollten die Arbeitsbedingungen  so angenhem wie möglich sein. Auch sollte man seinen Mitarbeitern die Umgebung bieten, die die besten Leistungen hervorruft. Nun haben Softwareentwickler meist andere Ansprüche an ein Büro, als Bänker. Softwareentwickler lieben die Freiheit, sich kreativ entfalten zu können. Und das haben wir versucht… und ich muss sagen: Es ist uns gelungen!

Offen

Wir pflegen eine sehr offene Kultur, also arbeiten wir gerne in Großraumbüros und das ohne Trennwände.

Unsere Besprechungsräume haben Fenster, so dass man sehen kann, wer sich gerade mit wem bespricht. Open company, no bullshit!

Das bedeutet auch, dass es etwas unruhiger ist. Damit die Kollegen andere Mitarbeiter bei längeren Telefongesprächen nicht stören, haben wir Telefonzellen (bei Atlassian eher Skype-Zellen) eingerichtet.

Meetings

Damit man auch spontane ungezwungene Meetings abhalten kann, haben wir Besprechungsnischen eingerichtet.

Flexibel

Einfach mal den Arbeitsort wechseln und gemütlich auf einem Sessel weiter programmieren? Dazu haben wir viele Möglichkeiten geschaffen.

Wohlfühlen

Für das leibliche Wohl ist eine gut ausgestattete Küche vorhanden.

Einfach mal bei einer Partie Tischfussball ausspannen.

Nach dem langem sitzen vor dem Bildschirm tut eine Massage gut!

Mehr Fotos unserer SF Büros gibt es hier. Zusätzliche Informationen zu Atlassians Kultur gibt es auf der Atlassian Webpage.

Der neue Joel Test – 12 Schritte für besseren Code

Vor 12 Jahren erfand Joel Spolsky, Gründer von Fokgreek Software den Joel Test. 12 Fragen an denen man erkennen soll, ob man in einem vernünftigen Softwareentwicklungsteam arbeitet. Kann man nur 10 der 12 Fragen mit Ja beantworten, sollte man sich überlegen, etwas am Prozess zu verändern. Wie gesagt: Das ganze ist jetzt schon 12 Jahre her. Um es vorwegzunehmen es hat sich doch einiges geändert. Hier mein Vorschlag für einen aktualisierten Joel Test (Sven Test):

  1. Kannst du deine Software in einem Schritt bauen und deployen?*
  2. Erstellst du bei jedem Checkin einen automatischen Build?*
  3. Erstellst du regelmäßig Metriken über deinen Code und wertest diese aus?*
  4. Spricht dein Issue-Tracker mit dem Build- und Versionskontrollsystem?*
  5. Werden bei dir Bugs gefixt bevor neue Features programmiert werden?
  6. Wird Funktionalität der Software vor der Implementierung in irgendeiner Form aufgeschrieben und mit Stakeholdern abgeglichen?*
  7. Haben deine Programmierer ruhige Arbeitsbedingungen?
  8. Benutzt du die besten Tools, die man kaufen kann?
  9. Hast du Mitarbeiter, die sich Vollzeit mit Tests beschäftigen?*
  10. Müssen Bewerber Quellcode während des Vorstellungsgespräches schreiben?
  11. Führst du Usability Tests mit Endbenutzern durch?
  12. Wird jede geänderte und neu programmierte Zeile deines Codes reviewt?*

* neu hinzugefügt
Aber schauen wir uns den Joel Test aus dem Jahr 2000 einmal genauer an, um zu verstehen, wie es zu meinem neuen Joel Test kam:

  1. Benutzt du eine Versionskontrolle?
    Das braucht man im Jahr 2012 wohl nicht mehr zu fragen. Teams ohne Source Control dürfen sich nicht Softwareentwicklungsteam nennen sondern Adrenalin Junkies. Im Jahr 2012 heißt die Frage eher: Benutzt du eine verteilte Versionskontrolle? So essinziell finde ich die Frage allerdings nicht, dass sie in den Joel Test kommen müsste: Fazit: Die Frage fliegt raus!
  2. Kannst du den gesamten Build in einem Schritt ausführen?
    Dies ist leider in vielen Projekten immer noch ein Problem, ist aber durch Continuous Integration Tools wie Jenkins, Cruise Control und Bamboo viel besser geworden.
    Heutzutage müsste es aber heißen: Kannst du deine Software in einem Schritt deployen? Dies rückt spätestens seit der Verbreitung des Begriffes DevOps mit Konfigurationsmanagement immer mehr ins Zentrum.
  3. Erstellst du tägliche Builds?
    Wie die Zeiten sich doch geändert haben: Das gehört definitiv ins Museum. Heute ist es eigentlich selbstverständlich einen Build pro Checkin aufzurufen: Erstellst du bei jedem Checkin einen automatischen Build? Ich würde das gerne noch ergänzen durch: Erstellst du regelmäßig Metriken über deinen Code und wertest diese aus?
  4. Hast du eine Datenbank für deine Bugs?
    Ich hoffe, das können wir streichen. Vielmehr sollten es heutzutage heißen: Spricht dein Issue-Tracker mit dem Build- und Versionskontrollsystem? Die Verknüpfung von textuell beschriebenen Funktionen mit dem tatsächlichen Code, den Builds und den Code Reviews ist super brauchbar!
  5. Werden bei dir Bugs gefixt bevor neue Features programmiert werden?
    Das ist immer noch aktuell und wird es wohl auch immer bleiben. Allerdings sind wir dank Scrum , also durch kurze Entwicklungsiterationen und Releasecyclen, dem Problem dichter auf den Fersen… oder etwa nicht?
    Fällt ein Fehler in der laufenden Software auf, kann er in der nächsten Iteration gefixt werden… Dies kann manchmal auch kritisch werden. Mit Kanban nähern wir uns dem Problem schon besser an. Mein Fazit: Behalten wir bis auf weiteres mal im Test.
  6. Hast du einen aktuellen Entwicklungsplan?
    Klar, heute hat man ein Scrum- oder Kanban Board! Diese Frage können wir also streichen. Und da Product Owner für die Features verantwortlich sind, die programmiert werden sollen, ist das nicht mehr das Problem der Entwicklung: Aufgabe abgewälzt.
  7. Hast du eine Spezifikation?
    Durch Epics und User Stories existiert eine bessere Spezifikation. Funtionaltäten müssen noch nicht bis ins kleinste Detail im voraus festgelegt werden. Diese Art ist übersichtlicher und nicht so zeitaufwendig. Der Punkt ist aus meiner Sicht auch nicht mehr aktuell und sollte durch die Frage: Wird Funktionalität der Software vor der Implementierung in irgendeiner Form aufgeschrieben und mit den Stakeholdern abgeglichen?
  8. Haben deine Programmierer ruhige Arbeitsbedingungen?
    Das ist natürlich auch heute noch interessant. Aber Joels Vorschlag, alle Mitarbeiter in separate Büros zu sperren, ist meiner Meinung nach auch nicht die Lösung. Man verliert dadurch die Zusammenarbeit, den Informationsfluss und Erfahrungsaustausch. Ich habe sehr gute Erfahrung mit Regeln gemacht, indem man ein bestimmte Zeit zur ruhigen Arbeit vereinbart und jemanden als Ansprechpartner für das gesamte Team ernennt. Diese Frage ist also immer noch aktuell und sollte im Joel Test bleiben.
  9. Benutzt du die besten Tools, die man kaufen kann?
    Glücklicherweise sind heutzutage die besten Tools entweder umsonst oder kosten nicht viel. Dank Cloud-Angeboten werden diese wohl auch in nächster Zeit noch günstiger, auch weil man nicht den Betrieb übernehmen muss.
    Anderseits höre ich heutzutage auch oft: Warum ein etwas besseres Tool einsetzen wenn etwas schlechteres umsonst ist? Aber an den Tools für die Entwickler sollte man auch heutzutage nicht sparen!
  10. Hast du Tester?
    Wir Entwickler schreiben Unit-Tests. Diese werden bei jedem Check-In automatisch ausgeführt. Zusätzlich haben wir automatische Integrationstests, die auch automatisch ausgeführt werden. Es fehlt noch der Abgleich der programmierten Funktionalität mit der User Story. Das könnten doch auch die Programmierkollegen übernehmen? Wozu also heutzutage noch Tester? Weil diese viel mehr Erfahrung mitbringen. Die Aufgabe des Testers, bzw. der QA sollte darin bestehen, sich um die Infrastruktur zu kümmern, die Regeln zu überprüfen, Usability Tests durchzuführen und die Programmierer befähigen, dass diese die QA unterstützen können. Tester gehören ins Team und sollten kein eigenständiges Team sein. Also kurz gesagt: Immer noch ein berechtigte Frage für den Joel-Test, die heute aber so heißen muss: Hast du Mitarbeiter, die sich Vollzeit mit Tests beschäftigen?
  11. Müssen Bewerber Quellcode während des Vorstellungsgespräches schreiben?
    Ich glaube nicht, dass sich hier viel verbessert hat. Es ist immer noch die Ausnahme, dass Arbeitsproben gefordert werden. Da viele Programmierer sich aber an Open Source Projekten beteiligen, kann man sich heutzutage oft schon vorab über die Programmierqualität informieren. Aber ein paar programmierte Zeilen, während eines Vorstellungsgespräches, sollte man trotzdem einfordern. Auch wenn das mehr Vorbereitungs- und Nachbereitungsarbeit erfordert.
  12. Führst du Usability Tests mit Endbenutzern durch?
    Dieser Punkt wurden in vielen agilen Unternehmen aus 2 Gründen verbessert: Die Stakeholder nehmen am Ende der Iteration die Funktionalität ab. Man bekommt also alle 2-4 Wochen direktes Feedback. Leider sind Stakeholder nicht unbedingt auch Endbenutzer. Wir kommen aber dichter dran. Durch häufigere Releases kann bekommt man schneller Feedback darüber, ob die neue Funktion auch Benutzerfreundlich ist.
    Auch dank Apple legen die Unternehmen immer mehr Aufmerksamkeit auf Usability.
    Ist dieser Punkt wirklich immer noch so wichtig? Klar! Stakeholders wissen manchmal auch nicht was benutzbar ist und was nicht.

Five reasons why you should have attended W-JAX

W-JAX in Munich. This conference took place from the 7th to 9th of November 2011 and was all about Java, web technologies and agility. The W-JAX is with 1,200 attendees one of the biggest developer conferences in Germany.

You couldn’t make to W-JAX this year? Here is what you’ve missed:

  1. Meet the experts
    You missed your chance to discuss hot technologies directly with the experts after the talks or on Tuesday evening at the Ballroom Event. The organizers had set up tables with specific topics like “Mobile Development”, “Java Enterprise” or “Performance”. At every table was sitting an or more experts of this specific topic. The attendees could than go to each table, ask questions and join into the discussion.
  2. Networking
    You missed the chance to broaden your network. Actually, that is what I think conferences are about. Speaking to people and getting ideas how to fix problems from other developers who has been down that road already or just get a new angle to your day to day work.
  3. The latest trends in software development
    You missed to hear the newest topics from Europe’s best experts on Cloud, Java, Continuous Delivery, Agility and Web Technologies. One highlight was definitely Kevlin Henney’s keynote about Cool Code. Kevlin was showing how to fit the code of a chess program into just 4.8 SMS and how to write a web server in just one line of code. The point was, that programmers should start studying code by reading more of it. There is so much free and cool code out there.
    A big trend of this years W-JAX was the DevOps movement. Matthias Marshall talked in his keynote about improving the team collaboration between the operational staff and the developers. He encouraged the listeners to show more interest for each other and exchange problems and ideas.
  4. The great atmosphere
    You missed the free beer reception, the delicious food, the original Bavarian brezl and the hallway conversations. And of course you missed Munich. Atlassian has of course visited the Hofbräuhaus and tried some Maß of German beer (one liter beer in a mug) and someWeißwürste (special Bavarian sausages). You can imagine that this was a long night.
  5. Cool Atlassian Swag
    You missed the chance to make your team mates jeleous and come to work after W-JAX with an awesome Angry Nerds Shirt. We brought 150 Shirts with us and ran out of them after 1 day. Additionally you missed the opportunity to get an unique AtlassianNovemberfest beer glass. These were exclusively produced for W-JAX.

Of course you also missed 2 great talks of Atlassian staff: John Stevenson gave a presentation on Clojure, a new functional programming language that runs on the JVM and I talked about how to clean up old code bases to keep your legacy code alive and kicking. The slides from my talk are available here.

You see, you missed very cool and important stuff. So catch Atlassian on the next big event to talk to us about newest trends in agile development, new features in JIRA or the latest soccer results of Bayern München. You can find a list of conferences we or our partners attending here.

Motivation für Softwareteams VII – Spaß haben und Gutes tun

Dies ist offensichtlich der letzte Teil meiner Blog-Serie über Mitarbeiter-Motivation. Wenn man keinen Spaß mehr an und auf der Arbeit hat, nützen die besten Motivationstipps nichts.

Lachen erwünscht

Wir bei Atlassian strengen uns täglich an, für unsere Kunden die besten Entwicklertools der Welt zu bauen. Manchmal sollte man aber auch mal einen Schritt von der Tastatur zurücktreten und einfach mit Kollegen zusammen Spaß haben. Wir sind ja nicht nur Nerds und können auch feiern (na ja, manche von uns sind wirklich nur Nerds). Durch solche Events wird die Arbeit auch nicht langweilig. Hier einige Beispiele, die die Arbeit bei Atlassian zu etwas besonderen macht:

  • eine Wii steht an jedem Standort den Mitarbeitern zur Verfügung, um sich mal von einem Problem abzulenken
  • die End Of Fiscal Year (Geschäftsjahresabschluss) Parties sind legendär (ein kleines Video davon?)
  • we’re ballin … a lot. Ob Tischtennis, Basketball oder Fußball. Wir spielen Ball, (fast) alle zusammen (auch hier ein kleines Video?)
  • wir lassen keinen Anlass aus, um zu feiern: Halloween, Thanksgiving oder der Melbourne Cup
  • und natürlich Spontan-Treffen und Hackathons in der Küche, da jemand meint, die neuen Google-Dart Features seien Übercool

Tu Gutes

Man fühlt sich so richtig gut, wenn man eine gute Tat vollbracht hat. Warum immer nur für die Gewinnmaximierung der Aktionäre schufften? Man kann doch auch einmal im Jahr die Arbeitskraft für die gute Sache einsetzen. Beispielsweise den Strand aufräumen, die örtliche Tafel unterstützen oder der Behindertenwerkstatt bei einem Ausflug behilflich sein. In Ihrem Unternehmen undenkbar? Schade! Aber hier ist etwas, dass wirklich jeder machen kann: Movember! Lassen sich sich einen Monat lang einen Schnäuzer wachsen und sammeln Sie Spenden zur Bekämpfung von Postatakrebs ein! Atlassian spendet 5 Arbeitstage je Mitarbeiter im Jahr für wohltätige Zwecke. So sind die Mitarbeiter direkt an den wohltätigen Aktionen des Unternehmens beteiligt. Gutes zu tun und für ein Unternehmen zu arbeiten, das dies unterstützt, hebt die Stimmung und Motivation am täglichen Job.

Ein Appell zum Schluss

Ich hatte eigentlich an dieser Stelle vor, einen Appell an die Manager von Softwareteams zu schreiben. Letztendlich können sich aber heutzutage gute Softwareentwickler Unternehmen aussuchen, bei dem Sie arbeiten wollen und mit dem sich der Programmierer identifizieren kann. Unternehmen, die sich nicht um die Motivation ihrer Entwickler kümmern, haben oft ein hohe Fluktuation, oder können ihre Innovationsträger nicht halten. Ein Appell möchte ich lieber an die Entwickler richten: Es ist euer Job, neue Ideen zur Motivationssteigerung durchzusetzen. Fast alle Motivationstipps in meiner Blogserie können auf unterster Managementebene durchgesetzt werden. Geht also zu eurem Teamleiter und sagt, dass ihr nächsten Freitag einen FedEx Tag durchführen wollt, jeden Montag Mittag zu einem Brown Bag trefft und zwischen 13:00 und 16:00 Uhr nicht gestört werden wollt, um in den Flow zu kommen. Am Ende bekommt das Unternehmen motivierte Mitarbeiter und die Entwickler einen motivierenden Arbeitsplatz.

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 6: 20% Zeit

Motivation für Softwareteams VI – 20% Time

Google hat es berühmt gemacht, 3M hat es in den 70ern erfunden und Atlassian macht es seit mehr als 3 Jahren: Die 20% Zeit. Hier bekommt jeder Entwickler bei Atlassian die Möglichkeit einen Tag in der Woche, sich um sein eigenes Projekt zu kümmmern, das man sich selbst aussuchen kann. Das war am Anfang ein großes Risiko, da wir nicht absehen konnten, ob sich so etwas irgendwann mal auszahlt oder ob die Mitarbeiter die Zeit mit Projekten verbringen, die zu nix führen. Wir geben also jährlich $USD 4,000,000 für unsere 20% Zeit aus. Ja richtig! 140 Ingenieure arbeiten an Projekten, von denen wir nicht wissen, ob diese irgendwann mal einen Nutzen für uns haben.

Warum machen wir das?

Wir legen keine Ziele fest, was in der 20% Zeit erreicht werden sollte. Es geht hierbei darum, die Innovation zu steigern. Diese kann man aber nicht messen, bzw. als Ziel festlegen. Wir haben so viele coole Ideen aus unseren FedEx Days bekommen. Es entstehen dadurch aber keine fertigen Produkte, es sind lediglich halbfertige Prototypen, die aus FedEx Days entstehen. Wir haben uns Gedanken gemacht, wie man diese Protoypen in ein Produkt bringen kann, ohne dass Entwickler abgezogen werden. Diese innovativen FedEx Prototypen müssen meistens nicht innerhalb einer bestimmten Zeit auf den Markt gebracht werden. Diese Features oder Produkte sind also predestiniert dafür, als 20% Zeit Projekt weitergeführt und verfeinert zu werden.

20% Zeit Regeln

Ja, ein paar Regeln müssen sein: Ein Projekt sollte nicht zur Tarnung dienen, eine neue Programmiersprache oder Technologie ausprobieren zu wollen. Hier einige Ideen, was bei uns als “gutes” Projekt gilt:

  • Open Source Projekte, die auch Atlassian weiterhelfen
  • Fehler, die einen schon lange nerven
  • Features,die unsere bestehende Software verbessern, ohne das Kunden dies angefragt haben oder die es nicht auf die Roadmap geschafft haben
  • “Proof of Concept” für ein neues Produkt
  • oder einfach endlich mal die Architektur verbessern

Auch kann man gerne als kleines Team an einem Projekt arbeiten. 20% Zeit Projekte dürfen auch fehlschlagen. Es geht bei dieser Zeit darum, etwas innovatives mit Risiko auszuprobieren, da ist es klar, dass die Idee auch mal nicht umzusetzen ist. Allerdings verfolgen wir auch den Fortschritt von 20% Zeit Projekten, um den Erfolg dieser Innovation messen zu können. Ein neues Projekt für diese Zeit zu beantragen , ist so einfach, wie ein Urlaubsantrag ausfüllen (was in manchen Unternehmen vielleicht auch schon gar nicht so einfach ist). Auch andere Bereiche machen bei 20% Zeit Projekten mit: Von Marketing über HR bis zur technischen Dokumentation!

Das Ergebnis

Jeden Monat laden wir zu einem Lunchtalk ein und Mitarbeiter können ihre Monatsergebnisse der eigenen 20% Zeit Projekte vorstellen. Dabei ist dies aber keinen Falls verpflichtend. Jeder kann während dieses Meeting aufstehen und seinen Fortschritt vortragen aber keiner muss. Es gibt allerdings zwei weitere Regeln, damit Kollegen nicht unendlich viel Zeit in ein 20 % Zeit Projekt versenken. Nach 5 Entwicklertagen, müssen 3 Supporter für das Projekt gefunden werden. Dieses können Kollegen aus anderen Projekten sein, die aber einen Wert in der Weiterverfolgung des Projektes sehen. Nach 10 Entwicklertagen müssen Mike & Scott (Atlassian’s Gründer) für das 20% Zeit Projekt unterschreiben.

Unser Erfolg

Statistiken haben ergeben, dass 20% Zeit Projekte 30% effektiver sind als Projekte des normalen Tagesgeschäfts. Wir haben zumindest so viel Erfolg damit, dass wir uns ein Leben ohne die innovative
“Auszeit” nicht mehr vorstellen können. Hier eine Liste von erfolgreichen 20% Zeit Projekten, die es bis in das Produkt geschafft haben:
– Wallboard Gadget für GreenHopper Rapid Board
– Bereichsverzeichnis in Confluence
– Bonfire
– JIRA Mobile Connect
– Atlassian OnDemand
– Netzwerk-Aktivitätsstrom in Confluence 4.1

Der größte Erfolg ist aber, dass Mitarbeiter mehr Spaß haben, da sie Ihre eigenen Ideen umsetzen dürfen. Sie sind motiviert und das auch in ihrer restlichen 80% Zeit! Wie oft wollte ich vor meiner Atlassian Zeit etwas an der Software ändern, hatte aber nie Zeit dazu.
Mehr über 20 Prozent Zeit bei Atlassian, gibt es auch auf unserem Blog.

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 7: Spaß haben und Gutes tun

Motivation für Softwareteams V – FedEx Days

FexEx days wurden bei Atlassian erfunden. Viele unserer Produkte wie Team Calenders, Bonfire oder JIRA Mobile Connect entstammen einem FedEx Day. Wirklich alle profitieren davon: Das Unternehmen bekommt neue Ideen für Produkte geliefert, die Mitarbeiter einen Tag in dem sie ausprobieren können, was sie schon immer machen wollten. Aber fangen wir erst mal mit den Basics an:

Was ist ein FedEx Day?

An Atlassian’s “FedEx Day” nehmen sich Entwickler Zeit, sich mit irgend etwas zu beschäftigen, was (auch entfernt) mit unseren Produkten zu tun hat. Typerscherweise starten wir an einem Donnerstag Mittag, arbeiten bis 15:00 Uhr am Freitag und präsentieren dann das Ergebnis dem gesammten Unternhemen. Dies bedeutet also, dass man 24 Stunden Zeit hat, sein Ergebnis abzuliefern – daher auch der Name FedEx Day.

Die Ziele von FedEx sind:
– Kreativität fördern. Atlassian stellt eine Menge schlauer Köpfe ein. Es wäre dumm, diese nicht zu nutzen
– Jedem Entwickler stört etwas an unserem Produkten oder möchte sehen, dass es was bestimmtes tut
– Oft bekommen radikale Ideen nicht die notwendige Aufmerksamkeit, da viele den Nutzen daran nicht erkennen
– Spaß haben. Darf man ja auch mal auf der Arbeit 😉

Planung ist die halbe Arbeit

FedEx Days werden bei Atlassian gründlich vorbereitet. Auch wenn es sich danach anhört, dass man sich einfach nur eine Lösung überlegt und loscoded, hilft es, das ganze gut vorzubereiten. Im Vorfeld machen sich die Entwickler schon mal Gedanken, wie sie ein Problem lösen wollen, zeichnen MockUps und untersuchen Technologien. Zu jedem FedEx Day wird ein Organisator bestimmt, der 2-3 Meetings bei Pizza und Bier einberuft, um sich über Ideen für Projekte zu einigen.

Den Gewinner feiern

Am Ende jedes FedEx Days werden die Ergebnisse des 24 stündigen Hackathons den anderen Teilnehmener vorgestellt. Dann wird ein Gewinner gekührt, der eine Trophäe und ein T-Shirt erhält und bis zum nächsten FedEx Day mit dem Titel angeben darf. FedEx Days werden bei Atlassian in jeder Nierlassung auf der ganzen Welt abgehlaten. Letztes Jahr sind die Gewinner der letzten 4-5 FedEx Days dann zu einem FedEx Day World Cup angetreten.

Was passiert mit den tollen Ideen?

Einige Ergebnisse von FedEx Days haben es schon in unsere Produkte geschafft. Beipsielsweise die Plattform für unseren OnDemand Service oder die Vergleichsansicht in Fisheye. Natürlich ist es toll, wenn sich ein Projekt aus einem FedEx Day in einem unserer Produkte wiederfindet. Es geht aber vielmehr bei dem Ereignis darum, miteinander Spaß zu haben und seiner Leidenschaft nachzugehen.

Gut für Ihr Unternehmen?

Bei uns funktionieren FedEx Days super. Aber auch wir ändern ständig etwas am Konzept. Wir benutzen dazu eine Seite im unseren internen Confluence Wiki. Nachdem ich mir die Seite mit den Verbesserungsvorschlägen durchgelesen habe, konnte ich feststellen, dass sich die meisten Verbesserungen um die Pizzabestellung drehen – ein wichtiger Bestandteil von FedEx Days.

Andere Unternehmen wie Sonar6, Adobe, Yahoo und Xing haben so etwas wie FedEx Days durchgeführt. Dank Dan Pinks TED Talk sind FedEx Days bekannter geworden. Hier das Video mit Illustrationen dazu.

Mehr über FedEx Days gibt es auf unserer Webseite.

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags

Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun