Video: Innovationen in 24 Stunden liefern

Du hast ein Idee für dein Produkt? Dich nervt die Usability einer Funktion in eurer Software? Du möchtest eine Integration mit einem Cloud-Service bauen? Aber dein Chef oder der Product Qwner gibt dir keine Zeit! Du müsstest ein Prototyp bauen, damit der Kunde den Sinn versteht! Oder die Prioritäten liegen für das nächste Quartal woanders!

Auch die Mitarbeiter haben Ideen, wie man die Software verbessern kann. Warum diese nicht einfach fragen? Warum nicht mal 24 Stunden für ein Spike investieren, um die Machbarkeit von Ideen zu testen? Warum nicht mal “Back to the Roots” und einfach ohne Rücksicht auf Wartbarkeit loshacken. Darum geht es bei Atlassian ShipIt Days. In dem Video erkläre ich, wie bei uns ein solcher 24 Stunden Hackathon abläuft.

Advertisements

Video: Berichtest du noch oder programmierst du schon?

Was wollen Softwareentwickler? Richtig: Software entwickeln. Was nervt Softwareentwickler? Richtig: Excel und Word. Wenn es zu Projektberichten kommt, kommen wir aber leider meist nicht um diese Tools herum. Wir müssen Daten aus den verschiedensten Tools zusammensammeln. Leider bietet jedes Tool ein anderes Exportformat an und manche Daten kann man nur manuell abschreiben. Und dann? Dann müssen wir doch Word oder Excel öffnen und Diagramme für das Management erstellen. Versteht mich nicht falsch: Es ist extrem wichtig zu verstehen, wie unser Team und das Projekt performt. Man kann so viele Dinge aus den Daten ablesen und schnell reagieren, falls was schief läuft. Was können wir also besser machen, damit die Aufgabe nicht eintönig und nervig wird und wir weniger Zeit darauf verwenden, an Berichten zu schreiben? Die Lösung heißt: ROBOTER. Was das bedeutet, erkläre ich im Video:

Video: Teste und kenne deine eigene Software!

Wir Softwareentwickler kennen alle nützlichen Shortcuts und Features von Eclipse, IntelliJ oder welche IDE wir auch immer benutzen. Wir müssen uns schließlich mit unseren Tools auskennen, um effektiv zu arbeiten. Wir haben auch schon mal die ein oder andere Stelle in der IDE gefunden, die uns nervt. Wir waren dann ziemlich froh, als diese in der nächsten Version verbessert wurde. Manchmal habe ich auch schon gedacht: “Wenn ich doch nur den Quellcode hätte, dann würde ich den Bug schnell selbst fixen”. Kurz: Wir sind Toolexperten!

Wie steht es aber mit der Software, die wir entwickeln? Ist es Aufgabe der QA diese zu testen? Wissen wir, was die Benutzer nervt, welche Features sie hassen und welche sie lieben? Verstehen wir unsere Kunden? Und wie lange braucht es, wenn ein Kunden einen Usability Bug findet, bis wir diesen behoben haben und der Kunde ein Update bekommt? Wäre es nicht viel besser, wenn wir den Bug vor der Auslieferung gefunden und gefixt hätten? Klar: Ist ist Zeit für Dogfooding. Schau dir das Video an und finde heraus, warum Dogfooding so wichtig ist!

Video: Lobe deine Kollegen!

Wer hört nicht gerne ein Lob auf der Arbeit? Leider machen wir das viel zu selten! Wir sollten viel öfter zu einem Kollegen gehen und sagen: ” Das hast du echt gut gemacht”. Genau das zeigt demjenigen, der das Lob empfängt, dass Kollegen die Leistungen beachtet und anerkannt haben. Wenn man beispielsweise an einem Feature bis spät abends programmiert hat, damit es noch in das nächste Release kommt, ist es Zeit für Kudos. Oder wenn ein Mitarbeiter sich endlich einmal die Zeit genommen hat, die hygienisch vernachlässigte Küche aufzuräumen, vergeben wir Kudos. Kudos gibt es bei Atlassian für außergewöhnliche Arbeiten. Bei Lösungen, die unsere Erwartungen übertroffen haben oder die uns überrascht haben. Aber was sind Kudos und wie bekommen die anderen Mitarbeiter mit, dass jemand außergewöhnliches geleistet hat? Schaut euch das Video an:

Warum geplante Zeit für Innovation bei IT-Teams besser ankommt

Erst einmal hört es sich merkwürdig an: Zeit für Innovationen sollte doch gerade frei genutzt werden können, was soll man daran denn bitte planen? Inhaltlich stimmt das auch: Die sogenannte 20 Prozent Zeit bedeutet, dass der Arbeitgeber seinen Mitarbeitern Zeit zur Verfügung stellt, die der Mitarbeiter “frei” gestallten kann. Das Wort frei wird von Unternehmen unterschiedlich interpretiert. Manche Arbeitgeber überlassen die inhaltliche Gestaltung völlig den Mitarbeitern, andere machen leichte Vorgaben. Atlassian erlaubt beispielsweise die Nutzung der Zeit unter der Voraussetzung, dass man diese zur Verbesserung unserer Produkten einsetzt. Was das ist, liegt dann aber in der Freiheit des Mitarbeiters.

 Freie 20-Prozent Zeit

Bei Atlassian haben wir mit einer freien 20-Prozent Zeit gestartet: Jeder Mitarbeiter legt selber fest, wann er seine sogenannte Slack-Time nutzt, nämlich dann, wann es ihm am Besten passt. Das gleiche Modell hat beispielsweise auch Google… und scheinbar auch die gleichen Probleme, die wir bei Atlassian beobachten konnten: Mitarbeiter in Entwicklungsteams haben ihre Slack-Time nur zu 50% genutzt… also eher eine 10%-Zeit. Woran liegt das? Wichtige Key-Programmierer bei Google, die an Unternehmens- und Produktschnittstellen arbeiten, nehmen sich meist nicht die Zeit zum Arbeiten an den eigenen Ideen. Bei Atlassian konnten wir beobachten, dass die 20%-Zeit besonders dann nicht genutzt wird, wenn ein größeres Release vor der Tür steht. Die nicht genutzte Zeit holt man dann aber auch meist nicht nach. Auch haben einige Entwickler berichtet, dass sie ihr Team hinsichtlich des Sprintziels nicht im Stich lassen wollen.

 Geplante 20-Prozent Zeit

Mittlerweile sind die Entwicklungsteams bei Atlassian dazu übergegangen, die 20-Prozent Zeit gemeinsam im Team zu planen. Nach 4 Sprints (die jeweils eine Woche bei Atlassian dauern), plant man dann eine sogenannte Innovationswoche ein. Diese Woche kann dann frei von den Teammitgliedern für deren eigenen Projekte genutzt werden. Das bietet den Vorteil, dass es in dieser Woche kein Sprintziel gibt und nicht am Release gearbeitet wird. Man kann sogar ohne Koordinationsprobleme kleine Teams im Team bilden. Bei Atlassian gibt es keine Regel, wann Teams ihre Innovationswochen durchführen, was zur Folge hat, dass nicht alle Teams gleichzeitig ihre 20-Prozent-Zeit nehmen. In dieser Zeit kann also ein Mitarbeiter im JIRA Team nicht an einer Innovation gemeinsam mit einem Mitarbeiter aus dem Confluence Team arbeiten. Dies kam aber auch extrem selten bei uns vor.

 Also alles gut an geplanter Slack Time?

Eigentlich schon, oder? Für Atlassian’s Entwicklungsteams sind Innovationswochen perfekt. Allerdings gibt es auch Teams bei Atlassian, die lose zusammenarbeiten, wie zum Beispiel das Ambassador-Team, in dem ich arbeite. Für uns wäre es ziemlich schwierig eine solche Innovationswoche zu planen, da wir viel auf Events und User Groups unterwegs sind. Für solche Teams ist eine freie 20-Prozent-Zeit sicherlich besser. Es kommt also immer darauf an, wie stark man im Team aufeinander angewiesen ist.

Was ein cooles Event ausmacht

Ich bin im letzten Jahr auf vielen Konferenzen gewesen, das bringt mein Job als Technologie Evangelist so mit sich. Dabei habe ich aber gravierende Unterschiede festgestellt. Es gibt Konferenzen, da geht man nach Hause und denkt: “Das hätte ich mir schenken können”. Und dann gibt es welche, da kommt man gar nicht wieder von los und denkt nur: “Wie cool war das denn?”.

Für mich war der Atlassian Summit dieses Jahr eine der Highlight-Konferenzen (und nicht nur, weil ich für Atlassian arbeite). Die Stimmung habe ich versucht in einem Video einzufangen. Viel Spaß:

Aber was macht denn jetzt wirklich den Unterschied zwischen einer coolen und einer weniger coolen Konferenz aus? Hier meine Top 5:

1. Die Vorträge – weniger ist mehr

Manchmal ist es besser weniger Tracks zu haben, dafür aber ein höhere Qualität. Wenn es mal vorkommt, dass mich von den angebotenen Talks keiner interessiert, ist es vollkommen OK für mich einfach mal Emails zu checken, den Twitter Stream zu verfolgen und mich auf den nächsten Kick Ass Vortrag zu freuen. Ich habe schon zu viele mittelmäßige Vorträge gehört, bei denen ich nach 15 Minuten nicht mehr bei der Sache war. Allerdings gibt es nur wenige Rock Star-Vorträge, die mir noch lange im Gedächtnis geblieben sind. Ach ja, um mal ein Gerücht aus der Welt zu schaffen: Gute Präsentationen haben nicht unbedingt mit der Berühmtheit des Vortragenden zu tun. Es kann ein Indiz sein, muss aber nicht.

2. Der Ort – Zahnärztekongress oder Geek-Festival

An manchen Orten von Konferenzen fühlt es sich an wie auf einem Zahnärztekongress: Staubig, langweilig, verklemmt. Das hängt meiner Meinung nach nicht mit den Teilnehmern zusammen, sondern direkt mit dem Veranstaltungsort. Ich kann auch nicht sagen, dass Kongresszentren grundsätzlich besser sind als Tagungshotels. Allerdings:  Es sind öfter die Tagungshotels, die zwar eine super Küche bieten, manchmal aber auch Vortragsräume mit dem Charme der 70er oder 80e.  Es kommt auch darauf an, dass die Vortragsräume nicht zu weit auseinanderliegen, so dass man Teilnehmer zwischen den Talks wiedertrifft, um eine spannende Unterhaltung fortzusetzen. Ein eindeutiges Negativbeispiel ist die JavaOne! Staubige Hotelräume, verteilt auf 3 Hotels, extrem lange Wege, viele Flure, schlechte Übersicht.

3. Die “Ruhezonen” – abseits des Getümmels

Aussteller sind wichtig, um eine Konferenz auf die Beine zu stellen. So ein Event kostet halt viel Geld und ist ohne Sponsoren nicht durchzuführen. Es ist auch interessant, sich mit dem ein oder anderen Softwarehersteller oder Serviceanbieter direkt zu unterhalten. Allerdings sollte es auch Rückzugsräume geben, an denen man ungestört mit anderen Teilnehmern reden oder kurz mal arbeiten kann, da der Geräuschpegel im Ausstellungsraum meist sehr hoch ist. Ich finde Konferenzen richtig cool, die in Themenbereiche unterteilt sind und wo man sich mit den Experten nach deren Talks dort treffen kann.

4. Abendveranstaltung – Party like it’s 1999

Ich bin zwar immer ziemlich fertig nachdem ich einen ganzen Tag auf einer Konferenz verbracht habe. Allerdings schätze ich es auch, wenn die Organisatoren noch ein Abendprogramm anbieten. Bei einem Bier und einem Snack, kann man sich noch einmal gut über das am Tag gehörte austauschen und Plänen schmieden, wie man die neuen Erkenntnisse in die tägliche Arbeit einfließen lässt. Besonders cool finde ich es, wenn die Organisatoren es schaffen, die Star Sprecher des Tages auf die Abendparty zu bringen. Es lässt sich doch viel ungezwungener bei einem Drink in der Hand fachsimpeln.

5. Die Details

Es kommt auf die Kleinigkeiten an. Hier ein paar Beispiele

  • Ich liebe Badges mit aufgedrucktem Programm
  • Mobile Apps mit Programm und Raumplan gehören zum Glück mittlerweile zum Standard
  • WLAN, dass auch in einer Pause nicht zusammenbricht
  • Wenn man etwas schief läuft: Schnelle Reaktion anstatt zu sagen :”Nächstes Jahr machen wir es besser”
  •  Keynotes ohne oder mit sehr guten interessanten sponsored Talks
  • den ganzen Tag kostenlos Kaffe und Softdrinks
  • und die Kleinigkeiten eben…

Video: Softwareentwickler müssen lernen, lernen, lernen

Als Softwareentwickler müssen wir ständig dazulernen. Wir haben uns halt einen Job ausgesucht, der sich schnell verändert.

Vor 12 Jahren hat man mir beigebracht, dass man erst Pseudocode schreiben soll. Das ist Code, der eigentlich kein Code ist, da er nicht ausgeführt werden kann und lediglich dem Verständnis dient, was der Code macht. Mir wurde also beigebracht, erst Kommentare zu schreiben, bevor man den eigentlichen Code programmiert. Das führt dazu, dass man zur jeden Programmzeile auch einen Kommentar mit Pseudocode hat. Dies war bestimmt wichtig, als man noch hauptsächlich Assembler programmiert hat und nur die Freeks sofort verstanden haben, was der Quellcode eigentlich macht. Heutzutage schreibt man so wenig Kommentare wie möglich. Der Code soll sich durch intelligente Variablenbezeichnung und einfache Programmierweise selbst beschreiben, oder man nutzt eine DSL um den Pseudocode direkt in ausführbaren Code umzuwandeln. Hätte man sich nicht umgeschaut und gesehen was andere Programmierer so machen oder welche Entwicklungen es im Bereich Softwareentwicklung gibt, würde man heute noch denken, dass Pseudocode eine super Idee ist. Zugegeben: Man hätte schon ziemlich ignorant sein müssen.

Nun ist es so, dass man nicht immer Zeit hat, sich die neusten Artikel und Bücher durchzulesen, auf User Group Treffen abzuhängen oder Konferenzen zu besuchen. In dem Video “Feed your Brain” aus meinem Talk “7 Dinge: Wie man gute Teams großartig macht” gebe ich ein paar Tipps, wie man es dennoch schaffen kann, mit Coding Sessions und Brown Bags weiter auf dem Laufenden zu bleiben.

Video: Beste Arbeitsbedingungen für Geeks

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

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

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