Hier findet ihr einige Bilder vom Agile Coach Camp 2012 Germany in Rückersbach. Unsere Zusammenfassung des Camps veröffentlichen wir in den kommenden Tagen. Viel Spaß mit den Bilder. Update: Zusammenfassung ist online.
Letztes Jahr konnte ich auf dem Scrum Day einen Vortrag zu Scrum & Projektmanagement halten (Slideshare). Dieses Jahr hatte ich durch meinen Umzug nach Frankfurt und diverse Projekte leider keinen Zeit eine Präsentation vorzubereiten und einzureichen. Schade, denn der diesjährige Scrum Day verspricht durch seine Ausrichtung auf Agilität im Konzernkontext sehr interessant zu werden!
Er findet vom 4. bis 5. Juli im Trainingszentrum der SAP in Walldorf statt. Vor dem eigentlichen Scrum Day gibt es zudem am 3. und 4. Juli zwei sehr interessante Workshops:
Am 13. März fand wieder einmal ein ObjektForum in Frankfurt statt. Dieses Mal mit dem Thema „Agile Softwareentwicklung im Spannungsfeld zwischen Kollegen und Kunde„, vorgetragen von Joachim Weiß (Netpioneer).
Es wurden die üblichen Themen besprochen, interessant wurde es bei dem Themenkomplex rund um Teamorganisation und natürlich bei den Themen, die direkt den Product Owner betreffen.
Zentrale Frage bei der Teamorganisation: Verteilt man Arbeit auf Teams und pflegt somit stabile Teams oder bildet man neue Teams sobald neue Projekte anstehen? Die Antwort war eindeutig und zu erwarten: Stabile Teams sind eine Voraussetzung für hohe Produktivität.
Ein interessantes Ergebnis brachte die Frage danach, wie gut der Product Owner den Kunden vertreten kann. Nur bei ca. 10% der Anwesenden wird der PO entweder direkt durch den Kunden gestellt bzw. der PO ist vor Ort beim Kunden tätig. Hier wird klar, welche Optimierungspotentiale gerade an dieser Schnittstelle noch zu aktivieren sind.
Fazit: Guter Vortrag, interessanter Termin!
Agilität und Software-Architektur sind immer für eine Diskussion gut. Ich kann mich gut an diverse (hitzige) Diskussionen erinnern, in denen von stark traditionell geprägten Architekten gefordert wurde, dass doch bitte die Architektur detailliert im Vorfeld zu erstellen wäre. Zudem müsse man sich zu Projektstart darauf festlegen, welche Referenzumgebungen genutzt werden sollen, welche Technologien relevant sind und wie die nicht-funktionalen Anforderungen im Detail lauten. Das ergebe sich doch automatisch aus dem Scope und überhaupt müssen die typischen Sichten auf die Architektur detailliert geplant und beschrieben werden, bevor mit der Umsetzung begonnen wird. Eine Freigabe des Ganzen vor Eintritt in die Umsetzungsphase ist natürlich auch noch bei den entsprechende Entscheidungsinstanzen einzuholen.
Eine Ansicht, die in einem Phasenmodell ohne echte inkrementelle Elemente nicht ganz unbegründet ist und auch einen gewissen Wert hinsichtlich Identifikation und Bewertbarkeit von Risiken darstellt.
Wie sieht die Realität in vielen Fällen aus? Eine Vielzahl an umfangreichen Modellierungsartefakten, eine Architektur die die Änderungen im Projektverlauf nicht abbilden kann. Kurz: Eine anfangs schöne Architekturvorstellung gleitet in einen „Architektursumpf“ ab. Der Ruf nach großen Re-Design Phasen wird laut (neue Dokumente, Modelle, Reviews, Freigaben). Das eigentliche Ziel, lauffähige Software zu liefern gerät schnell in den Hintergrund.