<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Agile | Sparring Space GmbH</title>
	<atom:link href="https://sparringspace.de/category/agile/feed/" rel="self" type="application/rss+xml" />
	<link>https://sparringspace.de</link>
	<description></description>
	<lastBuildDate>Wed, 31 Jan 2024 08:10:50 +0000</lastBuildDate>
	<language>de</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.1</generator>

<image>
	<url>https://sparringspace.de/wp-content/uploads/2022/02/cropped-Logo_Symbol_Hoch_Sparring_Space-32x32.png</url>
	<title>Agile | Sparring Space GmbH</title>
	<link>https://sparringspace.de</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Kontrolle ist besser als Vertrauen (auf die Selbstregulation eines komplexen Systems)?</title>
		<link>https://sparringspace.de/agile/kontrolle-ist-besser-als-vertrauen-auf-die-selbstregulation-eines-komplexen-systems/</link>
		
		<dc:creator><![CDATA[Patrick]]></dc:creator>
		<pubDate>Mon, 29 Jan 2024 15:15:38 +0000</pubDate>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[Coaching]]></category>
		<category><![CDATA[Scrum]]></category>
		<guid isPermaLink="false">https://sparringspace.de/?p=684</guid>

					<description><![CDATA[]]></description>
										<content:encoded><![CDATA[<div class="et_pb_section et_pb_section_0 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_0">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_0  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_0  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>Ein Kamingespräch mit ChatGPT zu dieser Antithese: Kontrolle ist besser als Vertrauen (auf die Selbstregulation eines komplexen Systems)?</p>
<p>Ich hatte weder Zigarren noch einen Kamin zur Hand, dennoch fühlte sich das Gespräch wie ein Kamingespräch an. Mich beschäftigte der o.g. Glaubenssatz, den ich bei der Arbeit in Unternehmen häufig beobachte, insbesondere im Management. Was ist dabei Kontrolle überhaupt? Wie wirkt diese sich aus?</p>
<p>Vorweg, ich glaube an Selbstregulation mit Leitplanken, Sinnausrichtung und Zielsetzungen, die laufend neu ausgehandelt werden.</p>
<p>Jetzt zurück zum Kamingespräch.</p>
<p><strong>Ich</strong>: Wie würdest du als Führungskraft diese These einordnen: Kontrolle ist besser als Vertrauen (auf die Selbstregulation eines komplexen Systems)?</p>
<p><strong>ChatGPT</strong>: Als Führungskraft würde ich diese These kritisch betrachten. Während Kontrolle in einigen Situationen wichtig sein kann, um bestimmte Ziele zu erreichen oder Risiken zu minimieren, ist Vertrauen oft entscheidend für die Motivation, das Engagement und die Kreativität der Teammitglieder. Ein ausgewogenes Verhältnis zwischen Kontrolle und Vertrauen ist oft am effektivsten, insbesondere in komplexen Systemen, in denen Flexibilität und Anpassungsfähigkeit erforderlich sind.</p>
<p><strong>Ich</strong>: Und wenn es kritisch wird?</p>
<p><strong>ChatGPT</strong>: Wenn die Situation kritisch wird, kann es notwendig sein, die Kontrolle zu erhöhen, um Risiken zu minimieren oder Fehler zu korrigieren. In solchen Fällen ist es wichtig, klar zu kommunizieren und transparent zu sein, warum die zusätzliche Kontrolle erforderlich ist, und gleichzeitig das Vertrauen der Teammitglieder aufrechtzuerhalten, indem sie in den Entscheidungsprozess einbezogen werden, wo immer dies möglich ist. Es ist wichtig, dass die erhöhte Kontrolle nicht zu einem dauerhaften Zustand wird, sondern als temporäre Maßnahme betrachtet wird, um die Situation zu stabilisieren, bis eine nachhaltigere Lösung gefunden werden kann.</p>
<p><strong>Ich</strong>: Gilt das auch in der Softwareentwicklung?</p>
<p><strong>ChatGPT</strong>: Ja, das gilt auch in der Softwareentwicklung. In diesem Bereich ist Vertrauen besonders wichtig, da kreative Problemlösung, Innovation und Zusammenarbeit oft entscheidend sind. Ein zu starker Fokus auf Kontrolle kann die Kreativität und das Engagement der Entwickler beeinträchtigen und letztendlich die Qualität und Effizienz der Entwicklung negativ beeinflussen. Allerdings können in kritischen Phasen des Projekts oder bei der Einhaltung von strengen Sicherheitsstandards zusätzliche Kontrollmechanismen erforderlich sein, um Risiken zu minimieren. Dennoch ist es wichtig, auch in der Softwareentwicklung ein Gleichgewicht zwischen Kontrolle und Vertrauen zu finden, um erfolgreiche Ergebnisse zu erzielen.</p>
<p><strong>Ich</strong>: Ich glaube an Selbstregulation mit Leitplanken, Sinnausrichtung und Zielsetzungen, die laufend neu ausgehandelt werden. In kritischen Situationen werden ggf. kurzfristigere Anpassungen der Zielsetzungen anhand neuer Erkenntnisse notwendig.</p>
<p><strong>ChatGPT</strong>: Das klingt nach einem ausgewogenen und flexiblen Ansatz, der die Selbstregulation und Eigenverantwortung der Teammitglieder fördert, während gleichzeitig klare Leitplanken, Sinnausrichtungen und Zielsetzungen vorhanden sind. Durch die laufende Neuverhandlung der Ziele und Anpassung an neue Erkenntnisse können Sie sicherstellen, dass das Team agil und anpassungsfähig bleibt, insbesondere in kritischen Situationen. Dieser Ansatz ermöglicht es Ihrem Team, auf Veränderungen schnell zu reagieren und weiterhin effektiv und zielgerichtet zu arbeiten.</p>
<p>Meine Gedanken danach:<span class="Apple-converted-space"> </span></p>
<ul>
<li><span></span>Ich mag den Ansatz der Balance zwischen Kontrolle und Vertrauen, den ich bei ChatGPT rausgelesen habe: letztlich sind Zielsetzungen und das regelmäßige Überprüfen und Anpassen dieser ebenfalls eine Art von transparenter Kontrolle.</li>
<li>Überprüfen und Anpassen ist für mich also ein transparentes Kontrollinstrument welches in Scrum Teams bei der Retrospektive, im Review oder auch beim Testen auf allen Ebenen auftaucht.</li>
<li><span></span>Ich würde in kritischen, komplexen Situationen nicht dem Impuls folgen, kurzfristig Kontrollmechanismen einzuführen oder per se zu erhöhen, um Fehler bzw. Scheitern (vorab) zu korrigieren. Eher ist mein Ansatz die Frequenz des Überprüfens und Anpassens erhöhen, damit aus Fehlern schneller gelernt werden kann. Ggf. fehlen auch Feedback-Schleifen komplett, die eingeführt werden sollten. Mein Augenmerk liegt hier klar auf wiederkehrenden Mechanismen, die Daten liefern anhand derer ein sinnvolles Überprüfen und Anpassen möglich ist. Ein Beispiel: Ein integrativer Test durch Anwender wurde noch nicht durchgeführt? Dann wissen wir noch nicht, ob Anwender sinnvoll mit der neuen Lösung bzw. dem neuen Feature arbeiten können.</li>
<li><span style="font-size: 16px;">Vertrauen ist für mich als Basis für Transparenz nötig, damit Menschen Scheitern teilen können und gemeinsam daraus lernen können &#8211; auch außerhalb des Teams mit Stakeholdern, Managern und anderen Teams bei Abhängigkeiten. Ein selbst reguliertes System (Team, Organisation) ist für mich ohne Vertrauen kaum vorstellbar.</span></li>
<li><span></span>Misstrauen fördert vermehrtes Auftreten toxischer Verhaltensweisen wie Schuldzuweisungen, Abwehrverhalten und Mauern, die speziell unter Druck auftreten.</li>
</ul></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Scrum Master im Urlaub: was passiert mit der Sprint Retrospektive?</title>
		<link>https://sparringspace.de/agile/scrum-master-im-urlaub-was-passiert-mit-der-sprint-retrospektive/</link>
		
		<dc:creator><![CDATA[Patrick]]></dc:creator>
		<pubDate>Sat, 02 Sep 2023 13:39:42 +0000</pubDate>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[Scrum]]></category>
		<guid isPermaLink="false">https://sparringspace.de/?p=673</guid>

					<description><![CDATA[]]></description>
										<content:encoded><![CDATA[
<div class="et_pb_section et_pb_section_1 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_1">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_1  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_1  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h2 class="wp-block-heading">Innerer Dialog eines Scrum Masters: Dogmatiker und Pragmatiker im Diskurs, Teil 2</h2>
<p>&nbsp;</p>
<p>Diese Frage kam nach meinem letzten Beitrag auf und wurde auch in den Agile Coach und Scrum Master Communities in meinen Projektkontexten diskutiert.</p>
<p>In zwei unterschiedlichen Kontexten arbeite ich gerade mit Teams und moderiere regelmässig die Retrospektiven.</p>
<p>In einen Fall haben wir eine große Scrum Master / Agile Coach Community und auch zuvor schon häufig auf wechselnde Facilitation gesetzt. Hier übernimmt jemand aus der Community wie auch zuvor bereits.</p>
<p>Im anderen Fall arbeite ich recht eng mit dem Team zusammen und wir haben bisher keine Vertretungskultur für die Facilitation der Events unter den Scrum Mastern. Da dieses Team erfahren ist und schon länger zusammenarbeitet, habe ich mit dem Team gemeinsam beschlossen, die Retrospektive sowie die anderen Events erstmals in Selbstorganisation durchzuführen. Hier bin ich sehr gespannt auf die Ergebnisse nach meiner Rückkehr.</p>
<p>In Anlehnung an den ersten Teil habe ich wieder ChatGPT nach dem inneren Dialog gefragt. Ich würde es in einigen Teilen anders formulieren, aber der Tenor ist meiner Meinung nach ein spannender Impuls / Startpunkt für eigene Überlegungen.</p>
<div class="group w-full text-token-text-primary border-b border-black/10 dark:border-gray-900/50 bg-gray-50 dark:bg-&#091;#444654&#093;">
<div class="flex p-4 gap-4 text-base md:gap-6 md:max-w-2xl lg:max-w-&#091;38rem&#093; xl:max-w-3xl md:py-6 lg:px-0 m-auto">
<div class="relative flex w-&#091;calc(100%-50px)&#093; flex-col gap-1 md:gap-3 lg:w-&#091;calc(100%-115px)&#093;">
<div class="flex flex-grow flex-col gap-3">
<div class="min-h-&#091;20px&#093; flex flex-col items-start gap-3 overflow-x-auto whitespace-pre-wrap break-words">
<div class="markdown prose w-full break-words dark:prose-invert light">
<p><strong>Dogmatiker:</strong> Oh nein, der Scrum Master geht in den Urlaub, und die nächste Retrospektive steht an! Das Scrum-Framework ist ganz klar: Die Retrospektive ist eine der wichtigsten Zeremonien. Sie darf auf keinen Fall ausfallen. Wir sollten eine Interims-Srum-Masterin oder einen Interims-Scrum-Master ernennen und sicherstellen, dass die Retrospektive wie geplant stattfindet.</p>
<p><strong>Pragmatiker:</strong> Ich verstehe deine Sorgen, aber wir müssen realistisch sein. Es ist großartig, dass die Retrospektive so geschätzt wird, aber der Scrum Master hat auch ein Recht auf Urlaub. Die Teams sind in der Regel selbstorganisiert, also sollten sie in der Lage sein, ohne den Scrum Master eine Retrospektive durchzuführen.</p>
<p><strong>Dogmatiker:</strong> Ja, aber der Scrum Master spielt eine entscheidende Rolle bei der Leitung der Retrospektive und bei der Gewährleistung, dass sie effektiv ist. Wenn wir die Retrospektive ohne den Scrum Master durchführen, könnte sie ineffizient oder oberflächlich sein.</p>
<p><strong>Pragmatiker:</strong> Du hast recht, der Scrum Master spielt eine wichtige Rolle, aber das bedeutet nicht, dass die Retrospektive zwangsläufig scheitert, wenn er fehlt. Wir könnten das Team ermutigen, die Moderation der Retrospektive selbst zu übernehmen oder einen erfahrenen Teammitgliedern bitten, vorübergehend die Rolle des Scrum Masters zu übernehmen.</p>
<p><strong>Dogmatiker:</strong> Das klingt zwar vernünftig, aber es besteht immer noch die Gefahr, dass die Retrospektive nicht so effektiv ist wie sonst. Außerdem können wichtige Themen und Verbesserungsmöglichkeiten übersehen werden.</p>
<p><strong>Pragmatiker:</strong> Das ist wahr, aber wir könnten auch die Retrospektive verschieben, wenn der Scrum Master wieder zurück ist. So stellen wir sicher, dass wir genug Zeit haben, um sie ordnungsgemäß vorzubereiten und sicherzustellen, dass sie effektiv ist.</p>
<p><strong>Dogmatiker:</strong> Ich bin immer noch besorgt, dass wir die Prinzipien des Scrum-Frameworks vernachlässigen, wenn wir die Retrospektive verschieben oder ausfallen lassen.</p>
<p><strong>Pragmatiker:</strong> Ich verstehe deine Bedenken, aber es geht darum, die Balance zwischen den Prinzipien des Frameworks und der Realität zu finden. Der Urlaub des Scrum Masters ist eine unvorhergesehene Situation, die wir berücksichtigen müssen. Wichtig ist, dass wir sicherstellen, dass das Team weiterhin die Möglichkeit hat, zu lernen und sich zu verbessern, auch wenn die Retrospektive einmal ausfällt oder verschoben wird.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<!-- /divi:paragraph --></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Keine Sprint Retrospektive wegen Urlaub von vielen Teammitgliedern?</title>
		<link>https://sparringspace.de/agile/keine-scrum-retrospektive-wegen-urlaub/</link>
		
		<dc:creator><![CDATA[Patrick]]></dc:creator>
		<pubDate>Mon, 21 Aug 2023 12:03:49 +0000</pubDate>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[Scrum]]></category>
		<guid isPermaLink="false">https://sparringspace.de/?p=659</guid>

					<description><![CDATA[]]></description>
										<content:encoded><![CDATA[

<div class="et_pb_section et_pb_section_2 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_2">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_2  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_2  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><h2 class="wp-block-heading">Innerer Dialog eines Scrum Masters: Dogmatiker und Pragmatiker im Diskurs</h2>
<p>&nbsp;</p>
<p>Das Beispiel passt sicher für viele Scrum Master in die aktuelle Urlaubszeit und beruht auf einer wahren Begebenheit mit einem meiner Teams.</p>
<p>Ist es also ok eine Retrospektive ausfallen zu lassen, wenn viele Teammitglieder im Urlaub sind? Ich war neugierig, wie ChaptGPT einen solchen Diskurs führen würde und war ehrlicherweise positiv überrascht. Einige Statements waren in meinem inneren Dialog ziemlich ähnlich (insbesondere der zweite Dogmatiker). Lest selbst:</p>
<p><b>Dogmatiker:</b> Die Retrospektive ist ein festes Event im Scrum-Prozess und sollte niemals ausfallen! Sie ist ein grundlegender Bestandteil, um kontinuierliche Verbesserungen zu ermöglichen. Urlaub hin oder her, das Team muss die Verantwortung für sein eigenes Wachstum übernehmen. Wenn wir die Retrospektive ausfallen lassen, verzichten wir auf wertvolle Gelegenheiten zur Reflexion und zur Identifizierung von Problemen. Das ist ein klarer Verstoß gegen die Prinzipien von Scrum!</p>
<p><b>Pragmatiker:</b> Ich verstehe deinen Standpunkt, aber manchmal müssen wir flexibel sein. In agilen Ansätzen geht es darum, sich den aktuellen Umständen anzupassen. Wenn viele Teammitglieder im Urlaub sind, könnten wir die Retro vielleicht auf einen späteren Zeitpunkt verschieben, wenn alle wieder da sind. Das Ziel ist schließlich, kontinuierlich zu lernen und zu verbessern, und das können wir auch in einer verspäteten Retrospektive tun. Es geht darum, den Geist von Scrum aufrechtzuerhalten, selbst wenn wir manchmal von den festen Regeln abweichen müssen.<b></b></p>
<p><b>Dogmatiker:</b> Aber das öffnet die Tür zu weiteren Ausnahmen und schadet langfristig dem Scrum-Prozess. Wenn wir einmal anfangen, Events ausfallen zu lassen, verlieren wir schnell die Disziplin und die Vorteile, die Scrum mit sich bringt. Die Teams könnten anfangen, das als Entschuldigung zu verwenden, um anderen Verpflichtungen nachzugehen, anstatt sich auf die kontinuierliche Verbesserung zu konzentrieren.<b></b></p>
<p><b>Pragmatiker:</b> Ich stimme zu, dass wir nicht in die Gewohnheit verfallen sollten, Events einfach ausfallen zu lassen. Aber wir sollten auch realistisch sein. Wenn wir eine Retro in einer Zeit abhalten, in der viele nicht anwesend sind, könnten wir uns nur oberflächlich mit den Problemen befassen. Vielleicht könnten wir eine abgespeckte Version oder ein alternatives Format in Erwägung ziehen, um dennoch einige Erkenntnisse zu gewinnen, ohne die Prinzipien von Scrum vollständig zu opfern.<b></b></p>
<p><b>Dogmatiker:</b> Ich bin immer noch besorgt über den Präzedenzfall, den wir damit schaffen könnten. Aber ich verstehe deinen Ansatz. Wenn wir sicherstellen können, dass die retrospektive Reflexion auf irgendeine Weise stattfindet, ohne den eigentlichen Rhythmus zu unterbrechen, dann könnte das eine akzeptable Lösung sein. Wir müssen jedoch sicherstellen, dass dies eine Ausnahme bleibt und nicht zur Regel wird.</p>
<p>In meinem Fall haben wir mit dem Team im Daily kurz zum Wert einer Retrospektive mit nur sehr wenigen Teilnehmern reflektiert und dann gemeinsam beschlossen, diese ausnahmsweise ausfallen zu lassen.</p>
<figure class="wp-block-image size-large"></figure>
<p>&nbsp;</p>
<p>&nbsp;</p>
<!-- /divi:paragraph --></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Was ich für Scrum und Agile Coaching oder Training aus meinem Hobby mitnehme</title>
		<link>https://sparringspace.de/agile/was-ich-fuer-scrum-und-agile-coaching-oder-training-aus-meinem-hobby-mitnehme/</link>
		
		<dc:creator><![CDATA[Patrick]]></dc:creator>
		<pubDate>Sat, 19 Aug 2023 13:42:58 +0000</pubDate>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[Scrum]]></category>
		<guid isPermaLink="false">https://sparringspace.de/?p=633</guid>

					<description><![CDATA[]]></description>
										<content:encoded><![CDATA[<p><div class="et_pb_section et_pb_section_3 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_3">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_3  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_3  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p><!--</p>




<h2 class="wp-block-heading"></h2>




<h2 class="wp-block-heading"></h2>




<h2 class="wp-block-heading">Fictional story: A transformational twist in delivering software</h2>




<p>&nbsp;</p>




<p>--></p>
<p><span>&#8222;Kampfsportler? Und noch Krav Maga Trainer? Müssen wir uns jetzt in Acht nehmen? Vorsicht, nix Falsches mehr sagen&#8230;&#8220; </span></p>
<p><span>Solche Kommentare beim Erwähnen meines Hobbies haben dazu geführt, dass ich es am liebsten bei Arbeitseinsätzen als Scrum Master, Agile Coach oder Trainer erstmal verschweige. </span></p>
<p><span>Aber im Ernst: Kampfsport Training ist für mich ein perfekter Ausgleich zum &#8222;Bürojob” &#8211; Kopf ausschalten und auspowern. Und seit 6 Jahren unterrichte ich nebenher wöchentlich Krav Maga / Selbstverteidigung.</span></p>
<p><span>Hier sind fünf Dinge, die ich als Krav Maga Trainer gelernt habe und auch für Agile oder Scrum Trainingsimpulse und als Moderator so einsetze:</span></p>
<p><span>🥊 Sei klar in deinen Anweisungen zu einer Übung. Was ist das Ziel der Übung? Trotzdem sollte genug Raum zum Ausprobieren da sein.</span></p>
<p><span>🥊 Selbst üben und erfahren geht vor erklärt bekommen &#8211; der auditive Kanal ist nur einer, um unterschiedlichen Lernarten wie auditiv, visuell, motorisch, kognitiv-intellektuell und kommunikativ anzusprechen. Menschen springen meiner Erfahrung nach auf unterschiedliche Arten besser oder schlechter an, daher biete ich Inhalte auf möglichst vielen Kanälen an.</span></p>
<p><span>🥊 Gemeinsames Reflektieren über die Erfahrungen einer Übung hat oft großen Wert: Teilnehmer lernen voneinander.</span></p>
<p><span>🥊 Erfahrenere Teilnehmer erklären eine bereits bekannte Technik &#8211; dabei fallen fehlende Details oder Unklarheiten auf, bzw. das Gelernte wird mit einer höheren Wahrscheinlichkeit behalten.</span></p>
<p><span>🥊 Stärken und Fortschritte sichtbar machen, anerkennen und wertschätzen.</span></p>
<p>Jedes Hobby bittet sicherlich eine Menge Potential Dinge für den eigenen Beruf zu übertragen, bestimmt auch deine.  </p>
<figure class="wp-block-image size-large"></figure>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p><!-- /divi:paragraph --></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div></p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Agile Transformation for Cloud Software Development: a fictional story</title>
		<link>https://sparringspace.de/agile/fictional-story-a-transformational-twist-in-delivering-software/</link>
		
		<dc:creator><![CDATA[Patrick]]></dc:creator>
		<pubDate>Sat, 19 Aug 2023 13:01:06 +0000</pubDate>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[Scrum]]></category>
		<guid isPermaLink="false">https://sparringspace.de/?p=616</guid>

					<description><![CDATA[]]></description>
										<content:encoded><![CDATA[


<div class="et_pb_section et_pb_section_4 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_4">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_4  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_4  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><!--<h2 class="wp-block-heading"></h2>
<h2 class="wp-block-heading"></h2>
<h2 class="wp-block-heading">Fictional story: A transformational twist in delivering software</h2>
<p>&nbsp;</p>-->
<p>Three managers Monica, James and Tom from different companies meet each other during a community event for managers in Switzerland. Leadership in agile software development especially in Cloud environments has been the main topic. They just have worked together during a group reflection exercise and continue to chat during their break while getting some coffee.</p>
<p>Tom: ‘Great discussion, thanks for that. I really enjoy getting out of the rabbit hole after the pandemic lockdown to see people face-to-face again.’</p>
<!-- /divi:heading -->
<p>Tom co-founded a cloud software company that has grown to a mid-sized company in the last years. He lives in Sacramento and wonders about exciting sights to visit for the weekend, asking for good hiking spots.</p>
<p>Monica is head of a department in a large company developing software products. In her free time, she enjoys sports in nature.</p>
<p>She suggests to Tom: ‘You might enjoy nature while hiking on the mountains here.’</p>
<p>James lives in London and shared earlier that he is a soccer fan. He smiles: ‘Oh yeah, great hikes here… by the way, did you follow the European soccer championship? Although I don’t know any individual player from that team of Switzerland, they really rocked in the final rounds, even defeating the world champions from France. Such an amazing team spirit and success…’</p>
<p>With some bitterness in his voice he continued: ‘I wish I could see this kind of energy and enthusiasm at work…’ His phone rings and he hurries to answer it: ‘Excuse me, I have to answer that call from my colleague.’</p>
<p>She nods thoughtfully and turns to Tom: ‘I enjoyed some of the matches, although I’m usually not following soccer matches, just the international ones. And I agree, I’m following those because of the great spirit and atmosphere.<br />The mission and main goal really seems very clear to soccer teams, not so easy in my department at my huge international software company. I feel, everyone follows individual goals, stuck somewhere between old KPIs and new OKRs that were introduced. Our management team is busy with a lot of different initiatives to follow up.<br />And there is high pressure for every release because senior management made commitments for features to important customers and stakeholders, or we just can’t get it delivered completely due to dependencies to other teams&#8230; planning just feels overly complex, annoying and energy-sapping.’</p>
<p>Her eyes seem to focus something far away. She frowns and continues: ‘I mean ‘cloud software’ implies some lightness that I miss. Also, I observe frustration and heaviness building up within the organization.<br />In the end, it always works somehow, but I feel that it could be improved.’</p>
<figure class="wp-block-image size-large"><img decoding="async" src="https://sparringspace.de/wp-content/uploads/2023/08/the-jopwell-collection-OG7Naof18w4-unsplash.jpg" alt="" class="wp-image-455" /></figure>
<p>Tom embodied her situation and wants to try a technique that he just observed during the previous session of today’s event: ‘I can totally feel your situation, sounds familiar to me &#8211; we struggled a year ago with our agile transformation journey in a cloud software environment. Let’s try that method that we just learned, Monica. Are you in?’</p>
<p>Monica nods.</p>
<p>Tom: ‘Where should your department be in one year according to the situation you just shared?’</p>
<p>Monica seems not convinced and shoots back: ‘Good question, I’m not sure… can’t you just share what your organization did to improve?’</p>
<p>Tom shakes his head: ‘I think that’s not how it works. I don’t believe in one solution fits all or owning a silver-bullet solution, let’s just explore your situation a bit further if you like.’</p>
<p>Monica answers pondering: ‘Improvement areas that I can think of might be around quality time, due to the pandemic situation we missed opportunities to meet in person, afterwards returning to office happened scarcely… probably clarifying and focusing on a clear common mission and goals for our department… the way we do release our software in versions every three to six months… and how it creates pressure on our teams if senior management commits features to important customers or stakeholders… how we get and incorporate feedback from users’</p>
<p>Tom: ‘That’s a lot already, let’s pick one aspect and focus on that one for now.’</p>
<p>She smiles a bit sarcastically and states: ‘Ok, I’ll play along. Let’s say the goal is: We abandon the release-based delivery! How do we now move on from here?’</p>
<p>Tom calmly responds: ‘Great. Now please imagine your department one year later. You abandoned delivering in releases. How does that look like?’</p>
<p>Monica reflects a while and explains: ‘No more pressure every quarter. No long, energy-sapping meetings to plan the next release and trying to allocate scarce resources to make everyone happy… we are developing and delivering in a continuous and sustainable pace, features are delivered whenever they are done. Our customers will consume product features as an offer at their pace. No more blaming for failures due to pressure, we have space to learn from them.’</p>
<p>She stops and Tom asks after a while of silence: ‘Wow! Great achievement. How did you reach that? What were important insights and steps?’</p>
<p>Monica frowns: ‘That question is nasty… ok, let me think… first step: we arranged a return-to-office-face-to-face event with our management team. It had been a long time without spending time together.’</p>
<p>She continues: ‘We learned that we forgot to strengthen our relationship as management team during Covid time, so we agreed on regular events to meet in person. During one of the events, we realized that we lacked a commonly focused direction or mission that our goals are matching to. There were so many initiatives and individual goals to follow that we needed to focus as a team. This was a bit of a struggle.</p>
<p>But after finding our focus, we even managed to free space for management and teams to adapt to this new way of working. Due to more available space the teams figured out that using Design Thinking practices led to learning faster if they are building the right features.</p>
<p>Improvements impacted our whole Product Engineering Lifecycle. Our goal setting was starting with our longer termed visions and missions, linked to product goals, and matching to sprint goals for the Scrum teams to create a proper focus. OKR are reintroduced just for the most important strategic initiatives and connected to the goal setting of the products where applicable.’</p>
<p>Monica pauses a moment, smiles, and adds: ‘And finally, I referred to James’ soccer match example of Switzerland vs France &#8211; a bunch of great, high potential individuals in a group doesn’t necessarily form an outstanding champion team. Every team and manager in our department is a strong player and our products are champions in the market but if we don’t manage to get feedback from the market and deliver the needed things in time to our customers, there might be emerging stars kicking us out of the game – like Switzerland did to France.’</p>
<p>James joins the conversation: ‘Sorry, my teams had an issue with planning the next big release, some escalation in management and with important business stakeholders about a feature that needed to be squeezed in&#8230;’</p>
<p>Monica jokingly throws in: ‘What is a release?’</p>
<p>James looks confused while Tom and Monica chuckle. A signal indicates the end of the break and the three managers leave for the next session.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<!-- /divi:paragraph --></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>


]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
