Über Robert Lippert

Management & Teambuilding for Mayflower GmbH, specialized in Agile Doing. Traveling between Berlin, Frankfurt, Munich and Würzburg. Handshake via Xing or Twitter.

Code und Kanban: Mit Mayflower auf der webinale/IPC 2017

Ende Mai/Anfang Juni lädt wieder einmal die Doppelkonferenz webinale/IPC nach Berlin, um dort zu Diskussionen, Workshops und Networking rund um aktuelle Web-Development-Themen zu laden. Unsere Kollegen Martin Ruprecht (@mrupilo) und Maximilian Berghoff (@ElectricMaxxx) haben hier zur Unterstützung des Programms zwei Sessions erarbeitet, die etwas Praxis aus unseren Kundenprojekten herausarbeiten — und den Teilnehmern entsprechende Best Practices kompakt mit auf den Weg geben. Weiterlesen

Was hat es mit diesen Barcamps auf sich?

Kommenden Monat soll es ja wieder ein Barcamp von uns geben. Für Softwareentwickler. Aber warum organisieren wir das eigentlich? Was haben Softwareentwickler davon? Und was ist für Firmen drin, die ihre Mitarbeiter für so ein Barcamp freistellen müssen? Ein paar Ansichten und Einsichten.

Herausforderungen in komplexen Softwareprojekten

In komplexen, vernetzten Situationen – also Umgebungen, wie sie in der Softwarewelt verstärkt anzutreffen sind – müssen oft genug mehrere Ziele gleichzeitig berücksichtigt werden, die sich auch durchaus widersprechen können. Mit dem eigenen Domänenwissen allein (also der Kompetenz auf dem individuellen Fachgebiet) kommt man hier nicht viel weiter.

Weiterlesen

DevCamp Nürnberg: Das Barcamp für Developer

Die Idee ist eigentlich ganz einfach: Einen guten Themenmix für eine Konferenz bekommst Du am besten, wenn Du die Themenwahl den Teilnehmern freistellst. Und einen hohen fachlichen Nutzwert, indem Du den Teilnehmerkreis auf eine thematisch gut fokussierte Zielgruppe legst.

Für Softwareentwickler organisieren wir im Mai daher gemeinsam mit unseren Partnern wieder ein Developer Camp, dieses Jahr in Nürnberg, nachdem wir 2016 in Würzburg bereits einen sehr guten Start hinlegen konnten. Das Developer Camp ist ein klassisches Barcamp – nur eben speziell für Softwareentwickler. Weiterlesen

Mayflower jetzt auch in Berlin

Bereits Mitte 2016 hatten wir die ersten Vorbereitungen getroffen und seit kurzem verkündet es ein kleines Schild in der Ritterstraße 2a auch offiziell: Mayflower hat – nach München und Würzburg – jetzt einen dritten Standort in Berlin. Dadurch können wir insbesondere unsere norddeutschen Kunden noch besser erreichen, wobei wir, dank der günstigen Verkehrsanbindung, auch weiterhin eng mit unseren weiteren Standorten verzahnt bleiben. Weiterlesen

Das LMU Entrepreneurship Center und Mayflower unterstützen Startups in München

Vor kurzem haben Mayflower und das LMU Entrepreneurship Center (LMU EC) eine Partnerschaft vereinbart, die insbesondere den in München organisierten Startups einen Zugriff auf professionelles IT-Know-how und Entwickler-Ressourcen (agile Teams) ermöglicht und es ihnen erlaubt, gerade in der Wachstumsphase auch softwareseitig mit ihren jeweiligen Business-Prozessen skalieren zu können.

Natalie Kho, Startup Managerin beim LMU EC und Albrecht Günther, Geschäftsführer bei der Mayflower GmbH, beschreiben im Gespräch die Inhalte und Ziele der Kooperation. Weiterlesen

Legacy, Maintenance und agile Abenteuer – IPC München 2016

Nur ein paar Gehminuten von unserem Büro München entfernt (rund 963 Meter), trifft sich die Webentwickler-Community Ende Oktober zur IPC/WebTech Conference, um über aktuelle PHP-, JavaScript-, Web- und allgemeine Themen rund um Softwareentwicklung und -organisation zu diskutieren.

Weiterlesen

Das war die Tools4AgileTeams 2016

Scrum funktioniert nicht! Agile Transition birgt Gefahren! Trotzdem machen wir es und erzählen das auch noch jedem, der daraus lernen möchte.

Die t4at

Auf der vergangenen Tools4AgileTeams hatten wir Gelegenheit, uns als Sponsor und Teilnehmer mit anderen Agilisten zu diesen und weiteren Themen auszutauschen. Der Ansatz der kleinen Konferenz ist vielversprechend — die zwei Tage Programm teilen sich auf in einen ersten halben Tag Open Space, wo der Besucher seine eigenen Schwerpunkte setzen und Themen frei diskutieren kann. Sehr angenehm, um sich gegenseitig kennenzulernen. Das eigentliche Hauptprogramm folgt dann im zweiten Konferenztag, der ganz klassisch ausgewählte Vorträge rund um die agile Zusammenarbeit bereithält. 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.