Agilität

Agilität hat eine lange Historie und findet seinen Ursprung in der Softwareentwicklung.
https://de.wikipedia.org/wiki/Agile_Softwareentwicklung

Ein sehr guter Artikel der sich übergreifende Gedanken macht zur Einordnung und Steigerung der Produktivität hab ich bei Leadingagile.com gefunden.
Unter dem Thema Productivity Patterns hat DEREK HUETHER einen sehr hilfreichen Artikel geschrieben.
Die wesentlichen Punkte habe ich unter Personal Organization in einem Abschnitt dokumentiert.

Darüber hinaus sammle ich seit einiger Zeit spannende Visualisierungen zum Thema Agiltität auf Pinterest.

Eine lange und hilfreiche Zusammenstellung von Quellen https://proagile.de/toolbox/#agile-information. Eigentlich braucht es kaum mehr für die Durchführung von Lehrveranstaltungen.

Es stellt sich immer die Fragestellung, wann setzte ich eher klassische Verfahren der Ablauforganisation (Wasserfall o.ä.) ein und wann nehme ich eher Agilität?
Eine eingängiges Modell hat Ralph D. Stacey um 1990 entwickelt. Die sogenannte Stacy Matrix spannt zwei Dimensionen auf.
Die Klarheit bzw. die vollständige Übereinstimmung in der Anforderung und die Beständigkeit oder auch Veränderungsrobustheit in der Anforderung.
Der Einsatz von Agilität, der durch ständige Iteration und den inkrementellen Ansatz auf Dynamik ausgelegt ist, scheint immer dann das geeignetere Vorgehensmodell zu sein, je unbestimmter eine oder beide Dimensionen sind.

https://www.slideshare.net/berniemaloney/agile-in-an-hour

Darüber hinaus habe ich das Thema Agil@Family so spannend gefunden, dass ich begonnen habe mit meiner eigenen Familie diesen Ansatz für uns zu entdecken.

Agilität hat ab den Jahren 2014 beginnend immer mehr Aufwind bekommen.
Damit ergibt sich leider stets auch ein Hype (mindestens in der Begriffsverwendung) und plötzlich ist alles agil und vor jedem Produkt oder Service muss dringend noch agil stehen.
Einen bekannte Eckpfeiler stellt sicher die Entstehung des Agilen Manifestes dar, was im weiteren Verlauf noch näher ausgeführt wird. http://www.iweihs.net/weihswiki/doku.php/agile#das_manifest
Einen sehr schönen Überblick über die Landscape Agility wurde von Chris Webb erzeugt und ist hier im Blogartikel zu finden http://blog.deloitte.com.au/navigating-the-agile-landscape/

Alleine schon die Liste der verwendeten Quellen für diese Map lässt eine ungefähre Ahnung aufkommen, dass Agilität kein neues Konstrukt ist sondern über einen längeren Zeitraum iterativ ausgestaltet und verbessert wurde. Wenn Sie sich etwas länger mit dem Themenfeld beschäftigen, könnte es sein, dass sich die Erkenntnis einschleicht, dass Agilität keine Methode sondern eher eine grundsätzliche (Geistes-)Haltung sowie Denk- und Herangehensweise darstellt. Für die Umsetzung dieser Haltung gibt es einen reichlich gefüllten Werkzeugkasten.

References:

{{:agility_in_a_nutshell_sw.jpg?direct&300 |{{ :agility_in_a_nutshell_sw.jpg?direct&200|}}

Diese Visualisierung zeigt “auf einem Blick” die wichtigsten Elemente des Themas Agilität.
Es soll der Dialog mit unterschiedlichen Ebenen von Manager bis Andwender ermöglicht werden.
Die zu erreichende Tiefe für diesem Dialog hängt stark vom Vorwissen und der verfügbaren Zeitspanne für dieses Gespräch ab.
Die dargestellten Diskussionsfelder sind:

  1. Product Vision
  2. Incrementel & Business Value
  3. Product Backlog & Sprint Backlog
  4. Team is cross functional and self organized
  5. Dimensions are connected: - Time - Cash - Function - Quality
  6. Rolemodel SCRUM: PM - SM - DevTeam - User - Stakeholder
  7. Iteration - Deming Cycle - KVP - Plan - Do - Check - Act
  8. Impediment Backlog: Collaboration - Process - Technical - Functional
  9. SCRUM Flow - P1 & P2 Planning - Estimation - Demo & Retro - Releasmanagement

Das Manifest

Die agilen Prinzipien und Werte gehen auf das agile Manifest aus dem Jahr 2001 zurück.
http://agilemanifesto.org/iso/de/manifesto.html

Die Grundidee waren die Überlegungen und Beobachtungen zu konsolidieren und eine Antwort auf die Frage zu finden, wie mann bessere Software entwickeln kann.

  • Individuen und Interaktionen »»>(mehr als) Prozesse und Werkzeuge
  • Funktionierende Software »»>(mehr als) umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden »»>(mehr als) Vertragsverhandlung
  • Reagieren auf Veränderung »»>(mehr als) das Befolgen eines Plans

Hier wird schon deutlich, dass die Werte auf der rechten Seite als besonders wichtig empfunden werden allerdings heisst das nicht, das die Werte auf der rechten Seite völlig zu vernachlässigen sind. Das Bild eines Schiebereglers trifft es aus meiner Sicht ganz gut, um sich vorzustellen dass die Bedeutung für jeden spezifisch und situationsabhängig ist. Es gibt kein schwarz weiß Prinzip.

Die 12 Prinzipien

Die folgenden Prinzipien stehen hinter dem Agilen Manifest.

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
  2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
  10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

12 Prinzipien - Kurzversion

  1. Zufriedene Kunden “erzeugen”
  2. Welcome Change
  3. Regelmäßig, funktionierende Software liefern
  4. Tägliche, enge Zusammenarbeit
  5. Jede Unterstützung für das motivierte Team
  6. Dialog - Face 2 Face
  7. Fortschirtt = funktionierende Software
  8. nachhaltige Entwicklung = gleichmäßiges Tempo
  9. Technische Exzellenz und gutes Design als Ziel
  10. Einfachheit
  11. Selbstorganisierte Teams
  12. Regelmäßge Reflektion zur Verbesserung - KVP

Häufig werden im Zusammenhang mit Agilität die Begriffe Prinzipien und Werte sehr stark verkürzt und vermischt. Typische Schlagworte sind:

Agile Werte:

  • Selbstverpflichtung
  • Rückmeldung
  • Fokus
  • Kommunikation
  • Mut und Respekt
  • Einfachheit
  • Offenheit

Agile Prinzipien:

  • Adaption
  • Aktive Einbindung
  • Arbeit sichtbar Machen
  • Baby - Schritte
  • Team ist bevollmöchtigt
  • Experimentieren ist gewünscht
  • Iteration
  • KVP
  • Flow
  • Zusammenarbeit aller Beteiligten
  • Reflexion

Kanban ist eine mögliche Methode zur Organisation der agilen Zusammenarbeit. Es werden alle relevanten Schritte entlang eines Prozessmodells visualisiert, so dass für alle Beteiligten immer ein guter Überblick besteht. Das einfachste, bekannte Prozessmodell ist OPEN - WORK IN PROGRESS - DONE.

Portfolio KANBAN

In der fortgeschrittenen Anwendung kann man mit KANBAN aber auch ganze Unternehmensportfolien organisieren und den Abarbeitungsfluss koordinieren. Ein dazu möglicher grober Prozess in der Produktentwicklung ist

tip box
IDEE - PRODUCT VISION - READY4DEV - DEV - DONE - EFFECT

Markus Andrezak führt in seinem Video zum Thema Portfoliomanagement mit Kanban im Rahmen der Limited W.i.P Society Hamburg in die Thematik ein.

In der Anwendung kann das in Trello wie folgt aussehen.

ScrumTeams Example

Role Model für agile Teams / SCRUM Teams https://www.youtube.com/watch?v=szr0ezLyQHY&ab_channel=Nordstrom

Product Owner PO

Der Product Owner verantwortet das Produkt oder besser dem Product Owner gehört das Produkt.
Deswegen nimmet er auch die gelieferten Inkremente ab oder eben nicht und definiert die User Stories.
Er priorisiert aus der Business Sicht kontinuierlich das Product Backlog und sorgt sich um die Akzeptanz seines Produktes durch geeignete Kommunnikation mit den unterschiedlichen Zielgruppen im Unternehmen.

Steve Jobs wird gerne als Rollenmodell für einen sehr guten PO genommen.

Ein guter Artikel, der die Arbeit eines PO beschreibt ist im Teamworkblog im November 2017 erschienen.
http://www.teamworkblog.de/2017/11/welche-tools-braucht-ein-product-owner.html Mit diesem Artikel als Grundüberlegung ist die folgende Matrix entstanden.

Product Ownership Evolution Model

Scrum Master SM

DevelopmentTeam DevTeam

Stakeholder

User

The official SCRUM Guide: http://www.scrumguides.org/scrum-guide.html

Auch für SCRUM sind die 5 gundelgenden Werte festgelegt.

  1. Selbstverpflichtung+
  2. Mut
  3. Fokus
  4. Offenheit
  5. Respekt

Diese 5 Werte auf den 3 Basissäulen

  1. Transparenz
  2. Überprüfung
  3. Anpassung

führen im Ergebnis zu einer kontinuierlichen Steigerung der Kompetenz aller Beteiligten in der Erfüllung dieser Werte. Daraus entsteht dann das nötige Vertrauen.

Prozess

  • ? - Initial Backlog
  • PB - Product Backlog
  • SB - Sprint Backlog
  • Big Loop - Sprint Cycle
  • Small Loop - Daily
  • Increment - shipable product
  • PO - Product Owner
  • SM - Scrum Master
  • Dev - Development Team
  • S1 - Meeting Structer per iteration

Meetings

Planning 1

Im Planning 1 wird der grundlegende Dialog zwischen Business und Technik geführt.
Definition des Sprintziels aus der Perspektive PO.

  • Was wünschen sich die Anwender / User / PO Runde als Sprintziel?
  • Welche User Stories zahlen auf die Zielerreichung ein?
  • Welche Fragen pro User Story gibt es aus der Perspektive DEV Team?
  • Abschluss Commit des DEV Teams zu dem definierten Umfang.

Planning 2

Im Planning 2 Meeting wird der im P1 Meeting definierte Umfang des Sprintinhaltes weiter detailliert und in die nötigen technischen Aufgaben heruntergebrochen.

  • Was müssen wir technisch realisieren um die User Story umzusetzten?
  • Wie gehen wir vor und welche technischen Komponenten (DB, Frontend, Interfaces, Backend, …) müssen berücksichtigt werden?
  • Welche Granularität in der Planung / Aufteilung der technischen Aufgaben ist hilfreich?
  • Der Abschluss ist ein gemeinsames Verständnis wie weiter vorgegangen wird und wer was zu tun hat aus einer technischen Perspektive des DEV Teams.
  • Diesr Plan darf oder besser soll sich sogar im Zuge der Daily Meetings weiter detaillieren und verändern.

Demo

Retrospective

  • Fokus auf Dev. Team
  • Identifikation von Verbesserungspotenzialen an dem Arbeitsprozess

Retrospectiven sind ein Werkzeug aus dem agilen Werkzeugkasten, um am Ende eines Sprints gemeinsam mit dem Team über die eigenen Abläufe und Zusammenarbeit nachzudenken. Grundsätzlich werden nach Esther Derby und Diana Larsen (siehe Quellen unten) immer 5 Phasen durchlaufen. Für die Durchführung gibt es aus der Moderation verschiedene Werkzeuge die sich dafür eignen. Wie so oft macht gerade die Abwechslung Sinn um immer wieder neue Impulse mit dem Team zu erzeugen. Sonst wird es ja auch schnell langweilig.

Retrospectiven

The Product Backlog Grooming

  • Product Backlog
    • Anforderungsliste
    • priorisiert nach Business Relevanz (das Wichtigste steht oben)
    • Pool aller vorbereiteten User Stories
    • Geführt vom Product Owner mit seinen Anwendergruppen
  • Sprint Backlog
    • Priorisierte Liste der für diesen Sprint zugesagten Stories
    • Verschiedene Statusspalten in KANBAN für die Visualisierung des Fortschrittes im Team
  • User Story
    • Beschreibung einer Anfroderung aus Businessperspektive
    • Ich als <ROLLE>, möchte <Aktion / Wunsch>, um <Ergebnis / Nutzen>.
    • Jede User Storiy hat zugehörige Aktzeptanzkriterien die für die Technik beschreiben auf was der User bei der Abnahme achtet.
  • Impediment Backlog
    • List der Hürden und Hindernisse für das Dev Team
    • die “to do liste” für den Scrum Master
  • Increment
    • Gelieferte nutzbare Teilprodukte
    • Getestet und dokumentiert als “done”
  • DoD, DoE, DoR
    • DoD Definition der vereinbarten Fertigstellungskriterien Definition of Done
      • Akzeptanzkriterien sind erfüllt
      • Code ist im Versionierungssystem eingecheckt
      • Deployment auf <System> war erfolgreich
      • Tests waren erfolgreich und sind dokumentiert
      • Dokumentation ist in … abgelegt und umfasst mindstens ….
    • DoE Definition of Entry beschreibt die Eingangkriterien für die Formulierung einr User Story
      • User Story ist in Jira dokumentiert
      • US ist nach INVEST fromuliert (Independent - Negotiable - Valuable - Estimable - Small - Testable)
      • Es sind Akzeptanzkriterien aus Business / User Perspektive definiert
    • DoR Definition of Ready beschreibt die Kriterien die erfüllt sein müssen bevor die US für einen Sprint selektierbar wird
      • US ist der Technik vorgestellt und verstanden
      • US ist geschätzt
      • US muss in einer Iteration (Sprint) abarbeitbar sein
      • US hat nicht mehr wie XX Story Points
    • Alles Definition of X können uns sollen sich über der Zeit entwickeln
    • In der Regel werden die Definitionen über der Zeit “enger” und “zielgenauer”, da sich eine Lernkurve ergibt. (Wir schätzen genauer, wir sind sicher im Umgang mit den Werkzeugen, der Staging Umgebung, …)

Agilität ist seit ein paar Jahren in aller Munde und es wird schlimmer. Es existiert eine Art Zwang zur Agilität. Jeder will muss heute agil sein oder wenigstens behaupten es zu sein. Durch die ständige, gebetsmühlenartige Wiederholung des Begriffs entwickelt sich eine Art genervtes Zuhören. Der Begriff beginnt sich abzunutzen, wie schon die Begriffe “Social Media, Web 2.0 und weitere …

Es entstehen Vorurteile und Mythen um das Thema, die hauptsächlich genährt werden im Zuge der zu wenig durchdrungenen Thematik.
Klassiker sind hier die folgenden Mythen:

  1. Agil = SCRUM
  2. Agil = Neu
  3. Agil = kein Planen
  4. Agil = Anarchie
  5. Agil = nur bei kleinen, technischen, unbedeutenden aber nicht bei große, wichtigen, Business Projekten möglich
  6. Agil = haben wir schon immer so gemacht, wir nennen es nur nicht so.

Diese Mythen und Argumentationen folgen dem reproduzierbaren Mustern, der allseits beliebten Theorie der “Austauschbarkeit der Technik Kritik”. –> Top Ranking der Hypothesen. Ich bin immer wieder begeistert erstaunt, wie gut sich dieses Muster im Alltag wiederfinden lässt.

inital version by http://www.barryovereem.com/

  1. The Agile Principles Checklist: How Agile is my Team
  2. The Unofficial Scrum Checklist by Henrik Kniberg
  3. Scrum Checklist by Tobias Fors
  4. Agile Strides Scrum Checklist Based on Henrik Kniberg
  5. Product Management Test by Roman Pichler
  6. Not a checklist, but the Open Assessments by Scrum.org are very useful to assess your knowledge
  7. The Team Metrics tool by Christiaan Verwijs
  8. 20 Product Owner Questions For a New Scrum Master by Stefan Wolpers

Agilität in non IT Projekten

Das Thema hatten wir auch auf der Agile Unconference im Oktober 2017 in Zürich.
Die Werkzeuge und Ablauforganisation bleibt bestehen, allerdings ist das Inkrement am Ende des Sprints eben keine Software, sondern ? Hier muss man sich je Projekt viel Mühe geben spannende, relevante, vorzeigbare Sprintziele und Ergebnisse zu definieren.

Agile Skalierung

Die agile Skalierung beschäftigt sich mit den Fragestellungen und Prinzipien, die benötigt werden wenn nicht nur der erste agile Pilot zum Einüben und Lernen von Agilität im Fokus steht. Es geht demnach um mehrere Teams in großen Projekten oder ganze Abteilungen oder sogar ganze Organisationen die sich gerne auf die agile Reise begeben möchten.

Erfahrungsberichte zum Thema Agilität & Skalierung

Skalierung bedeutet arbeiten mit

  • große Projekte
  • viele Teams
  • viele Kulturen

5 Werte in SCRUM

  1. FOKUS
    • Fokus auf genau eine Sache ein Ziel
  2. COMMITMENT
    • Einladung zum freiwilligen Mitmachen
  3. MUT / COURAGE
    • Ausprobieren, Experimentieren, Doing as a way of Thinking
  4. OFFENHEIT
    • aus mir selber heraus bin ich offen für Neues,
    • wir sagen auch was Sache ist,
    • Umgang mit unseren Zahlen –> Transparenz
  5. RESPEKT
    • Ich nehme den Anderen so wie er ist
    • ich aktzeptiere erstmal seine Perspektive und seine Ideen und Beiträge

Grundprinzipen der agilen Skalierung

  1. Architektur
    • Marktplatz kann viele unabhängige Marktstände (alle wollen verdienen) betreiben und doch ein z.b. Weihnachtsmarkt sein —> Plattformgedanke
      • Die Stände können untereinander Beziehungen und Abhängigkeiten haben bzw sich abstimmen
      • Jede Organisation baut sich die Struktur in Ihrer Organisation hin die sie erreichen möchte. —> Unabhängigkeit, Fehlertoleranz, Kapselung, ….*
      • Spotify, Netflix, Amazon, ….. Jedes einzelne Team kann permanent neue Produkte auf der Plattform anbieten —> Dynamik
    • Architekturen müssen einem Design Prinzip entsprechen
      • Kapselung für operative Unabhängigkeit —> Aktzeptanz dass SW auch redundant in verschiedenen Teams entsteht
      • oder schnelle Crossfunktionale Teams (z.B Dimension Team)
      • fraktale Skalierung ist Grundidee
  2. Infrastruktur
    • Teamgröße (5-7) ist ideal —> Umgang mit Größe —> Granularität
    • muss in Echtzeit über STO hinweg die Kommunikation ermöglichen
      • Videoconferencing, HangOut, Versionierung von Dokumenten, Chat, Telefon, Performance ist wichtig, Versionierugnssysteme für Code,
    • muss “Continous Delivery Pipeline” ermöglichen
      • gemeinsame Lieferung von integrierter SW
  3. Know How / Skills
    • Selbstmanagement
    • Fachliche Skills
    • Domain Know How (Banking, Automboil, Versicherungen, ….)
    • Kulutur Know How (Indien, US, BRD, …)
  4. Design Thinking
  5. Management Framework
  6. Org 4.0 / Agile Führung

Quellen zur agilen Skalierung:

Studien zum Thema Agilität

2017

2016

bis 2015

  • agile.txt
  • Last modified: 2018/02/26 08:58
  • by aweihs