Mayflower unterstützt fränkische Berufsschulen bei der Einbindung von Scrum in den Lehrplan

„Sie wurden mir empfohlen!“

Ich staunte nicht schlecht, als im April diesen Jahres mein Telefon klingelte und sich Herr Zobel von der Klara-Oppenheimer-Schule bei mir meldete. „Sie wurden mir empfohlen!“, sprach Herr Zobel weiter. Ich war immer noch ein wenig verwundert, wie ich einer Schule weiterhelfen konnte. Es stellte sich jedoch heraus, dass ich von einem unserer damaligen Auszubildenden als Scrum Master empfohlen wurde. Herr Zobel organisierte einen Lehrgang für den Fachbereich Informatik/IT: „Scrum als agiles Vorgehensmodell für Programmierer“. Scrum im Lehrplan für berufliche Schulen? Und ich soll die Grundlagen dafür vermitteln? Ich sagte zu. Die Vorstellung, dass neben Wasserfall- und dem V-Modell in den Berufsschulen zukünftig auch Scrum unterrichtet wird, finde ich extrem spannend.

Back to school

Am 17. Dezember 2015 war es dann endlich so weit. Mit 25 Teilnehmern war das Klassenzimmer der Würzburger Klara-Oppenheimer-Schule randvoll. Die Teilnehmer der Fortbildung waren Lehrerinnen und Lehrer beruflicher Schulen aus ganz Franken. In den nächsten zwei Stunden erzählte ich den Teilnehmern über die Grundlagen von Scrum, wie Scrum in Projekten angenommen wird, was die Erfolgsfaktoren und die Ergebnisse von Scrum sind. Dabei durfte ich mich immer wieder den kritischen Fragen der Teilnehmer stellen. Hierbei konnte ich auf meine Praxiserfahrung zurückgreifen, was von den Lehrkräften dankend angenommen wurde.

Scrum im Unterricht

Im Anschluss übernahm Herr Zobel das Rednerpult. Er demonstrierte, wie er Scrum in seinen Unterricht eingebunden hat. Was mich persönlich dabei beeindruckt hat, war seine pädagogische Herangehensweise bei der Scrum-Integration. Ich erkannte, dass hier nicht das Produkt oder die korrekte Integration und Optimierung von Scrum im Vordergrund stand. Sein Schwerpunkt lag auf der Wissensvermittlung: Wie kann man Scrum seinen Schülern näher bringen, ohne sie damit zu überfordern? Wie ergeht es den Schülern damit? Weiterhin stellte Herr Zobel vor, wie sich Scrum in den Lehrplan integrieren lässt.

Scrum und Empathie

Trotzdem blieb bei mir hängen, dass auch außerhalb des schulischen Umfelds der soziale Aspekt bei der Einführung von Scrum in Organisationen gerne mal unterschätzt wird. Wie ergeht es den Mitarbeitern, wenn das nächste Projekt mit dem bisher unbekannten Scrum Rahmenwerk umgesetzt wird? Eine Frage, die sich jeder Scrum Master stellen sollte.

Danke nochmals an OStR Michael Kühnert und StR Christoph Zobel für die tolle Organisation und das Schaffen neuer Blickwinkel.

Warum man in der Launchphase nicht auf das Daily Scrum verzichten sollte

Auch bei uns läuft nicht alles rund und so passiert es hin und wieder mal, dass trotz aller Erfahrung, Erklärungen und Bemühungen in unseren Projekten komische Dinge passieren, mit denen man irgendwie nicht gerechnet hat. So vermeldete eines Tages das Projektmanagement einer unserer Kunden während der heißen Launchphase, aus Zeitgründen auf das Daily Scrum verzichten zu wollen. Schließlich stimmen sich alle Projektbeteiligten auch so untereinander ab. Die Zeit, die für das Daily Scrum aufgewendet wird, könne man besser in den Launch investieren. Die Entscheidung steht fest und ist indiskutabel. Das ist der Moment, in dem sich in einem Scrum Master alles zusammen zieht und er tief Luft holen muss: Der Kunde ist König.
Weiterlesen

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

Wie für verteilte Teams Scrum-Meetings angepasst werden können

Auf den diesjährigen agilen Meetups, die ich besucht habe, bin ich regelmäßig über die Worthülse „Remote-Teams“ gestolpert. Remote-Teams sind Entwickler-Teams, die nicht gemeinsam im selben Büro arbeiten, sondern verteilt – nicht selten weltweit. Oft wurde gefragt, wer damit schon Erfahrungen gemacht hat. Im Gespräch hat sich ebenso oft herausgestellt, dass die Erfahrungen, die da draußen in der weiten agilen Welt gemacht werden, nicht immer positiv sind. Speziell, wenn ein Remote-Team auf Scrum trifft, scheint das hin und wieder für Unmut zu sorgen. Denn Scrum an sich ist nicht für verteilte Teams ausgelegt.

Auch wir bei Mayflower werden in unseren Projekten immer wieder vor die Herausforderung gestellt, mit externen Entwicklern auf Kundenseite und unseren eigenen Entwicklern ein großes, verteiltes Scrum-Team zu bilden. In unserem Team haben wir bei solchen Team-Zusammensetzungen in verschiedenen Projekten festgestellt, dass die Scrum-Meetings für eine gut funktionierende Remote-Arbeit unbedingt angepasst werden sollten.
Weiterlesen

Teamkalender 2016

Der Teamkalender 2016 ist frisch von der Druckerpresse bei uns eingetroffen und kann nun an euch versendet werden.

Früher war er mal nur zur Organisation agiler Softwareentwicklungsteams gedacht und ist mittlerweile dank eurer Verbesserungsvorschläge auch für andere Bereiche sinnvoll nutzbar geworden. So kann der Teamkalender beispielsweise durch zusätzliche Teammitgliederzeilen auch für die Schichtenplanung bei größeren Mitarbeiterzahlen genutzt werden.

Für kleine Projektteams bleiben alle gewöhnten Vorteile natürlich vorhanden. So sind etwa die Urlaubszeiten einzelner Teammitglieder immer im Blick, wichtige Deadlines gut planbar und der Kunde hat die Möglichkeit selbst zu sehen, wie sein Team gerade aufgestellt ist. Die übrigen Zeilen eigenen sich wunderbar für Anmerkungen und Notizen.

Der Kalender kommt wie immer kostenfrei zu euch und ist ab sofort bei uns auf Lager, wir hoffen auch im Jahr 2016 wieder auf ein positives Feedback von euch.

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

NoEstimates – Kunden ohne Schätzungen glücklich machen

NoEstimates?

Immer häufiger liest man von einer neuen Bewegung, die allerdings nirgends so richtig erklärt wird. Das liegt augenscheinlich daran, dass es eine emergente Strömung ohne formale Organisation ist. Der wohl präsenteste Verfechter von NoEstimates ist Woody Zuill. In seinem Blog und seinen Vorträgen vertritt er radikal die Ansicht, dass keine Zeitschätzungen von Entwicklerteams gemacht werden sollten. Allerdings wirkt seine extreme Position in Verbindung mit den selbstgemalten Einhörnern auf seinen Slides und dem Leitsatz „I like to imagine wonderful“ etwas weltfremd. Aus der Sicht eines Dienstleisters wirken die Vorschläge eher praxisfern, fehlendes Kundenvertrauen einfach durch Finden besserer Kunden zu lösen. Eine weitere Prämisse ist, dass ein Team in der Lage sein sollte, so schnell Wert für den Kunden zu liefern, dass dieser nicht mehr den Drang verspürt, nach Schätzungen zu fragen. Woodys finnischer Sparringspartner Vasco Duarte vertritt in seinem Buch realitätsnähere Ansichten und gibt praktische Ansätze, wie die negativen Aspekte des Schätzens reduziert werden können.

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