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

Sichere Passwörter und gute Authentifizierungsmechanismen

Wir alle nutzen sie: Passwörter. Für unseren E-Mailaccount, Computerspiele, Shoppingseiten, Onlinebanking und Co. Viele Studien kommen regelmäßig auf ähnliche Ergebnisse: Zwischen 50 bis 80 Prozent der Anwender verwenden für verschiede Webseiten das gleiche Passwort. Wieso das ein Problem ist, wie wichtig Passwörter sind und wie man mit wenig Aufwand bereits viel Sicherheit bekommt, beschreibe ich im folgenden Text. 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 :)

Warum wir keine Titel und Positionen mehr haben

Wir kommen aus der PHP-Community und sind inzwischen in der agilen Community und der JavaScript-Community angekommen. Deshalb bekommen wir es mit, wenn gute Leute nach einer neuen Herausforderung, sprich: nach einem Arbeitgeber, der besser in ihr Leben passt als der bisherige, schauen.

Die Nachricht finden wir erst mal immer super, weil wir die Leute kennen und wissen was sie können. Bei den meisten könnte ich aus dem Stand eine halbstündige Eloge über ihre Fähigkeiten und Talente halten.

Und dann kommt die Irritation. Denn sie wollen Teamleiter, C*O, irgendwas mit Personalverantwortung, Head of *, * Lead oder Senior Architect werden. Auf gar keinen Fall einfach nur Developer. Nein, ein Titel muss her, man will ja die eigene Leistungsfähigkeit in der Karriere abgebildet sehen.

Tja, und damit können wir – und viel wichtiger wollen wir – gar nicht dienen. Weder die HR-Abteilung noch die Geschäftsführung kann Leute auf Positionen einstellen oder einen Titel vergeben.
Denn die existieren bei uns nicht mehr.
Weiterlesen

Vom langweiligen Meeting zur Sprint Planning II Werkstatt

„Im zweiten Teil der Sprint-Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprint-Ziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind. […] Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung.” Aus dem Wikipedia-Artikel über Scrum. Weiterlesen

Warum wir lieber feiern als loben

Teams in der Challenge Zone sind motivierter, engagieren sich stärker für das Ziel und bringen eine deutlich höhere Performance. Doch welche Faktoren führen dazu, dass sich ein Team traut, in die Challenge Zone zu gehen? Es ist nicht das Lob des Chefs, sondern die Möglichkeit, eigene Erfolge zu erleben und zu feiern. Weiterlesen

ExtJS Theming: Eine Anwendung, 100 Gesichter

In der Frontendentwicklung ist es nicht unüblich, eine Anwendung in verschiedener Art in Erscheinung treten zu lassen. Ob für die Abgrenzung mehrerer Brands voneinander, den Verkauf einer Software mit spezifischen Designanpassungen für den Käufer (etwa für einen Online-Shop), oder zur Durchführung von A/B-Tests mit unterschiedlich gestylten Frontendkomponenten – es gibt eine Vielzahl von Gelegenheiten, bei denen es Sinn macht, eine Anwendung mit unterschiedlichen Gestaltungen in anderen Gewändern zu zeigen.

Hier möchte man selbstverständlich in den wenigsten Fällen das komplette Frontend neu schreiben. Dabei können bereits kleinere Änderungen, etwa eine Anpassung der verwendeten Farben, das Aussehen der Anwendung grundlegend ändern.

Im Folgenden möchte ich zeigen, wie man durch den Einsatz von Themes die eigene Anwendung mit relativ geringem Aufwand in neuem Glanz präsentieren kann. Weiterlesen