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

Agile Bodensee 2016 | Agile Verträge Do’s and Don’ts

Björn Schotte wird am 29. September auf der Agile Bodensee sprechen.

Mehr als 3 Jahre sind ins Land gezogen, seit er seinen Vortrag zu Agilen Verträgen publik machte. In Agile Verträge: Do’s and Don’ts auf der Agile Bodensee wird er eine provokante These vertreten: die stärkste Vertragsform für Agile Projekte ist und bleibt Time & Material.

Aus seiner Sicht sind Einkäufer und Rechtsanwälte doch nur Angsthasen. Die Sorge nicht zu wissen, welches Feature man denn nun für seine Investition bekommt, ist allgegenwärtig.

Er erinnert an die Grundlagen dessen, weswegen man ein Projektvorhaben „agil“ durchführen möchte.

Im Verlauf des Vortrags möchte er alle Parteien – Entwickler-Team/Operative, Einkauf, Rechtsabteilung – miteinander versöhnen. Und Ideen aufzeigen, welche praktikablen Vertragsformen es geben könnte. Um das Bewusstsein zu schärfen, welches Potenzial brach liegt, wenn der Fokus zu sehr auf dem Vertraglichen liegt.

Wie immer gibt es vor und nach dem Vortrag zahlreiche Gelegenheiten, miteinander ins Gespräch zu kommen und neue Ideen auszutauschen. Schließlich wollen wir Alle doch nur Eins: Das Beste für das Projekt!

Wir sehen uns!

Berlin Ops Summit 2016 | Gute Organisations-Aufstellung in Zeiten digitaler Transformation

Björn Schotte wird am 8. September auf dem Berlin Ops Summit in Berlin sprechen.

Der Vortrag „Gute Organisations-Aufstellung in Zeiten digitaler Transformation“ wird das Buzzword „digitale Transformation“ im Kontext von Organisations-Strukturen näher beleuchten.

Organisationen, die vor dem Aufkommen des Internets bereits existierten, haben es häufig schwer, der neuen Konkurrenz Paroli zu bieten. Insbesondere sogenannten „Online Pure Playern“.

„Klar, wie müssen jetzt agil sein. Alles muss schneller werden. Die Büroräume so hip wie im Digital Valley.“, ist die häufige Antwort der Konzernlenker. Doch wir brauchen gar nicht weit in die Ferne schweifen.

Die gewachsene Struktur der Organisation ist dem zukünftigen Erfolg im Weg. Das Immunsystem wehrt sich.

Björn meint: das muss nicht sein. Wenn die Organisation erst einmal begreift, dass IT nicht mehr nur Unterstützung ist, sondern ein Kern-Anliegen. Und Abteilungen im Sinne des Produkts zusammen arbeiten. Mit IT-Crews, die einen „fit for purpose“ haben.

Der Weg wird steinig sein. Und schmerzhaft. Die Medizin gibt es am 8. September im Vortrag. Und wenn du magst, in ausführlichen Gesprächen auf der Abend-Party. Wer schon einmal das Gespräch suchen möchte, meldet sich am besten per E-Mail.

Wir sehen uns!

 

Die schönsten Fettnäpfchen aus 10 Jahren agiler Transition

Die agile Transition war bei Mayflower begleitet von einigen Irrtümern und Fehleinschätzungen. Das begann schon damit, dass wir 2006 davon ausgingen, die Implementierung von Scrum würde drei Monate dauern und der Übergang wäre geschafft. Heute stellen wir fest, dass wir gut unterwegs sind zum Wandel in eine echt agile Organisation.

Das ist nur einer von vielen Lessons Learned aus zehn Jahren Transition. Im Interview blickt Albrecht auf die schönsten Fettnäpfchen aus 10 Jahren agiler Transition zurück. Weiterlesen

Fight your Project – Transfer von Kampfsport und agilem Projektmanagement (Theorie)

Projektmanagement und Kampfsport — zwei doch recht unterschiedliche Begriffe, die sich auf den ersten Blick nicht verheiraten lassen. Ersteres bezeichnet einen Pool von Anwendungsmethoden, der in Zusammenwirkung die Initiierung, Planung, Steuerung und den Abschluss von einem oder mehreren Projekten innehat. Im Kampfsport hingegen steht ein Leistungsvergleich innerhalb des Kampfringes im Vordergrund und die Vorgabe, sich außerhalb des Rings in Zurückhaltung und Selbstbeherrschung zu üben. Was beide Termini jedoch eint ist, dass man sich — um Erfolg zu haben — eine hohe sensitive Wahrnehmung im Bereich der zwischenmenschlichen Aktionsebene und des eigenen Bewusstseins erarbeiten muss. Weiterlesen

Stacey, Cynefin, oder warum zelebriert Mayflower Agil

In der Zusammenarbeit erleben wir als Dienstleister immer wieder mal, dass der Kunde zwar unsere erfolgreiche Arbeit schätzt, unser Drängen auf agile Methoden aber als exzentrische Marotte betrachtet. Irgendwie kommt man dann natürlich auch ins Grübeln, wie man am besten erklärt, dass nicht der Auftraggeber hier dem Externen einen Gefallen tut, sondern der Experte bereits an dieser Stelle auf das Kundenproblem eingeht.

Was steckt also hinter der Strategie, statt große Gewerke mit Pflichten- und Lastenheft zu vereinbaren, lieber darauf zu setzen, dass der Kunde jederzeit seine Meinung komplett ändern darf?

Weiterlesen

Wie begründe ich eine Gehaltserhöhung? Die Gehalts-Kata

Eine Gehaltserhöhung zu begründen, ist für beide Seiten – Arbeitgeber wie Arbeitnehmer – oftmals eine schwierige Sache. Noch schwieriger wird es, wenn Du Dich im Bereich wissensbasierter Arbeit in Umgebungen mit mehr oder weniger hoher Marktdynamik und Überraschungen in Deinem Umfeld befindest. Dein Vorgesetzter wird irgendetwas zwischen Schwarzer Magie, Teil-Gesprächen mit Kollegen, Eindrücken, Ergebnis-Resultaten zur Bewertung nehmen und mit Dir in das Gehaltsgespräch reingehen.

Weiterlesen

Von SugarCRM zu Jira und Confluence

Viele brauchen CRM-Systeme, aber nahezu alle hassen sie. Gründe gibt es dafür viele: Datengrab. Mühsame User eXperience mit der Folge, dass Daten kaum gepflegt werden. Wenig Kollaboration. Und so weiter, und so weiter. Betrachtet man sich die Entwicklungen bei den CRM-Systemen in den vergangenen ein bis zwei Jahren, so stellt man fest, dass Salesforce in einem weltweiten Launch unter Begeisterungsstürmen unter anderem verschiebbare Kärtchen für Opportunities feiert. Da schauen wir ITler allerdings nur mit einem müden Lächeln drauf, denn Kanban Boards kennen wir aus Tools wie JIRA zu Genüge. Systeme wie SugarCRM feierten das Ankommen der Version 7 damit, dass man nun auch @-Notifications hatte, um andere User im System auf zum Beispiel Leads aufmerksam zu machen. Activity Streams sollten aufzeigen, was gerade im System oder bei einem Lead passiert.

Ihr ahnt es: wir Jira/Ticketing Nutzer kennen diese Funktionen schon seit längerem und haben sie zu schätzen gelernt. Wir machten uns also auf eine Reise zu prüfen, ob wir nicht ein anderes Tooling nutzen sollten, um zu mehr Nutzeraktivität und Wertschöpfung für uns zu kommen …

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.

Autonomes Segeln: Pionierarbeit auf der Mayflower

Der Name Mayflower ist geschichtsträchtig. Wir tragen ihn mit Stolz in unserem Firmennamen und dem stilisierten Segel im „a“ des Logos. Pionierarbeit, das zeichnet uns aus, wenn wir Kunden helfen, den weiten Ozean des Internets zu überqueren. Stichwort digitale Transformation.

Umso mehr freut es uns, dass nach beinahe 400 Jahren der Name Mayflower erneut Pate für ein ehrzeiziges Ziel steht: dem autonomen Überqueren des Atlantiks mit einem sogenannten Trimaran. golem.de schreibt:

Es soll auf dem Kurs der historischen Mayflower selbstständig nach Neuengland segeln.

 

2020 soll es dann soweit sein. Wer nicht so lange warten will, dockt bei uns an. Wir kümmern uns um Ihr IT-Projekt.

Den ganzen Beitrag zum Roboterschiff Mars (Mayflower Autonomous Research Ship) finden Sie auf http://www.golem.de/news/mars-autonom-auf-dem-kurs-der-mayflower-1508-115820.html

„Eine Atlantiküberquerung könnte bei optimalen Windbedingungen sieben bis zehn Tage dauern“

 

Zehn Arbeitstage, so lange dauert bei uns ein Sprint. Sprinten Sie mit?

Immer eine Handbreit Wasser unterm Kiel!