Agile - Argumentationswippe (Pro- und Kontra-Liste)

Gerade bei Retros im Team bzw einer größeren Gruppe werden Pro- und Kontra-Listen an einer Moderationswand gesammelt. Siehe auch zum Beispiel Siehe auch Agile - "Lifehack" Sammlung => Team-/Projekt Retrospektiven.

Eine digitale Alternative ist die Argumentationswippe (https://argumentationswippe.de). 

Die Retro-Teilnehmer sammeln ihre Argumente und können sie so auf die eine oder andere Seite der "Wippe" sortieren.

Agile - Wieso geht es ständig ums Feedback? Agiles Schiffe versenken!

In verschiedenen Beiträgen bin ich bereits auf das Thema "Warum eigentlich agil?" bzw. "Agile - "Lifehack" Sammlung Selbstmanagement und Kollaboration" eingegangen. Das Vorgehen ist natürlich in der Softwareentwicklung weit verbreitet, für Teams mit einem anderem beruflichen Kontext benötigt eine Umstellung jedoch viel Zeit.

Agiles Schiffe versenken als Antwort auf die Fragen:

• Wieso verändert sich ständig unser Ziel? 
• Wieso muss ich mich selbst organisieren? 
• Wieso reden wir ständig von Feedback?

 

Softwareentwickler Box UK hat eine Version "Schiffe versenken" entwickelt, bei der man im 1. Durchgang kein direktes Feeback zu möglichen Treffern erhählt. Im 2. Durchgang jedoch nach jedem Schuss eine Rückmeldung (ob Treffer oder nicht) bekommt.

In der anschließenden Statistik sieht man sofort, dass man mit direktem Feeback viel erfolgreicher ist!

Scrum - Sprint / Team Retrospektive

Die Sprint Retrospektive findet am Ende des Sprints statt. Hierbei überprüft das gesamte Scrum Team seine Arbeits- und Verhaltensweise während des Sprints, um im nächsten Sprint noch effektiver und effizienter arbeiten zu können.

Ablauf

• Es sollte eine angenehme Atmosphäre für das Team geschaffen werden,
• z.B. durch den Raum, der Umgebung und dem Zeitpunkt,
• jedes Teammitglied sollte Zeit für die Vorbereitung auf den Termin haben.
• Die Daten werden vom Scrum Master gesammelt (Erkenntnisse und Einsichten) und z.B. auf einem „Board“ festgehalten.
• Abschließend werden Aktionen und Verbesserungsmöglichkeiten daraus abgeleitet.

Beispiel

• Eine Pinnwand mit den Symbole: "Gewitter", "Regen", "Sonne".

Quelle: https://cdn.pixabay.com/photo/2013/07/12/12/53/weather-forecast-146472_1280.png

• Jeder im Team bekommt 3 Karten, für jede Kategorie eine und gibt Feedback zu den folgenden Fragen:
  
• Gewitter - Was hat mich im letzten Sprint wütend gemacht hat?
• Regen - Was hat mich im letzten Sprint traurig gemacht hat?
• Sonne - Was hat mich im letzten Sprint froh gemacht hat?
  

Eine nächste (Team) Retrospektive steht an und man hat keine Ideen für einen Ablauf? Dann kann ich die Seite https://retromat.org/de/ empfehlen. Hier kann man sich zufällig Ideen für eine Retro generieren lassen.

Why, How, What - The golden circle von Simon Sinek

Die Anforderungen werden bei Scrum nicht in Use Cases (Anwendungsfälle), sondern in User Stories erfasst. User Stories (Anwendererzählung) beschreiben GUIs, Funktionalitäten und Testszenarien.

Als „Anwender“ will ich „Eigenschaft/Feature“ Damit „Nutzen“.

Einen ähnlichen Ansatz verfolgt auch der "golden circle" von Simon Sinek.

In dem Buch Frag immer erst: warum: Wie Top-Firmen und Führungskräfte zum Erfolg inspirieren  beschreibt Sinek, dass die Menschen von einem Sinn für Ihre Absichten (dem "Warum") inspiriert sind. Daher sollte das WHY (Warum und wofür ist es wichtig?) bei der Anforderungsbeschreibung an erster Stelle stehen, bevor man mit dem "Wie" und "Was" in die Detaillierung geht.

Sinek nennt diese "Triade" den goldenen Kreis, beschrieben in einem Kreis-Diagramm mit

• "Why / Warum" im innersten Kreis, der die Motive oder Zwecke darstellt. Umgeben von einem Ring mit der Bezeichnung
• "How / Wie" hier werden die die Prozesse und Methoden dargestellt (Wie willst du dein Ziel erreichen?). Eingeschlossen mit der Bezeichnung
• "What / Was" welcher die Ergebnisse darstellt (Was machst du um dein Ziel zu erreichen?).

Quelle: Wikipedia (The golden circle diagram, redrawn from Start with Why - Mosborne01)

Warum eigentlich agil?

Das Scrum Manifest der agilen Softwareentwicklung definiert agile Methoden nach z.B. der Eigenschaft das sich Prozesse während der gesamten Projektzeit ständig weiterentwickeln und immer wieder neu bewertet müssen. Aber warum ist man überhaupt gezwungen agile Methoden zu verwenden?

Eine gute Antwort auf die Frage bietet mein Blog Eintrag vom April 2020  "Digitalisierung - The Six D's of Disruption". Mit Hilfe des Modells kann man verstehen, wie Technologien bzw. Digitalisierung uns beeinflussen.

In letzten Jahren kam es immer schneller zu einer "Demokratisierung" und Technologien sind immer schneller mehr und mehr Menschen zugänglich. Dies führt zu einem Verschwinden von alten Technologien bzw. kompletter Berufszweige. Die folgendene Grafik zeigt die Anzahl der Jahre, bis die aufgeführten Technologien eine Reichweite von 50 Millionen Nutzern erlangt hatten. So hatte Facebook bereits nach 3,5 Jahren 50 Millionen Nutzer. Das Telefon benötigt 75 Jahre für 100 Millionen Nutzer, das Fernsehen benötigte 13 Jahre und Candy Crush nur 1,3 Jahre bis es eine Nutzerschaft von 50 Millionen erreicht hatte.

Quelle: https://www.visualcapitalist.com/how-long-does-it-take-to-hit-50-million-users/

Definition Agilität

Schnelle Reaktions-(Adaptions-)fähigkeit in einer komplexen Welt. Siehe hierzu auch "Die Komplexität von Scrum bzw. eines Projektes kann durch die Stacey Matrix dargestellt werden".

Die Themen Unsicherheit und Komplexität könne auch gut durch das Akronym VUCA beschrieben werden, welches sich aus den vier Begriffen Volatilität (Unstet - schneller Wandel - Flüchtigkeit), Unsicherheit (Unberechenbarkeit - keine Strategien), Komplexität (Multioptionen -
Vernetzung - Schnelligkeit) und Ambiguität (Mehrdeutigkeit - Multifaktoriell - verwirrend) zusammensetzt.


AGILE => "Always run a changing system" anstatt "Never change a running system"!

Softwaretest bei agiler Entwicklung durch Testautomatisierung

Das Testen von Software bzw. eines fertigen Teilprodukts (Product Increment) ist ein fester  Bestandteil der agilen Softwareentwicklung und somit auch ein festes Element während eines Sprints.

Gerade bei Testfällen, die sehr oft wiederholt werden, ist eine Automatisierung sinnvoll (z.B. Regressionstests, testgetriebene Entwicklung oder schwer durchführbaren Tests). Viel zu oft wird gerade bei nicht automatisierten Tests die Anwendung nicht ausgiebig genug getestet.

Folgende Grundsätze sollten daher angewendet werden:

• So viel Testautomatisierung wie möglich, damit bei vielen neuen oder sich ändernde Anforderungen ein lauffähiges System gewährleistet wird. Darunter fallen Unit Tests, System- und Akzeptanztests.

• Die Rolle "Tester" innerhalb des Entwicklungsteam verteilen, damit die Zuständigkeit innerhalb des Entwicklerteams gleich ist. Keine strikte Trennung zwischen Entwickler und Tester aufbauen!

• Teststufen des V-Modells (Einordnung von Testzyklen) aufheben, da dies innerhalb eines Sprints nicht umsetzbar ist und einen zu hohen zeitlichen Aufwand bedeutet. Die einzelnen Teststufen (Komponententest, Integrationstest usw.) sollte als kleine Einheiten innerhalb der einzelne User-Stories integriert oder teilweise als einzelne User-Story je Sprint geplant werden

• Der finale Abnahmetest (User Acceptance Test) erfolgt jeweils am Ende eines Sprints durch den eigentlichen Auftraggeber oder Product Owner.

• Continuous Integration, der Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung, hat das Ziel zur Steigerung der Softwarequalität. Hier erfolgt ein Zusammenspiel von einem Versionsverwaltungssystem z.B. SVN oder GIT, einem Artifactory z.B. Nexus, automatisierter Tests (z.B. JUnit) und einem Tool (z.B. Jenkins ) zur Verwaltung der Continuous Integration (bauen von Pakten und deployen der Anwendung). Dieser Prozess wird z.B. automatisch durch Einchecken einer Codeänderung in das Versionsverwaltungssystem gestartet.

Scrum: Werte & Prinzipien

Time-Boxed:

• Für die einzelnen Scrum Meetings gibt es immer einen festen zeitlichen fokussierten Rahmen.
• Hierbei ist es besonders wichtig, dass die Meetings immer pünktlich beginnen und zu einem fest definierten Zeitpunkt aufhören.

Deliver early and regulary:

• Der Entwicklungsprozess soll sich vorwiegend auf die zu erreichenden Ziele fokussieren und auf Probleme eingehen, die während der Entwicklung auftreten können.
• Das Hauptziel ist, so schnell wie möglich, fertige Software an den Kunden ausliefern zu können.

Empowered, self-organized teams:

• Die Selbstorganisation ist unerlässlich, da im Sprint das Team „regiert“. Die Mitglieder des Teams bestimmen wie sie arbeiten wollen. => Dieses Prinzip sollte nicht von Führungskräften verletzt werden!
• Das Team benötigt Vertrauen vom Management.
• Gegenseitige Wertschätzung und gleichberechtigte Teammitglieder.
• Fokussierung durch gemeinsame Besprechung von Zielen und Vorgehensweisen

Transparency

• Regelmäßige Präsentation des Produkts (min. im Sprint Review Meeting)
• Das gesamte Team darf Feedback geben und neue User Stories erstellen und einsteuern, damit durch diese Wirkung eine Verbesserung des Produktes erfolgt.
• Transparenz des Projektfortschritts durch
• kleine Iterationen
• Vertrauen und Akzeptanz des Vorgehens nach Scrum
• Offenheit und Akzeptanz von Fehlern

Inspect and adapt

• Die Entwicklungsmethode soll sich an die Projektanforderungen anpassen können. Es wird damit eine stetige Verbesserung der Prozesse und Abläufe verfolgt. Das Ziel ist dabei einer Erhöhung der Effizienz und Verbesserung der Kunden- und Teamzufriedenheit.
• Fehler müssen erkannt werden und Annahmen korrigiert werden, damit eine Annäherung an das gewünschte Ergebnis erfolgt.
• Erfolgt kein Lerneffekt und ist das Ergebnis fehlerhaft, entsteht Unzufriedenheit beiderseits.
• Ist das Prinzip von Scrum bekannt und wird vom Entwicklungsteam gelebt, sind mehrere Iterationen notwendig um dies umzusetzen.
• Hierbei erfolgt eine stetige Kommunikation und Dokumentation mit dem Product Owner.

Scrum: Manifest der agilen Softwareentwicklung

• Eine agile Methode muss folgende Eigenschaften besitzen:

• Sie muss iterativ und inkrementell sein.
• Sie setzt auf das sich selbst organisierende Team, dabei bestimmt das Team selbst die beste Umsetzungsmethode.
• Die Prozesse werden während der gesamten Projektzeit ständig weiterentwickelt und immer wieder neu bewertet.

• Die Zusammenarbeit zwischen den betroffenen Personen ist wichtiger und geht vor einer starren Anwendung von Verfahren und Werkzeugen.
• Das Erreichen einer funktionsfähigen Software ist wichtiger als eine komplette und fehlerfreie Dokumentation des Softwareproduktes.
• Siehe auch http://agilemanifesto.org/

Stacey Matrix

• Die Komplexität von Scrum bzw. eines Projektes kann durch die Stacey Matrix dargestellt werden. (vgl. 1)
• Hierdurch wird die Komplexität analysiert und eingeordnet.
• Unscharfe Anforderungen und Unklarheit bei der Technologie, welche verwendet werden soll, bilden hierbei die Grundlage zur Einordnung.
• Gerade bei größeren IT-Projekten hält man sich oft im „komplexen“ bzw. unbekannten Bereich auf.

1) https://www.mittelstandswiki.de/wissen/Gastbeitrag:Agiles_Projektmanagement

Scrum: Rahmen (Werte)

Der Scrum Rahmen ist ein Zusammenspiel von der Organisation, dem Produkt und dem Team.

• Herkunft:
• „Toyota Production System“ als Vorbild (vgl.1)
•  „Schlankes Management“ (lean)
• Werte schaffen durch
• Kontinuierliche Verbesserung
• Ausrichtung auf den Kunden
• Stärkung der Teamarbeit
• Offene Information- und Feedback-Prozesse

1) https://de.wikipedia.org/wiki/Toyota-Produktionssystem

Certified ScrumMaster - Ablauf des Online-Examen

Da ich vor kurzem den Certified ScrumMaster erfolgreich absolviert habe, möchte ich den Ablauf der Online-Prüfung näher beschreiben.

Im Januar 2012 stellte die Scrum Alliance eine neue Version des Zertifizierungsprogramms für den ScrumMaster vor (Online-Examen). Damit man an diesem Test teilnehmen kann, muss man vorab an einer Certified ScrumMaster Schulung teilgenommen haben (zum Beispiel bei der wibas GmbH). Anschließend wird man für das Online-Examen bei der Scrum Alliance (www.scrumalliance.org) angemeldet.

Nun hat man innerhalb von 90 Tagen nach dem Kurs zwei Versuche um das Examens zu bestehen. Sollte ein bestehen in diesem Zeitraum nicht klappen, muss man für jeden weiteren Versuch 25 $ bezahlen.

Das Online-Examen beinhaltet 35 multiple-choice Fragen ohne Zeitbegrenzung, von denen man 24 oder mehr korrekt beantworten muss.

Beispielfragen für das Online-Examen

• Welche Herangehensweise an die Architektur empfehlen die Prinzipien hinter dem Agilen Manifest? - Antwort: Architektur entwickelt sich.

• Wann sollte das Release Burndown Chart aktualisiert werden? - Antwort: Nach jedem Sprint.

• Wie werden Teams während eines Sprints geführt? - Antwort: Durch ihr kollektives Wissen und ihre Erfahrung.

• Was ist ein HAUPTZWECK eines Sprint Backlogs? - Antwort: Für das Team: sich während des Sprints selbst zu steuern.

• Was ist eine zielführende Technik für den ScrumMaster, um eine Kommunikation zwischen dem Team und dem Product Owner zu ermöglichen? - Antwort: Alle diese Antworten (Den Product Owner über die während der Sprints angewandten Technologien unterrichten. ; Das Team unterrichten, sich im Hinblick auf die geschäftlichen Anforderungen und Ziele auszudrücken. ; Gemeinsame Besprechungen moderieren.)

Nach dem erfolgreichen Bestehen des Online-Examens kann das CSM-Zertifikat alle zwei Jahre erneuert werden.

Zur Vorbereitung empfehle ich folgende Literatur: Scrum - Agiles Projektmanagement erfolgreich einsetzen