think!agile https://www.thinkagile.de Agile Coaching und Training für Personen, Teams und Organisationen Fri, 03 Jul 2020 11:07:52 +0000 de-DE hourly 1 Großartige Retrospektiven mit Design Thinking https://www.thinkagile.de/design-thinking-retrospektive/ https://www.thinkagile.de/design-thinking-retrospektive/#respond Fri, 06 Sep 2019 17:45:10 +0000 http://www.thinkagile.de/?p=1672
Empathize - Define - P.o.V.
Design Thinking entfesselt Energien zur Ideenfindung

English version on medium.com

Ein zentraler Unterschied von agilen Vorgehensmodellen zu klassischen Vorgehensmodellen liegt in der Durchführung von kleinen Iterationen und schnellen Feedback-Loops. Die Ursache hierfür liegt in einer sich immer schneller verändernden Welt, in der auch die Änderungsgeschwindigkeit von Anforderungen drastisch zunimmt. Damit ist nicht mehr gewährleistet, dass die eingangs aufgestellten Annahmen und Anforderungen an ein Produkt im Laufe des Konzeptions- und Entwicklungszeitraums identisch bleiben.

Um sich in einem volatilen Umfeld permanent zu hinterfragen, ob

  1. sich die Ausrichtung des Produktes noch an den Bedürfnissen des Marktes orientiert,
  2. die eigene Vorgehensweise noch die richtige ist,
  3. wir als Team(s) performant und kollaborativ arbeiten und
  4. wie unsere technische Exzellenz verbessert werden kann,

gibt es das Format der Retrospektive. Gerade im Framework Scrum ist sie ein essentieller Event – aber auch in Kanban ein wichtiger Aspekt, wenn auch nicht formal vorgegeben.

Um die Durchführung von Retrospektiven zu strukturieren und gewinnbringend zu gestalten, gibt es einige grundlegende Standardwerke, die sich seit vielen Jahren bewährt haben. Ergänzend zu diesen kann man Kernideen des Design Thinking hinzufügen, um seinen Retrospektiven-Werkzeugkasten zu erweitern.

5 Schritte einer agilen Retrospektive

In Ihrem Buch Agile Retrospectivesbeschreiben Esther Derby und Diana Larsen ein fünfstufiges Vorgehensmodell zur Durchführung von Retrospektiven, das sich in vielen Teams und Organisationen bewährt hat und das unter anderem dem Online-Projekt retromat.org als Grundlage gedient hat.

Fünf Phasen einer Retrospektive
5 Retro-Phasen nach Derby/Larsen
  • Phase 1: Set the stage
    Die Teilnehmer werden aus ihrem bestehenden Alltag mit seinen Herausforderungen und Gedanken gelöst und damit eine “Bühne” für einen offenen und unvoreingenommenen Austausch geboten.
  • Phase 2: Gather data
    Nachdem die Teilnehmer angekommen sind, geht es in diesem Schritt um die Sammlung von Inhalten, Problemen, guten – wie schlechten – Erfahrungen. Also allgemein gesprochen um die Sammlung der Dinge, die die Teilnehmer im zurückliegenden Zeitraum beschäftigten.
  • Phase 3: Generate Insights
    Bei den zuvor gesammelten Punkten wird nach den tiefer liegenden Ursachen “gegraben”.
  • Phase 4: Decide what to do
    In diesem Schritt wird nach Lösungsansätzen gesucht, die helfen sollen, die Probleme und Herausforderungen zu adressieren und damit zu einer kontinuierlichen Verbesserung beizutragen.
    => Ganz nach dem Motto “inspect & adapt”.
  • Phase 5: Close the Retrospective
    Um die Teilnehmer nicht einfach so zu entlassen und auch für das durchgeführte Retrospektiven-Format ebenfalls Feedback zu erhalten, wie sie in Zukunft verbessert werden kann, soll dieser Schritt dienen.

Design Thinking

Die Idee hinter Design Thinking ist eine Herangehensweise, sich in neuem Terrain mit unbekannten Problemstellungen mittels eines strukturierten Vorgehensmodells auseinanderzusetzen, das folgende Phasen durchläuft:

  • Empathize
  • Define
  • Point of View
  • Ideate
  • Prototype
  • Test

Getrennte Spaces für Probleme und Lösungen

Dabei beleuchten die Vorgehensweisen in diesen sechs Phasen zwei wesentliche Betrachtungswinkel: Den Problem-Space und den Solution-Space. Während sich die Phasen Empathize, Define und Point of View im Problem-Space abspielen, machen dies die Phasen Ideate, Prototype und Test im Solution-Space.

Erst Erweitern, dann Eingrenzen

In sämtlichen Kreativitätstechniken ist ein Kernthema die Trennung von divergierenden und konvergierenden Aktivitäten. Also von der Sammlung (Erweiterung) von Ideen/Problemen im ersten Schritt und der Auswahl (Eingrenzung) von Ideen/Problemen im anschließenden Schritt. Der Grund dafür liegt darin, dass man mit der größeren Quantität auch eine Steigerung der Qualität erreicht. Umso mehr Auswahlmöglichkeiten man hat – auch gerne völlig absurde Ideen, kann man sich durch Ergänzung, Symbiose oder Fokussierung besser auf eine qualitativere Lösung konzentrieren. Hat man lediglich wenig Ideen zur Auswahl, ist man von vornherein beschränkt.

Diese beiden Aktivitätstypen finden wir auch in den beiden Spaces wieder:
In den Phasen Empathize und Define wird im Design Thinking der Problemraum geöffnet, Themen gesammelt – bei einer klassischen Kundensituation dessen Sorgen, Nöte und Wünsche. Beim Übergang von Define zu Point of View wird der Problemraum mehr und mehr geschlossen, um sich auf wenige, wichtige Problemstellungen zu konzentrieren.
In der Ideate-Phase wird nun der Lösungsraum beschritten und geöffnet. Hier geht es wieder darum, möglichst viele Auswahlmöglichkeiten zu generieren, die dann in der Prototype- und Test-Phase mehr und mehr eingegrenzt werden.

Diese Abfolge von Erweitern und Eingrenzen in den beiden Bereichen Problem und Lösung nennt man den Double-Diamond des Design Thinking. Letztlich geht der Kerngedanke in die gleiche Richtung wie die Walt-Disney-Methode, bei der explizite Rollen für diese beiden Sichtweisen existieren, die abwechselnd eingenommen werden.

SCAMPER und andere kreative Helferlein

Bei den divergierenden Aktivitäten – gerade im Lösungsraum – kann man sich zum Beispiel der Methode SCAMPER (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate parts, Replace parts) bedienen. Sobald man eine erste Ideensammlung hat, kann man mit dieser Methode schnell Spin-offs generieren, die in ihrer Kombination neue Räume erschließen. Hier bieten sich aber genauso Methoden wie “Kopfstand“, “6-3-5” oder Ähnliche an.

Und jetzt – wie verbinde ich das?

Bei der Vorbereitung einer Großgruppenmoderation bin ich über das Thema Retrospektivengestaltung gestolpert und habe dabei erstmals die Analogien der beiden Vorgehensweisen für mich entdeckt und seither erfolgreich eingesetzt.
Im Prinzip ersetzt man lediglich die Phasen 2-4 von Derby und Larsen durch den Double Diamond.

Double Diamond im Retromodell von Derby/Larsen

Das heißt, man startet wie gewohnt mit dem Schritt Set the stage. Danach kann man den Problem Space betreten und kritische Punkte sammeln. Dies kann man nach einem ersten Durchlauf mittels Brainwriting (jeder sammelt still Problempunkte z.B. auf PostIts) und Präsentation durch weitere Iterationen ergänzen, indem man z.B. einen Kopfstand (“Wie machen wir die Situation noch schlimmer, als sie bereits ist?”) durchführt.
Da die meisten Retrospektiven mit einer begrenzten Zeitdauer kämpfen – man sich also auf die drängendsten Probleme konzentrieren muss, bleibt der Gruppe nur der schwierige Weg des Aussortierens übrig. Letztlich ist dies eine Frage von Zeit und der Selbsteinschätzung, wie viele Themenstränge sich die Gruppe zutraut, anzugehen. Bei regelmäßigen Retrospektiven empfiehlt es sich, am Ende der Retrospektive über eine Wiedervorlage der abgewählten Themen abzustimmen.

Im Anschluss erfolgt die Analyse der Problemstellungen, um die Sachverhalte genauer zu verstehen. Hier gilt es, die sicher auftauchenden Lösungsvorschläge zwar nicht abzuwürgen, sie aber auf die anschließende Arbeit im Lösungsraum zu verschieben.

In der Folge beschäftigt sich die Gruppe mit der Lösungsfindung. Gerade hier ist ein typisches Verhalten in Diskussionsgruppen zu beobachten – es ist das Auftauchen der “Ja, aber…”-Typen. Man kennt das sicher: Sobald eine neue Idee skizziert wird, begegnet einem eine Person mit dem Satz der Kategorie: ” Ja, das ist ein klasse Idee, aber das geht wegen[…] nicht!”
Dieses Muster ist in unserem Verhalten so eingebrannt, dass diese Reaktionen nahezu unvermeidlich sind. Hier gilt es als Facilitator, die Einhaltung von zunächst divergierenden und erst anschließend konvergierenden Aktivitäten zu betonen und einzufordern.
Mit einem SCAMPER-Ansatz kann man dann den Lösungsraum noch erweitern, um eine möglichst große Auswahl an Problemlösungsansätzen zu erhalten.

Da man i.d.R. als Gruppe nicht alle Lösungsansätze angehen kann und einige aller Voraussicht nach im Bereich Wol­ken­ku­ckucks­heim liegen, gilt es, die sinnvollsten Lösungsansätze zu priorisieren und sich eine realistische Menge an Action Items vor die Brust zu nehmen.

Mit dem Abschluss des Double Diamond hat man nun auch das gewünschte Ergebnis einer Retrospektive: Konkrete Action Items, die einer Verbesserung der Situation dienen sollen. Zum Abschluss kann man die Phase 5 von Derby/Larsen anschließen und die Retro abschließen.

Abschließende Gedanken

Da die beiden Vorgehensweisen in meiner Wahrnehmung in so unterschiedlichen Kontexten eingesetzt werden, habe ich diese offensichtliche Analogie bisher nicht gesehen. Ich halte die Ideen hinter den Phasen Gather Data, Getting Insights, und Decide what to do nahezu identisch zu den Schritten im Design-Thinking.
Mir hilft die strikte Trennung von Lösungs-/Problemraum einerseits und von divergierenden und konvergierenden Tätigkeiten andererseits in der Moderation und Strukturierung von Retrospektiven. Die Retrospektiven arten nicht mehr in “Schwatzbuden” oder “Auskotzrunden” aus, sondern sind ein Ort der Ermittlung drängender Problemen, Ursachenforschung und sinnvollen Lösungen zur Situationsverbesserungen. Und das ist letztlich auch eine Kernidee von Design Thinking:

“Design Thinking ist eine systematische Herangehensweise an komplexe Problemstellungen aus allen Lebensbereichen”

Hasso-Plattner-Institut

Hier geht’s zum englischen Beitrag auf medium.com

Was kommt demnächst?

In den nächsten Iterationen möchte ich noch die Phasen Empathize und Define methodisch konkretisieren und weiter ausbauen und ausprobieren. Eine Fortsetzung kommt also bald!

]]>
https://www.thinkagile.de/design-thinking-retrospektive/feed/ 0
LeSS-Buch Übersetzung fertig https://www.thinkagile.de/less-buchuebersetzung-fertig/ https://www.thinkagile.de/less-buchuebersetzung-fertig/#respond Wed, 15 Mar 2017 10:57:52 +0000 http://www.thinkagile.de/?p=853
LeSS-Buch Cover
Large-Scale Scrum (LeSS) Buch-Cover

Im vergangenen Jahr habe ich zusammen mit Björn Jensen das neue Standardwerk zum Thema Large-Scale Scrum ins Deutsche übersetzt. Wir hatten viel Spaß dabei, unser Produkt auch nach Scrum zu erstellen, mit allem was dazu gehört. Tolle Erfahrung!

LeSS-Buch publiziert

Seit Januar ist das LeSS-Buch auf dem deutschen Markt erhältlich:
https://dpunkt.de/buecher/12524/9783864903762-large-scale-scrum.html

Wir freuen uns jetzt schon auf Rezensionen und Euer Feedback. Gerne auch hier per Kommentar.

]]>
https://www.thinkagile.de/less-buchuebersetzung-fertig/feed/ 0
Make it big! LeSS – Large Scale Scrum https://www.thinkagile.de/make-it-big-less-large-scale-scrum/ https://www.thinkagile.de/make-it-big-less-large-scale-scrum/#comments Fri, 07 Mar 2014 16:46:36 +0000 http://www.thinkagile.de/?p=723 Präsidentenpalast BukarestIn den letzten Monaten wirft sich mir bei Kunden immer wieder die Frage nach einer Skalierung von Scrum auf. Das ist zwar insofern recht bemerkenswert, da viele Firmen schon mit einer stabilen Implementierung innerhalb eines einzelnen Teams Schwierigkeiten haben. Da werden Entwickler zum Teilzeit Scrum Master ausgelobt und der Product Owner ist auch nicht genügend in den Entwicklungsprozess eingebunden, off-site oder ist eine Art Architekt mit Chefentwicklerstatus.

Vielleicht könnte ja gerade ein Skalierungsansatz diese Probleme bereits im Kern lösen, da bei einer SCRUM-Einführung im Enterprise-Umfeld ja ohnehin umfassender gedacht wird und die systemischen Probleme dabei grundsätzlich behoben werden könnten.

Deshalb habe ich mir eine Skalierungsmethodik für SCRUM näher angeschaut, die Craig Larmann entwickelt hat und erfolgreich in Produktentwicklungen mit mehreren tausend Personen und über mehrere Standorte hinweg eingesetzt hat. Dazu hatte ich die Gelegenheit, bei Craig persönlich eine Einführung zu bekommen, die nicht nur sehr interessant sondern dabei auch kontrovers und spannend diskutiert wurde.

LeSS

Eine der ersten Beschreibungen über LeSS lautet: “LeSS is SCRUM”. Das klingt zunächst trivial ist aber ein sehr wichtiger Aspekt, der einem beim Blick auf das visualisierte Framework ins Auge sticht. Im Grunde genommen gibt es keine zusätzlichen Rollen, Artefakte oder Abstimmungstermine , die man nicht schon vom klassischen SCRUM kennt.

Es gibt ebenso:

  • das Team,
  • den Product Owner und
  • den SCRUM Master.

Die Teams sind so aufgestellt, dass sie als multifunktionale Teams alle am selben Produkt arbeiten. Damit gibt es genau einen Product Owner für alle Teams, die an diesem Produkt arbeiten. Die Teams sind inhaltlich und priorisierungstechnisch gleich gestellt, müssen aber nicht zwangsläufig gleich groß sein.

Also: Bisher alles beim Alten!

Interessant ist , in welcher Zusammensetzung die Meetings stattfinden und mit welchem Fokus. Nehmen wir das:

Planning 1

Die Teilnehmer
Die Beteiligten des Planning1 sind der Product Owner, von jedem Team maximal zwei Vertreter und evtl. die Scrum Master – wobei diese nicht erforderlich sind. Die Scrum Master sind niemals die Repräsentanten der Teams. Es geht hier nicht um vermeintliche Teamverantwortung oder gar um eine “Projektleitung”. Es sind tatsächliche Teammitglieder notwendig, die im Laufe der Sprints auch wechseln, damit alle Team Mitglieder diese Rolle einnehmen.

Vorgehen
Der Product Owner stellt die Backlog-Items, die er für den anstehenden Sprint ausgewählt hat den Team Vertretern aus allen Teams vor und beantwortet die dabei anfallenden Fragen. Soweit geschieht inhaltlich erst einmal das gleiche, wie bei jedem anderen Scrum-Planning 1 auch.

Danach suchen sich die Vertreter aus den vorgestellten Items, die aus, die sie in ihre Teams tragen möchten.

Anschließend werden in dieser Runde die Abhängigkeiten zwischen den einzelnen Arbeitssträngen besprochen – seien es Architektur- oder fachliche Fragen. Am Ende der Diskussion ist klar, welches Team im kommenden Sprint welche Themen mit anderen Teams noch näher beleuchten muss, um den Sprint erfolgreich anzuschließen. Diese Abstimmungen erfolgen parallel zum Sprint in dazu selbständig einzurichtenden Communities of Practise. Im Planning 1 werden lediglich die Notwendigkeiten zur Abstimmung untereinander festgehalten und evtl. leicht lösbare Themen schon angegangen.

Planning 2

Die Repräsentanten der Teams gehen mit ihren Sprint Backlogs in Ihre Teams und planen die Spezifizierung der Backlog Items, die Vorgehensweise und die Umsetzung für den Sprint. Hier bleibt im Prinzip alles, wie gehabt. Am Ende startet das Team in den Sprint.

Sprint Review

Hier treffen sich wieder der Product Owner und Repräsentanten der Teams und das fertige Produkt wird vorgeführt. Die DoD wird abgehakt und der Product Owner nimmt das fertige Produkt-Inkrement ab.

Team Retrospective

Die Retro zum Sprint wird zunächst im Team mit seinem Scrum Master durchgeführt. Auch hier gelten die gleichen Regeln wie beim nativen SCRUM. Lediglich Themen, die in der Zusammenarbeit zwischen Teams oder mit dem Product Owner liegen, werden in die Joint Retro mitgenommen

Joint Retrospective

Hier werden die Themen zwischen Vertretern aller Teams, den Scrum Mastern und dem Product Owner besprochen, Änderungen festgehalten und nach dem Prinzip “inspect and adapt” durchgeführt

Im Schaubild sieht so ein Vorgehen folgendermaßen aus:

LeSS Framework
LeSSFramework nach Craig Larmann

LeSS Huge

Craigs provokative Aussage zum Thema “Große Produktentwicklungen, die an verschiedenen Orten und offshore stattfinden” lautet:

large: don’t

multisite: dont

offshore: don’t

Dennoch gibt es zu LeSS noch eine Erweiterung, die den Faktor von einer großen Anzahl von Teams (>8-10 Teams) und das (global) verteilte Aufstellen von Produktentwicklungen behandelt.

Essentielle Änderung ist die verteilte Aufstellung eines Product Owner Teams. Es gibt zwar nach wie vor nur einen Product Owner. Dieser kann in einer multisite-Umgebung aber nicht an allen Standorten parallel am Planning 1 teilnehmen. Deshalb teilt sich der Product Owner mit den Area Product Ownern diese Tätigkeit. Davon gibt es so viele, wie es Standorte gibt.

Ebenso macht dieses Vorgehen bei Produktentwicklungen mit mehr als 10 Teams Sinn, da bei wachsender Anzahl von Team Vertretern das Planning 1 zu lange würde. So teilen sich die Area Product Owner die Arbeit an einem Standort auf.

Im Schaubild sieht so ein Vorgehen folgendermaßen aus:

 LeSS Huge Framework
LeSS Huge Framework nach Craig Larmann

Transition

Wie kann man von einer Linien-geprägten Unternehmensstruktur in einen solchen Arbeitsmodus wechseln? Das ist für die meisten Unternehmen aber auch Agile Coaches und Scrum Master eine essentielle Frage, die von Craig sehr “straight” beantwortet wurde:

top -> down, starting from C-level management

Eine Änderung und Implementierung hin zu SCRUM geht nur, indem die komplette Produktionskette umgestellt wird und das geht nur mit einem verbindlichen committment der Unternehmensleitung oder mindestens dem Vice-President / Bereichsleiter der Produktentwicklung. demnach wäre ein Strategie:

  1. Schulung und Verpflichtung des C-Level Managements, agile Produktentwicklung anzuwenden
  2. Auflösen bestehender Abteilungen und Teams, die zu Spezialisten- oder Komponententeams zusammengestellt wurden. Damit sind aber auch die daran gekoppelten Abteilungs- und Teamleiter ihrer Funktion entledigt.
  3. Zusammenstellen der Multifunktionalen Teams unter Anleitung der SCRUM Master. Diese füllen die Lücke, die durch die weg fallenden Linien-Führungskräfte entstanden ist.
  4. Erstellen und Priorisieren des Product Backlogs
  5. Vorbereitung für den ersten Sprint durch den Product Owner und die SCRUM Master

Fazit

Wie man leicht erkennen kann, ist LeSS nur eine kleine Erweiterung zum bisher bekannten SCRUM. Es erweitert diesen Ansatz um wenige Punkte, die einerseits die Abhängigkeiten zwischen den Teams steuert und den Umgang mit einer Vielzahl von Teams koordiniert. Der Rest ist den Maximen der agilen Entwicklung unterworfen:

  • Selbstverantwortung und -organisation der Teams,
  • Verantwortung für die Weiterentwicklung des Produkts liegt beim Produkt Owner und
  • die SCRUM Master dienen der Adaption von SCRUm und agilen Werten und sind methodische Impulsgeber.

Meiner Meinung nach hat dieses Vorgehen den Charme, dass es natives SCRUM ist und sich nicht an die alt hergebrachten Bedürfnisse von Unternehmensstrukturen der klassischen Welt anbiedert. Auch löst es das “Contract Game” zwischen Beauftrager und Umsetzer auf, da der Entscheider – also der “Eigentümer des Produkts” direkten Einfluss auf den Zeitpunkt und die Priorisierung einer Feature-Entwicklung hat. Er entscheidet und verantwortet, wann welches Feature kommt.

Schwierig dürfte eine agile Transition nach LeSS deshalb werden, da es keine “Grassroots-Bewegung” zulässt, sondern im oberen Management angesiedelt sein muss. Nur wenige Agile Coaches und Berater werden die Gelegenheit haben, an diesen Punkten anzusetzen und den enormen Umbau der Unternehmensstruktur durchsetzen können. Und mit einer Fake-SCRUM Implementierung, da Strukturen nicht aufgelöst werden, gehen die offensichtlichen Vorzüge von SCRUM leider verloren – egal ob im Kleinen oder im Großen.

Links und Literatur

]]>
https://www.thinkagile.de/make-it-big-less-large-scale-scrum/feed/ 2
Definition of Done – Ein Tool für Team und Product Owner https://www.thinkagile.de/definition-of-done-checkliste-fuer-das-team-und-den-product-owner/ https://www.thinkagile.de/definition-of-done-checkliste-fuer-das-team-und-den-product-owner/#respond Thu, 06 Mar 2014 16:26:07 +0000 http://www.thinkagile.de/?p=693 Sobald man sich mit dem Aufbau eines agil nach SCRUM arbeitenden Teams beschäftigt, stellt sich die Frage, wie man den Zustand der geleisteten Arbeit am Sprintende messen kann. Hierzu steht dem Team und dem PO die Definition of Done zur Verfügung, die das Team gemeinsam bestimmt. Wie kann nun eine solche DoD aussehen?

  1. Beschreibung
  2. Download

Mit dem angehängten Excel-Sheet kann man sich die Arbeit sehr einfach machen und die Erreichung der DoD wunderbar als Sprint-Historie festhalten.

Das Sheet ist bereits mit Elementen versehen, die wir aus unserem Alltag entnommen haben. Diese können Sie einfach gegen Ihre Eigenen ausgetauscht und/oder an Ihre Bedürfnisse anpasst werden.

1.Beschreibung

Die Excel-Datei dient der Aufnahme und der Pflege von Items der DoD auf der linken Seite und der Beschreibung der Backlog-Items (z.B. User Stories) oben. Dann kann in der Matrix der aktuelle Stand eingetragen werden.

DoD Screenshot

Mit dieser Ansicht auf einem Bildschirm neben dem Taskboard, kann das Team seinen eigenen strategischen Fortschritt sehen und messen – der Inhaltliche/Fachliche wird ja am Taskboard getrackt.

DoD auf einem Flip Chart
Statuspflege der DoD auf einem Flip Chart

Alternativ oder ergänzend kann man das Ganze natürlich auch analog an einem Flipchart in folgender Form pflegen:

 

 

2.Download

Definition of Done.xlsx

Creative Commons Lizenzvertrag
Definition of Done for Scrum Projects von ¡think!agile ist lizenziert unter einer Creative Commons Namensnennung – Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.

]]>
https://www.thinkagile.de/definition-of-done-checkliste-fuer-das-team-und-den-product-owner/feed/ 0
Testen – aber richtig https://www.thinkagile.de/testen-aber-richtig/ https://www.thinkagile.de/testen-aber-richtig/#respond Fri, 01 Nov 2013 21:38:05 +0000 http://thinkagile.de/?p=509
test_pyramide
Die Testpyramide, leider viel zu häufig auch ‘umgedreht’ vorzufinden

Dem Thema Testen und Testautomatisierung wurden schon sehr viele hervorragende Bücher und Artikel gewidmet. Und dennoch kann die Bedeutung dieses Themas nicht oft genug betont werden:

  • Wer einmal in einer schlecht test-abgedeckten Software entwickelt hat, kann nachvollziehen wie schwer es ist, Regressionen frühzeitig erkennen zu können.
  • Wer versucht, nachträglich die Qualität von legacy-code durch Refaktorierung und Tests zu verbessern, kennt die Unabwägbarkeiten, in die man sich von Methode zu Methode begeben muss.

Und dennoch, eine schlechte Testimplementierung kann eine große Software-Entwicklung genauso behindern, wie schlechte Codequalität. Wenn man den Tests nicht trauen kann und deren Pflege sehr aufwändig ist, wird ein zu großer Teil der Arbeit in diese undankbare Aufgabe fliessen. Wie es dazu kommen kann, erläutert Craig sehr anschaulich:

Bei einer Neu-Entwicklung ist die Auswahl der richtigen Tools für die Realisierung der Tests genauso wichtig, wie die Tests in der richtigen Software-Schicht anzusiedeln, die GUI ist hierbei die am wenigsten abgedeckten Schicht, aus guten Gründen:

]]>
https://www.thinkagile.de/testen-aber-richtig/feed/ 0
Was bedeutet Agilität heute – 9 Tipps für Leadership https://www.thinkagile.de/was-bedeutet-agilitaet/ https://www.thinkagile.de/was-bedeutet-agilitaet/#comments Fri, 01 Nov 2013 20:05:13 +0000 http://thinkagile.de/?p=489
Agilität

Inhalt:

  1. Was bedeutet Agilität in der Praxis?
  2. Worauf beruht Agilität?
  3. Aufgabe des Managements
  4. Fazit

Der Begriff Agilität findet heute sehr viele Ausprägungen und Eigeninterpretationen in jeder Organisation, welche sich mit diesem Thema aus unterschiedlichen Beweggründen befasst.
Und je mehr Interpretationen hierüber im Umlauf sind, desto weniger ist es verwunderlich, dass Dinge  schlecht geredet werden, welche nichts hiermit zu tun haben.

Um die Frage zu beantworten, was Agilität ist, muss man sich zunächst darüber im klaren werden, was Agilität nicht bedeutet: Agilität bedeutet nicht, schneller zu liefern. Die Enttäuschung hierüber lässt sich in grossen Organisationen immer wieder feststellen. Meist, weil die Erwartungshaltung eine andere war und ist, bzw. falsche Erwartungen in die Einführung von agilen Praktiken bewusst oder auf Grund mangelnder Kenntnisse suggeriert wurden.
Agil bedeutet auch nicht, weniger Fehler im Produkt oder eine höhere Qualität. Dies sind sicherlich Nebeneffekte, dürfen aber nicht die Motivation für einen agilen Change-Prozess sein.
Agilität ist auch keine Methodensammlung. Auch wenn geläufige Techniken oder Methoden wie Xtreme Programming, Iterative Software-Entwicklung oder Kanban agilität fördern, und zu den “agilen Methoden” zählen, können diese aber in einem nicht-agilen Umfeld einer großen Organisation für sich alleine nur sehr geringe lokale Optimierungen auf die Anpassungsfähigkeit eines Unternehmens haben. Bleiben sie mittelfristig auf der Entwicklungsebene isoliert, findet man sich sehr schnell in pseudo-agilen Unternehmen wieder.

Agil zu sein, kann nur ein Ziel verfolgen: Durch häufigere Lieferung von wertschöpfenden Produkten, Features und/oder Wissen wirtschaftlichen Erfolg im Wettbewerb zu haben.

why_agile

Agilität ist die Qualität einer Organisation, sich reaktiv an sich verändernde Bedingungen anzupassen, kontinuierlich zu lernen und sich als Ganzes weiterzuentwickeln.

Was bedeutet Agilität in der Praxis?

Agilität wird Ihre Organisation nachhaltig verändern. Vorausgesetzt Sie sind bereit, diesen langen und teilweise beschwerlichen Weg zu gehen.

batch_size
Angemessen kurze Releasezyklen bis zur Auslieferung sind das große Ziel jeder agilen Transitio

Business Agility wird z.B. lange Prozessketten identifizieren und Sie werden, abhängig von Ihrer Rolle gefordert sein, die Schwachstellen zu identifizieren, an deren Optimierung oder Beseitigung mitzuarbeiten, oder aber die Voraussetzungen und Mittel hierfür bereitzustellen.

Der Abbau von sogenannten Warteschlangen (Queueing Theory), welche die Wertschöpfungskette Ihrer Produkte verlangsamen, ist ebenso ein klar definiertes Ziel von Agilität, wie die Verringerung der Zyklen, z.B. von der Produktidee/Beauftragung bis zur Monetarisierung. Cycle-Times sind eine wertvolle und eine der wenigen echten Messkriterien einer agilen Transition.

Die Fragen, die Agilität immer wieder in Ihrer Organisation aufwerfen wird: Wie können wir einen höheren Wert (Value) bei geringeren Kosten erzeugen? Und was kostet uns ein verspätetes Feedback?

Worauf beruht Agilität?

Ohne im Detail auf die Ursprünge von lean und agile einzugehen, so sind dessen Pfeiler “continous improvement” und “respect for people” doch die wichtigste Voraussetzung, welche verantwortungsvolle Führungskräfte verinnerlicht haben und anwenden müssen, wenn eine agile Transition eine Chance haben soll. Sie sind gefordert, wenn es um eine kontinuierliche Weiterentwicklung Ihrer wertvollsten Ressource, der Mitarbeiter, geht. Genauso liegt es in Ihrer Verantwortung, die Kultur für eine beständige Verbesserung der Organisation zu schaffen und beizubehalten.

Die Aufgabe des Managements

Die Aufgabe und Verantwortung des Managements beeinflusst den Erfolg einer erfolgreichen agilen Transition mehr, als jeder andere Faktor. Und doch wird er am häufigsten vernachlässigt.

Jim Highsmith hat die Aufgaben folgendermassen zusammengefasst:

1. Erzeuge für den Kunden etwas von Wert und analysiere, was er eigentlich will
2. Kultiviere engagierte Stakeholder
3. Wende einen Führungsstil der Zusammenarbeit an
4. Baue kompetente und gemeinschaftliche Teams auf
5. Ermögliche Team-Entscheidungen
6. Nutze kurze (timeboxed) Iterationen um Features zügig auszuliefern
7. Ermutige zur Anpassungsfähigkeit
8. Sei ein Verfechter technischer Exzellenz
9. Fokussiere mehr auf Auslieferungsaktivitäten als auf process-compliance Aktivitäten

inspiring_engaging
Eine Vision für ein Unternehmen in einer agilen Transition, ein Produkt in einer agilen Entwicklung zu entwickeln und zu vermitteln, ist eine einfache, aber äusserst mächtige Möglichkeit, alle Beteiligten auf ein gemeinsames Ziel einzuschwören.

Fazit

Der Umgang mit Agilität und dessen Einführung in grossen Organisationen wird leider zu oft zu leichtfertig angegangen, ohne dass sich die Verantwortlichen über deren Auswirkung und Ziele bewusst sind.
Dies führt zu oberflächlichen Implementierungen von Pseudo-Scrum Artefakten in der Entwicklung, in der Führungskräfte Zeit und Scope diktieren, ohne in den Dialog über organisatorische Veränderungen und hohe Produktqualität einzutreten.
Es ist der Anfang vom Ende vieler teurer – und speziell für die involvierten Teams frustrierenden – agilen Fehlschlägen.

Die Vergeudung von Zeit und Ressourcen durch die falsche Interpretation von Agilität kann aber verhindert werden, wenn der Fokus von Beginn an auf der Business-Perspektive liegt und mit lean- und agiler Methodik umgesetzt wird.
Wer eine agile Transition als Führungskraft erfolgreich unterstützen will, muss die Prinzipien der agilen Software-Entwicklung verinnerlicht haben und konsequent einsetzen.

]]>
https://www.thinkagile.de/was-bedeutet-agilitaet/feed/ 1
Pflege des Product Backlogs https://www.thinkagile.de/pflege-des-product-backlogs/ https://www.thinkagile.de/pflege-des-product-backlogs/#respond Thu, 03 Oct 2013 00:13:27 +0000 http://thinkagile.de/?p=440 Als Product Owner ist eine der essentiellsten Arbeiten sicher die Entwicklung und die Pflege von Backlog Items, User-Stories und der Priorisierung. Den Überblick über die Dinge, die schon umgesetzt wurden und die, die noch kommen werden, zu behalten, ist nicht immer einfach.

  1. Beschreibung
  2. Download

Zu diesem Zweck bieten wir hier eine kleine vorbereitete Tabelle für das Product Backlog an. Damit kann man auch gut beim Kunden die nächsten, wichtigen Punkte priorisieren und neue Items aufnehmen

1. Beschreibung

Das Sheet ist bereits lediglich mit Dummy-Werten versehen, die man als erstes gegen die Eigenen austauschen wird. Die Spalten für die Sprints, Releases und den Status sind bereits vorbelegt und es kann ausgiebig sortiert und gefiltert werden.

 

2. Download

ProductBacklog.xlsx

Creative Commons Lizenzvertrag
Product Backlog von ¡think!agile ist lizenziert unter einer Creative Commons Namensnennung – Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.

]]>
https://www.thinkagile.de/pflege-des-product-backlogs/feed/ 0
Keynote Scrum Gathering 2013 https://www.thinkagile.de/keynote-scrum-gathering-2013/ https://www.thinkagile.de/keynote-scrum-gathering-2013/#respond Tue, 01 Oct 2013 13:03:31 +0000 http://thinkagile.de/?p=416 Henrik Kniberg hat auf dem Scrum Gathering 2013 eine bereichernde Opening Keynote gehalten und dabei über den Faktor der Arbeits- und Firmenkultur in der agilen Transition gesprochen. Dies tat er am Beispiel von spotify und einigen Vorgängerprojekten.

Fazit: Die Arbeitskultur ist ein wichtiger Faktor bei der Transition zu agilen Projektsituationen. Diese kann ein sehr förderlicher Punkt bei der Umstellung sein – stellt aber im Zweifelsfall auch den größten Hemmblock bei der erfolgreichen Umstellung dar.
Einen detaillierten Abriss der Keynote gibt es in Markus Gärtners Blog.

Keynote von Henrik Kniberg Teil I:

Keynote von Henrik Kniberg Teil II:

Hier gibt es alle Präsentationen des Scrum Gatherings zum Download:
http://www.scrumalliance.org/courses-events/events/global-gatherings/2013/paris-2013/presentations

]]>
https://www.thinkagile.de/keynote-scrum-gathering-2013/feed/ 0
Earned Value Analyse in agilen Projekten https://www.thinkagile.de/earned-value/ https://www.thinkagile.de/earned-value/#comments Mon, 30 Sep 2013 14:28:01 +0000 http://thinkagile.de/?p=400 Auch in agilen Projekten steht man immer wieder vor der Herausforderung, dem Kunden über den Verlauf des Projektes bis zum nächsten Meilenstein oder bis zum nächsten Release Auskunft geben zu müssen.

  1. Beschreibung
  2. Download

Mit dem angehängten Excel-Sheet kann man sich die Arbeit sehr einfach machen und erhält sogar noch schicke Diagramme, die man beim Kunden Management-verständlich vorzeigen kann.

Das Sheet ist bereits mit beispielhaften Werten versehen, die man gegen die Eigenen austauschen und an die eigenen Bedürfnisse anpassen kann – zum Beispiel bei kürzeren oder längeren Sprint-Zyklen o.Ä.

1.Beschreibung

Zunächst tragen wir unter 1. und 2. die anfangs geschätzten Werte für die im Release abzuarbeitenden Estimation Points (EP) aus unserem ersten Schätzworkshop ein und die geplanten Projektaufwände, sofern diese vorliegen.

Excel-Sheet mit Aufwänden und erreichten EPs pro Woche und Sprint

Anhand der abgetragenen Kalenderwochen und Sprints (hier 16 Wochen und 8 Sprints) und der Gesamtanzahl von Aufwänden (PDs) und Schätzpunkten (EPs) ergibt sich bei gleicher Verteilung ein Idealwert pro Woche/Sprint – gekennzeichent mit 3. und 5.

In den Zeilen mit 4. und 6. tragen wir wöchentlich oder im Sprintrhythmus unsere erreichten Estimation Points (EP) und Personentage (PD) ab.

Danach kann man das Ergebnis des Fortschritts sehen:

Fortschrittsverlauf im ReleaseDie zu erwartenden Aufwände, um das Release mit dem geschätzten Scope zu erreichen, kann man dann an folgendem Diagramm entziffern:

Die zu erwartenden Release-Aufwände

2.Download

EarnedValue4Agile.xlsx

Creative Commons Lizenzvertrag
Earned Value Analysis for Scrum Projects von ¡think!agile ist lizenziert unter einer Creative Commons Namensnennung – Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.

]]>
https://www.thinkagile.de/earned-value/feed/ 3
Scrum’s Eleven – Spezialisten-Teams vs. interdisziplinäre Feature-Teams https://www.thinkagile.de/spezialisten-teams-vs-interdisziplinare-teams/ https://www.thinkagile.de/spezialisten-teams-vs-interdisziplinare-teams/#respond Wed, 30 Jan 2013 00:35:46 +0000 http://thinkagile.de/?p=233 Wer kennt ihn nicht – den Ganovenfilm über den kongenialen Casino-Coup des Teams um Danny Ocean alias George Clooney. Neben dem amüsanten Plot des Films fiel mir schon immer auf, wie interessant und umfassend dieses Team zusammengestellt wurde. Und erfolgreich im Projektabschluss war dieser Haufen obendrein.

Bild aus dem Film Oceans Elven
Das perfekte Team: interdisziplinär, agil und erfolgreich

Im Gegensatz dazu sehe ich in vielen Unternehmen, die sich mit Scrum beschäftigen, nach wie vor Teams, die sich dezidiert um einen Tätigkeitsbereich kümmern: Da gibt es ausgewiesene Testabteilungen, die sämtliche Produkte im Unternehmenskontext testen. Auch gerne in größeren Unternehmen anzutreffen sind Teams von Systemarchitekten, die sich um alle Software-Elemente im Produkt-Portfolio kümmern. Oder Operations-Abteilungen, die die technische Infrastruktur all dieser Produkte installieren und parallel dazu deren Betrieb gewährleisten.

Bereits im klassischen Projektmanagement führt dies zum simultanen Arbeiten in mehreren Projekten mit den klassischen Problemen wie Multitasking, immer wieder auftretende Rüstzeiten beim gedanklichen Wechsel von einem Themenbereich zum Nächsten und letztlich Überforderung der Mitarbeiter.

Spezialisten haben einen Zweitnamen – Bottleneck!

Was darüber hinaus auch noch zum Problem führt, ist die Tatsache, dass Mitarbeiter, die sich ausschließlich auf ein Tätigkeitsbereich spezialisiert haben, von sämtlichen Projekten zur Durchführung dieser Arbeiten heran gezogen werden. Das führt in der Regel dazu, dass diese Personen entweder für sich selbst oder der Teamleiter eines solchen Spezialistenteams Aufwände für jedes Projekt abschätzen und für jedes Projekt eine fest definierte Zeitspanne einplanen, in der diese Tätigkeit durchgeführt wird. Verändert sich aus Projektsicht der zeitliche Ablauf, und diese Tätigkeit wird entweder früher oder später benötigt, sind Wartezeiten auf die Durchführung dieses Tasks vorprogrammiert. Da nivelliert sich jeder vorher erarbeitete Projektfortschritt gleich wieder. Auch wachsen die Aufwände für die Planung im Spezialistenteam und im Projekt, da kontinuierlich umfänglich nachjustiert werden muss. Die Folge ist das Aufbauen von unnötigen Puffern, die systemimmanent sind.

Aber wie geht es nun anders? Schauen wir dazu das Team von Danny Ocean genauer an: ein Team völlig unterschiedlicher Charaktere und Fähigkeiten. Jeder für einen speziellen Einsatz eingeplant, der in diesem Projekt – dem Casinoraub – benötigt wird. Die Team-Mitglieder arbeiten nicht an verschiedenen Raubprojekten gleichzeitig, sondern schließen sich gemeinsam ein und planen Ihren Coup zunächst durch und beginnen parallel mit den Vorbereitungen. Wie bei jedem anderen Projekt auch, ändert sich das Vorgehen, der Weg und viele Details parallel zur Durchführung mitunter kolossal. Wir sind also auch hier in einem agilen Umfeld.

Diesem Sachverhalt trägt das Team der ‘Eleven’ auch Rechnung, indem im Falle eines Ausfalles der nächste das Thema übernehmen kann. Natürlich nicht zu 100 Prozent, aber in gewissem Maße durchaus und das ist in Anbetracht des geringen zeitlichen Spielraums auch kaum anders möglich. Wobei hier auch anzumerken ist, dass es immer wieder Teilbereiche geben wird, für die nur ein Einzelner die Fähigkeiten haben wird. Kaum vorstellbar, das Reuben – ein in die Jahre gekommener gediegener Herr – die Aufgabe des Schlangenmenschen übernehmen könnte und sich in einen Koffer zwängen würde. Dazu wäre er einfach zu schwer und zu ungelenk. Wir sehen also auch, dass dem Interdisziplinären Team Grenzen gesetzt sind.

Interdisziplinär und erfolgreich

Wenn wir unser agiles Team anschauen, sehen wir durch dieses Vorgehen aber folgende Vorteile.

  • Schnellere Abstimmung, da alle Beteiligten eng und kontinuierlich miteinander arbeiten
  • Architektur- und Designanpassungen können schnell zum Produktionsverlauf angepasst werden
  • keine unnötigen Puffer oder Leerlaufzeiten, da auf anderweitig ausgelastete Experten-Teams nicht gewartet werden muss
  • geringere Aufwände für Ressourcenplanung von Spezialisten-Teams und deren Einsatz im Projekt
  • schneller Ersatz innerhalb des Teams, da bei einem Ausfall eines Team-Mitglieds das restliche Team die Aufgabe abfedern kann

Deshalb Mut zur Umstrukturierung – mit einem starken, interdisziplinären Team knackt man auch den Jackpot!

]]>
https://www.thinkagile.de/spezialisten-teams-vs-interdisziplinare-teams/feed/ 0