Mit Einführung von Release Pipelines wurde TFS schon vor geraumer Zeit in die Lage versetzt, auch das physikalische Rollout von Anwendungen zu verwalten. Zwischenzeitlich hat das Leistungsmerkmal Release Management auch schon eine durchaus nennenswerte Verbreitung gefunden.

Wer unter TFS 2015 (ab Update 2) oder unter TFS 2017 schon einmal versucht hat, ein Rollout bis zur produktiven Umgebung hin zu automatisieren, der kennt das Leid: die produktive Umgebung ist „dicht“, für ein Deployment muss aber logischer weise ein Kanal geöffnet sein. Mögliche Kanäle sind vielfältig und von den meisten Verantwortlichen einer produktiven Umgebung durchaus nicht wirklich gerne gesehen. In der Regel führt dies zur Diskussion über „das kleinere Übel“: ist nun eine Netzwerkfreigabe auf dem Server, auf die die neue Version kopiert werden kann, das Richtige oder soll besser über IIS WebDeploy veröffentlich werden oder auch FTP. Und wie wird anschließend die Konfiguration der Anwendung vorgenommen, dies sollte ja ebenfalls stabil automatisiert werden.

Herkömmliche Tasks, Ausführung auf dem Release Agent

• Task: Copy Files: wird lokal auf dem Release Agent ausgeführt. Das Zielsystem muss eine Netzwerkfreigabe haben, um die Anwendung auf das System kopieren zu können
• Task: PowerShell: PowerShell wir auf dem Release Agent ausgeführt
• Task: Deploy IIS App: Hierfür müssen auf dem Zielsystem die IIS WebDeploy Dienste ausgeführt werden. Diese erlauben ein Kopieren der Dateien über „Web Deployment Agent Service“ (MsDepSvc:80), die Konfiguration erfolgt über „Web Management Service“ (WmSvc:8172)

Einen ersten Lösungsansatz hat Microsoft mit WinRM basierten Tasks bereits seit längerem im Leistungsangebot. WinRM vereinheitlicht zwar die Wege hin zum einem Zielsystem, über einen einzigen Port können sowohl Daten kopiert als auch „Remote Admin“ durchgeführt werden. Doch wer WinRM in der Praxis konfiguriert, sieht dies ebenfalls nur als „kleineres Übel“ an, muss doch ein eingehender Port auf dem System erlaubt werden. Und wer WinRM schon einmal über die Grenzen einer Windows-Domain hinweg konfigurieren durfte hat dabei sicherlich ein paar mehr Stunden als geplant damit zugebracht. Und nicht zu vergessen, Cross Platform tauglich ist dieses Modell sicherlich nicht.

WinRM Tasks, Ausführung auf dem Release Agent, die eigentliche Aktion wird aber Remote auf dem Zielsystem ausgeführt

• Task: Windows Machine File Copy: Der Copy Befehl wird über WinRM an das Zeilsystem weitergegeben, die Dateien werden ebenfalls per WinRM auf das Zielsystem übertragen
• Task: PowerShell on Remote Machines: Das PowerShell Skript wird per WinRM an das Zielsystem übertragen und dort ausgeführt
• Task: WinRM – IIS Web App Deployment / Management: Hier wird die Kommunikation über WinRM ausgeführt, das eigentliche Konfigurieren läuft dann direkt auf dem Zielsystem ab.

Einsatz von Deployment Groups, es findet nur noch ausgehende Kommunikation statt, ports müssen auf den Zielmaschine nicht mehr veröffentlicht werden Deployment Groups, mit TFS 2018 eingeführt, addressieren genau dieses Problem. Im Grunde wird das gleiche Konzept, ja sogar das gleiche Software-Paket zum Einsatz gebracht, wie dies schon seit Jahren für Build und Release Pipelines erfolgreich in hybriden Umgebungen zum Einsatz kommt. Auf den Zielmaschinen werden „task based agents“ installiert und im Modus „deployment group“ konfiguriert. Läuft ein solcher Agent auf der Zeilmaschine, so nutzt er
das Pull Verfahren, um kontinuierlich beim TFS Application Tier nachzufragen, ob ein neuer Deployment Auftrag zu ihn vorliegt. Dieser wird dann wie auf einem Build und/oder Release Agent abgearbeitet. Der Vorteil dieses Vorgehens: Tasks werden im Kontext der Zielmaschine ausgeführt, die nochwendigen Artifacts werden automatisch vorab vom Release Agent auf die Zielmaschine repliziert. Somit laufen alle Kopier- und Konfigurationsschritte lokal ab und die produktive Zeilmaschine kann nach außen hin auch komplett dicht bleiben.

Unter VSTS bedeutet dieses Modell, dass nun die eigentlichen Release Agents ebenfalls problemlos Hosted genutzt werden können, die Zielmaschinen im firmeninternen Netz holen nun ihre Aufträge selbst von den
VSTS ab.

• Agile Softwareentwicklung
• Teamarbeit
• Spaß an der Arbeit
• Schnellere Ergebnisse
• Sprints

Die Antwort, die wir eigentlich im Sinn haben, ist für viele überraschend:
Das Done Product Increment

Warum ist das wichtig?

Ohne ein Produkt, welches wir entwickeln wollen, ist Scrum unnötig. Wir brauchen kein Team, keine Regeln, keine Zusammenarbeit. Dieses Produkt ist aber nicht das große endgültige Ziel, sondern es wird schrittweise in Sprints
von maximal 4 Wochen Länge entwickelt. Am Ende eines jeden Sprints erwarten wir ein Inkrement des Produkts, welches einen Mehrwert darstellt und produktiv eingesetzt werden kann – es muss also „Done“ sein.
Leider legen unserer Erfahrung nach zu wenige
Scrum Teams wirklich wert auf diese Idee von Done. Häufig wird das Product Increment am Ende eines Sprints nicht ausgeliefert und das Entwicklungsteam hat deshalb keine echte Motivation, ein Done Increment zu liefern. Das Resultat
sind qualitativ nicht ausreichende Ergebnisse, an denen für den Produktivbetrieb noch einiges nachgearbeitet werden muss. Das schränkt den Product Owner in seiner Entscheidungsfähigkeit ein. Er kann oft nicht beurteilen, was tatsächlich noch zu
tun ist, um ein Release der Software wirklich durchzuführen.

Der Weg zu Done

Ein Done Increment entwickelt sich nicht einfach so. Es gehören einige Dinge dazu, die es einem Entwicklungsteam in Scrum erleichtern, Systeme und Anwendungen zu entwickeln, die wirklich „releasable“ sind. Wir zeigen einen
möglichen Weg auf, bei dem ein Entwicklungsteam dem Done Increment Stück für Stück näherkommt.

Selbstverantwortung übernehmen

Der erste Schritt ist, die Verantwortung für das Done Increment nicht bei Anderen zu suchen, sondern sie selbst zu übernehmen. Unsere Anwender, Kunden und die Organisation, in der wir arbeiten, bieten uns keine
perfekte Umgebung. Wir müssen unter den bestehenden Rahmenbedingungen dafür sorgen, auslieferbare Software zu entwickeln. Dafür erarbeiten wir Kriterien, die diese Auslieferbarkeit gewährleisten: die Definition of Done.

Ein cross-funktionales Team sein

Eine grundlegende Anforderung an ein Scrum Entwicklungsteam ist: es soll cross-funktional sein. Das heißt, das Entwicklungsteam muss in der Lage sein, ein Done Increment herzustellen. Das funktioniert oft in
drei Schritten:

1. Daran glauben, dass Cross-Funktionalität möglich ist
2. Strategien entwickeln, um Wissen im Team zu verteilen
3. Echte Zusammenarbeit als Team

Scrum lernen und verstehen

Dieser Punkt klingt zunächst trivial. Die 11 Regeln, die Scrum ausmachen, sind einfach und wirken offensichtlich. Wichtig ist aber, hinter diesen Regeln die Prinzipien zu entdecken. Scrum basiert auf der empirischen Prozesssteuerung:
Transparenz, Überprüfung und Anpassung. Dabei werden konkrete Erfahrungen genutzt, um das eigene Vorgehen konsequent und kontinuierlich zu verbessern. Alle Regeln in Scrum sind danach ausgerichtet.
Daneben sind die Werte Offenheit,
Respekt, Fokus, Commitment und Mut nötig, um nachhaltig mit Scrum erfolgreich sein zu können.

Done definieren

Ein Entwicklungsteam muss nicht nur wissen, welche Qualitätskriterien für sein Produkt erfüllt sein müssen, es muss auch in der Lage sein, diese Kriterien zu erreichen. Die Maßnahmen dafür beschreibt das Team in einer Definition of Done.

Die Definition of Done ist abhängig vom Produkt und vom Kontext der Produktentwicklung. Eine App fürs Online Banking hat andere Qualitätsanforderungen als ein medizinisches Gerät und braucht deshalb andere Maßnahmen, um diese Qualität herzustellen.

Als Team zusammenwachsen

Es geht in Scrum nicht darum, als Einzelner möglichst tolle Leistungen zu erbringen. Viel wichtiger ist es, als echtes Team zusammen zu arbeiten. Die Gesamtleistung eines gut funktionierenden Teams übertrifft dabei die Leistungsfähigkeit
der einzelnen Mitglieder bei weitem. Dabei arbeitet das Team als Ganzes am gemeinsamen Ziel, z.B. dem Sprintziel.

Quality first!

In Scrum ist Qualität nicht verhandelbar. Sie wird nicht zu Gunsten einer kurzfristig schnelleren Entwicklung ignoriert. Teams, die mit Scrum wirklich erfolgreich sein wollen, dürfen deshalb nicht der Versuchung erliegen, Abkürzungen
in Bezug auf die Qualität zu akzeptieren, um noch eine weitere Funktionalität liefern zu können.

Geeignete Architekturen einsetzen

Da sich Anforderungen in Scrum laufend ändern können, muss die Software flexibel und erweiterbar sein. Die Softwarearchitektur entwickelt sich zusammen mit der Software. Gute Prinzipien der Softwareentwicklung wie
lose Kopplung / starke Kohäsion, Self-contained Systems oder konsequentes Refactoring helfen dem Team dabei.

Automatisierung einsetzen

Werkzeuge allein machen kein gutes Team. Aber die richtigen Werkzeuge können ein gutes Team dabei unterstützen, noch besser zu werden und auf die vielfältigen Anforderungen in der Softwareentwicklung zu reagieren.
Entwicklungsteams
sollten nach technischer Exzellenz streben und Werkzeuge gezielt einsetzen, wo diese sie bei der Softwareentwicklung, -verteilung und -betrieb unterstützen. Prinzipien wie Testgetriebene Softwareentwicklung oder DevOps können hilfreiche und sinnvolle
Praktiken für Scrum Entwicklungsteams sein.

Unfertige Features isolieren

Scrum Teams müssen spätestens am Ende eines Sprints ein auslieferbares Product Increment liefern. Häufig stehen Teams vor der Herausforderung, dass zu diesem Zeitpunkt noch unfertige Funktionalität in der Codebasis
vorhanden ist, die nicht auslieferbar ist.
Entwicklungsteams sollten Strategien entwickeln, um diese unfertigen Teile der Software isolieren zu können, damit trotzdem ein Done Increment präsentiert werden kann.
Kurzlebige Branchesim Versionskontrollsystem können dabei helfen, sind jedoch oft ein Risiko, weil es beim Merge zu Konflikten und Fehlern kommen kann. Eine Entwicklungsstrategie mit nur einem Master Branch und die Verwendung von Feature Toggles können
dieses Problem beheben.

Sind wir jetzt Done?

Diese Frage ist spannend. Scrum Teams liefern mit jedem Sprint ein Done Increment, also müssen sie irgendwann mal „Done“ sein. Auf der anderen Seite lernen sie jeden Sprint etwas Neues dazu und verbessern sich und
ihre Arbeitsweise. Sie sind dadurch in der Lage, ihr Verständnis von Done zu verfeinern und die Maßnahmen hin zum Done Increment zu verbessern.
Diese vom Team übernommene Verantwortung führt häufig zu einer Erweiterung des Denkens. Entwicklungsteams
kümmern sich nicht mehr nur um die reine Softwareentwicklung, sondern übernehmen mehr und mehr Verantwortung für den gesamten Lebenszyklus des Systems. Diese Geisteshaltung von DevOps ist die Basis vieler sehr guter Scrum Teams.
Ein Scrum Team
hat also nicht irgendwann eine Definition of Done, mit der es ab dann auslieferbare Product Increments liefert. Vielmehr schließt sich hier der Kreis zur Legende vom Heiligen Gral: dieser kann auch nicht gefunden werden, sondern der Weg
hin zum Gral und die Vervollkommnung der Person ist das Ziel.
Jeder im Scrum Team, insbesondere im Entwicklungsteam, ist verantwortlich dafür, diesen Weg mit zu gehen und die kontinuierliche Verbesserung bei sich selbst und im Team voran zu bringen.

Autorenprofile

Peter Götz

Peter ist agiler Coach mit mehr als 15 Jahren Erfahrung in der Softwareentwicklung. Als Professional Scrum Trainer der Scrum.org und Mitglied im international Software Architecture Qualification Board (iSAQB) unterstützt er seine Kunden.
Peter hat langjährige Erfahrung als Softwareentwickler und –architekt, sowie als agiler Coach, Scrum Master und Product Owner.

Thomas Schissler

Thomas ist Leiter der Softwareentwicklung bei der artiso solutions GmbH und unterstützt als Coach und Consultant Kunden bei der Verbesserung ihrer agilen Softwareentwicklungsprozesse. Seit 2007 ist er jährlich mit dem Microsoft MVP
Award im Bereich Visual Studio ALM ausgezeichnet worden. Seit 2010 ist er Professional Scrum Trainer. Sein Steckenpferd ist aktuell das Thema DevOps.

Aller Anfang

• Was habe ich gestern gemacht?
• Was möchte ich als nächstes tun?
• Was hat mich behindert? Welche Probleme sind aufgetreten?

Eine Verbesserung

• Was haben wir gestern an diesem PBI erreicht?
• Was wollen wir heute an diesem PBI als nächstes tun?
• Was behindert uns um das PBI fertig zu bekommen?

Ist das schon alles?

• Es sollte gut erreichbar sein
• Es sollte uns einen positiven Spirit geben
• Es müssen nicht alle daran arbeiten
• Das Team sollte alles dafür tun, damit das Tagesziel erreicht wird.

• Die Verlässlichkeit der Velocity wird unter anderem durch die folgenden Faktoren beschränkt: Hindernisse, Impediments
• Motivation → was treibt uns an
• Wissen / Expertise / Kompetenz der Entwickler
• Entwicklungsumgebung (lokal wie auch TFS Infrastruktur etc.)
• Transparenz
• Zielvorstellungen
• Prozess
• Das Ziel (das Produkt)
• Krankheit
• Unvorhergesehene / ungeplante Ereignisse

• Aus unserer bisherigen Erfahrung ist das Schätzen in einer abstrakten Größe genauer als eine rein zeitbasierte Schätzung.
• Bei größeren Release-Planungen ist die Planung immer zyklisch anzupassen und es gilt zu beachten, dass auch die Velocity nur eine Planzahl ist.
• Scrum bietet zusätzlich den Vorteil, dass die Planungen nach jedem Sprint (alle 2-4 Wochen) angepasst werden können und somit eine gute Reaktionsfähigkeit gegeben ist, die es ermöglicht die wichtigen Dinge zuerst zu implementieren.

Ein Thema das Softwareentwicklungs-Teams oft beschäftigt: Wie können wir als Team besser zusammenarbeiten? Interessanterweise kommt diese Frage erst auf, wenn das Team bereits einen gewissen Reifegrad erreicht hat. Erst dann genügt es nicht, am selben Produkt zu arbeiten, Code zu sharen und vielleicht sogar ein Scrum-Team zu sein. Ein echtes Team zeichnet aus, dass alle Mitglieder im Team ein gemeinsames Ziel teilen. Und das darf nicht nur lauten: “Wir wollen am Ende des Sprints alle versprochenen Backlog Items abgearbeitet haben”.

Wie sieht nun ideale Zusammenarbeit in einem Team aus? Sicher ist hier ein gegenseitiges Angebot zur Unterstützung bei Problemen alleine nicht ausreichend. Ich kenne kein Team bei dem der Kollege bei einer Frage oder einem Problem weggeschickt wird. Keiner sagt “Das ist nicht mein Problem, sehe selber zu, wie du das lösen kannst”. Also ist dieser Level der Zusammenarbeit höchstens ein Einstieg, aber es muss doch besser gehen.

Es geht es darum, wie können wir alle Teammitglieder so einbinden, dass wir Kompetenzen bündeln, Probleme schnell und effizient lösen und dabei gute Qualität liefern? Wie können wir durch gemeinsame Diskussionen gute Lösungen finden und wie können wir individuelle Schwächen kompensieren und Fehler vermeiden? Eine Voraussetzung für diese Punkte ist, dass wir nicht nur am selben Produkt, sondern am selben Thema arbeiten. Damit wird das Verständnis viel besser und jeder fühlt sich direkt betroffen. 

Eine Methode diese Zusammenarbeit zu fördern, ist das sogenannte Swarming. Eine Technik mit der das Team gemeinsam zum Ziel hat, das wichtigste Backlog Item (PBI) so schnell wie möglich abzuarbeiten. Dazu stell sich jeder im Daily Scrum die Frage “Kann ich eine Aufgabe übernehmen, damit wir dieses PBI voranbringen?”. Wenn nicht, lautet die zweite Frage: “Kann ich einen Kollegen unterstützen, damit dieser mit seiner Aufgabe schneller vorankommt?”. Erst wenn beide Fragen mit “Nein” beantwortet werden, wird mit Arbeiten am zweitwichtigsten PBI begonnen.

Es genügt aber nicht, die Aufgaben im Daily gut zu verteilen, viel entscheidender ist die Frage, wie die Zusammenarbeit während des Tages läuft. Hier mache ich mit 2 Teams gerade ein Experiment, bei dem wir versuchen, die Zusammenarbeit durch Umformulierung der Frage “Kann ich dich bei deiner Aufgabe unterstützen?” zu verbessern. Zukünftig wollen wir so vorgehen, dass ein Entwickler, der eine Aufgabe abgeschlossen hat, überlegt, an welcher Stelle er gerade das größte Hindernis zur Fertigstellung des PBIs sieht. Den Kollegen der gerade an dieser Aufgabe arbeitet fragt er dann “Wo stehst du gerade?”. Den folgenden Kurzbericht kann der Entwickler der gerade seine Aufgabe abgeschlossen hat nutzen um konkrete Unterstützungspunkte zu identifizieren. Daraus entsteht dann entweder eine Arbeit im Pair oder auch eine Aufteilung der noch zu erledigenden Punkte.

Die Umformulierung des Unterstützungsangebots zu einer Statusabfrage aus meiner Sicht einen entscheidenden Vorteil: Während bei der klassischen Vorgehensweise der aktuell beschäftigte Kollege überlegen soll, wo eine Unterstützung möglicherweise Sinn macht, drehen wir das um. Er muss dann nur kurz berichten, wo er steht, das identifizieren von Unterstützungsmöglichkeiten liegt dann aber beim Kollegen der seine Aufgabe gerade abgeschlossen hat. Ich erhoffe mir aus dieser Vorgehensweise mehr Unterstützungen während des Tages, da beim bisherigen Vorgehen der Gefragte ja auch einfach sagen kann: “Danke, brauche gerade keine Unterstützung”, was für ihn meistens wohl der bequemere Weg ist. Zudem hilft dem Gefragten sicher mal kurz zu reflektieren, wo er gerade steht. Und er wird ja nicht aus seinem Kontext herausgerissen, da es ja genau um sein Thema geht.

Ich bin gespannt, wie sich das Vorgehen bei den beiden Teams auswirkt. Ich werde wieder berichten. 

Vor kurzem habe ich mit einem Team die interessante Frage aufgeworfen, ob Softwareentwickler Leidenschaft für das Produkt das sie entwickeln benötigen oder ob Leidenschaft für Technologie wichtiger ist. Und wie wirkt sich diese Frage auf die Zusammenarbeit im Team aus?

Hintergrund der Frage ist, dass viele Teams mit denen ich zusammenarbeite, zwar Scrum nutzen, aber im Grunde genommen im Sprint einzelne Backlog Items abarbeiten und am Ende des Sprints ein Inkrement an den Product Owner liefern. Bewusst oder unbewusst haben die Entwickler aber sehr wenig Kontakt mit Personen außerhalb des Scrum Teams. Und daraus ergibt sich die Frage, was ist das Ziel des Teams?

Nach Definition des Scrum Guides ist das Ziel eines Development Teams, ein „Done“ Inkrement des Produkts am Ende jedes Sprints abzuliefern. Das Development Team ist damit verantwortlich für die Qualität des Produktes. Hier ist nun genau die Frage, welche Qualität hier genau gemeint ist. Natürlich ist das Development-Team verantwortlich für die „innere Qualität“ des Produktes, also für die Wartbarkeit und Erweiterbarkeit des Codes und dafür, möglichst wenig technische Schuld aufzuhäufen. Auch für den Teilaspekt Fehlerfreiheit der „äußeren Qualität“ ist klar, dass das Development Team dafür die Verantwortung trägt. Wie sieht es aber mit anderen Aspekten wie Usability, Sicherheit oder allgemein mit dem Thema „Zufriedenheit des Anwenders“ aus? Kann ein Development Team sich ausschließlich auf die technischen Aspekte fokussieren und das Generieren von Mehrwert dem Product Owner überlassen? Schließlich ist das genau die Aufgabe dieser Rolle. Der Product Owner wird oft ja auch als „Value Maximizer“ bezeichnet.

Nach der Diskussion mit dem Team bin ich überzeugt, dass das Development Team eine Leidenschaft für das Produkt haben muss. Die Entwickler müssen zunächst das Interesse haben, ein gutes Produkt zu entwickeln, das die Anwender begeistert. Die Erstellung von gutem Code allein darf hier nicht genügen. Hier kommt mir ein Vergleich mit einer Fußballmannschaft in den Sinn. Wenn alle Spieler nur das Ziel haben technisch perfekt zu spielen und persönlich möglichst keine Fehler zu machen, wird das möglicherweise nicht ausreichen um das Spiel zu gewinnen. Wir brauchen also ein übergeordnetes Ziel. Im Fußball ist es, das Spiel zu gewinnen. In der Software ist es, mit unserer Software Anwender zu begeistern oder wenigstens zufrieden zu stellen.

Damit übernehmen die Entwickler auch eine gewisse Kontrolle, dass der Product Owner einen guten Job macht. Er trifft zwar letztendlich die Entscheidungen, aber wenn das Development Team das Gefühl hat, dass die falschen Schwerpunkte gesetzt werden und dass Potenziale nicht ausgeschöpft werden, dann muss es darüber zumindest eine Diskussion geben. Diese wird aber nur dann stattfinden, wenn sich die Entwickler nicht als reine Umsetzer verstehen, die einen Arbeitsauftrag bekommen und diesen möglichst gut umsetzen. Sie müssen sich mit Leidenschaft für den Erfolg ihres Produktes einsetzen – also nicht das Produkt des Product Owners. Diese Leidenschaft wird aber nur entstehen, wenn die Entwickler verstehen wie ihre Software genutzt wird, wenn sie direkt Feedback von Anwendern bekommen und selbst verstehen wie auf bestimmte Funktionen reagiert wird. Dieses Feedback kann im Sprint Review entstehen oder durch Telemetriedaten die die Nutzung durch die Anwender visualisieren oder durch soziale Medien oder, oder. Dem Product Owner erwächst hier eine zusätzliche Aufgabe. Er muss die Leidenschaft für das Produkt bei den Entwicklern wecken, indem er die Ziele und Vision erklärt, indem er Success-Stories mit den Entwicklern teilt und auch indem er Fehlschläge oder Misserfolge direkt kommuniziert.

Darüber hinaus ist auch wichtig, dass das Development Team an dieser Stelle einheitlich agiert. Sollten nur einzelne Teammitglieder diese Leidenschaft für das Produkt besitzen, so sind soziale Spannungen bereits vorprogrammiert. Wenn ich das tollste Produkt aller Zeiten entwickeln möchte und ich gleichzeitig das Gefühl habe, dass der Kollege ein anderes Ziel hat und seine persönliche Agenda verfolgt, wird das zu Spannungen führen. Ähnlich wie bei dem zuvor genannten Beispiel aus dem Fußball gehört natürlich die Fähigkeit und die Kompetenz auf technischer Ebene dazu, denn nur so werden wir in der Lage sein das Spiel zu gewinnen bzw. ein gutes Produkt zu bauen. Aber es ist eben nicht unser primäres Ziel. Um ein gutes Produkt zu erstellen gehört noch mehr dazu als Technologie zu beherrschen.

Aber letztendlich macht eines für mich eine Gruppe von Personen erst zu einem Team – wenn sie ein gemeinsames Ziel haben, das sie verfolgen. Für das sich jeder engagiert und seinen Beitrag leistet. Wo wir möglicherweise unterschiedlicher Meinung sind, wie wir das gemeinsame Ziel am besten erreichen. Wo wir aber diese Meinungsvielfalt nutzen, um aus verschiedenen Optionen die besten auszuwählen.

Vielleicht lohnt es sich für sie auch einmal die Frage zu stellen, ob ihre Softwareentwickler Leidenschaft für ihr Produkt haben und wie sie diese evtl. wecken oder steigern können. Denn letztendlich ist diese Leidenschaft nichts Anderes als Motivation und wer möchte denn nicht motivierte Mitarbeiter? Leidenschaft und Motivation werden aber nur entstehen, wenn den Teams auch Gestaltungsmöglichkeiten eingeräumt werden und nicht alles von außerhalb vorgegeben ist.

In letzter Zeit haben wir einige IoT Showcases gebaut und dabei häufig den Raspberry Pi eingesetzt. Leider kam es da immer wieder zu Problemen und der Raspberry hat manchmal nicht mehr gebootet. Die Vermutung war, dass das möglicherweise durch ein Ausschalten ohne vorheriges Herunterfahren zusammenhängt. Um diesen Verdacht aber zu erhärten und vor allem herauszufinden, in welchen Konstellationen das Problem vermieden werden kann, stellte sich schnell heraus, dass ein manuelles Unterbrechen der Stromversorgung nicht wirklich praktikabel ist um statistisch belastbare Wiederholungsraten zu erzielen. Deshalb musste eine Automatisierung her.

Der Aufbau dazu ist recht einfach. Wir haben einen Raspberry (Power Switch), der über seinen GPIO ein Relais steuert. Das Relais wiederum schaltet einen Mehrfachstecker in dem nun unsere Testobjekte angesteckt werden können. So war es möglich, auch mehrere Devices mit unterschiedlichen Konfigurationen parallel zu testen. Der  Raspberry Power Switch kann über eine REST Schnittstelle mit den Test-Devices kommunizieren und so feststellen, ob diese hochgefahren sind. Nachdem die Test-Devices alle gebootet sind, wartet er eine zufällige Zeit zwischen 0 und 5 Minuten und schaltet dann den Strom ab. Danach wartet er wieder, bis alle Devices hochgefahren sind.

Ist ein Device nach einer gewissen Zeitspanne nicht verfügbar, dann wird das entsprechend in einem Log vermerkt. Tatsächlich haben wir zwei Fehlerszenarien festgestellt. Teilweise hat ein Reboot geholfen und das Device hat wieder funktioniert, teilweise hat nur ein erneutes Flashen der SD-Karte geholfen.

Mit Hilfe dieses Testaufbaus konnten wir nun verschiedene Testreihen mit verschiedenen Devices und Konfigurationen durchführen und haben ausreichend viele Wiederholungen erzielen können – etwas das ohne Automatisierung nicht möglich gewesen wäre. Für mich ein schönes Beispiel, wie wichtig Testautomatisierung tatsächlich ist, auch wenn es auf den ersten Blick nicht möglich erscheint.

Tatsächlich haben unsere Tests ergeben, dass der Raspberry Pi Probleme mit Stromunterbrechungen hat, bis hin zu einem Zustand, in dem er sich gar nicht mehr booten lässt. Die Probleme sind mit dem Raspberry Pi 2 und Raspberry Pi 3 mit verschiedenen SD Karten aufgetreten, zumindest mal in Verbindung mit Windows 10 IoT. Tests mit anderen Betriebssystemen laufen aktuell noch. Das Verhalten ist natürlich nicht wirklich ideal für ein IoT Device das ja irgendwo ohne Wartung zuverlässig seinen Dienst verrichten sollte. Deutlich robuster hat sich dagegen das Dragonboard 410C verhalten. Damit konnten wir diese Probleme aktuell nicht feststellen

1. Api App auf Azure

   
   
   
   
   

   1. Anlegen der Api App in Azure

      Zunächst erstellt man eine Api App im Azure Portal. Anschließend kann für die Api App Name, Resourcengruppe und Region ausgewählt werden. Nach der Fertigstellung wird man zur Portalseite der Api App weitergeleitet, auf der man seine Einstellungen vornehmen kann. Hier kann z.B. die Skalierung eingestellt werden, um die Kosten zu regulieren.

   2. Konfiguration der Api App

      Die Api App hat standardmäßig das Pricing Tier „Free“. Im Reiter/Tab „Application Setings kann man Remote Debugging für die jeweilige Visual Studio Version aktivieren. Nach dem Speichern ist die Konfiguration in Azure vorerst abgeschlossen und man kann mit der Entwicklung der App beginnen.

2. Erstellen der App

   Nachdem man im ersten Kapitel auf Azure die Api App angelegt hat wird im zweiten Kapitel des Blogs auf die Erstellung der Azure Api App eingegangen. Diese Api App soll jetzt die Events erhalten, die bei VSTS über die Sevice Hooks getriggert werden und danach über die TFS REST API Tasks anlegen soll.

   1. Anlegen eines neuen Azure Api App Projekts

      Als Voraussetzung braucht man das Azure SDK für .NET, welches man hier bekommt (https://azure.microsoft.com/de-de/downloads/), falls es noch nicht installiert ist. Nach der Installation wird in Visual Studio ein neues Web Application Projekt angelegt. Bei der Auswahl des Templates wählt man die Api App aus. Diese hat keine Authentifizierung. Diesen Umstand können wir später beheben, indem man eine eigene Authentifizierung erstellt. Die checkbox „Host in the Cloud“ kann man ignorieren, da die Api App ja schon auf Azure regristriert ist.

   2. Implementierung der API App

      Nach dem Wizard wird eine Solution angelegt, die ein Controllers-Verzeichnis enthält. Darin ist eine Klasse enthalten, die von ApiController erbt. Diese benutzt man um Http-Requests abzuarbeiten. Dazu ändern wir diesen Controller und fügen unsere eigene Methode ein. Diese nimmt den POST-Request vom ServiceHook (siehe Kapitel 3) entgegen und generiert eine Antwort. Die weitere Logik kann man hier dann einbetten.

      public async Task<HttpResponseMessage> WorkItemChanged()
      {
        var content = this.Request.Content.ReadAsStringAsync().Result;
        return this.Request.CreateResponse(HttpStatusCode.Accepted, content);
      }
      

      Um sich z.B. den Content anzusehen, liefert z.B. (https://jsonviewer.stack.hu/) eine schöne Darstellung. Der erhaltene JSON-String kann mit dem Nuget Package NewtonSoftJson deserialisiert werden.

   3. Eigene Authentifizierung erstellen

      Um eine gewisse Sicherheit zu gewährleisten, kann man sich selbst Credentials erstellen, welche später bei der Konfiguration des Service Hooks, für eine Basic-Authentifizierung, verwendet werden können. Folgende Abfrage stellt sicher, dass nur authentifizierte Anfragen bearbeitet werden:

      if (this.Request.Headers.Authorization.Scheme == "Basic" &&
        this.Request.Headers.Authorization.Parameter == Convert.ToBase64String(Encoding.ASCII.GetBytes($"{Username}:{Password}")))
      

   4. Verbindungsaufbau über Security Token

      Jetzt kann eine Verbindung zu VSTS aufgebaut werden, wozu ein Token benötigt wird, welches man sich auf dem VSTS Portal erstellen lässt. (https://{yourAccount}.visualstudio.com/_details/security/tokens) Bei der Erstellung kann die Lebensdauer und der Scope eingestellt werden. Die Lebensdauer bedeutet natürlich, daß man nachdem die Zeit abgelaufen ist, das Token erneuern muss und entsprechend in den Code einpflegen muss. Beim Scope wird eingestellt,welche Rechte der jeweilige Aufruf hat. In diesem Fall bekommt das Token Lese- und Schreibzugriff auf Work Items. Nun kann man im Controller eine Verbindung zu VSTS aufbauen.

      var uri = $"https://{this.account}.visualstudio.com/{this.collection}/{teamProject}/_apis/wit/workitems/${workItemType}?api-version=1.0";
      using (HttpClient client = new HttpClient())
      {
        client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json-patch+json"));
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(Encoding.ASCII.GetBytes($"{this.user}:{this.password}")));
      }
      

      Hierbei ist der Username leer und das Passwort das vorher erzeugte Token. Die Uri kann natürlich angepasst werden. Mehr Informationen dazu findet man auf: https://www.visualstudio.com/en-us/integrate/api/overview

   5. Auslesen der wichtigen Informationen aus dem eingegangenen Service Hook Event

      Die einzelnen Parameter können aus dem eingegangenen Event geholt werden. Die Id des WorkItems liegt auf dem folgenden Feld: var parentWorkItemId = deserializedWorkItem.Resource.WorkItemId; Aus der folgenden Methode bekommt man alle Informationen, die auf dem WorkItem gespeichert sind:

      public async Task ReadFullyExpandedWorkItem(int workItemId)
      {
        FullyExpandedWorkItem workItem;
        var uri = $"https://{this.account}.visualstudio.com/{this.collection}/_apis/wit/workitems/{workItemId}?$expand=all&api-version=1.0";
        using (var client = new HttpClient())
        {
          client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
          client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic",
          Convert.ToBase64String(Encoding.ASCII.GetBytes($"{this.user}:{this.password}")));
          using (HttpResponseMessage response = client.GetAsync(uri).Result)
          {
            response.EnsureSuccessStatusCode();
            string responseBody = await response.Content.ReadAsStringAsync();
            workItem = JsonConvert.DeserializeObject (responseBody);
          }
          return workItem;
        }
      }
      

   6. Erstellen des neuen WorkItems

      Um jetzt ein WorkItem anzulegen, muss man analog zu der in der TFS REST API beschriebenen PATCH Operation (https://www.visualstudio.com/en-us/integrate/api/wit/work-items#CreateaworkitemWithaworkitemlink) vorgehen. Man kann diese JSON-PatchOperation gut mit dem Nuget-Package NewtonSoftJson nachbilden:

      private JsonPatchDocument CreateJsonPatchDocument(string newWorkItemTitle, int workItemId, string iteration, string description)
      {
        var json = new JsonPatchDocument
        {
          new JsonPatchOperation
          {
            Operation = Operation.Add,
            Path = "/fields/System.Title",
            Value = newWorkItemTitle
          }
        };
        if (iteration != null)
        {
          json.Add(new JsonPatchOperation
          {
            Operation = Operation.Add,
            Path = "/fields/System.IterationPath",
            Value = iteration
          });
        }
        if (description != null)
        {
          json.Add(new JsonPatchOperation
          {
            Operation = Operation.Add,
            Path = "/fields/System.Description",
            Value = description
          });
        }
      
        /// Hier kommt der unten genannte Teil mit der Verlinkung hinein
        return json;
      }
      

      Wichtig ist hier ein Teil, der die Verlinkung zu dem ParentWorkItem gewährleistet, damit der Task der erstellt wird auch unter dem richtigen Product Backlog Item erscheint:

       if (workItemId >= 0)
        {
          json.Add(new JsonPatchOperation
          {
            Operation = Operation.Add,
            Path = "/relations/-",
            Value = new WorkItemLink
            {
              Rel = "System.LinkTypes.Hierarchy-Reverse",
              Url = $"https://{this.account}.visualstudio.com/{this.collection}/_apis/wit/workItems/{workItemId}",
              Attributes = new Attributes()
              {
                Comment = "Created by TFSServicesForExpertBlog"
              }
            }
          });
        }

   7. Senden des Json-Patchdocuments an die TFS Rest API

      Die nächste Methode beschreibt, wie man die erzeugte JSON-Patchoperation dann an die TFS REST API schickt.

      public async Task CreateNewLinkedWorkItem(string teamProject, string newWorkItemTitle, string workItemType, int parentWorkItemId, string iteration, string description)
      {
        WorkItem createdWorkItem;
        var json = this.CreateJsonPatchDocument(newWorkItemTitle, workItemId, iteration, description);
        var jsonString = JsonConvert.SerializeObject(json);
        var uri = $"https://{this.account}.visualstudio.com/{this.collection}/{teamProject}/_apis/wit/workitems/${workItemType}?api-version=1.0";
        var content = new StringContent(jsonString, Encoding.UTF8, "application/json-patch+json");
        using (HttpClient client = new HttpClient())
        {
          client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json-patch+json"));
          client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(Encoding.ASCII.GetBytes($"{this.user}:{this.password}")));
          using (var response = client.PatchAsync(uri, content).Result)
          {
            response.EnsureSuccessStatusCode();
            string responseBody = await response.Content.ReadAsStringAsync();
            createdWorkItem = JsonConvert.DeserializeObject(responseBody);
          }
        }
        return createdWorkItem;
      }

   8. Publishing der Azure Api App aus Visual Studio

      Um die Azure Api App zu publishen klickt man mit der rechten Maustaste im Solution Explorer auf das Projekt und wählt „Publish“ aus. Über den Button Microsoft Azure App Service kann man sich bei Azure mit seinem Microsoft Account anmelden, und die vorher angelegte Api App wird angezeigt. Dieser wird ausgewählt und der Wizard holt alle wichtigen Daten für das Publishen. Nun können noch die Konfiguration und die Settings eingestellt werden. Nach einem Klick auf „Next“ kann mit dem neu erstellten „Web Publish“-Profil die Api App auf Azure hochgeladen werden.

3. Registrieren der Api App im VSTS Service Hook

   Nach dem Erstellen und Publishen der Api App soll jetzt im dritten Teil die Verbindung zum VSTS Service Hook erstellt werden.

   1. Erstellen des Service Hooks

      Jetzt kann man zum VSTS Dashboard des TeamProjects wechseln.(https://{account}.visualstudio.com/{Collection}/{TeamProject}/_dashboards)Über das Zahnrad in der rechten oberen Ecke, wird zu Administrationsseite navigiert, und dort zum Tab für die Service Hooks. Hier wird ein neuer Service Hook vom Typ „Web Hooks“ erstellt:

   2. Konfiguration des Service Hooks

      Es kann ausgewählt werden welches Event die Api App triggern soll, sowie welche Bedingungen zusätzlich erfüllt sein sollen.Im Beispiel wird für den Trigger „Work item updated“ und für Work Item Type „Product Backlog Item“ gewählt um auf jegliche Änderung eines PBIs zu reagieren. Auf der letzten Konfigurationsseite kann nun die Api App URL mit dem Zusatz „/api/WorkItemChanged“ eingegeben werden. Damit hier die Authentifizierung nicht in Klartext verschickt wird, muss der URL https vorangestellt werden. Zur Authentifizierung geben wir nun den Username und das Passwort, das wir im zweiten Kapitel erstellt haben an. Nach einem optionalen „Test“, ob die Api App angesprochen werden kann, wird die Konfiguration mit „Finish“ beendet. Im Ganzen haben wir jetzt also folgende Prozesskette: Durch das Verschieben eines Product Backlog Items triggert VSTS den konfigurierten ServiceHook. Dieser sendet das WorkItemChanged Event an den Api Controller. Dieser handelt die Informationen ab und der Rest Client schickt die Anfrage für das Erstellen des Workitems an die VSTS Rest Api. Für den abschließenden Test wird auf dem Kanban Board ein Product Backlog Item in die Spalte „Committed“ verschoben. Daraufhin wird ein WorkItemChangedEvent ausgelöst, welches über den Service Hook eine Mitteilung an die Api App schickt. Die Api App legt dann über die REST API von VSTS den Task „Make it Done“ an. So bekommt man den Task, den man im Sprint immer braucht, automatisch angelegt.

4. Troubleshooting

   1. Remote Debugging aus Visual Studio

      Falls man Probleme hat kann man die Api App aus Visual Studio heraus debuggen.https://blogs.msdn.microsoft.com/webdev/2013/11/04/remote-debugging-a-window-azure-web-site-with-visual-studio-2013/

Am Wochende war ich auf der Spartakiade und habe dort einen ganztägigen Workshop mit dem Titel “Ab morgen bitte Scrum” geleitet. Die Spartakiade ist eine Community-Konferenz die ausschließlich aus herausfordernden Workshops besteht – ein interessantes Konzept, das es erlaubt ein Thema auch mal mit entsprechender Tiefe zu bearbeiten.

Mit diesem Post möchte ich ein paar Eindrücke von der Konferenz und aus meinem Workshop berichten.

Die Konferenz

Inzwischen gibt es eine Reihe von sehr professionell organisierten Community-Veranstaltungen und die Spartakiade gehört auf jeden Fall mit in diesen Kreis. Ca. 150 Teilnehmer konnten sich an 2 Tagen in entsprechenden Workshops weiterbilden und untereinander austauschen. Persönlich hat mir das Konzept mit den Workshops sehr gut gefallen, da ich in meinem Workshop, bei dem es um die kulturellen Aspekte von Scrum geht, endlich nicht nur theoretisch bleiben musste wie bei Vorträgen, sondern ich konnte diese Themen für die Teilnehmer “erlebbar machen”.

Was auch auffällt, das Publikum auf Community-Konferenzen ist etwas anders. Dort treffen sie die Leute, denen ein Thema so sehr am Herzen liegt, dass sie sogar ihr Wochenende investieren und vielen bezahlen Reisekosten aus der eigenen Tasche statt sich das vom Arbeitgeber finanzieren zu lassen. Diese Motivation merkt man, auch, wie die Teilnehmer sich im Workshop engagiert haben.

Vielen Dank nochmals an Torsten Weber und Janek Fellien mit ihren Unterstützern dafür, dass sie diesen großartigen Rahmen für den Austausch in der Community geschaffen haben.

Der Workshop

In meinem Workshop ging es vor allem darum, wie die Unternehmenskultur Agilität beflügeln oder ausbremsen kann und wie man zu einer agilen Unternehmenskultur kommen kann.Da es dabei auch darum geht, einfach Dinge mal auszuprobieren und anders zu machen, habe ich die Vorstellungsrunde schon versucht etwas ungewöhnlich zu gestalten.

Vorstellungsrunde

Nach meiner Überzeugung ist ein wichtiger Aspekt der agilen Unternehmenskultur, Dinge einfach auch mal anders zu machen. Deshalb wollte ich eine Alternative zur klassischen Vorstellung bei der sich jeder reihum selbst vorstellt. Ich habe ein anderes Format gewählt, bei dem sich die Teilnehmer sich zu Paaren zusammengefunden haben. Dann gab es eine Timebox von 7,5 Min. in der sich die Paare untereinander kennenlernen konnten. Nach der Timebox hat jeder mit 3 kurzen Fakten bzw. Statements seinen Partner vorgestellt. Es hat zwar nicht perfekt geklappt, dass sich jeder auf 3 Aspekte der Vorstellung fokussiert hat, aber persönlich fand ich diese Form der Vorstellung deutlich besser. Man hat seinen Partner intensiver kennengelernt als in einer üblichen Vorstellungsrunde und bei der Vorstellung war interessant zu sehen, welche Aspekte ausgewählt wurden, um den Partner vorzustellen. Angenehmer Nebeneffekt war, dass die Vorstellungsrunde insgesamt zeitlich sogar kürzer war als beim klassischen Vorgehen.

Mit der Vorstellungsrunde konnte ich auch schon 2 wesentliche agile Werte bzw. Konzepte vermitteln. Timeboxing und Fokussierung. Durch die Timebox muss jeder darauf achten, innerhalb der gegebenen Zeit ein ausreichend gutes Ergebnis zu liefern und z.B. zu verhindern, dass das Kennenlernen bis zum Ende der Timebox nur in eine Richtung erfolgte. Und es ist einfach, in aller Länge viele Details über sich oder jemand anderen zu erzählen. Aber die 3 wesentlichen Kernpunkte auszuwählen und sich auf diese zu fokussieren ist deutlich schwieriger.

Impulsvortrag

Im anschließenden Impulsvortrag wollte ich die Teilnehmer auf das Thema einstimmen. Ich wollte nicht viel vorwegnehmen und auch nicht viel Zeit mit der Einführung vernichten, deshalb habe ich es sehr kurz gehalten. Meine Kernaussagen waren:

• Der Erfolg von Agilität hängt im Wesentlichen von der Kultur im Team und im Unternehmen ab. Die Mechanismen sind trivial.
• Leider wird Agilität oft als Tool installiert in der Annahme, dass sich bereits dadurch entsprechende Erwartungen erfüllen. Dadurch bleibt aber die Bereitschaft für einen echten Wandel auf der Strecke.
• Wir brauchen eine geeignete Wertebasis. Die gelebten Werte durch die beteiligten Personen habe ich als Kultur bezeichnet.
• Über Werte zu diskutieren ist schwierig, da die meistens positiv formuliert sind und eigentlich niemand gegen Werte wie Ehrlichkeit oder Offenheit argumentieren wird.
• Eine Kultur kann nicht verordnet werden. Demzufolge kann der Workshop auch eher Impulse und Denkanstöße liefern, keine “Best Practices”.

Hier die Notizen die ich für den Impulsvortrag genutzt habe:

Erwartungen und Erfolgskriterien festlegen

Danach haben wir in der Gruppe versucht zu definieren, wann der Workshop für die Teilnehmer erfolgreich ist und woran wir das festmachen können. Ich habe die Teilnehmer gebeten, ihre Erwartungen zu formulieren, woran sie am Abend erkennen können, ob sie den Workshop für sich persönlich als Erfolg bewerten. Hier sind die Ergebnisse:

Zudem haben wir begonnen konkrete Fragen und Problemstellungen zu sammeln die wir dann den Tag über in einzelnen Q&A Sessions bearbeiten können. Hier war die Aufforderung, auch den ganzen Tag über neu hinzukommende Fragen entsprechend zu ergänzen.

Wahl des ersten Themas

Damit wir den Workshop möglichst gut auf die Wünsche der Teilnehmer abstimmen konnten, habe ich eine Reihe von Themen vorgestellt, die ich vorbereitet hatte und diese dann zur Wahl gestellt. Die erste Frage lautete: Welches Thema wollt ihr als erstes angehen?

Für das anschließende Voting habe ich eine Anregung genutzt, die ich vor kurzem von meinem Kollegen Cédric bekommen habe. Oft macht man ja Dinge einfach so, weil man sie schon immer so macht, auch wenn man mit dem Vorgehen eigentlich nicht richtig glücklich ist. So ging es mir bisher mit solchen Votings die ich in meinen Workshops und Trainings sehr häufig mache. Das übliche Vorgehen sind Striche zu machen wobei jeder 5te Strich diagonal gezeichnet wird. Das hat aber oft nicht richtig gut funktioniert. Jeder musste darauf achten, wie viele Striche schon da sind und dann daran denken, den 5ten entsprechend diagonal zu zeichnen. Die Auswertung war hinterher auch entsprechend, da man nochmals kontrollieren musste, ob die 5er-Blöcke korrekt gesetzt wurde etc. Ich war nie glücklich mit dem Vorgehen, hab es aber immer wieder verwendet. Nun hat Cédric bei einem Voting eine andere Methode angewendet, die ich viel schöner fand und die habe ich auch gleich in den Workshop übernommen, auch um zu zeigen, dass es gut ist, ausgetretene Wege mal zu verlassen und neues zu probieren.

Das neue Voting funktioniert so, dass auch 5er-Blöcke gebildet werden aber in Form eines Quadrats, wobei die ersten 4 Stimmen die 4 Seiten des Quadrats bilden und die 5te eine Diagonale. Das ist aber viel klarer als bei den Strichen. Hier das Ergebnis des ersten Votings:

Das Ergebnis des Votings war dann folgendes:

Geschichten aus dem Alltag eines Scrum-Coaches

Als erstes haben sich die Teilnehmer für eine Gruppendiskussion entschieden. Ich habe verschiedene Situationen die ich beobachtet habe, beschrieben. Anschließend haben wir gemeinsam diskutiert, ob wir die Situation positiv oder negativ bewerten, warum das so ist, welche Auswirkungen diese Situation haben kann und was alternative Möglichkeiten gewesen wären.

Ich fand es sehr positiv, dass bereits in der ersten Runde eine ausgiebige Diskussion entstand und die Teilnehmer begonnen haben, über die offensichtliche Bewertung der Situation hinaus zu denken. Bei dieser Übung kam sehr gut heraus, dass es sich lohnt, nicht seinem ersten Impuls zu folgen, sondern etwas genauer hinzuschauen. So kann es beispielsweise hilfreich sein, sich in die jeweils handelnden Personen zu versetzen und sich zu überlegen, wie man selbst sich fühlen würde. Oder man muss versuchen, sich auf den Kern einer Sache zu fokussieren und sich nicht auf unnütze Nebendiskussionen einlassen. Dazu gehören beispielsweise Rechtfertigungen des Teams, wenn der Product Owner im Sprint Review die erstellte Lösung kritisiert und Änderungen haben möchte.Eine der beschriebenen Situationen sollte auch deutlich machen, dass es nicht genügt, Scrum einmal erfolgreich angewendet zu haben. Man muss kontinuierlich daran arbeiten, sonst fällt das Team schnell wieder in alte Muster zurück. Eine andere Situation zeigte, dass es wichtig ist, offen für Neues zu sein und Dinge nicht einfach abzulehnen, weil man nicht überzeugt davon ist. In einigen Situationen ist es besser, sich auf das Neue zunächst einmal einzulassen und die gewonnenen Erfahrungen dann auszuwerten um auf dieser Bassi dann zu entscheiden.

Wir konnten in der angestrebten Timebox nur 4 der 16 von mir vorbereiteten Situationen besprechen, aber die Diskussionen waren sehr fruchtbar und haben sehr gut aufgezeigt, warum die kulturellen Aspekte viel wichtiger sind, als die reinen Mechanismen von Scrum.

Team Values Game

In der nächsten Runde ging es dann in das Team Values Game. Ich werde das Spiel noch ausführlicher in einem separaten Post beschreiben. Deshalb hier kurz beschrieben, wie es in unserem Workshop abgelaufen ist. Bei diesem Spiel hatte ich 2 Beobachter. Die restlichen Teilnehmer bekamen einer Reihe von Zetteln auf denen verschiedene Aussagen standen.

Die Teilnehmer mussten diese nun in eine Reihenfolge bringen, die die persönliche Wichtigkeit ausdrückt. In der zweiten Runde war dann das Ziel, seine eigene Liste mit der von anderen Teilnehmern zusammenführen zu können. Dazu wurden die Unterschiede diskutiert und warum einem bestimmte Themen wichtig waren oder eben nicht. Ziel war, innerhalb der Gruppe möglichst wenige Listen zu haben zu denen aber alle auch wirklich stehen.

Dieses Spiel zeigt sehr gut auf, wie schwierig es ist, über Werte zu diskutieren. Das Verständnis bzw. die Interpretation der einzelnen Punkte können sehr voneinander abweichen. Dabei spielt der persönlicher Erfahrungshintergrund und die eigene aktuelle Situation eine wichtige Rolle. Diese unterschiedlichen Interpretationen sichtbar zu machen kann aber sehr wertvoll sein. Man beginnt auf einmal zu verstehen, warum jemand in bestimmten Situationen unerwartet reagiert oder sich jemand nicht verhält wie erwartet. Zudem beginnt man für sich ein Bewusstsein zu entwickeln, welche Werte einem wirklich wichtig sind und bei welchen man Kompromisse eingehen kann. Letztendlich stand die Frage im Raum, ob es erstrebenswert ist, sich in einem Team tatsächlich auf eine Liste zu einigen. In der Gruppe war die Meinung, dass das nicht sinnvoll ist, um auch eine bestimmte Meinungsvielfalt zu erlauben. Aber wir brauchen eine gemeinsame Basis und vor allem ein Verständnis, wo unsere Wertesysteme im Team abweichen.

Agile Product Management Game

Als nächstes stand dann das Agile Product Management Game oder Business Value Game auf dem Programm. Dabei handelt es sich um ein interessantes Spiel das leider etwas zeitaufwändiger ist (min. 90 Min.). Dabei geht es darum transparent zu machen, wie ein Product Owner bestimmte Entscheidungen für die Entwicklung eines Teams treffen muss / kann. Warum dieses Spiel aber nun bei einem Workshop zum Thema Kultur? Zunächst einmal war das Feedback der Teilnehmer, dass das Spiel sehr gut verdeutlicht hat, wie komplex solche Entscheidungsprozesse oftmals sind und dass der Entwickler ja nur eine sehr eingeschränkte Sicht darauf hat. Mit einem besseren Verständnis für die Einflussfaktoren werden viele Entscheidungen nachvollziehbar. Die Teilnehmer berichteten von Situationen bei denen sie in der Rolle als Entwickler tatsächlich schon hin und wieder Entscheidungen nicht nachvollziehen konnten und diese umgesetzt haben, obwohl sie nicht überzeugt davon waren, das richtige zu tun – eine Situation die wir im agilen Kontext unbedingt vermeiden möchten. Daraus entspannte sich dann eine Diskussion über Transparenz und vor allem darum wie viel Transparenz möglich / sinnvoll ist. In der Gruppe war der Status Quo hier auch sehr unterschiedlich. Während in einem Unternehmen die finanziellen Aspekte eines Kundenauftrages und die Kostensituation voll transparent gemacht werden, will man sich bei anderen eher nicht so tief in die Karten schauen lassen. Wir waren uns einig, dass diese Art der Transparenz sich entwickeln muss, sonst ist das Risiko eines Missbrauchs zu hoch. Ein wichtiger weiterer Aspekt war die Erkenntnis, dass es wichtig ist, dass alle im Team sich auf das eigentliche Ziel fokussieren, nämlich den Nutzen für den Kunden zu maximieren. Dieser Fokus gerät manchmal etwas aus dem Blick, wenn sich Entwickler ausschließlich auf die Umsetzung der Anforderungen konzentrieren. Hier ist wichtig, dass sich alle im Team entsprechend abstimmen und auch immer wieder hinterfragen, ob einzelne Punkte wirklich zielführend bzw. relevant für die Zielerreichung sind.

Ball Point Game

Zum Abschluss hat sich die Gruppe dann noch das Ball Point Game gewünscht. Dabei wird gezeigt, wie wichtig es ist, durch regelmäßige Retrospektiven seine aktuelle Vorgehensweise zu hinterfragen und zu optimieren. Im Spiel geht es darum, möglichst viele Bälle einmal durch das Team zu reichen. In der Realität zeigt das die Wichtigkeit und die Wirksamkeit von Retrospektiven. Retrospektiven werden von Teams oft als lästig und unbequem empfunden und am Ende ändert sich doch nichts. Das Spiel zeigt, dass das Team selbst in der Retrospektive Verantwortung für diese Veränderungen übernehmen muss.

Feedbackrunde

Zum Abschluss haben wir nochmals auf unsere Erfolgskriterien geschaut und die Teilnehmer haben kommentiert, was sie aus dem Workshop mitgenommen haben. Ich habe dann noch gebeten, die Einschätzung zum Workshop über einen Smiley und einem kurzen Satz zu geben. Hier das Feedback das mich sehr gefreut hat

Zusätzlich haben die Teilnehmer noch abgestimmt, welcher Teil des Workshops ihnen am besten gefallen hat. Hier das Ergebnis:

1. Impulsvortrag – 1

2. Vorstellungsrunde – 8

3. Aus dem Leben eines Scrum Coaches – 4

4. Team Values Game – 9

5. Agile Product Mgmt. Game – 1

6. Ball Point Game – 3

Überrascht hat mich dabei, dass die Vorstellungsrunde 8 Stimmen bekommen hat. Ich hoffe, dass die anderen Themen nicht zu langweilig waren und nehme das jetzt mal als die positivste Vorstellungsrunde die ich je gemacht habe Im persöänlichen Gespräch habe ich dann im Anschluss noch sehr viel positives Feedback der Teilnehmer bekommen.

Von meiner Seite aus auch nochmal ein dickes Dankeschön an meine Workshop-Teilnehmer. Ihr wart spitze!

Fazit

Die Spartakiade hat Spaß gemacht und es war ein Workshop bei dem ich auch als Trainer wieder sehr viel mitnehmen konnte. Ich mag das Format und die Leute.

Community rocks!

Blogserie

• Teil 1: Pakete verwenden
• Teil 2: Pakete erstellen
• Teil 3: Pakete verteilen
• Teil 4: Pakete debuggen (dieser Artikel)

Lokal erstellte Pakete debuggen

Debugging von Paketen aus dem Team Build

Die Zwei-Repository-Lösung

1. Wir haben die Consumer-Solution geöffnet. Diese benutzt bereits unser Package aus dem zentralen Repository in der Version 26.1.31.6. Das lokale Repository ist leer.
2. Wir analysieren einen Bug und stellen fest, dass dieser in unserem Package liegen muss. Wir öffnen nun in einer zweiten Visual Studio Instanz die Package Solution und passen den Code entsprechend an.
3. Ein lokaler Build in Visual Studio erzeugt nun das Package. Mit der zuvor beschriebenen Versionierungs-Methodik ergibt sich ein Package mit der Version 999.99.99.99. Wir kopieren das Symbol-Package in unser lokales Repository. Dieser Vorgang haben wir ja bereits durch unseren Post Build Event automatisiert.
4. Durch ein einfaches Update wird das Package in der Consumer-Solution nun auf diese Version aktualisiert und wir können unsere Anpassungen einfach testen und debuggen.
5. Nachdem wir die Änderungen geprüft und eingecheckt haben, starten wir einen TFS-Build. Erzeugt nun ein Package mit der nächst höheren Version, welches wir in unser zentrales Repository kopieren.

Fazit