Guten Tag {Vorname},

auf dem Bild oben siehst du einen Ausblick dessen, was wir aus unserem zukünftigen Büro sehen werden (aus dem Fenster des neuen Schulungsraums). it-agile zieht um, allerdings erst zu Anfang Juli. Das Wasser ist schon noch Elbwasser, zu sehen ist der Zollkanal am Rand der Speicherstadt. Weitere Infos folgen in den nächsten Wochen.
Erst konnten wir uns nur schwer mit der Tatsache abfinden, dass wir umziehen müssen, aber mittlerweile überwiegt der Blick auf die Vorteile und die Vorfreude aufs Neue. Wir werden mehr Platz haben, einen weiteren großen Schulungsraum einrichten, einen stillen Arbeitsbereich und sind näher am Hamburger Hauptbahnhof. 
Wie geht es dir mit solchen Veränderungen?

In diesem Newsletter findest du folgende Themen:

• Online-Artikel bei Xing: „Agilität bedeutet, dem Kontrollwahn ein Ende zu bereiten“
• Vortrag „Agile Verträge“ am 12. Juni in Düsseldorf
• Technical Digest: Integrate After Push
• Training „Datengetriebene Produktarbeit“ am 1./2. August in Hamburg
• Agiler Tipp: Von der Wirkung aus gedacht
• Aktuelle Schulungstermine
• Schiff des Monats: Feuerwehr

Viel Spaß beim Lesen!

Viele Grüße, 
Henning

P.S.: Scrum und Skalierung ein Thema bei dir? Dann hätten wir zwei Angebote für dich: 1-tägig Certified Less Basic (CLB) am 28. Mai in Hamburg oder die ausführlichere Version der Certified Less Practitioner (CLP) vom 25.-27. Juni in Hamburg.
 

In der Xing-Reihe Klartext hat mein Kollege Stefan Roock einen kurzen Artikel veröffentlicht, in dem er beschreibt, was für ihn Agilität im Kern ausmacht.

Seine Thesen:

• Viele Unternehmen glauben, dass sie agil arbeiten würden
• Mit Methoden wie Scrum streben sie erneut nach klar definierten Strukturen
• Agilität entsteht aber im gekonnten Umgang mit immer weniger Struktur

Aber lies doch selbst...
Viel Spaß dabei!
 

Am 12. Juni hält mein Kollege Stefan Roock zusammen mit dem Rechtsanwalt Fritz Pieper einen Vortrag zur Vertragsgestaltung in agilen Projekten. Der Vortrag führt in die juristischen Grundlagen des Softwarevertragsrechts ein und warnt vor den häufigsten Fallstricken. Insbesondere macht der Vortrag klar, dass Werkvertrag nicht unbedingt Festpreis impliziert und neben Dienstleistung und Werkvertrag auch noch andere Vertragstypen denkbar sind. 
Anschließend wird argumentiert, dass in agilen Verträgen die Zusammenarbeit mindestens ebenbürtig zu den Ergebnissen thematisiert werden muss. Und nicht zuletzt werden unterschiedliche Vertragsmodelle vorgestellt: 

• Festpreise: garantierter Maximalpreis, garantierter Minimalumfang, Money for Nothing - Change for Free 
• Time&Material: Design to Cost, garantierte Produktivität
• Nutzenorientierte Verträge: Proviant&Prämie, Pay per Use, Profit Sharing

Der Vortrag findet am Abend statt und ist kostenfrei. Du kannst dich vormerken lassen, indem du unten auf die Anmeldung klickst und dadurch eine E-Mail schickst an unseren Kollegen Gregor Sälker.
Du erhältst dann den genauen Ort und Uhrzeit per E-Mail mitgeteilt.
 

Tief in meinem Herzen bin ich ja noch immer Entwickler. Das Programmieren hat mir immer viel Freude bereitet. Gerade, weil es dabei regelmäßig kniffelige Rätsel zu lösen gab.

Mein Kollege Björn Ostermann hat jetzt einen Teil seiner Erfahrungen aus einem großen E-Commerce-Projekt aufgeschrieben: Wie verwendet ein hochperformantes Software-Entwicklungsteam die Versionsverwaltung so, dass sie häufiges Integrieren ohne Wartezeit fördert? Die Lösung ist überraschend.

Den ganzen Text kann man in unserem Technical Digest auf der it-agile Website lesen. Vielleicht für dich oder deine Kollegen interessant? 

Viel Spaß beim Lesen!
 

Vor allem für Anwendungen mit vielen anonymen Nutzern würde man lieber auf Basis von Daten als nach Bauchgefühlen entscheiden, welche neuen Features eingebaut werden sollten. Aber welche Daten nützen wirklich? Wie formulieren wir Hypothesen und erheben möglichst schlank die Daten, um sie zu überprüfen?

Diese und weitere Fragen beantwortet Markus Andrezak in einer Schulung, die wir mit ihm gemeinsam jetzt auch in Hamburg bei it-agile (schon im neuen Büro!) anbieten:
„Datengetriebene Produktarbeit“
Hypothesengetriebene Entwicklung und Verbesserung von Produkten braucht Daten. In dieser Schulung lernen die Teilnehmer, wie Annahmen formuliert und mit welcher Art von Daten sie validiert werden können.

Wir wünschen viel Spaß und Erfolg mit dieser Schulung!
 

In der gemeinsamen Arbeit beim Kunden, haben meine Kollegen Sabrina Spiegel und Stefan Zumbrägel bemerkt, dass sich die Teams schwer damit getan haben ein Sprintziel zu formulieren. Das Ergebnis waren Ziele wie „alle Items müssen fertig werden“ oder „an Kontent XY wird weitergearbeitet“. Das Problem dieser Ziele war, dass sie niemand mehr beachtet hat. Der Fokus auf zu erstellende Features brachte auch im Sprint Review Probleme bei der Vorstellung der Sprintergebnisse. Um diesem Problem zu begegnen, haben wir uns eines Punktes aus dem Bereich User Story Mapping bedient: von der Wirkung her denken.

Wie verändert sich dadurch das Sprintziel?
Bei der Suche nach einem Sprintziel haben wir uns mit dem Team die Frage gestellt:

• Was verändert sich spürbar oder sichtbar für den Benutzer durch die Entwicklung in diesem Sprint?
• Und vielleicht noch viel wichtiger: Welchen Mehrwert hat er davon, wenn wir z. B. 2 Wochen an dem Produkt gearbeitet haben? 

Das hatte verschiedene positive Effekte auf die Arbeit im Team:

• in jedem Sprint entstand ein MVP Minimal Viable Product und damit die Möglichkeit Feedback zu bekommen
• Flexibilität in der Featureausgestaltung während des Sprints
• besseres Feedback im Review
• ein viel stärkerer Fokus auf den Benutzer

Spannend ist auch, dass wir diese Denke im Weiteren auch auf die Planung von Releases übertragen konnten.


Welchen Tipp kannst du zu dieser Rubrik beitragen? Schreib mir gern?
 

Hier als Service für dich, unsere nächsten Schulungs- und Workshoptermine, in denen es noch freie Plätze gibt:

Agile Fluency:

• Agile Fluency Simulation 6. Juni (halber Tag) in Hamburg
• Agile Fluency Simulation 27. Juni (halber Tag) in Hamburg
• Agile Fluency Enterprise Workshop 16./17. Juli in Hamburg

Agiles Management:

• Management 3.0 24./25. Mai in Hamburg
• Certified Agile Leader (CAL-1) 12.-14. September in Hamburg

Effektive Kommunikation und Meetings:

• Grundlagen der Konfliktbearbeitung in Teams 24./25. Juli in München
• Eine Frage der Retrospektive 9. August in Hamburg
• Grundlagen der Meetingmoderation 5./6. September in Hamburg

Kanban:

• Kanban Management Professional 1 (KMP I) 4./5. Juni in Hamburg
• Team Kanban Practitioner (TKP) 11. Juli in Hamburg
• Kanban Management Professional 1 (KMP I) 18./19. Juli in München
• Kanban Management Professional 1 (KMP I) 23./24. Juli in Hamburg
• Team Kanban Practitioner (TKP) 22. August in Hamburg
• Kanban Management Professional 2 (KMP II)  3./4. September in Hamburg
• Team Kanban Practitioner (TKP) 5. September in München
• Kanban Management Professional 2 (KMP II)  11./12. September in München

Scrum-Specials:

• Certified Less Basic (CLB) 28. Mai in Hamburg
• Certified Less Practitioner (CLP) 25.-27. Juni in Hamburg
• Datengetriebene Produktarbeit 1./2. August in Hamburg
• Scrum Basics 23. August in Hamburg
• Scrum Basics 4. September in München

Scrum-Zertifizierungen:

• Agile Developer Skills/Certified Scrum Developer (ADS/CSD) 28.-30. Mai in Hamburg
• Certified Scrum Master (CSM+Kanban) 29.-31. Mai in Hamburg
• Certified Scrum Master (CSM) 18./19 Juni in Hamburg
• Certified Scrum Developer (CSD) 2.-4. Juli in Hamburg
• Certified Scrum Master (CSM) 9./10 Juli in Hamburg
• Certified Scrum Master Deluxe (CSM) 16.-18 Juli in Hamburg
• Certified Scrum Developer (CSD) 7.-9. August in München
• Certified Scrum Master (CSM) 7./8. August in Hamburg
• Certified Scrum Product Owner plus Exploration (CSPO) 10.-12. September in München

Das Schiff der Hamburger Feuerwehr mit dem Namen „Branddirektor Krüger“ ist 23,38m lang und 5,60m breit. Es hat 550 KW (750 PS) und schafft mit seiner Feuerlöschpumpe bis zu 12.000l Wasser pro Minute. Branddirektor Krüger war Chef der Hamburger Feuerwehr von 1916 bis 1926.

Was hat jetzt die Feuerwehr mit Agilität zu tun? Ja klar, die Feuerwehr kann die Einsätze nicht planen, sie müssen sich dem Notfall anpassen. Andererseits gibt es viel Erfahrung und Best Practices, wie man Feuer löscht. Ich wollte aber auch mehr über die Projektfeuerwehren herziehen, die es rund um viele agile Kontexte nach wie vor gibt:
Da wird ein Feuer erklärt (und manchmal sogar erst gelegt) und mit der Begründung, dass es ja brennt, werden alle Regeln außer Kraft gesetzt, einer macht die Ansagen, alle haben zu folgen und das schnell und hektisch. Das ergibt viel Sinn, wenn es wirklich brennt. Aber ist das ungute Gefühl, die Kunden könnten enttäuscht sein, wenn wir nicht schneller mehr Features liefern, ein guter Grund für die Feuerwehr?
Und wenn schon Feuerwehr, dann doch bitte immer eine Nachbetrachtung, wie das Feuer entstanden ist! Nur so könnte man auf Dauer die Ursachen beheben, die zu echten oder vermeintlichen Feuern führen; oder wenigstens lernen, das eine vom anderen zu unterscheiden. 

Ich wünsche dir, dass die Feuerwehr nicht kommen muss zu deinen Vorhaben, obwohl ihr im Team alle (für die Sache) brennt!
 

Was passiert bei euch, wenn die Vorhaben brennen?  Schreibe mir gern dazu.


Für eine größere Aufnahme des Schiffes, klicke einfach auf das nebenstehende Bild.