Willkommen zur webinale/IPC 2016 in Berlin

Frontend- und Backend-Development, moderne Architekturen und ein praktischer Erfahrungsaustausch zu agilen Modellen mit Softwareentwicklern und IT-Entscheidern – die Doppelkonferenz aus webinale und International PHP Conference verspricht auch in diesem Jahr wieder ein abwechslungsreiches Programm. Aus unserem Kollegenkreis können wir Anfang Juni zwei Talks beisteuern – Max spricht über die Bedeutung guter Schnittstellen in Content-Management-Systemen (Mit dem API ins CMS) und Albrecht steht gemeinsam mit Judith Andresen zu Fuck-ups in der agilen Transition Rede und Antwort. Weiterlesen

Mayflower Girls‘ Day 2016

Der Girls‘ Day 2016 bei Mayflower

Neun interessierten Mädchen durfte Mayflower mit dem Girls‘ Day 2016 dieses Jahr und damit zum fünften Mal in Folge, einen Einblick in einen technischen Beruf geben. In den vergangen Jahren wurde oft der Wunsch geäußert, mal die ganze Strecke vom Browser bis zum Server zu machen, um das Zusammenspiel der Enden besser zu verstehen.

Das wollten wir mit einer einfachen Shopping Liste und einem Server zum Anfassen auf einem Raspberry Pi nachstellen. Ein Nodejs + Express Backend lieferte über eine REST-Schnittstelle die Daten für ein Angular Frontend. Es galt, eine Shopping Liste zum Laufen zu bekommen, mögliche Verbesserungen in Design und Funktionaliät zu besprechen und einfach umzusetzen. So sollte man den Zyklus von Entwicklung, Deployment (hier nur ein git pull auf dem Raspberry) und einem erneuten Aufruf im Client beispielhaft zeigen. Ein Raspberry Pi war bereits lauffähig und lieferte die Shopping List aus, ein zweiter sollte im Laufe des Tages fertig gestellt werden und als quasi Staging-Server zum Testen der Änderungen dienen. Weiterlesen

Slacktime: Anti-Pattern App

Slacktime. Im Rahmen dieses Konzepts sind wir bei Mayflower alle zwei Wochen für einen Tag von unseren Projekten freigestellt. Zeit, die wir dafür nutzen, uns (uns selbst, uns als Team, uns als Firma) mit Experimenten, eigenen Projekten oder der Vorbereitung auf Workshops und Konferenzvorträge weiterzuentwickeln. Intern nennen wir den Tag bei uns Mayday, aber wichtig ist eigentlich nur, dass wir die Freiheit haben — nun, uns die Freiheit zu nehmen.

Mein aktuelles Projekt ist eine kleine App für den Umgang mit Agile Anti-Patterns. Die haben meine Scrum-Master-Kollegen über die Zeit hinweg im internen Wiki gesammelt; Anfang Februar habe ich die Anti-Patterns testweise als Kartenstapel drucken lassen (übrigens auch im Rahmen eines Slacktime-Projekts — ich selbst finde unsere Slacktime wunderbar, um für mein Bauchgefühl „solche Karten dürften super in Kundenteams ankommen, die gerade neu in agile Prozesse hineinkommen möchten“ über Experimente zu belastbaren Erfahrungswerten zu kommen).

Nun gut, agile Anti-Patterns im Wiki, Spielkarten für Kundenteams und zuletzt positives Feedback („Die reißen die uns aus den Händen, kann ich noch welche mitnehmen?“) — was kann ich noch aus den Anti-Patterns machen? Eigentlich wollte ich ja immer schonmal eine App entwickeln …

MAPA — Die Mayflower Anti-Pattern App

Leider (oder vielleicht zum Glück, kommt ganz darauf an, wen Ihr fragt) bin ich kein Softwareentwickler. Was kann jemand wie ich also tun, um zu einer App zu kommen?

Zum Glück muss ich ja nicht alles allein stemmen und zum Glück ist die Slacktime auch dazu da, Ideen im Team/in der Firma zu pitchen.

MAPA - Main Screen

Ich habe zunächst mit etwas Doku angefangen, um ein Bild der Idee zu bekommen, das ich später mit meinen Kollegen diskutieren konnte. Für mich selbst habe ich mir meinen Elevator Pitch notiert und anschließen einen kleinen Klick-Dummy gebastelt. Der wirft noch ein paar Bedienkonzepte durcheinander (mir lag zunächst Windows Phone als Zielplattform am Herzen, die Kollegen wollten aber lieber iOS und aktuell vielleicht doch besser Android, aber das ist eine andere Geschichte …). Immerhin — ich kann zeigen, welche Funktionen ich wie in welcher Bildsprache verpackt haben möchte und ich sehe, ob sich die Theorie auch als App noch so anfühlt, wie gedacht. Eine erste wichtige Grundlage für die weitere Planung. Und eine Gelegenheit, sich schon vor Beginn der Entwicklung Feedback aus dem Kollegenkreis zu holen. Das Open Device Lab nutzen wir dann später für den Feinschliff …

Elevator Pitch für Scrum Master

Die nächste Scrum-Aktivität (Meeting) steht vor der Tür. Klar, wie Scrum geht, weißt Du. Aber wie schnell führt eine vermeintlich gute Absicht als Anti-Pattern langfristig zu unangenehmen Konsequenzen? Mit MAPA, der Mayflower Anti-Pattern App, kannst Du Dir gezielt typische Anti-Pattern aus Grooming/Refinement, Planning, Daily, oder auch der Retrospektive analysieren – und Dich so optimal auf das nächste Meeting vorbereiten.

Als besonderes Highlight trackt MAPA jedes von Dir bemerkte Anti-Pattern mit. Über die Zeit erkennst Du so, über welche Aktivität Du mit Deinem Team noch einmal sprechen solltest. Und kannst so Euer Scrum-Know-how nach und nach perfektionieren.

Elevator Pitch für das Team

Siehe den Pitch für den Scrum Master. Nur eben, dass die App Euch hilft, Fettnäpfchen auch dann zu vermeiden, wenn der Scrum Master einmal verhindert ist.

So geht es jetzt weiter

Inzwischen haben sich die ersten drei Kollegen gefunden, die die App softwareseitig weiter unterstützen möchten. Windows Phone ist mangels Begeisterung (leider) erst einmal vom Tisch, wir konzentrieren uns aktuell auf Android; später vielleicht eine Version für iOS. Das ist aber gar nicht schlimm, im echten Leben wär es sicher nicht anders — Du entwickelst halt für die Plattform, die Deine Anwender bevorzugen.

Für mich selbst steht dabei zwar MAPA im Vordergrund, meine Kollegen schätzen das Slacktime-Projekt, weil sie sich näher mit Android und iOS auseinandersetzen können. Selbst, wenn die App an sich nur sehr einfache Konzepte verlangt — das Setup für mobile Apps so zu perfektionieren, dass es für künftige Projekte wiederverwertbar ist oder vielleicht zu den Continuous-Deployment-Prozessen unserer Kundenprojekte kompatibel ist, dürfte ein wichtiges Learning sein. Das in einer Slacktime mit abzufrühstücken, ist doch nett. Ich bin jedenfalls schon sehr gespannt, wie sich die App am Ende anfühlen wird.

Das neue AngularJS-Poster

Ein neues AngularJS-Poster? Jetzt noch, wo doch ein neues AngularJS 2.0 vor der Tür steht? Ja, das ist sinnvoll. Nicht nur, weil es bis zur Umstellung noch ein wenig hin ist (geschweige denn, ob und wenn AngularJS 2 denn den neuen Standard stellt) sondern auch, weil ein Überblick zu gängigen AngularJS-Konventionen hilft, lesbaren und strukturierten Code zu schreiben. Was letztlich dazu beitragen wird, auch im Nachgang noch zusätzliche Features in bestehende AngularJS-Applikationen zu ergänzen oder Module aus anderen Projekten wiederzuverwenden Und ja, am Ende wird das auch helfen, strukturiert auf AngularJS 2 zu migrieren. Weiterlesen

Können wir DevOps noch reparieren?

»Wer DevOps nur auf die Tools reduziert, vermeidet es, sich mit der eigenen Kultur auseinanderzusetzen. Und läuft so Gefahr, am eigentlichen Ziel vorbeizuschießen.«

Anmerkung: dieser Text fasst im Grunde genommen nur das zusammen, was wir in unserer täglichen Arbeit erleben. Im konkreten Fall haben wir diese Zusammenhänge bei zweien unserer Kundenteams beobachten können – Kudos daher an die Teams für ihre Insights.

Warnung: Dies hier ist nur eine erste Zusammenfassung eines in weiten Teilen sehr komplexen Themas. Gerade was das Mindset und die gelebte Kultur hinter dem Begriff DevOps angeht, ist es nicht damit getan, einzelne Punkte als Checkliste herauszuziehen. Trotzdem (oder vielleicht auch gerade daher) liefert der Text aber vielleicht erste Impulse, sich mit neuen Aspekten auseinanderzusetzen. En Détail möchte ich für den größeren Zusammenhang gerne Johanns Keynote „DevOps jenseits der Tools“ weiterempfehlen:

DevOps und die Ziele dahinter

Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasi-Standard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen. Wie breche ich Silos jenseits von Development & Operations auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Woran scheitert es in meinem Unternehmen?

Hinter DevOps steht im Grunde das CAMS-Prinzip: Culture, Automation, Measurement und Sharing. Mit den Zielen, Features deutlich schneller von der Idee zum Kunden zu bekommen, die Verfügbarkeit und Qualität hoch zu halten und dabei den Aufwand und die Zeit für ein Deployment gegen 0 gehen zu lassen. Gleichzeitig sollen die zur Verfügung stehenden Hardware-Ressourcen optimal genutzt werden und Performance- und User-Feedback sehr schnell an Ops, Dev und Product-Development weitergereicht werden.

Nun ist in der Praxis oft genug jedoch nur noch der Punkt Automation spürbar. Schaut man sich die Ursachen dann im Detail an, stellt man eben fest, dass es neben den Tool eben auch noch weiterer Dinge im DevOps-Kontext bedarf. Das Aufbrechen von Silos über viel mehr Kooperation und rollenüberschreitende Teamkultur mit hohem Qualitätsfokus. Autonome Teams. Eine „shared Responsibility“. Vertrauen und Respekt. Und oft genug sind hierzu die grundlegenden Weichen in den Unternehmen noch nicht gestellt, zum Beispiel, wenn die funktionale Struktur lokale KPIs über gemeinsame Ziele stellt, oder eine Hero-Culture die persönlichen Ziele noch vor den Unternehmenszielen würdigt.

Also: Unternehmen brauchen, was DevOps verspricht, und es ist deshalb massiv erfolgreich – ja, insbesondere wegen der Tools. Kultur und Organisation verhindern jedoch noch oft das Erreichen der Ziele und erzeugen so lustige Dysfunktionen. Die kann man reparieren, indem man die Struktur anpasst und an der Kultur arbeitet. Das macht man auf einen von drei Wegen, die tatsächlich helfen, dieses magische Dreieck zu brechen.

Und wie soll man das jetzt reparieren?

Erster Weg zu DevOps: Systems Thinking

  • ein gemeinsames Verständnis des Systems erzeugen
  • Flow von Feature-Idee zu Development zu Produktion zu Kunde und zurück zu Dev abbilden, z.B. über Value Stream Mapping

Zweiter Weg zu DevOps: Feedback Loops einführen

  • „Measure all the things“
  • Feedback über alle Schritte
  • Gemeinsame Anpassungen und Korrekturen

Dritter Weg zu DevOps: Learning Culture

  • Kontinuierliches Experimentieren
  • Risiken eingehen
  • Aus Fehlern lernen
  • Wiederholung und Übung wird zu Meisterschaft
  • Infrastruktur: Learning Cycles & Communities of Practice

Das Resultat: die Gesamtperformance erhöht sich, bei gleichzeitig wachsender Qualität und mehr wertvollen Features. Am Ende stehen mehr Verlässlichkeit und mehr Features bei gleicher Arbeit.

Dieser Artikel ist einer von vielen, die wir regelmäßig in unserem Wiki mit unseren Kolleginnen und Kollegen austauschen. Er beruht in weiten Teilen auf Johanns Notizen, lediglich noch einmal zusammengefasst. Offene Kommunikation ist Teil unserer Kultur und sie hilft uns gut zu sein, in dem was wir tun.

Engelsystem extended

Am Dienstag hat es nun endlich einmal geklappt, mehrere Gruppen, die sich das sogenannte Engelsystem vom Chaos-Computer-Club für die Organisation von Helfer-Schichten verwenden, fanden sich in einem Hangout zusammen. Ziel war es sich in Code und Organisation abzusprechen um beispielsweise Redundanzen zu vermeiden.

An dem Gespräch nahmen Vetreter aus Rostock, Hamburg und München teil. Jeder betreibt derzeit seinen eignen Fork vom Originalsystem, wobei Hamburg und München sich noch am nähsten sind. Wie ist der Stand in den Städten? Weiterlesen

Level — Yourself — Up

Seit Jahren bin ich begeisterter Anhänger von Rollenspielen. Was mich dabei am meisten motiviert ist das Sammeln von immer besseren Gegenständen, sowie natürlich auch das Sammeln von Erfahrungspunkten und die dadurch verbundenen Level-Ups. Nun liegt es leider in der Natur der Sache, dass einen Online-Rollenspiele, bis auf den Spaßfaktor natürlich, im realen Leben nicht wirklich weiterbringen. Weiterlesen

Wevent #21: Führung & Organisation in einer modernen Arbeitswelt

Was müssen Führung und Organisation leisten, damit Menschen sich in unserer neuen Arbeitswelt nicht mehr wie unbedeutende Pflichterfüller fühlen, sondern mehr Spaß durch echte Arbeit haben und damit ihre Unternehmen zu mehr Erfolg führen?

 

Dieser Frage gingen Mitte September um die knapp 100 Teilnehmer des 21. Wevents in München nach. Organisiert von Intrinsify.me und intrinsisch motivierter Unterstützung von Mayflower nahmen wir das Motto zum Anlass, uns gemeinsam allen möglichen Fragestellungen aus dem Dunstkreis von #NewWork, #Stoos, #Agile, #Augenhöhe und anderen zu stellen. Weiterlesen

Work & Travel – Remote arbeiten & bezahlter Urlaub

Auf der Rückfahrt vom Mayflower Barcamp nach München hatten einige Kollegen und ich die Idee, für eine Woche, abseits vom Alltag am Kundenprojekt zu arbeiten und nebenbei Urlaub zu machen. Das Ziel war dabei schon klar: möglichst in Richtung Strand, wo es warm ist, abends was los ist und man in einer entspannten Atmosphäre fokusiert arbeiten kann.

Der Trip sollte aus eigener Tasche bezahlt werden, damit es möglichst wenig Abhängigkeiten gibt. Die Kommunikation und Koordination mit unseren Teams und unseren Kunden wollten wir selbst erledigen. Damit unser Vorhaben nicht ins Wasser fällt, haben wir uns dazu entschlossen, das Ganze zeitnah umzusetzen. Die Planung wurde ausformuliert, ein passender Zielort recherchiert und ein gemeinsamer Termin definiert. Anschließend haben wir den Kostenplan aufgestellt und uns auch schon mit dem Hotel in Verbindung gesetzt. Parallel dazu haben wir begonnen, die Idee und die von uns davon erhofften Vorteile dem Kunden vorzustellen. Die Resonanz dafür war durchwegs positiv. Einer fand die Idee sogar so gut, dass er direkt einen seiner Entwickler mit uns auf die Reise geschickt hat.

Nachdem wir unseren Plan soweit vorbereitet hatten, involvierten wir die Geschäftsführer der Mayflower und stellten unsere Idee vor. Unter der Prämisse, alles selbst zu bezahlen und nur die offizielle Genehmigung zu erhalten, hatten wir nicht damit gerechnet, dass Mayflower unser Vorhaben prüft und passable Finanzierungsoptionen definiert. Warum? – Damit auch andere Kollegen mit ihren Teams solche Reisen unternehmen können. Da durch die Mitreise eines Kunden zusätzlich positive Faktoren entstehen, wie Kunden- und Teambindung, welche Mayflower unterstützen möchte, haben wir einen Zuschuss von einem Drittel der Reisekosten bekommen.

Es war klar das wir nicht planlos auf Reise gehen werden. Darum haben wir im Vorfeld passende Aufgabenpakete definiert. So wurden z.B. Refactoring-Tasks, die schnell und fokussiert durchgezogen werden sollten, gewählt. Auch die prototypische Implementierung einer REST-Api auf Basis von Spring REST und Cassandra Data stand an. Ideale Themen also für den Strand :)

Der eine oder andere mag jetzt an ein typisches Offsite Event denken, in dem ein Team sich gesammelt zurückzieht um weg vom Alltag gezielt an Spikes oder anderen offenen Aufgaben zu arbeiten. Unser Work & Travel war im Gegensatz dazu eine bunte Mischung. 4 Leute aus 4 verschiedenen Teams, Technologiebereiche von JS, PHP, Java bis hin zur Datenbank Cassandra sollten es nicht langweilig werden lassen. Über die Durchführung und unsere Erfahrungen mit dem Work & Travel möchten wir im Laufe der nächsten Woche einen weiteren Artikel veröffentlichen. Dort werdet ihr auch erfahren wohin es bei dem Trip ging :)

Neuzugänge im ODL Würzburg

Gestern sind TATSÄCHLICH die ersten postalischen Device-Spenden bei uns im Würzburger Office für das ODL (Open Device Lab) angekommen! Danke, danke, danke, Martin Günther!!

Kollege: „Katrin, hier liegt ein Päckchen für Dich.“
Katrin: „Aber ich habe doch gar nichts bestellt…?!“

*⇒ flitz*

Katrin: „Oooooh!!! Ich glaube, das sind bestimmt die angekündigten Device-Spenden!!!!!!!!“

Ich erspare uns jetzt die Beschreibung des kleinen Freudentanzes und wie ich jedem Kollegen das Päckchen unter die Nase gehalten habe. ;)

Beim Auspacken kamen dann neben einem kleinen, handgeschriebenem Brief das erste Google Phone (!!) — ein HTC Dream — und ein Blackberry (hier bin ich nicht so firm, was die Modellbezeichnungen angeht) zum Vorschein. Beide Modelle gibt es bisher noch nicht im Würzburger ODL — ein Blackberry-Modell sogar noch gar nicht — und wir werden sie mit Freude spätestens am nächsten MayDay aufnehmen und damit der Allgemeinheit zur Verfügung stellen. (Und ein Raffaelo lag auch noch mit im Umschlag <3 …)

Damit können wir ein gutes halbes Jahr nach der Eröffnung bereits mit 21 Devices aufwarten, die aus Device Donations, privaten Mitarbeiter-Spenden und Mayflower-Mitteln kommen. Wow!

Vielen, vielen Dank noch einmal, Martin Günther/@madin!!! Das sind die Momente, in denen das Betreiben eines ODL besonders viel Spaß macht!